Panduan Pengembang untuk Kumpulan Replika MongoDB

MongoDB sering kali melibatkan kerja dengan sekumpulan besar data termasuk array yang disematkan dan objek array. Oleh karena itu, selalu penting untuk memastikan kecepatan pemrosesan database Anda secepat mungkin untuk meningkatkan operasi baca dan tulis. Selain itu, untuk menghindari anomali data yang mungkin timbul karena inkonsistensi data, Anda perlu memastikan ketersediaan data Anda meningkat untuk berjaga-jaga jika Anda ingin mendapatkan pemulihan dari peristiwa kegagalan perangkat keras atau beberapa gangguan layanan. MongoDB menyediakan beberapa 2 konsep untuk tujuan itu - ReplicaSets dan Sharding.

Replikasi di MongoDB

Replikasi Master-Slave

Ini adalah salah satu teknik tertua yang digunakan untuk memastikan data selalu tersedia bagi pengguna bahkan ketika satu sistem gagal. Namun, replikasi Master-Slave tidak digunakan lagi di versi terbaru MongoDB mulai dari 3.2 dan dengan demikian diganti dengan kumpulan Replika.

Untuk membuat konfigurasi ini, seseorang memulai 2 instance mongod sambil mempertimbangkan satu dalam mode master dan yang lainnya adalah mode budak.

Untuk memulai instance dalam mode master, jalankan:

mongod --master --port portNumber

Opsi --master menginstruksikan mongod untuk membuat koleksi local.oplog.$main dengan daftar operasi yang diantrekan untuk diterapkan oleh slave dalam mereplikasi data.

Untuk memulai instance mongod dalam mode budak, jalankan saja:

mongod --slave --source <masterhostname><:<port>>

Di sini Anda perlu menentukan nama host dan port instance master ke argumen --source. Ini adalah ringkasan ikhtisar menggunakan replikasi slave Master dan karena tidak digunakan lagi, perhatian kami akan tertuju pada kumpulan Replika.

Set Replika

Ini adalah sekelompok proses MongoDB yang dikenal sebagai instance mongod yang pada dasarnya meng-host kumpulan data yang sama. Ini ditampilkan oleh satu simpul utama dan beberapa simpul sekunder untuk memuat data. Node utama menerima semua operasi tulis dan mencatat semua perubahan lain pada kumpulan datanya dalam log operasinya. Node sekunder, di ujung lain, mereplikasi log operasi utama dan menerapkan operasi ke kumpulan data mereka sehingga kumpulan data mereka mencerminkan kumpulan data primer. Dengan kata sederhana, kita dapat mengatakan bahwa kita memiliki mesin A sebagai node utama dan mesin B dan C sebagai node sekunder. Mesin A menerima operasi tulis dan membuat perubahan pada datanya dan kemudian membuat daftar perubahan yang telah dibuat. Mesin B dan C kemudian akan menyalin operasi dari daftar yang disediakan, dalam hal ini oplog, dan menjalankannya sehingga data yang dihasilkan sama seperti di Mesin A.

Seperti disebutkan sebelumnya, selalu penting untuk memastikan ketersediaan data yang tinggi, terutama dalam pengaturan produksi. Replikasi datang untuk membantu dengan menyediakan redundansi data dalam instance Mongod yang berbeda. Dalam kasus kehilangan data, karena salinan data yang sama disimpan di database yang berbeda di beberapa lokasi, mudah untuk memulihkannya di yang sudah ada.

Dengan banyak instance yang berjalan, operasi baca dan tulis dari klien dikirim ke server yang berbeda dan oleh karena itu kecepatan pemrosesan meningkat. Struktur dasar dari proses replikasi ditunjukkan di bawah ini.

Terkadang yang utama mungkin tidak tersedia misalnya karena pemutusan koneksi internet atau gangguan layanan. Dalam hal ini, set replika akan menominasikan sekunder untuk menjadi simpul utama. Sebanyak permintaan baca pada dasarnya dibuat ke primer, beberapa kesempatan permintaan baca dapat dikirim ke sekunder tetapi hati-hati karena data yang dikembalikan mungkin tidak mencerminkan apa yang ada di primer atau lebih tepatnya data mungkin tidak mutakhir.

