Replikasi di MongoDB melibatkan set replika oleh anggota dengan arsitektur anggota primer dan sekunder tetapi kadang-kadang dengan anggota yang tidak membawa data yang disebut arbiter. Proses replikasi adalah bahwa, setiap kali data telah ditulis ke node utama, perubahan dicatat pada file oplog dari mana anggota sekunder menerapkan perubahan yang sama. Operasi baca dapat dilakukan dari setiap anggota bantalan data sehingga menciptakan skenario yang umumnya dikenal sebagai Ketersediaan Tinggi.
Namun, dalam beberapa kasus, anggota sekunder mungkin gagal mengejar yang utama dalam membuat perubahan dan jika simpul utama gagal sebelum perubahan ini diterapkan, seseorang akan dipaksa untuk menyinkronkan ulang seluruh klaster sehingga mereka dapat berada dalam status data yang sama.
Apa itu Rollback?
Ini adalah fitur failover otomatis di MongoDB di mana node utama dalam kumpulan replika mungkin gagal saat membuat perubahan yang sayangnya akhirnya tidak dicerminkan ke anggota sekunder tepat waktu dari oplog sehingga perlu mengembalikan keadaan utama ke satu sebelum perubahan dilakukan.
Oleh karena itu, rollback hanya diperlukan jika operasi utama telah diterima untuk menulis operasi yang belum direplikasi ke anggota sekunder sebelum langkah utama dihentikan karena beberapa alasan seperti partisi jaringan. Jika seandainya operasi tulis berhasil direplikasi di salah satu anggota yang tersedia dan dapat diakses oleh sebagian besar kumpulan replika, rollback tidak akan terjadi.
Alasan utama dibalik rollback di MongoDB adalah untuk menjaga konsistensi data untuk semua anggota dan oleh karena itu, ketika primer bergabung kembali dengan set replika, jika perubahannya belum diterapkan ke anggota sekunder, itu akan dikembalikan ke keadaan sebelum kegagalan.
Namun, rollback harus jarang terjadi atau sebaiknya dihindari di MongoDB karena dapat mengakibatkan banyak kehilangan data dan akibatnya memengaruhi pengoperasian aplikasi yang terhubung ke database.
Proses Rollback MongoDB
Mari kita pertimbangkan kumpulan replika tiga anggota dengan A sebagai anggota utama, B dan C sebagai anggota sekunder. Kami akan mengisi data ke A dan pada saat yang sama memicu beberapa partisi jaringan ke B dan C. Kami akan menggunakan MongoDB versi 4.2 dan Atlas dalam pengujian ini.
Pertama kita akan mendapatkan status set replika dengan menjalankan perintah rs.status() pada mongo shell
MongoDB Enterprise Cluster0-shard-0:PRIMARY> rs.status()Melihat atribut anggota, Anda dapat melihat sesuatu seperti
"members" : [
{
"_id" : 0,
"name" : "cluster0-shard-00-00-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891079,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:19.509Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:18.532Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 1,
"name" : "cluster0-shard-00-01-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891055,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:17.914Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:19.403Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 2,
"name" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1891089,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1592935644, 1),
"electionDate" : ISODate("2020-06-23T18:07:24Z"),
"configVersion" : 4,
"self" : true,
"lastHeartbeatMessage" : ""
}
],Ini akan menunjukkan status setiap anggota kumpulan replika Anda. Sekarang kita membuka terminal baru untuk node A dan mengisinya dengan 20000 record:
MongoDB Enterprise Cluster0-shard-0:PRIMARY> for (var y = 20000; y >= 0; y--) {
db.mytest.insert( { record : y } )
}
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest 2020-07-15T21:28:40.436+2128 I NETWORK [thread1] trying reconnect to 127.0.0.1:3001 (127.0.0.1) failed
2020-07-15T21:28:41.436+2128 I
NETWORK [thread1] reconnect 127.0.0.1:3001 (127.0.0.1) ok
MongoDB Enterprise Cluster0-shard-0:SECONDARY> rs.slaveOk()
MongoDB Enterprise Cluster0-shard-0:SECONDARY> db.mytest.count()
20000Selama partisi jaringan, A akan down sehingga tidak tersedia untuk B dan C dan karenanya B terpilih sebagai yang utama dalam kasus kami. Ketika A bergabung kembali, itu akan ditambahkan sebagai sekunder dan Anda dapat memeriksanya menggunakan perintah rs.status(). Namun, beberapa catatan berhasil direplikasi ke anggota B sebelum partisi jaringan seperti yang terlihat di bawah ini:(Ingat dalam hal ini B adalah yang utama sekarang)
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest.find({}).count()
12480 Angka adalah jumlah dokumen yang dapat direplikasi ke B sebelum A turun.
Jika kita menulis beberapa data ke B dan mengizinkan A untuk bergabung dengan jaringan, maka kita dapat melihat beberapa perubahan pada A
connecting to: 127.0.0.1:3001/admin
MongoDB Enterprise Cluster0-shard-0:ROLLBACK>
MongoDB Enterprise Cluster0-shard-0:RECOVERING>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:PRIMARY>Menggunakan anggota sekunder oplogFetcher menyinkronkan entri oplog dari syncSource mereka. oplogFetcher memicu metode find ke oplog sumber diikuti oleh serangkaian seri kursor getMores. Ketika A bergabung kembali sebagai sekunder, pendekatan yang sama diterapkan dan dokumen yang lebih besar dari stempel waktu predikat dikembalikan. Jika dokumen pertama di B tidak cocok dengan entri terakhir oplog A, A akan dipaksa melakukan rollback.
Memulihkan Data Rollback di MongoDB
Rollback bukanlah hal yang buruk di MongDB tetapi orang harus mencoba sebanyak mungkin untuk memastikan hal itu tidak sering terjadi. Ini adalah ukuran otomatis keamanan untuk memastikan konsistensi data antara anggota set replika. Jika terjadi rollback, berikut adalah beberapa langkah untuk mengatasi situasi tersebut:
Kembalikan Pengumpulan Data
Anda perlu mengumpulkan data anggota mengenai rollback. Hal ini dilakukan dengan memastikan file rollback dibuat (hanya tersedia dengan MongoDB versi 4.0) dengan mengaktifkan createRollbackDataFiles. Secara default opsi ini disetel ke true maka file rollback akan selalu dibuat.
File rollback ditempatkan di jalur
Memuat Data File Rollback di Database atau Server Terpisah
Mongorestore adalah aspek penting dari MongoDB yang dapat membantu mengaktifkan pemulihan file data rollback. Hal pertama adalah menyalin file rollback ke server baru kemudian menggunakan mongorestore memuat file ke server Anda. Perintah mongorestore ditunjukkan di bawah ini.
mongorestore -u <> -p <> -h 127.0.0.1 -d <rollbackrestoretestdb> -c <rollbackrestoretestc> <path to the .bson file> --authenticationDatabase=<database of user>Membersihkan Data yang Tidak Diperlukan dan Memilah Data
Langkah ini memerlukan kebijaksanaan untuk memilih antara data yang akan disimpan dari file rollback dan data yang akan dibuang. Dianjurkan untuk mengimpor semua data file rollback, titik keputusan ini membuat langkah ini menjadi langkah tersulit dalam pemulihan data.
Menggunakan Utama sebagai Cluster untuk Mengimpor Data
Mulai langkah terakhir dengan mendownload data yang telah dibersihkan melalui penggunaan mongorestore dan mongodump, ikuti langkah ini dengan mengimpor kembali data ke dalam cluster produksi asli.
Mencegah Rollback MongoDB
Untuk mencegah terjadinya rollback data saat menggunakan MongoDB, seseorang dapat melakukan hal berikut.
Menjalankan Semua Anggota Voting 'MAJORITY'
Hal ini dapat dilakukan dengan menggunakan w:mayority write concern yang memiliki kekuatan untuk opsi permintaan pengakuan yang akan memungkinkan operasi tulis ke tag tertentu dari instance Mongod. Ini dapat dicapai dengan menggunakan opsi w diikuti dengan tag
Operasi Pengguna
Versi MongoDB yang diperbarui, yaitu versi 4.2 memiliki kemampuan untuk mematikan semua operasi yang sedang berlangsung jika terjadi rollback.
Pembuatan Indeks
Versi 4.2 dari versi kompatibilitas fitur MongoDB (fcv) "4.2" mampu menunggu semua indeks dalam proses yang sedang dibangun dan diselesaikan sebelum rollback dilakukan tempat. Namun, versi 4.0 menunggu proses yang berkelanjutan dan membangun indeks latar belakang sehingga kemungkinan rollback tinggi.
Ukuran dan Batasan
MongoDB versi 4.0 tidak mencantumkan batasan data tertentu yang dapat dibatalkan saat indeks latar belakang sedang dibuat.
Kesimpulan
Rollback MongoDB adalah fenomena umum bagi mereka yang menggunakan MongoDB tanpa mengetahui cara mencegahnya. Rollback dapat dicegah jika seseorang mengikuti dan mematuhi beberapa praktik aman dan cara menghindari rollback di MongoDB. Secara keseluruhan, selalu disarankan untuk meningkatkan versi MongoDB ke versi terbaru untuk menghindari beberapa gangguan yang dapat dicegah.
