Protokol Server Konfigurasi
MongoDB 3.0 dan sebelumnya hanya mendukung satu jenis protokol penyebaran server konfigurasi yang disebut sebagai SCCC lama (Konfigurasi Koneksi Cluster Sinkronisasi) pada MongoDB 3.2. Penerapan SCCC memiliki 1 server konfigurasi (khusus pengembangan) atau 3 server konfigurasi (produksi).
MongoDB 3.2 tidak lagi menggunakan protokol SCCC dan mendukung jenis penerapan baru:Config Servers as Replica Sets (CSRS). Penyebaran CSRS memiliki batas yang sama dengan set replika standar, yang dapat memiliki 1 server konfigurasi (khusus pengembangan) atau hingga 50 server (produksi) seperti pada MongoDB 3.2. Minimal 3 server CSRS disarankan untuk ketersediaan tinggi dalam penerapan produksi, tetapi server tambahan mungkin berguna untuk penerapan yang didistribusikan secara geografis.
SCCC (Konfigurasi Koneksi Cluster Sinkronisasi)
Dengan SCCC, server konfigurasi diperbarui menggunakan komit dua fase protokol yang membutuhkan konsensus dari beberapa server untuk transaksi. Anda dapat menggunakan server konfigurasi tunggal untuk tujuan pengujian/pengembangan, tetapi dalam penggunaan produksi Anda harus selalu memiliki 3. Jawaban praktis mengapa Anda tidak dapat menggunakan hanya 2 (atau lebih dari 3) server di MongoDB adalah bahwa basis kode MongoDB hanya mendukung 1 atau 3 server konfigurasi untuk konfigurasi SCCC.
Tiga server memberikan jaminan konsistensi yang lebih kuat daripada dua server, dan memungkinkan aktivitas pemeliharaan (misalnya, pencadangan) pada satu server konfigurasi sementara masih memiliki dua server yang tersedia untuk mongos Anda untuk bertanya. Lebih dari tiga server akan meningkatkan waktu yang dibutuhkan untuk melakukan commit data di semua server.
Metadata untuk klaster sharding Anda harus identik di semua server konfigurasi, dan dikelola oleh implementasi sharding MongoDB. Metadata mencakup detail penting pecahan mana yang saat ini menyimpan rentang dokumen (alias chunks ). Dalam konfigurasi SCCC, server konfigurasi tidak kumpulan replika, jadi jika satu atau lebih server konfigurasi sedang offline maka data konfigurasi hanya akan dibaca -- jika tidak, data tidak dapat disebarkan ke server konfigurasi offline saat mereka kembali online.
Jelas 1 server konfigurasi tidak menyediakan redundansi atau cadangan. Dengan 2 server konfigurasi, skenario kegagalan potensial adalah di mana server tersedia tetapi data di server tidak sesuai (misalnya, salah satu server memiliki beberapa kerusakan data). Dengan 3 server konfigurasi, Anda dapat memperbaiki skenario sebelumnya:2/3 server mungkin konsisten dan Anda dapat mengidentifikasi server yang aneh.
CSRS (Server Konfigurasi sebagai Kumpulan Replika)
MongoDB 3.2 tidak lagi menggunakan tiga mongod . yang dicerminkan instans untuk server konfigurasi, dan mulai dari 3.2 server konfigurasi (secara default) digunakan sebagai set replika. Server konfigurasi set replika harus menggunakan mesin penyimpanan WiredTiger 3.2+ (atau mesin penyimpanan lain yang mendukung readConcern
membaca semantik isolasi). CSRS juga melarang beberapa opsi konfigurasi set replika non-default (mis. arbiterOnly , buildIndexes , dan slaveDelay ) yang tidak cocok untuk kasus penggunaan metadata cluster yang di-shard.
Penerapan CSRS meningkatkan konsistensi dan ketersediaan untuk server konfigurasi, karena MongoDB dapat memanfaatkan protokol baca dan tulis set replika standar untuk memisahkan data konfigurasi. Selain itu, ini memungkinkan sharded cluster untuk memiliki lebih dari 3 server konfigurasi karena set replika dapat memiliki hingga 50 anggota (seperti pada MongoDB 3.2).
Dengan penerapan CSRS, ketersediaan tulis bergantung pada pemeliharaan kuorum anggota yang dapat melihat primer saat ini untuk kumpulan replika. Misalnya, set replika 3-simpul akan membutuhkan 2 anggota yang tersedia untuk mempertahankan yang utama. Anggota tambahan dapat ditambahkan untuk toleransi kesalahan , tunduk pada aturan pemilu
yang sama sebagai set replika normal. Sebuah readConcern dari majority digunakan oleh mongos untuk memastikan bahwa metadata kluster sharded hanya dapat dibaca setelah dikomit ke sebagian besar anggota kumpulan replika dan readPreference dari nearest digunakan untuk merutekan permintaan ke server konfigurasi terdekat.