Arbiter

Dalam hal pemilihan primer, Anda akan memerlukan instance mongod tambahan ke set replika untuk menambahkan suara dalam proses pemilihan. Instansi ini disebut sebagai arbiter dan fitur-fiturnya yang menonjol adalah:

1. Tidak memiliki salinan set data, sehingga tidak memerlukan perangkat keras yang kuat seperti node bantalan data..
2. Tidak dapat dipromosikan menjadi yang utama.
3. Mereka selalu memiliki 1 suara elektoral sehingga memungkinkan set replika memiliki jumlah anggota voting yang tidak merata tanpa biaya tambahan dari anggota tambahan yang mereplikasi data. Oleh karena itu, peran pentingnya adalah memilih node utama saat tidak tersedia.
4. Tetap tidak berubah.

Berlawanan dengan arbiter, set replika lainnya dapat diubah menjadi primer dari sekunder dan sebaliknya.

Replikasi Asinkron

Proses replikasi berlangsung dalam dua bentuk sinkronisasi data. Pertama, anggota dalam kumpulan diisi dengan data lengkap dalam sinkronisasi awal. Replikasi berikutnya dilakukan untuk menerapkan perubahan lanjutan ke seluruh kumpulan data.

Dalam sinkronisasi awal, data disalin dari satu anggota kumpulan replika ke yang lain. Ketika proses selesai, anggota bertransisi ke node sekunder.

Kegagalan Otomatis MongoDB

Mungkin ada gangguan layanan seperti pemutusan jaringan yang datang dengan konsekuensi pemutusan komunikasi antara primer dan sekunder. Jika pemutusan lebih dari 10 detik atau gagal sepenuhnya, kumpulan replika yang tersisa akan memilih anggota untuk menjadi anggota utama baru. Node sekunder yang mendapat mayoritas suara menjadi primer baru.

Di MongoDB versi 3.0, satu set replika dapat memiliki hingga 50 anggota dengan 7 anggota voting.

Anggota Set Replika Nol Prioritas

Ini adalah anggota sekunder yang tidak dapat transit menjadi node utama dan juga tidak dapat memicu pemilihan. Ada peran penting dalam kumpulan data adalah untuk:memelihara salinan kumpulan data, memilih node utama dan melakukan operasi baca. Mereka bertindak seperti cadangan di mana anggota baru mungkin gagal untuk segera ditambahkan. Dengan demikian akan menyimpan data yang diperbarui dan dapat segera menggantikan anggota yang tidak tersedia.

Anggota Kumpulan Replika Tersembunyi MongoDB

Ini adalah anggota tanpa koneksi ke aplikasi klien. Mereka digunakan untuk beban kerja dengan persyaratan penggunaan yang berbeda dari anggota sekunder lainnya. Mereka hanya menerima lalu lintas replikasi dasar selama sinkronisasi awal.

Anggota Kumpulan Replika Tertunda MongoDB

Ini menyalin data dari file oplog node utama dalam beberapa durasi yang ditentukan. Mereka selalu mencerminkan keadaan tertunda atau bentuk himpunan sebelumnya. Oleh karena itu mereka penting dalam mendeteksi kesalahan dan memberikan petunjuk tentang bagaimana seseorang dapat pulih dari kesalahan tersebut, misalnya jika ada database yang telah dijatuhkan. Saat memilih jumlah penundaan, ini harus dipertimbangkan:

1. Durasi harus kurang dari kapasitas log operasi, yang untuk mesin penyimpanan WiredTiger, MMAPv1 dan In-Memory adalah 50 GB. Jika tidak, anggota yang tertunda tidak dapat berhasil mereplikasi operasi.
2. Durasi penundaan harus sama atau sedikit lebih besar dari durasi periode pemeliharaan yang Anda harapkan.

Konfigurasi

Ini adalah anggota nol prioritas, disembunyikan sehingga tidak terlihat oleh aplikasi dan terakhir dapat berpartisipasi dalam proses pemilihan. Oleh karena itu untuk mengonfigurasi prioritas, katakanlah Anda memiliki 10 anggota dalam kumpulan replika Anda, Anda dapat memilih anggota di posisi n sebagai anggota[n] dan mengatur propertinya sebagai:

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
} 

