Rilis ClusterControl terbaru kami mengubah beberapa tugas MongoDB yang paling merepotkan menjadi pekerjaan hanya 15 detik. Fitur baru telah ditambahkan untuk memberi Anda kontrol lebih besar atas cluster Anda dan melakukan perubahan topologi:
- Mengonversi replikaSet MongoDB menjadi Cluster MongoDB yang di-sharding
- Menambahkan dan menghapus pecahan
- Menambahkan shard router ke sharded MongoDB cluster
- Mundur atau membekukan node
- Penasihat MongoDB baru
Kami akan menjelaskan fitur tambahan ini secara mendalam di bawah ini.
Mengonversi ReplicaSet MongoDB menjadi Cluster MongoDB yang Di-Shared
Karena sebagian besar pengguna MongoDB akan memulai dengan replicaSet untuk menyimpan database mereka, ini adalah jenis cluster yang paling sering digunakan. Jika Anda mengalami masalah penskalaan, Anda dapat menskalakan replicaSet ini dengan menambahkan lebih banyak sekunder atau menskalakan dengan sharding. Anda dapat mengonversi replicaSet yang ada menjadi kluster sharded, namun ini adalah proses yang panjang di mana Anda dapat dengan mudah membuat kesalahan. Di ClusterControl kami telah mengotomatiskan proses ini, di mana kami secara otomatis menambahkan Configservers, shard router dan mengaktifkan sharding.
Untuk mengonversi replicaSet menjadi sharded cluster, Anda cukup memicunya melalui tarik-turun tindakan:
Ini akan membuka dialog dua langkah tentang cara mengubahnya menjadi pecahan. Langkah pertama adalah menentukan tempat untuk menyebarkan Configserver dan router shard ke:
Langkah kedua adalah tempat menyimpan data dan file konfigurasi mana yang harus digunakan untuk Configserver dan shard router.
Setelah tugas migrasi shard selesai, ikhtisar cluster sekarang menampilkan shard, bukan instance replicaSet:
Setelah mengonversi ke sharded cluster, shard baru dapat ditambahkan.
Tambah atau Hapus Pecahan dari Cluster MongoDB yang Dibagikan
Menambahkan Pecahan
Karena shard MongoDB secara teknis merupakan replicaSet, menambahkan shard baru juga melibatkan penerapan replikaSet baru. Di dalam ClusterControl, pertama-tama kita menerapkan replicaSet baru, lalu menambahkannya ke sharded cluster.
Dari UI ClusterControl, Anda dapat dengan mudah menambahkan pecahan baru dengan wizard dua langkah, dibuka dari tarik-turun tindakan:
Di sini Anda dapat menentukan topologi pecahan baru.
Setelah shard baru ditambahkan ke cluster, router shard MongoDB akan mulai menetapkan potongan baru ke dalamnya, dan penyeimbang akan secara otomatis menyeimbangkan semua potongan di semua shard.
Menghapus Pecahan
Menghapus pecahan sedikit lebih sulit daripada menambahkan pecahan, karena ini melibatkan pemindahan data ke pecahan lain sebelum menghapus pecahan itu sendiri. Untuk semua data yang telah di-shard ke semua shard, ini akan menjadi tugas yang dilakukan oleh penyeimbang MongoDB.
Namun database/koleksi non-sharded, yang ditetapkan shard ini sebagai shard utama, perlu dipindahkan ke shard lain dan membuat shard utama baru. Untuk proses ini, MongoDB perlu mengetahui ke mana harus memindahkan database/koleksi yang tidak di-sharding ini.
Di ClusterControl Anda cukup menghapusnya melalui drop-down tindakan:
Ini akan memungkinkan Anda untuk memilih pecahan yang ingin Anda hapus, dan pecahan yang ingin Anda migrasikan ke basis data utama:
Pekerjaan yang menghapus shard kemudian akan melakukan tindakan serupa seperti yang dijelaskan sebelumnya:itu akan memindahkan basis data utama ke shard yang ditentukan, mengaktifkan penyeimbang dan kemudian menunggu untuk memindahkan semua data dari shard.
Setelah semua data dihapus, shard akan dihapus dari UI.
Menambahkan Shard Router MongoDB Tambahan
Setelah Anda mulai menskalakan aplikasi Anda menggunakan sharded cluster MongoDB, Anda mungkin membutuhkan router shard tambahan.
Menambahkan router shard MongoDB tambahan adalah proses yang sangat sederhana dengan ClusterControl, cukup buka dialog Add Node dari drop down tindakan:
Ini akan menambahkan router pecahan baru ke cluster. Jangan lupa untuk mengatur port default yang tepat (27017) pada router.
Turunkan Server
Jika Anda ingin melakukan pemeliharaan pada node utama di replicaSet, lebih baik untuk membuatnya "turun" terlebih dahulu dengan anggun sebelum membuatnya offline. Mengundurkan diri dari yang utama pada dasarnya berarti tuan rumah berhenti menjadi yang utama dan menjadi yang kedua dan tidak memenuhi syarat untuk menjadi yang utama selama beberapa detik yang ditentukan. Node di replicaSet MongoDB dengan kekuatan voting, akan memilih primer baru dengan primer yang diturunkan dikecualikan untuk jumlah detik yang ditetapkan.
Di ClusterControl kami telah menambahkan fungsionalitas step down sebagai tindakan pada halaman Nodes. Untuk mundur, cukup pilih ini sebagai tindakan dari tarik-turun:
Setelah menetapkan jumlah detik untuk mundur dan mengonfirmasi, yang utama akan mundur dan yang utama baru akan dipilih.
Membekukan Node
Fungsionalitas ini mirip dengan perintah step down:ini membuat node tertentu tidak memenuhi syarat untuk menjadi yang utama selama beberapa detik. Ini berarti Anda dapat mencegah satu atau beberapa node sekunder menjadi primer saat mengundurkan diri dari primer, dan memaksa node tertentu menjadi primer baru dengan cara ini.
Di ClusterControl kami telah menambahkan fungsionalitas freeze node sebagai tindakan pada halaman Nodes. Untuk membekukan node, cukup pilih ini sebagai tindakan dari drop-down:
Setelah menyetel jumlah detik dan mengonfirmasi, simpul tidak akan memenuhi syarat sebagai primer untuk jumlah detik yang disetel.
Penasihat MongoDB Baru
Penasihat adalah program mini yang memberikan saran tentang masalah basis data tertentu. Kami telah menambahkan tiga penasihat baru untuk MongoDB. Yang pertama menghitung jendela replikasi, yang kedua mengawasi jendela replikasi, dan yang ketiga memeriksa database/koleksi yang tidak di-sharding.
Penasihat Jeda Replikasi MongoDB
Replikasi lag sangat penting untuk diperhatikan, jika Anda meningkatkan pembacaan dengan menambahkan lebih banyak sekunder. MongoDB hanya akan menggunakan sekunder ini jika mereka tidak tertinggal terlalu jauh. Jika sekunder memiliki jeda replikasi, Anda berisiko menyajikan data usang yang telah ditimpa di primer.
Untuk memeriksa jeda replikasi, cukup sambungkan ke primer dan ambil data ini menggunakan perintah replSetGetStatus. Berbeda dengan MySQL, yang utama melacak status replikasi sekundernya.
Kami telah menerapkan pemeriksaan ini ke dalam penasihat di ClusterControl, untuk memastikan jeda replikasi Anda akan selalu diawasi.
Penasihat Jendela Replikasi MongoDB
Sama seperti jeda replikasi, jendela replikasi adalah metrik yang sama pentingnya untuk dilihat. Penasihat lag sudah memberi tahu kami tentang jumlah detik node sekunder berada di belakang primer/master. Karena ukuran oplog terbatas, memiliki slave lag menimbulkan risiko berikut:
- Jika sebuah node tertinggal terlalu jauh, ia mungkin tidak dapat mengejar lagi karena transaksi yang diperlukan untuk mengejar tidak lagi berada di oplog utama.
- Node sekunder yang tertinggal kurang disukai dalam pemilihan MongoDB untuk primer baru. Jika semua sekunder tertinggal dalam replikasi, Anda akan mendapat masalah dan satu dengan lag paling sedikit akan dijadikan primer.
- Sekunder yang tertinggal kurang disukai oleh driver MongoDB saat menskalakan pembacaan dengan MongoDB, ini juga menambah beban kerja yang lebih tinggi pada sekunder yang tersisa.
Jika kita memiliki node sekunder yang tertinggal beberapa menit (atau beberapa jam), akan berguna untuk memiliki penasihat yang memberi tahu kita berapa banyak waktu yang tersisa sebelum transaksi kita berikutnya akan dihentikan dari oplog. Perbedaan waktu antara entri pertama dan terakhir di oplog disebut Jendela Replikasi. Metrik ini dapat dibuat dengan mengambil item pertama dan terakhir dari oplog, dan menghitung perbedaan stempel waktunya.
Di shell MongoDB, sudah tersedia fungsi yang menghitung jendela replikasi untuk Anda. Namun fungsi ini dibangun ke dalam shell baris perintah, jadi koneksi luar apa pun yang tidak menggunakan shell baris perintah tidak akan memiliki fungsi bawaan ini. Oleh karena itu kami telah membuat penasihat yang akan mengawasi jendela replikasi dan memperingatkan Anda jika Anda melebihi ambang batas yang telah ditentukan sebelumnya.
MongoDB un-sharded Databases and Collections Advisor
Basis data dan koleksi yang tidak di-sharding akan ditetapkan ke shard utama default oleh router shard MongoDB. Ini berarti basis data atau koleksi terbatas pada ukuran pecahan utama ini, dan jika ditulis dalam volume besar, dapat menggunakan semua ruang disk yang tersisa dari pecahan. Setelah ini terjadi, shard jelas tidak akan berfungsi lagi. Oleh karena itu, penting untuk mengawasi semua database dan koleksi yang ada, dan memindai database konfigurasi untuk memvalidasi bahwa mereka telah diaktifkan untuk sharding.
Untuk mencegah hal ini terjadi, kami telah membuat database dan penasihat koleksi yang tidak di-sharding. Penasihat ini akan memindai setiap database dan koleksi, dan memperingatkan Anda jika belum di-sharding.
ClusterControl meningkatkan pemeliharaan MongoDB
Kami telah membuat langkah besar dengan menambahkan semua peningkatan ke ClusterControl untuk ReplikaSet MongoDB dan sharded cluster. Ini sangat meningkatkan kegunaan untuk MongoDB, dan memungkinkan DBA, sysop, dan devop untuk mempertahankan cluster mereka dengan lebih baik!
