Um dos grandes problemas na corrupção de dados de erro humano ou de aplicativos é que a gravação incorreta no primário será imediatamente replicada no secundário.
Esta é uma das razões pelas quais os usuários aproveitam o "slaveDelay" - uma opção para executar um de seus nós secundários com um atraso fixo (é claro que isso só ajuda se você descobrir o erro ou bug durante o período de tempo menor que o atraso nesse secundário).
Caso você não tenha essa configuração, você precisa contar com um backup para recriar o estado dos registros que você precisa restaurar para o estado anterior ao bug.
Execute todas as operações em uma cópia independente separada de seus dados - somente após verificar se tudo foi recriado corretamente, você deve mover os dados corrigidos para seu sistema de produção.
O que é necessário para poder fazer isso é uma cópia recente do backup (digamos que o backup tenha X horas) e o oplog em seu cluster deve conter mais de X horas de dados. Eu não especifiquei o oplog de qual nó porque (a) cada membro do conjunto de réplicas tem o mesmo conteúdo no oplog e (b) ele é possível que o tamanho do seu oplog seja diferente em diferentes membros do nó; nesse caso, você deseja verificar o "maior".
Então, digamos que seu backup mais recente tenha 52 horas, mas felizmente você tem um oplog que contém 75 horas de dados (yay).
Você já percebeu que todos os seus nós (primários e secundários) têm os dados "ruins", então o que você faria é restaurar esse backup mais recente em um novo mongod. É aqui que você restaurará esses registros para o que eles estavam antes da atualização incorreta - e então você pode simplesmente movê-los para o primário atual de onde eles serão replicados para todos os secundários.
Ao restaurar seu backup, crie um mongodump de sua coleção de oplogs por meio deste comando:
mongodump -d local -c oplog.rs -o oplogD Mova o oplog para seu próprio diretório renomeando-o para oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Agora você precisa encontrar a operação "ofensiva". Você pode despejar o oplog para um formato legível, usando o
bsondump comando no arquivo oplogR/oplog.bson (e então use grep ou what-not para encontrar a atualização "ruim"). Alternativamente, você pode consultar o oplog original no conjunto de réplicas via use local e db.oplog.rs.find() comandos no shell. Seu objetivo é encontrar esta entrada e anotar seu
ts campo. Pode parecer assim:
"ts" : Timestamp( 1361497305, 2789 ) Observe que o
mongorestore O comando tem duas opções, uma chamada --oplogReplay e o outro chamado oplogLimit . Agora você irá reproduzir este oplog no servidor autônomo restaurado, MAS você irá parar antes desta operação de atualização ofensiva. O comando seria (host e porta são onde seu backup recém-restaurado está):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR Isso restaurará cada operação do arquivo oplog.bson no diretório oplogR parando logo antes da entrada com o valor ts Timestamp(1361497305, 2789).
Lembre-se de que a razão pela qual você estava fazendo isso em uma instância separada é para que você possa verificar a restauração e a reprodução dos dados criados corretamente - uma vez verificado, você pode gravar os registros restaurados no local apropriado no primário real (e permitir que a replicação se propague os registros corrigidos para os secundários).