Atau menggunakan mongo shell yang terhubung ke primer, Anda dapat menjalankan perintah ini untuk menyetel anggota pertama dari replika yang ditetapkan sebagai penundaan:

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

Setelah mengatur konfigurasi ini, sekunder tertunda tidak dapat menjadi primer dan karena itu tersembunyi dari aplikasi. Anggota akan tertunda 1 jam (3600 detik) dari operasi oplog.

Bagaimana Memulai Set Replika

Dalam panduan ini, kita akan melihat langkah demi langkah bagaimana kita dapat mengonfigurasi set replika di MongoDB.

1. Misalnya Anda memiliki 3 mongodb yang ingin Anda tiru dan dikonfigurasi sebagai berikut:
   1. Mongod1.conf berjalan pada port 27017
   2. Mongod2.conf berjalan pada port 27018
   3. Mongod3.conf berjalan pada port 27019

   Pastikan untuk menambahkan nama set replika yang tidak akan berubah di setiap file. Anda dapat melakukannya dengan menambahkan atau mengubah nilai replSet pilihan menjadi nama pilihan Anda.

2. Kita dapat memulai instance pertama dengan menjalankan

   sudo mongod --config /etc/mongo/mongod1.conf

   Ini jika, Anda tidak memiliki instance yang menjalankan mongod. Kemudian lakukan hal yang sama untuk contoh lainnya. Untuk memeriksa instance yang sedang berjalan di mesin Anda, jalankan

   ps -ax | grep mongo

   Anda akan mendapatkan beberapa daftar seperti ini:

   4328 ttys000    0:06.15 mongod
   4950 ttys001    0:00.00 grep mongo

   Ini berarti instance pertama di MongoDB secara default berjalan pada port 27017 sehingga kami memilikinya sebagai yang pertama dalam daftar. Jika Anda memulai yang lain, mereka juga akan diuraikan dalam daftar dengan url jalur yang sesuai. Untuk terhubung ke instance di mongo shell, jalankan perintah ini:

   mongo  --port port_number i.e mongo  --port 27017.

   Namun dalam kasus kami, kami perlu terhubung dengan nama set replika sehingga kami harus menambahkan nama itu ke perintah:

   mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017

   Dalam hal ini replicaSetName =“testrep”

3. Mari kita periksa apakah ada set replika yang diaktifkan dengan menjalankan rs.status()

   Jika Anda mendapatkan hasil seperti:

   {
       "ok" : 0,
       "errmsg" : "not running with --replSet",
       "code" : 76,
       "codeName" : "NoReplicationEnabled"
   }

   Maka itu berarti tidak ada set replika yang diaktifkan. Lain jika Anda mendapatkan hasilnya sebagai

   {
       "operationTime" : Timestamp(0, 0),
       "ok" : 0,
       "errmsg" : "no replset config has been received",
       "code" : 94,
       "codeName" : "NotYetInitialized",
       "$clusterTime" : {
           "clusterTime" : Timestamp(0, 0),
           "signature" : {
               "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
               "keyId" : NumberLong(0)
           }
       }
   }

   maka itu berarti replika belum dimulai.

4. Metode rs.initiate() akan membantu kita memulai set replika baru dan instance di mana ia dimulai menjadi node utama kita. Jadi kita bisa memulainya di instance kita dengan menjalankan metode inisiasi. rs.initiate().

5. Periksa kembali status kumpulan replika dengan menjalankan rs.status().members. Anda sekarang akan melihat sesuatu seperti

   "members" : [
           {
               "_id" : 0,
               "name" : "localhost:27018",
               "health" : 1,
               "state" : 1,
               "stateStr" : "PRIMARY",
               "uptime" : 577,
               "optime" : {
                   "ts" : Timestamp(1535301271, 1),
                   "t" : NumberLong(1)
               },
               "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
               "syncingTo" : "",
               "syncSourceHost" : "",
               "syncSourceId" : -1,
               "infoMessage" : "could not find member to sync from",
               "electionTime" : Timestamp(1535301265, 1),
               "electionDate" : ISODate("2018-08-26T16:34:25Z"),
               "configVersion" : 1,
               "self" : true,
               "lastHeartbeatMessage" : ""
           }
       ]

   Baik untuk pergi. Minat kami akan menjadi opsi anggota, seperti yang dapat kita lihat adalah n array dengan 1 anggota di dalamnya. Memeriksa opsi stateStr anggota pertama dalam hal ini disetel ke Utama yang berarti ini akan bertindak sebagai simpul utama kami.

