Replica set dalam ApsaraDB for MongoDB terdiri dari beberapa proses mongod yang mencakup node utama dan beberapa node sekunder. Driver MongoDB hanya menulis data ke node utama, kemudian data disinkronkan ke node sekunder untuk memastikan konsistensi data di seluruh replica set. Dengan demikian, replica set menyediakan ketersediaan tinggi.
Gambar berikut diambil dari dokumentasi resmi MongoDB dan menggambarkan replica set MongoDB tipikal dengan satu node utama dan dua node sekunder.
Pemilihan node utama (1)
Replica set diinisialisasi dengan menjalankan perintah replSetInitiate atau menggunakan perintah rs.initiate() di mongo shell. Setelah inisialisasi, anggota saling bertukar pesan detak jantung dan memulai pemilihan node utama. Node yang menerima suara mayoritas menjadi node utama, sementara node lainnya menjadi node sekunder.
Inisialisasi Replica Set
config = {
_id : "my_replica_set",
members : [
{_id : 0, host : "rs1.example.net:27017"},
{_id : 1, host : "rs2.example.net:27017"},
{_id : 2, host : "rs3.example.net:27017"},
]
}
rs.initiate(config)Definisi Mayoritas
Mayoritas didefinisikan sebagai sekelompok anggota pemilih yang mencakup lebih dari separuh jumlah total anggota. Jika jumlah anggota tidak melebihi rata-rata semua anggota pemilih, pemilihan tidak dapat dilakukan, sehingga penulisan data ke replica set tidak dimungkinkan.
Jumlah anggota pemilih | Mayoritas | Jumlah maksimum node gagal |
1 | 1 | 0 |
2 | 2 | 0 |
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
7 | 4 | 3 |
Disarankan untuk mengatur jumlah anggota replica set menjadi angka ganjil. Tabel di atas menunjukkan bahwa baik replica set dengan tiga node maupun dengan empat node dapat mentolerir kegagalan satu node, memberikan ketersediaan layanan yang sama. Namun, replica set dengan empat node menawarkan penyimpanan data yang lebih andal.
Node sekunder khusus
Node sekunder dalam replica set berpartisipasi dalam pemilihan node utama dan dapat terpilih sebagai node utama. Data terbaru dari node utama disinkronkan ke node sekunder untuk memastikan konsistensi data di seluruh node.
Anda dapat membaca data dari node sekunder, sehingga menambahkan node sekunder dapat meningkatkan performa baca dan ketersediaan layanan replica set. ApsaraDB for MongoDB memungkinkan konfigurasi node sekunder untuk memenuhi persyaratan skenario yang berbeda.
Arbiter
Node arbiter hanya berperan sebagai pemilih dalam pemilihan dan tidak dapat dipilih sebagai node utama atau mensinkronkan data dari node utama.
Misalnya, jika Anda memiliki replica set dengan satu node utama dan satu node sekunder, kegagalan salah satu node akan mencegah pemilihan node utama baru, membuat replica set tidak tersedia. Menambahkan node arbiter memungkinkan pemilihan tetap berlangsung.
Node arbiter adalah node ringan yang tidak menyimpan data. Jika jumlah anggota replica set genap, disarankan untuk menambahkan node arbiter guna meningkatkan ketersediaan replica set.
Priority0
Node dengan prioritas 0 tidak dapat dipilih sebagai node utama.
Misalnya, jika Anda memiliki replica set dengan node di Pusat Data A dan Pusat Data B, atur prioritas anggota di Pusat Data B menjadi 0 untuk memastikan node utama terpilih berada di Pusat Data A.
CatatanJika prioritas anggota di Pusat Data B diatur menjadi 0, pastikan mayoritas node replica set berada di Pusat Data A. Jika tidak, pemilihan node utama mungkin gagal selama pemisahan jaringan.
Vote0
Di MongoDB 3.0, replica set dapat memiliki maksimal 50 anggota, tetapi hanya tujuh anggota yang dapat memilih dalam pemilihan node utama. Atur atribut members[n].votes menjadi 0 untuk anggota yang tidak diharapkan untuk memilih.
Hidden
Anggota tersembunyi dalam replica set tidak dapat dipilih sebagai node utama karena prioritasnya adalah 0 dan tidak terlihat oleh driver MongoDB.
Node tersembunyi dapat digunakan untuk pencadangan data atau tugas komputasi offline tanpa memengaruhi layanan replica set karena tidak menangani permintaan dari driver MongoDB.
Delayed
Node tertunda harus berupa node tersembunyi. Data pada node ini mencerminkan status data sebelumnya pada node utama. Misalnya, jika dikonfigurasi dengan penundaan satu jam, data pada node tertunda sama dengan data pada node utama satu jam sebelumnya.
Jika data salah atau tidak valid ditulis ke node utama, Anda dapat menggunakan data pada node tertunda untuk mengembalikan data ke status sebelumnya.
Pemilihan node utama (2)
Pemilihan node utama tidak hanya terjadi setelah inisialisasi replica set, tetapi juga dalam skenario berikut:
Rekonfigurasi Replica Set
Pemilihan dipicu jika node utama gagal atau turun jabatan secara sukarela menjadi node sekunder. Faktor-faktor seperti pesan detak jantung antar node, prioritas node, dan waktu entri oplog terakhir memengaruhi pemilihan.
Prioritas Node
Semua node cenderung memilih node dengan prioritas tertinggi. Node dengan prioritas 0 tidak dapat memicu pemilihan. Jika node sekunder memiliki prioritas lebih tinggi daripada node utama dan selisih waktu entri log terbaru kurang dari 10 detik, node utama turun jabatan, dan node sekunder tersebut menjadi kandidat node utama.
Optime
Hanya node sekunder dengan entri oplog terbaru yang memenuhi syarat untuk dipilih sebagai node utama.
Pemisahan Jaringan
Hanya node yang terhubung ke mayoritas node pemilih yang dapat dipilih sebagai node utama. Jika node utama terputus dari mayoritas node, ia turun jabatan menjadi node sekunder. Selama pemisahan jaringan, replica set mungkin memiliki beberapa node utama sementara. Saat menulis data, disarankan untuk mengatur kebijakan yang hanya mengizinkan sinkronisasi data dari node utama yang terhubung ke mayoritas node.
Sinkronisasi data
Data disinkronkan dari node utama ke node sekunder berdasarkan oplog. Setelah operasi tulis selesai pada node utama, entri oplog ditulis ke koleksi khusus local.oplog.rs. Node sekunder terus mengimpor entri oplog baru dari node utama dan menerapkan operasi tersebut.
Untuk mencegah pertumbuhan tak terbatas ukuran oplog, local.oplog.rs dikonfigurasi sebagai koleksi capped. Ketika ukuran oplog mencapai ambang batas, entri paling awal dihapus. Semua operasi dalam oplog bersifat idempoten, memastikan hasil yang sama meskipun diterapkan berulang kali.
Berikut adalah contoh entri oplog yang berisi bidang seperti ts, h, op, ns, dan o:
{
"ts" : Timestamp(1446011584, 2),
"h" : NumberLong("1687359108795812092"),
"v" : 2,
"op" : "i",
"ns" : "test.nosql",
"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }
}ts: Waktu operasi dilakukan, terdiri dari dua angka. Angka pertama adalah timestamp UNIX, dan angka kedua adalah penghitung operasi dalam satu detik.
h: Pengenal unik operasi.
v: Versi oplog.
op: Jenis operasi.
i: Sisipkan.
u: Perbarui.
d: Hapus.
c: Jalankan perintah seperti createDatabase dan dropDatabase.
n: Null, digunakan untuk tujuan khusus.
ns: Koleksi tempat operasi dilakukan.
o: Detail operasi.
o2: Kondisi operasi pembaruan, valid hanya untuk operasi pembaruan.
Selama sinkronisasi awal, node sekunder menjalankan perintah init sync untuk menyinkronkan semua data dari node utama atau node sekunder lainnya dengan data terbaru. Kemudian, node sekunder menggunakan fitur tailable cursor untuk menanyakan entri oplog terbaru dalam koleksi local.oplog.rs dari node utama dan menerapkan operasi tersebut.
Proses sinkronisasi awal melibatkan langkah-langkah berikut:
Sebelum waktu T1, alat sinkronisasi data menjalankan perintah
listDatabases,listCollections, dancloneCollection. Pada waktu T1, semua data dalam database cloud (kecuali database local.oplog.rs) mulai disinkronkan dari node utama ke node sekunder. Sinkronisasi selesai pada waktu T2.Semua operasi dalam entri oplog yang dihasilkan dari T1 hingga T2 diterapkan ke node sekunder. Operasi dalam entri oplog bersifat idempoten, sehingga operasi yang telah diterapkan dapat diterapkan kembali.
Berdasarkan indeks untuk setiap koleksi pada node utama, indeks untuk koleksi yang sesuai dibuat pada node sekunder.
CatatanUkuran oplog harus dikonfigurasi berdasarkan ukuran database dan volume data yang akan ditulis oleh aplikasi. Jika oplog terlalu besar, ruang penyimpanan mungkin terbuang. Jika terlalu kecil, node sekunder mungkin gagal menyelesaikan sinkronisasi awal. Misalnya, jika database menyimpan banyak data dan oplog tidak cukup besar, oplog mungkin gagal menyimpan semua entri oplog yang dihasilkan dari T1 hingga T2, sehingga node sekunder tidak dapat menyinkronkan semua data dari node utama.
Modifikasi Replica Set
Anda dapat memodifikasi replica set dengan menjalankan perintah replSetReconfig atau perintah rs.reconfig() di mongo shell. Contohnya, Anda dapat menambahkan atau menghapus anggota, serta mengubah prioritas, suara, tersembunyi, dan atribut tertunda dari anggota.
Contohnya, Anda dapat menjalankan perintah berikut untuk mengatur prioritas anggota kedua dalam replica set menjadi 2:
cfg = rs.conf();
cfg.members[1].priority = 2;
rs.reconfig(cfg);Mengembalikan Operasi pada Node Utama
Jika node utama replica set gagal dan operasi tulis telah dilakukan pada node utama baru ketika node utama sebelumnya bergabung kembali, node utama sebelumnya harus mengembalikan operasi yang belum disinkronkan untuk memastikan konsistensi data.
Node utama sebelumnya menulis data pengembalian ke direktori khusus, memungkinkan administrator basis data menjalankan perintah mongorestore untuk mengembalikan operasi sesuai kebutuhan.
Pengaturan baca/tulis replica set
Preferensi Baca
Secara default, semua permintaan baca untuk replica set diarahkan ke node utama. Namun, Anda dapat memodifikasi mode preferensi baca pada driver untuk mengarahkan permintaan baca ke node lain.
primary: Mode default, semua permintaan baca diarahkan ke node utama.
primaryPreferred: Permintaan baca diarahkan ke node utama secara preferensial. Jika node utama tidak tersedia, permintaan baca diarahkan ke node sekunder.
secondary: Semua permintaan baca diarahkan ke node sekunder.
secondaryPreferred: Permintaan baca diarahkan ke node sekunder secara preferensial. Jika semua node sekunder tidak tersedia, permintaan baca diarahkan ke node utama.
nearest: Permintaan baca diarahkan ke node terdekat yang dapat dijangkau, yang dapat dideteksi dengan menjalankan perintah
ping.
Tingkat Kepedulian Tulis
Secara default, node utama mengembalikan pesan keberhasilan setelah data ditulis ke node utama. Anda dapat mengatur tingkat kepedulian tulis pada driver untuk menentukan aturan keberhasilan operasi tulis. Untuk informasi lebih lanjut, lihat Tingkat Kepedulian Tulis.
Tingkat kepedulian tulis berikut menunjukkan bahwa operasi tulis berhasil hanya setelah data ditulis ke mayoritas node sebelum permintaan habis waktu. Periode timeout adalah lima detik.
db.products.insert( { item: "envelopes", qty : 100, type: "Clasp" }, { writeConcern: { w: "majority", wtimeout: 5000 } } )Pengaturan sebelumnya berlaku untuk permintaan individu. Anda juga dapat memodifikasi tingkat kepedulian tulis default dari replica set, yang berlaku untuk semua permintaan.
cfg = rs.conf() cfg.settings = {} cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 } rs.reconfig(cfg)