Apa itu Replikasi Rantai?
Ketika kita berbicara tentang replikasi, kita mengacu pada proses membuat salinan data yang berlebihan untuk memenuhi kriteria desain pada ketersediaan data. Replikasi rantai, oleh karena itu, mengacu pada urutan linier server MongoDB untuk membentuk rantai yang disinkronkan. Rantai berisi simpul utama, digantikan oleh server sekunder yang disusun secara linier. Seperti yang disarankan oleh rantai kata, server yang paling dekat dengan server utama mereplikasi darinya sementara setiap server sekunder berikutnya mereplikasi dari server MongoDB sekunder sebelumnya. Ini adalah perbedaan utama antara replikasi berantai dan replikasi normal. Replikasi berantai terjadi ketika node sekunder memilih targetnya menggunakan waktu ping atau ketika node terdekat adalah node sekunder. Meskipun replikasi rantai seperti yang terlihat, mengurangi beban pada node utama, ini dapat menyebabkan jeda replikasi.
Mengapa Menggunakan Replikasi Rantai?
Infrastruktur sistem terkadang mengalami kegagalan yang tidak terduga yang menyebabkan hilangnya server dan karenanya memengaruhi ketersediaan. Replikasi memastikan bahwa kegagalan yang tidak terduga tidak memengaruhi ketersediaan. Replikasi lebih lanjut memungkinkan pemulihan dari kegagalan perangkat keras dan gangguan layanan. Replikasi berantai dan tidak berantai melayani tujuan ini untuk memastikan ketersediaan meskipun ada kegagalan sistem. Setelah menetapkan bahwa replikasi itu penting, Anda mungkin bertanya mengapa menggunakan replikasi berantai pada khususnya. Tidak ada perbedaan kinerja antara replikasi berantai dan tidak berantai di MongoDb. Dalam kedua kasus, ketika node utama gagal, server sekunder memilih primer baru yang bertindak dan oleh karena itu penulisan dan pembacaan data tidak terpengaruh dalam kedua kasus. Namun replikasi berantai adalah tipe replikasi default di MongoDb.
Cara Menyiapkan Replika Rantai
Secara default, replikasi berantai diaktifkan di MongoDB. Oleh karena itu kami akan menguraikan proses menonaktifkan replikasi rantai. Alasan utama mengapa replikasi rantai dapat dinonaktifkan adalah jika menyebabkan kelambatan. Kelebihan replikasi rantai bagaimanapun lebih unggul daripada kekurangan lag dan oleh karena itu dalam banyak kasus menonaktifkannya tidak diperlukan. Untuk berjaga-jaga jika replikasi rantai tidak aktif secara default, perintah berikut akan membantu Anda mengaktifkannya.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Proses ini reversibel. Ketika dipaksa untuk menonaktifkan replikasi berantai, proses berikut diikuti secara religius.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Tips &Trik untuk Replikasi Rantai
Keterbatasan replikasi rantai yang paling mengerikan adalah jeda replikasi. Replikasi lag mengacu pada penundaan yang terjadi antara waktu ketika operasi dilakukan pada primer dan ketika operasi yang sama direplikasi pada sekunder. Meskipun secara alami tidak mungkin, selalu diinginkan bahwa kecepatan replikasi menjadi sangat tinggi dalam lag replikasi adalah nol. Untuk menghindari atau meminimalkan jeda replikasi hingga mendekati nol, merupakan kriteria desain yang bijaksana untuk menggunakan host primer dan sekunder dengan spesifikasi yang sama dalam hal CPU, RAM, IO, dan spesifikasi terkait jaringan.
Meskipun replikasi rantai memastikan ketersediaan data, replikasi rantai dapat digunakan bersama dengan penjurnalan. Penjurnalan memberikan keamanan data dengan menulis ke log yang secara teratur di-flush ke disk. Ketika keduanya digabungkan, tiga server ditulis per permintaan tulis tidak seperti replikasi berantai saja di mana hanya dua server yang ditulis per permintaan tulis.
Tip penting lainnya adalah menggunakan w dengan replikasi. Parameter w mengontrol jumlah server tempat respons harus ditulis sebelum kembali sukses. Ketika parameter w disetel, getlasterror memeriksa oplog server dan menunggu hingga jumlah server 'w' yang diberikan memiliki operasi yang diterapkan.
Menggunakan alat pemantauan seperti MongoDB Monitoring Service (MMS) atau ClusterControl memungkinkan Anda memperoleh status node replika dan memvisualisasikan perubahan dari waktu ke waktu. Misalnya, di MMS, Anda dapat menemukan grafik jeda replika dari node sekunder yang menunjukkan variasi dalam jeda waktu replikasi.
Mengukur Kinerja Replikasi Rantai
Sekarang Anda menyadari bahwa parameter kinerja terpenting dari replikasi rantai adalah jeda waktu replikasi. Karena itu kami akan membahas cara menguji periode jeda replikasi. Tes ini dapat dilakukan melalui skrip shell MongoDb. Untuk melakukan uji jeda replikasi, kami membandingkan oplog kejadian terakhir pada node utama dan oplog kejadian terakhir pada node sekunder.
Untuk memeriksa informasi untuk node utama, kami menjalankan kode berikut.
db.printSlaveReplicationInfo()Perintah di atas akan memberikan informasi tentang semua operasi terbaru pada node utama. Hasilnya akan muncul seperti di bawah ini.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Setelah memperoleh oplog untuk primer, kami sekarang tertarik pada oplog untuk simpul sekunder. Perintah berikut akan membantu kita mendapatkan oplog.
db.printReplicationInfo()Perintah ini akan memberikan output dengan rincian tentang ukuran oplog, panjang log, waktu untuk acara pertama oplog, waktu untuk acara terakhir oplog dan waktu saat ini. Hasilnya muncul seperti di bawah ini.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)Dari oplog server utama, sinkronisasi terakhir terjadi pada Sel 05 Mar 2013 07:48:19 GMT-0800 (PST). Dari oplog server sekunder, operasi terakhir terjadi pada Sel 05 Mar 2013 07:48:19 GMT-0800 (PST). Replikasi lag adalah nol dan oleh karena itu sistem replika rantai kami beroperasi dengan benar. Namun, jeda waktu replikasi dapat bervariasi tergantung pada jumlah perubahan yang perlu direplikasi.