6. Tambahkan anggota baru ke set replika menggunakan nama hostnya. Untuk memeriksa nama host dari instance yang terhubung, Anda ingin menambahkan run

   db.serverStatus().host

   Anda akan mendapatkan sesuatu seperti

   ervername.local:27019

   Jadi dari PRIMARY Anda dapat menambahkan anggota lain dengan menjalankan perintah ini di shell mongo:

   rs.add("servername.local:27019");

7. Jalankan perintah status

   rs.status().members

   Untuk memeriksa apakah perubahan telah dilakukan.

   Anda sekarang harus memiliki sesuatu yang terlihat seperti ini:

   [
       {
           "_id" : 0,
           "name" : "localhost:27018",
           "health" : 1,
           "state" : 1,
           "stateStr" : "PRIMARY",
           "uptime" : 11479,
           "optime" : {
               "ts" : Timestamp(1535312183, 1),
               "t" : NumberLong(1)
           },
           "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
           "syncingTo" : "",
           "syncSourceHost" : "",
           "syncSourceId" : -1,
           "infoMessage" : "",
           "electionTime" : Timestamp(1535301265, 1),
           "electionDate" : ISODate("2018-08-26T16:34:25Z"),
           "configVersion" : 2,
           "self" : true,
           "lastHeartbeatMessage" : ""
       },
       {
           "_id" : 1,
           "name" : "127.0.0.1:27019",
           "health" : 1,
           "state" : 2,
           "stateStr" : "SECONDARY",
           "uptime" : 15,
           "optime" : {
               "ts" : Timestamp(1535312183, 1),
               "t" : NumberLong(1)
           },
           "optimeDurable" : {
               "ts" : Timestamp(1535312183, 1),
               "t" : NumberLong(1)
           },
           "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
           "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
           "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
           "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
           "pingMs" : NumberLong(0),
           "lastHeartbeatMessage" : "",
           "syncingTo" : "localhost:27018",
           "syncSourceHost" : "localhost:27018",
           "syncSourceId" : 0,
           "infoMessage" : "",
           "configVersion" : 2
       }
   ]

   Kami sekarang memiliki 2 anggota, satu adalah simpul UTAMA dan yang lainnya adalah simpul SEKUNDER. Anda dapat menambahkan lebih banyak anggota tetapi tidak melebihi 50. Sekarang mari kita buat database pada instance di port 27018 sebagai yang utama.

   

   Jika kita memutuskan sambungan primer, failover akan terjadi dan karena kita hanya memiliki 1 primer, maka secara otomatis akan dialihkan ke sekunder. Sekarang jika kita terhubung ke yang ada di port 27019, Anda akan mendapatkan database dan koleksi yang sama dengan dokumen mereka.

   

   Sekarang jika simpul utama yang terputus disambungkan kembali, simpul tersebut akan ditambahkan sebagai simpul sekunder karena ia menyalin operasi dari oplog primer yang ada.

Set Replika MongoDB Kekhawatiran Tulis

Jika MongoDB mengembalikan masalah penulisan jurnal yang berhasil, data akan disimpan ke disk sehingga tersedia setelah mongod dimulai ulang. Namun, untuk operasi penulisan, data hanya tahan lama setelah direplikasi dan dikomit ke jurnal yang didukung oleh mayoritas anggota voting dari kumpulan replika.

Beberapa data mungkin terlalu besar untuk diperbarui atau disisipkan, oleh karena itu mungkin perlu waktu lebih lama dari yang diharapkan agar data dapat direplikasi di anggota lain. Untuk alasan ini, disarankan untuk mengedit konfigurasi writeConcern untuk memenuhi durasi di mana operasi akan dijalankan. Konfigurasi writeConcern default menentukan bahwa set replika memerlukan pengakuan hanya dari anggota utama. Masalah penulisan default mengonfirmasi operasi penulisan untuk yang utama saja tetapi dapat diganti untuk memeriksa operasi penulisan pada beberapa anggota kumpulan replika dengan menentukan masalah penulisan untuk operasi penulisan tertentu. Misalnya:

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

