Di MongoDB, kumpulan data besar melibatkan operasi throughput tinggi dan ini dapat membebani kapasitas satu server . Kumpulan data kerja yang besar berimplikasi lebih banyak tekanan pada kapasitas I/O perangkat disk dan dapat menyebabkan masalah seperti Kesalahan Halaman.
Ada dua cara untuk menyelesaikan ini...
- Penskalaan Vertikal :meningkatkan kapasitas server tunggal. Dicapai dengan menambahkan lebih banyak CPU, RAM, dan ruang penyimpanan tetapi dengan batasan bahwa:teknologi yang tersedia dapat membatasi satu mesin agar tidak cukup kuat untuk beberapa beban kerja. Secara praktis, ada batas maksimum untuk penskalaan vertikal.
- Penskalaan Horizontal Melalui Sharding :Ini melibatkan pembagian dataset sistem ke beberapa server sehingga mengurangi beban kerja keseluruhan untuk satu server. Memperluas kapasitas penerapan hanya memerlukan penambahan lebih banyak server untuk menurunkan biaya keseluruhan daripada perangkat keras kelas atas untuk satu mesin. Namun, ini datang dengan trade off bahwa akan ada banyak kerumitan dalam infrastruktur dan pemeliharaan untuk penyebaran. Kompleksitas menjadi lebih canggih saat memecahkan masalah kluster yang di-sharding jika terjadi bencana. Di blog ini, kami menyediakan beberapa kemungkinan pemecahan masalah yang dapat membantu:
- Memilih Shard Key dan Ketersediaan Cluster
- Instance Mongo menjadi tidak tersedia
- Anggota absen dari set replika pecahan
- Semua anggota set replika tidak ada
- Data konfigurasi basi menyebabkan Kursor Gagal
- Server konfigurasi menjadi tidak tersedia
- Memperbaiki Kesalahan String Basis Data
- Menghindari Waktu Henti saat memindahkan server konfigurasi
Memilih Shard Key dan Ketersediaan Cluster
Sharding melibatkan pembagian data ke dalam kelompok-kelompok kecil yang disebut shard untuk mengurangi beban kerja keseluruhan untuk throughput tertentu operasi. Pengelompokan ini dicapai melalui pemilihan kunci optimal yang terutama merupakan bagian terpenting sebelum sharding. Kunci yang optimal harus memastikan:
- Mongo dapat mengisolasi sebagian besar kueri ke mongod tertentu. Jika misalnya lebih banyak operasi yang dikenai satu pecahan, kegagalan pecahan itu hanya akan membuat data yang terkait dengannya tidak ada pada saat itu. Sebaiknya pilih kunci pecahan yang akan memberikan lebih banyak pecahan untuk mengurangi jumlah ketidaktersediaan data jika pecahan rusak.
- MongoDB akan dapat membagi data secara merata di antara potongan. Hal ini memastikan bahwa operasi throughput juga akan didistribusikan secara merata sehingga mengurangi kemungkinan kegagalan karena lebih banyak tekanan beban kerja.
- Tulis skalabilitas di seluruh cluster untuk memastikan ketersediaan tinggi. Setiap pecahan harus merupakan kumpulan replika yang jika instance mongod tertentu gagal, anggota kumpulan replika yang tersisa dapat memilih anggota lain untuk menjadi anggota utama sehingga memastikan kelangsungan operasional.
Jika shard tertentu cenderung gagal, mulailah dengan memeriksa berapa banyak operasi throughput apakah itu tunduk dan pertimbangkan untuk memilih kunci pecahan yang lebih baik untuk memiliki lebih banyak pecahan.
Bagaimana Jika? Instance Mongos Menjadi Tidak Ada
Pertama periksa apakah Anda terhubung ke port yang benar karena Anda mungkin telah berubah secara tidak sadar. Misalnya, penerapan dengan platform AWS, ada kemungkinan masalah ini karena grup keamanan yang mungkin tidak mengizinkan koneksi pada port tersebut. Untuk pengujian langsung, coba tentukan host lengkap:port untuk memastikan Anda menggunakan antarmuka loopback. Hal baiknya adalah, jika setiap server aplikasi memiliki instance mongosnya sendiri, server aplikasi dapat terus mengakses database. Selain itu, instance mongos memiliki status yang diubah seiring waktu dan dapat dimulai ulang tanpa harus kehilangan data. Saat instance terhubung kembali, ia akan mengambil salinan database konfigurasi dan mulai merutekan kueri.
Pastikan port yang Anda coba sambungkan kembali juga tidak ditempati oleh proses lain.
Bagaimana Jika? Seorang Anggota Menjadi Absen Dari Kumpulan Replika Shard
Mulailah dengan memeriksa status pecahan dengan menjalankan perintah sh.status(). Jika hasil yang dikembalikan tidak memiliki clusterId maka shard memang tidak tersedia. Selalu selidiki gangguan dan kegagalan ketersediaan dan jika Anda tidak dapat memulihkannya dalam waktu sesingkat mungkin, buat anggota baru untuk menggantikannya sesegera mungkin untuk menghindari lebih banyak kehilangan data.
Jika anggota sekunder menjadi tidak tersedia tetapi dengan entri oplog saat ini, ketika terhubung kembali, ia dapat mengejar status set terbaru dengan membaca data saat ini dari oplog sebagai proses replikasi normal. Jika gagal mereplikasi data, Anda perlu melakukan sinkronisasi awal menggunakan salah satu dari dua opsi ini...
- Mulai ulang mongod dengan direktori data kosong dan biarkan fitur sinkronisasi awal normal MongoDB memulihkan data. Namun, pendekatan ini membutuhkan waktu lama untuk menyalin data, tetapi cukup mudah.
- Mulai ulang mesin host dengan salinan direktori data terbaru dari anggota lain di set replika. Proses cepat tapi dengan langkah rumit
Sinkronisasi awal akan memungkinkan MongoDB untuk...
- Klon semua database yang tersedia kecuali database basis data lokal. Pastikan anggota target memiliki cukup ruang disk di database lokal untuk menyimpan sementara catatan oplog selama data disalin.
- Terapkan semua perubahan ke kumpulan data menggunakan oplog dari sumbernya. Proses akan selesai hanya jika status replika beralih dari STARTUP2 ke SECONDARY.
Bagaimana Jika? Semua Anggota Set Replika Tidak Ada
Data yang disimpan dalam shard tidak akan tersedia jika semua anggota replika kumpulan shard tidak ada. Karena pecahan lainnya tetap tersedia, operasi baca dan tulis masih dimungkinkan kecuali bahwa aplikasi akan disajikan dengan sebagian data. Anda perlu menyelidiki penyebab gangguan dan mencoba mengaktifkan kembali pecahan sesegera mungkin. Periksa profiler kueri atau metode penjelasan mana yang mungkin menyebabkan masalah tersebut.
Bagaimana Jika? Data Konfigurasi Kedaluwarsa Menyebabkan Kursor Gagal
Terkadang instance mongos memerlukan waktu lama untuk memperbarui cache metadata dari database konfigurasi yang mengarah ke kueri yang dikembalikan peringatan:
could not initialize cursor across all shards because : stale config detectedKesalahan ini akan selalu ditampilkan hingga instance mongos menyegarkan cache mereka. Ini seharusnya tidak menyebar kembali ke aplikasi. Untuk memperbaikinya, Anda perlu memaksa instance untuk menyegarkan dengan menjalankan fluRouterConfig.
Untuk membersihkan cache untuk menjalankan koleksi tertentu
db.adminCommand({ flushRouterConfig: "<db.collection>" } )Untuk membersihkan cache untuk database tertentu, jalankan
db.adminCommand({ flushRouterConfig: "<db>" } )Untuk membersihkan cache semua database dan koleksinya, jalankan:
db.adminCommand("flushRouterConfig")
db.adminCommand( { flushRouterConfig: 1 } )Bagaimana Jika? Server Konfigurasi Menjadi Tidak Tersedia
Server konfigurasi dalam hal ini dapat dianggap sebagai anggota utama tempat node sekunder mereplikasi datanya. Jika tidak ada, node sekunder yang tersedia harus memilih satu di antara anggotanya untuk menjadi yang utama. Untuk menghindari situasi di mana Anda mungkin tidak memiliki server konfigurasi, pertimbangkan untuk mendistribusikan anggota kumpulan replika di dua pusat data sejak...
- Jika satu pusat data mati, data akan tetap tersedia untuk dibaca daripada tidak ada operasi jika Anda menggunakan satu pusat data .
- Jika pusat data yang mencakup anggota minoritas turun, set replika masih dapat melayani operasi tulis dan baca.
Disarankan untuk mendistribusikan anggota di setidaknya tiga pusat data.
Kemungkinan distribusi lainnya adalah mendistribusikan secara merata anggota pembawa data di dua pusat data dan anggota yang tersisa di awan.
Memperbaiki Kesalahan String Basis Data
Mulai dari MongoDB 3.4, server konfigurasi SCCC tidak didukung untuk instans mongod yang dicerminkan. Jika Anda perlu meningkatkan sharded cluster ke versi 3.4, Anda perlu mengonversi server konfigurasi dari SCCC ke CSRS.
Menghindari Waktu Henti Saat Memindahkan Server Konfigurasi
Waktu henti dapat terjadi sebagai akibat dari beberapa faktor seperti pemadaman listrik atau frekuensi jaringan sehingga mengakibatkan kegagalan server konfigurasi ke cluster. Gunakan CNAME untuk mengidentifikasi server itu untuk mengganti nama atau penomoran ulang selama koneksi ulang. Jika perintah komit moveChunk gagal selama proses migrasi, MongoDB akan melaporkan kesalahannya:
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of
<N>|<NN>" and "ERROR: TERMINATING"Ini berarti shard juga belum terhubung ke database konfigurasi sehingga yang utama akan menghentikan anggota ini untuk menghindari inkonsistensi data. Anda perlu menyelesaikan kegagalan migrasi chunk secara mandiri dengan berkonsultasi dengan dukungan MongoDB. Pastikan juga untuk menyediakan beberapa sumber daya yang stabil seperti jaringan dan daya ke cluster.
Kesimpulan
Kluster sharded MongoDB mengurangi beban kerja yang harus ditanggung oleh satu server sehingga meningkatkan kinerja dari operasi throughput. Namun, kegagalan untuk mengonfigurasi beberapa parameter dengan benar seperti memilih kunci pecahan yang optimal dapat membuat ketidakseimbangan beban sehingga beberapa pecahan akhirnya gagal.
Dengan asumsi konfigurasi dilakukan dengan benar, beberapa kemunduran yang tidak dapat dihindari seperti pemadaman listrik juga dapat terjadi. Untuk terus mendukung aplikasi Anda dengan waktu henti minimal, pertimbangkan untuk menggunakan setidaknya 3 pusat data. Jika salah satu gagal, yang lain akan tersedia untuk mendukung operasi baca jika yang utama ada di antara anggota yang terpengaruh. Tingkatkan juga sistem Anda ke setidaknya versi 3.4 karena mendukung lebih banyak fitur.
