Един от големите проблеми при повреда на данните за приложения или човешка грешка е, че нарушителната запис на първичния елемент веднага ще бъде репликиран на вторичния.
Това е една от причините, поради които потребителите се възползват от „slaveDelay“ – опция за стартиране на един от вашите вторични възли с фиксирано време закъснение (разбира се, това ви помага само ако откриете грешката или грешката през периода от време, който е по-кратък от забавянето на този вторичен елемент).
В случай, че нямате такава настройка, трябва да разчитате на резервно копие, за да пресъздадете състоянието на записите, които трябва да възстановите до състоянието им преди грешка.
Извършете всички операции върху отделно самостоятелно копие на вашите данни - само след като се уверите, че всичко е правилно пресъздадено, трябва да преместите коригираните данни във вашата производствена система.
Това, което е необходимо, за да можете да направите това, е скорошно копие на архива (да кажем, че архивът е на X часа) и oplog на вашия клъстер трябва да съдържа повече от X часа данни. Не посочих oplog на кой възел, защото (a) всеки член на набора от реплика има същото съдържание в oplog и (b) е възможно е размерът на вашия oplog да е различен за различните членове на възела, в който случай искате да проверите „най-големия“.
Така че да приемем, че последното ви архивиране е на 52 часа, но за щастие имате oplog, който съдържа данни на стойност 75 часа (ууу).
Вече разбрахте, че всичките ви възли (първични и вторични) имат "лоши" данни, така че това, което бихте направили, е да възстановите това последно архивно копие в нов 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 или what-not, за да намерите "лошата" актуализация). Като алтернатива можете да направите заявка срещу оригиналния 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).
Припомнете си, че причината да правите това на отделен екземпляр е, за да можете да проверите създадените за възстановяване и повторно възпроизвеждане правилни данни - след като ги проверите, тогава можете да запишете възстановените записи на подходящото място в реалния първичен (и да разрешите разпространението на репликация коригираните записи към второстепенните).