Opsi tulis dalam kasus ini menyatakan bahwa operasi harus mengembalikan respons hanya setelah respons menyebar ke primer dan setidaknya 2 sekunder atau jika waktu habis setelah 3,6 detik.

Mengonfigurasi Kekhawatiran Tulis untuk MongoDB

Opsi MongoDB getLastErrorDefaults memberi kita parameter untuk mengubah pengaturan default perhatian penulisan dalam konfigurasi set replika. Ini menyiratkan bahwa operasi harus diselesaikan di sebagian besar anggota pemungutan suara sebelum mengembalikan hasilnya.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

Nilai batas waktu akan mencegah operasi penulisan pemblokiran yaitu, jika seharusnya ada 5 anggota yang mengakui masalah penulisan tetapi sayangnya ada 4 atau kurang anggota dalam kumpulan replika, operasi akan memblokir sampai semua anggota tersedia. Dengan menambahkan ambang batas waktu, pemblokiran operasi akan dihapus setelah durasi ini.

Pemblokiran Replikasi

Memblokir operasi terutama ketika semua anggota telah direplikasi memastikan tidak ada lagi waktu yang terbuang untuk menunggu anggota kumpulan replika lain tersedia untuk mengembalikan respons. Opsi perintah MongoDB getLastError menentukan bagaimana pembaruan replikasi dilakukan menggunakan atribut "w" opsional.

Misalnya, kueri ini

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

mensyaratkan bahwa pemblokiran akan terjadi sampai N jumlah anggota telah mereplikasi operasi tulis terakhir. Jika N tersedia atau kurang dari 2, kueri akan dikembalikan. Lain jika nilai untuk N sama dengan 2, master setara dengan primer, akan merespon hanya setelah 1 dari budaknya telah direplikasi ke operasi terakhir.

waktu habis parameter pada dasarnya adalah untuk mengatur waktu dalam milidetik setelah perintah getLastError akan habis waktu dan mengembalikan kesalahan sebelum opsi terakhir direplikasi.

Sebanyak pemblokiran entah bagaimana menguntungkan, terkadang memiliki batasan. Ini secara signifikan memperlambat operasi baca terutama jika Anda mengatur nilai "w" menjadi terlalu besar. Saya sarankan Anda menyetel nilai “w” ke 2 atau 3 untuk meningkatkan keamanan dan efisiensi.

Preferensi Baca di MongoDB

Ini pada dasarnya adalah rute yang berdekatan dengan operasi pembacaan klien yang dibuat ke set replika. Pengaturan MongoDB default mengonfigurasi operasi baca ke operasi utama karena ini adalah operasi dengan versi terbaru dari dokumen yang Anda ambil. Seperti disebutkan sebelumnya, keuntungan tertinggi untuk mengeksploitasi set replika adalah untuk meningkatkan kinerja sistem database kami. Oleh karena itu, disarankan untuk mendistribusikan operasi baca ke banyak anggota sekunder untuk mengurangi latensi untuk aplikasi yang tidak selalu memerlukan data terkini. Namun, ada alasan yang lebih penting mengapa Anda juga harus menggunakan yang utama sebagai preferensi dasar Anda:

1. Menjaga ketersediaan data selama failover.
2. Untuk aplikasi yang terdistribusi secara geografis, yang utama akan menyediakan pembacaan lokal untuk klien di pusat data yang sama.
3. Tidak mempengaruhi aplikasi front-end, terutama yang menjalankan operasi sistem.

Mongo.setReadPref() Metode

Metode ini pada dasarnya untuk menentukan bagaimana klien akan merutekan semua kueri ke anggota kumpulan replika. Dibutuhkan 2 argumen, mode dan tagSet.

Argumen mode menentukan preferensi baca yang dapat berupa primer, primerPreferred, sekunder, secondaryPreferred atau terdekat.

