Masalahnya (kemungkinan besar)
Operasi terakhir pada primer adalah dari "2015-05-15T02:10:56Z", sedangkan operasi terakhir dari operasi sekunder adalah dari "2015-05-14T11:23:51Z", yang merupakan perbedaan kira-kira 15 jam. Jendela itu mungkin melebihi jendela oplog replikasi Anda (perbedaan antara waktu entri operasi pertama dan terakhir di oplog Anda). Sederhananya, ada terlalu banyak operasi pada operasi primer untuk diikuti oleh operasi sekunder.
Sedikit lebih rumit (meskipun disederhanakan):selama sinkronisasi awal, data dari sinkronisasi sekunder adalah data dari titik waktu tertentu. Ketika data pada titik waktu itu disinkronkan, sekunder terhubung ke oplog dan menerapkan perubahan yang dibuat antara titik waktu tersebut dan sekarang sesuai dengan entri oplog. Ini bekerja dengan baik selama oplog memegang semua operasi antara titik waktu yang disebutkan. Tetapi oplog memiliki ukuran terbatas (ini disebut koleksi yang dibatasi
). Jadi, jika ada lebih banyak operasi yang terjadi pada primer daripada yang dapat ditahan oleh oplog selama sinkronisasi awal, operasi terlama akan "menghilang". Sekunder mengakui bahwa tidak semua operasi tersedia yang diperlukan untuk "membangun" data yang sama dengan yang utama dan menolak untuk menyelesaikan sinkronisasi, tetap berada di RECOVERY modus.
Solusinya
Masalahnya adalah masalah yang diketahui dan bukan bug, tetapi hasil dari cara kerja MongoDB dan beberapa asumsi gagal-aman yang dibuat oleh tim pengembangan. Oleh karena itu, ada beberapa cara untuk menghadapi situasi tersebut. Sayangnya, karena Anda hanya memiliki dua node bantalan data, semuanya melibatkan waktu henti.
Opsi 1:Tingkatkan ukuran oplog
Ini adalah metode pilihan saya, karena ini menangani masalah sekali dan (semacam) untuk semua. Ini sedikit lebih rumit daripada solusi lain. Dari perspektif tingkat tinggi, inilah langkah-langkah yang Anda ambil.
- Matikan utama
- Buat cadangan oplog menggunakan akses langsung ke file data
- Mulai ulang
mongoddalam mode mandiri - Salin oplog saat ini ke koleksi sementara
- Hapus oplog saat ini
- Buat ulang oplog dengan ukuran yang diinginkan
- Salin kembali entri oplog dari koleksi sementara ke oplog baru yang mengkilap
- Mulai ulang
mongodsebagai bagian dari set replika
Jangan lupa untuk meningkatkan oplog sekunder sebelum melakukan sinkronisasi awal, karena mungkin akan menjadi primer suatu saat nanti!
Untuk detailnya, silakan baca "Mengubah ukuran oplog" dalam tutorial tentang pemeliharaan set replika .
Opsi 2:Matikan aplikasi selama sinkronisasi
Jika opsi 1 tidak dapat dijalankan, satu-satunya solusi nyata lainnya adalah mematikan aplikasi yang menyebabkan beban pada set replika, memulai ulang sinkronisasi dan menunggu hingga selesai. Tergantung pada jumlah data yang akan ditransfer, hitung dengan beberapa jam.
Catatan pribadi
Masalah jendela oplog adalah salah satu yang terkenal. Meskipun set replika dan sharded cluster mudah diatur dengan MongoDB, diperlukan beberapa pengetahuan dan sedikit pengalaman untuk memeliharanya dengan benar. Jangan menjalankan sesuatu yang penting seperti database dengan pengaturan yang rumit tanpa mengetahui dasar-dasarnya - jika terjadi Sesuatu yang Buruk (tm), itu mungkin mengarah pada situasi FUBAR.
