Изменение и повторное использование MongoDB oplog

Можно ли изменить MongoDB oplog и воспроизвести его?

Ошибка привела к тому, что обновление было добавлено к большему количеству документов, чем предполагалось, перезаписав некоторые данные. Данные были восстановлены из резервной копии и реинтегрированы, поэтому ничего не было действительно потеряно, но мне было интересно, есть ли способ изменить oplog, чтобы удалить или изменить оскорбительное обновление и воспроизвести его.

У меня нет глубоких знаний о внутренних функциях MongoDB, поэтому информативные ответы по строкам "вы не понимаете, как это работает, это так" будет также рассмотрено для принятия.

Ответ 1

Одной из серьезных проблем при использвании данных приложений или человеческих ошибок является то, что оскорбительная запись первичной будет немедленно реплицирована на вторичную.

Это одна из причин, по которой пользователи используют "slaveDelay" - возможность запускать один из ваших вторичных узлов с фиксированной задержкой времени (конечно, это поможет вам, если вы обнаружите ошибку или ошибку в течение периода времени что короче задержки на этом вторичном).

Если у вас нет такой настройки, вы должны полагаться на резервную копию, чтобы воссоздать состояние записей, которые вам нужно восстановить, до состояния предварительной ошибки.

Выполняйте все операции на отдельной автономной копии ваших данных - только после проверки того, что все было правильно воссоздано, если вы затем переместите исправленные данные в свою производственную систему.

Для этого требуется последняя копия резервной копии (скажем, резервная копия составляет X часов), а oplog на вашем кластере должен хранить больше, чем на Х часов. Я не указывал, какой node oplog, потому что (a) каждый член набора реплик имеет то же самое содержимое в oplog и (b) возможно, что ваш размер oplog отличается от разных членов node, и в этом случае вы хотите проверить "самый большой".

Итак, скажем, ваша самая последняя резервная копия составляет 52 часа, но, к счастью, у вас есть oplog, который хранит данные на 75 часов (yay).

Вы уже поняли, что все ваши узлы (первичные и вторичные) имеют "плохие" данные, поэтому вы можете восстановить эту последнюю резервную копию в новый mongod. Здесь вы восстановите эти записи до того, что они были правы до оскорбительного обновления, а затем вы можете просто перенести их в текущую начальную, откуда они будут реплицироваться на все вторичные.

Во время восстановления резервной копии создайте mongodump вашей коллекции oplog с помощью этой команды:

mongodump -d local -c oplog.rs -o oplogD

Переместите oplog в свой собственный каталог, переименовав его в oplog.bson:

mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson

Теперь вам нужно найти операцию "оскорбление". Вы можете вывести oplog в понятную для человека форму, используя команду bsondump в файле oplogR/oplog.bson(а затем использовать grep или что-то не найти "плохое" обновление). В качестве альтернативы вы можете запросить исходный oplog в наборе реплик с помощью команд use local и db.oplog.rs.find() в оболочке.

Ваша цель - найти эту запись и отметить ее поле ts.

Это может выглядеть так:

"ts" : Timestamp( 1361497305, 2789 )

Обратите внимание, что команда mongorestore имеет два параметра, один из которых называется --oplogReplay, а другой - oplogLimit. Теперь вы воспроизведете этот oplog на восстановленном автономном сервере, но вы остановитесь перед этой операцией обновления.

Команда будет (хост и порт, где ваша вновь восстановленная резервная копия):

mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR

Это приведет к восстановлению каждой операции из файла oplog.bson в каталоге oplogR, останавливающемся прямо перед записью с ts значением Timestamp (1361497305, 2789).

Вспомните, что причина, по которой вы делали это в отдельном экземпляре, заключается в том, что вы можете проверить восстановление и воспроизведение созданных правильных данных - после того, как вы проверили его, вы можете записать восстановленные записи в соответствующее место в реальном первичном (и разрешить репликацию распространять скорректированные записи на вторичные).