Mode tagSet menentukan preferensi baca kustom. Anda juga dapat menentukannya sebagai array objek. Contoh pengaturannya adalah:

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Apa yang terjadi di sini adalah, jika klien mencoba mengakses tag pertama dan permintaan tidak berhasil, mereka akan memilih preferensi baca kedua.

Membaca Mode Preferensi

• Utama:ini mendefinisikan bahwa semua operasi baca yang dibaca dari set replika yang diberikan adalah yang utama dan merupakan mode baca preferensi default.
• PrimaryPreferred:Jika hanya primer yang tidak tersedia, maka operasi baca dapat dilakukan dari sekunder.
• Sekunder:semua operasi baca dibuat dari anggota sekunder set replika.
• SecondaryPreferred:jika hanya tidak ada sekunder yang tersedia, operasi baca dapat dilakukan dari primer.
• Terdekat:anggota dengan latensi jaringan terkecil dipilih untuk operasi baca terlepas dari jenisnya.

Set Tag dan Konfigurasinya

Ini adalah opsi yang memungkinkan Anda untuk membuat model seperti yang Anda inginkan dari perhatian menulis dan preferensi membaca Anda. Mereka disimpan dalam objek konfigurasi set replika. Jika Anda menjalankan rs.conf().members, Anda akan mendapatkan objek ini dikembalikan:

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Seperti yang Anda lihat, setiap anggota memiliki atribut tag.

Perbedaan utama antara Preferensi Baca dan Kekhawatiran Tulis adalah, yang pertama mempertimbangkan nilai tag saat memilih anggota untuk dibaca sedangkan yang kedua tidak.

Katakanlah satu set tag untuk operasi baca diatur ke:

{ "disk": "ssd", "use": "reporting" }

Anggota dalam kumpulan replika harus memenuhi tag ini agar operasi baca dapat dilalui. Oleh karena itu untuk mengatakan, konfigurasi seperti ini

{ "disk": "ssd", "use": "reporting", "rack": "a" }

akan memenuhi kueri sedangkan yang ini

{ "disk": "ssd", "use": "production", "rack": "k" }

tidak akan memenuhi kueri.

Menambahkan Tag ke Kumpulan Replika

Untuk anggota yang Anda pilih dalam kumpulan replika, Anda dapat menambahkan kumpulan tag menggunakan metode rs.conf() di MongoDB.

Katakanlah Anda telah memilih anggota di posisi 1 dari kumpulan kumpulan replika, Anda dapat menambahkan kumpulan tag sebagai berikut.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Pola Penerapan untuk Kumpulan Replika MongoDB

1. Set replika yang didistribusikan secara geografis - Meningkatkan redundansi data selain melindungi data dari kesalahan seperti kehilangan daya. Instance yang berjalan terletak di beberapa lokasi.
2. Set Replika Tiga Anggota - arsitektur standar dasar untuk set replika.
3. Kumpulan Replika empat anggota atau lebih - Memungkinkan redundansi data yang lebih luas dan juga mendukung distribusi operasi baca yang lebih luas di Kumpulan Replika.

Teknik Penyetelan Penyetelan Replika MongoDB

Sebuah set replika yang ideal akan membutuhkan arsitektur yang ditata dengan baik dengan setidaknya 3 anggota untuk sistem produksi. Strategi penerapan ini akan membantu Anda mengaktifkan kumpulan replika yang hebat.

