Salah satu masalah besar dalam korupsi data aplikasi atau kesalahan manusia adalah bahwa penulisan yang melanggar ke primer akan segera direplikasi ke sekunder.
Ini adalah salah satu alasan mengapa pengguna memanfaatkan "slaveDelay" - opsi untuk menjalankan salah satu node sekunder Anda dengan waktu tunda yang tetap (tentu saja itu hanya membantu Anda jika Anda menemukan kesalahan atau bug selama periode waktu yang lebih pendek dari penundaan pada sekunder itu).
Jika Anda tidak memiliki pengaturan seperti itu, Anda harus mengandalkan cadangan untuk membuat ulang status rekaman yang perlu Anda pulihkan ke status pra-bug.
Lakukan semua operasi pada salinan terpisah dari data Anda - hanya setelah memverifikasi bahwa semuanya telah dibuat ulang dengan benar, Anda harus memindahkan data yang dikoreksi ke dalam sistem produksi Anda.
Apa yang diperlukan untuk dapat melakukan ini adalah salinan cadangan terbaru (misalkan cadangan berumur X jam) dan oplog di cluster Anda harus menyimpan data lebih dari X jam. Saya tidak menentukan oplog simpul mana karena (a) setiap anggota kumpulan replika memiliki konten yang sama di oplog dan (b) adalah kemungkinan ukuran oplog Anda berbeda pada anggota node yang berbeda, dalam hal ini Anda ingin memeriksa yang "terbesar".
Jadi katakanlah cadangan terbaru Anda berumur 52 jam, tapi untungnya Anda memiliki oplog yang menyimpan data senilai 75 jam (yay).
Anda telah menyadari bahwa semua node Anda (primer dan sekunder) memiliki data "buruk", jadi yang akan Anda lakukan adalah mengembalikan cadangan terbaru ini ke mongod baru. Di sinilah Anda akan memulihkan catatan ini ke keadaan semula sebelum pembaruan yang menyinggung - dan kemudian Anda bisa memindahkannya ke primer saat ini dari mana mereka akan direplikasi ke semua sekunder.
Saat memulihkan cadangan Anda, buat mongodump dari koleksi oplog Anda melalui perintah ini:
mongodump -d local -c oplog.rs -o oplogD
Pindahkan oplog ke direktorinya sendiri dengan mengganti namanya menjadi oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Sekarang Anda perlu menemukan operasi "menyinggung". Anda dapat membuang oplog ke bentuk yang dapat dibaca manusia, menggunakan bsondump perintah pada file oplogR/oplog.bson (dan kemudian gunakan grep atau apa-tidak untuk menemukan pembaruan "buruk"). Atau Anda dapat melakukan kueri terhadap oplog asli di set replika melalui use local dan db.oplog.rs.find() perintah di shell.
Tujuan Anda adalah menemukan entri ini dan mencatat ts-nya lapangan.
Mungkin terlihat seperti ini:
"ts" : Timestamp( 1361497305, 2789 )
Perhatikan bahwa mongorestore perintah memiliki dua opsi, satu disebut --oplogReplay dan yang lainnya disebut oplogLimit . Anda sekarang akan memutar ulang oplog ini di server berdiri sendiri yang dipulihkan TETAPI Anda akan berhenti sebelum operasi pembaruan yang menyinggung ini.
Perintahnya adalah (host dan port adalah tempat cadangan Anda yang baru dipulihkan):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
Ini akan memulihkan setiap operasi dari file oplog.bson di direktori oplogR yang berhenti tepat sebelum entri dengan nilai ts Timestamp(1361497305, 2789).
Ingatlah bahwa alasan Anda melakukan ini pada instance terpisah adalah agar Anda dapat memverifikasi pemulihan dan memutar ulang data yang benar yang dibuat - setelah Anda memverifikasinya, Anda dapat menulis catatan yang dipulihkan ke tempat yang sesuai di primer sebenarnya (dan memungkinkan replikasi menyebar catatan yang dikoreksi ke sekunder).