1. Gunakan anggota yang tertunda dan tersembunyi untuk mendukung fungsi khusus seperti pelaporan dan pencadangan.
2. Selalu buat jumlah anggota yang dikerahkan ganjil. Seperti yang telah kita diskusikan di atas, jumlah anggota yang ganjil akan dibutuhkan dalam pemilihan pendahuluan. Oleh karena itu pastikan Anda memiliki nomor ganjil dan jika tidak, Anda selalu dapat menambahkan arbiter.
3. Untuk penerapan yang banyak membaca, Anda perlu menyeimbangkan beban. Oleh karena itu Anda akan diminta untuk mendistribusikan bacaan ke sekunder untuk meningkatkan kinerja membaca. Selain itu, ketika data bertambah seiring waktu, Anda dapat menambahkan lebih banyak anggota dan mendistribusikannya, tetapi perlu diingat bahwa Anda harus mengonfigurasinya sedemikian rupa sehingga desain terpenting adalah memilih yang utama.
4. Selalu pertimbangkan toleransi kesalahan. Ini pada dasarnya menentukan berapa banyak anggota yang tidak dapat hadir pada waktu tertentu dan berapa banyak yang akan bertahan untuk mempertahankan proses pemilihan pendahuluan. Jika Anda tidak memiliki primer, sayangnya set replika tidak akan menerima operasi tulis apa pun.
5. Tambahkan anggota baru ke kumpulan replika yang ada sebelum permintaan muncul.
6. Gunakan kumpulan tag kumpulan replika untuk memastikan bahwa semua operasi direplikasi di pusat data tertentu. Anda juga dapat menggunakan tag ini dalam perutean untuk operasi baca untuk mesin penerapan tertentu.
7. Menyebarkan sebagian besar anggota Anda di satu lokasi untuk menghindari kemunduran yang akan timbul dari partisi jaringan. Pemisahan jaringan dapat terjadi akibat terputusnya komunikasi antar pusat data, sehingga menghambat proses replikasi dan proses pemilihan primer.
8. Untuk alasan keamanan, distribusikan anggota Anda secara geografis selain menyembunyikannya. Anda dapat menyetel setidaknya 2 atau 3 prioritas anggota ke nol untuk mencegah mereka menjadi yang utama.
9. Gunakan penjurnalan untuk melindungi kehilangan data yang dapat mengakibatkan sesuatu seperti kegagalan daya. Ini memastikan bahwa data ditulis ke disk jika terjadi shutdown mendadak.

Log Operasi (Oplog)

Oplog menyimpan catatan operasi master yang akan diterapkan ke budak. Itu disimpan dalam database yang disebut lokal di koleksi oplog.$main. Itu dibuat saat Anda memulai anggota kumpulan replika untuk pertama kalinya. Di batas atas, oplog dibatasi hingga ukuran 50GB untuk semua mesin penyimpanan. Ukuran oplog dapat diubah dari pengaturan default. Jika ukuran ini tercapai misalnya dalam 24 jam operasi, sekunder tidak akan dapat menyalin dari itu selama durasi ini dengan nyaman dan mungkin berakhir tidak menyalin sama sekali. Anda dapat mengubah ukuran oplog menggunakan opsi replSetResizeOplog yaitu

db.database({replSetResizeOplog:1, size: 16384})

Jika Anda ingin memperkecil ukuran oplog ini, beberapa data akan terhapus. Dampak inti dari ini di set replika adalah bahwa anggota yang disinkronkan ke node ini menjadi basi. Dengan demikian, Anda perlu menyinkronkan ulang anggota ini.

Pola Beban Kerja yang Memerlukan Ukuran Oplog Besar

1. Perbarui ke beberapa dokumen sekaligus. Operasi beberapa pembaruan harus diterjemahkan ke operasi individu untuk meningkatkan hasil di seluruh node. Operasi ini akan menggunakan ruang yang luas dari ruang oplog.
2. Sejumlah besar pembaruan di tempat. Hal ini umumnya terjadi ketika memperbarui data dokumen tidak serta merta meningkatkan ukuran dokumen ini. Basis data akan merekam sejumlah besar operasi ke oplog sehingga meningkatkan ukurannya.
3. Penghapusan sama dengan jumlah data yang sama dengan sisipan. Ini terjadi ketika Anda mencoba untuk menghapus sejumlah data (hampir) sama dengan jumlah data yang Anda masukkan. Operasi ini akan cenderung memperbesar ukuran oplog.

Kesimpulan

Replikasi adalah salah satu aspek penting dari basis data yang perlu dipahami oleh pengembang. Ini memastikan peningkatan ketersediaan data. Server MongoDB Anda mungkin mati, misalnya, karena pemadaman listrik tetapi Anda tetap ingin klien Anda mengakses datanya. Jika Anda memiliki data yang direplikasi di server lain, klien Anda akan dapat terus mengakses data darinya jika server utama gagal. Selain itu, ada peningkatan penyeimbangan beban sehingga alih-alih semua pengguna mengakses satu server, kita telah melihat pengorbanan melayani lalu lintas dari replika sekunder.