Pemeriksaan Esensial untuk Database MongoDB yang Sehat

Menjaga database MongoDB tetap sehat sangat penting untuk memastikan kestabilan aplikasi, performa optimal, dan integritas data. Cluster yang "sehat" adalah yang secara andal melayani operasi baca dan tulis, melindungi data dari kehilangan, dan beroperasi dalam parameter operasional yang diharapkan. Pemeriksaan rutin dan pemantauan proaktif sangat krusial untuk mengidentifikasi dan menangani potensi masalah sebelum memengaruhi layanan Anda.

Kesehatan cluster MongoDB dapat dikategorikan ke dalam tiga area mendasar:

• Replikasi
• Performa
• Cadangan

Dengan menilai area-area ini secara rutin, Anda memastikan platform data tetap tangguh dan andal. Selain itu, alat manajemen modern seperti MongoDB Atlas dan MongoDB Ops Manager menawarkan pemantauan terintegrasi dengan peringatan dan rekomendasi untuk membantu Anda mengantisipasi potensi masalah. Mengonfigurasi peringatan akan membantu Anda tetap sigap. Anda dapat menemukan petunjuk dan contoh tentang cara menyiapkan peringatan di dokumentasi resmi MongoDB.

Mari kita bahas satu per satu.

Status Replikasi

Replikasi adalah tulang punggung high availability di MongoDB. Replica set yang sehat memastikan redundansi data dan kemampuan failover. Mari kita tinjau tiga indikator kunci untuk memastikan replikasi berjalan efektif di antara server yang menjadi anggota replica set.

Status keseluruhan dan detail status replikasi 

Status lengkap sebuah replica set dapat diperoleh dengan menjalankan perintah rs.status() di shell MongoDB. Perintah ini memberikan tampilan komprehensif atas kondisi terkini replica set. Hasilnya perlu diperiksa untuk memastikan semua anggota sehat (yaitu dalam status PRIMARY atau SECONDARY) dan beroperasi sebagaimana mestinya.

Dari UI Atlas, Anda juga dapat mengakses informasi serupa seperti yang diberikan perintah di atas. Dari halaman "Clusters", klik nama cluster tertentu. Tindakan ini akan membawa Anda ke tab "Overview" yang menampilkan gambaran node. Jika ada masalah serius, akan terlihat di sana. 

Waktu untuk mereplikasi

Daya tahan pada cluster yang direplikasi bergantung pada replikasi data ke mayoritas node. Karena itu, cluster yang sehat harus mereplikasi dengan cepat. Jika tidak, operasi dengan write concern majority akan memiliki latensi lebih tinggi.

Indikator utama karakteristik ini adalah replication lag. Replication lag mengacu pada jeda antara suatu operasi di anggota primary dan penerapannya di anggota secondary. Lag yang rendah dan konsisten adalah indikator kuat dari kondisi sehat. Sebaliknya, replikasi yang lambat bisa menjadi tanda konfigurasi koneksi antarnode yang kurang baik.

Cara termudah untuk mengamati replica lag adalah dengan melihat grafik "Replication Lag" di bawah tab "Cluster Metrics". Berikut contoh grafik ini untuk cluster yang sehat. Perhatikan bahwa metrik ini tidak berlaku untuk node PRIMARY di cluster, yaitu yang berada di tengah dan ditandai dengan huruf "P".

Replication Oplog Window 

Replikasi diimplementasikan melalui koleksi khusus bernama "oplog". Oplog (operation log) adalah capped collection yang mencatat semua operasi yang memodifikasi data. "Replication Oplog Window" mengacu pada perkiraan waktu yang tersedia di oplog replikasi bagi sumber sinkronisasi sebelum operasi terkini mulai ditimpa. Dengan kata lain, Replication Oplog Window adalah selisih waktu antara stempel waktu terbaru dan terlama di oplog. Nilai jendela oplog yang memadai sangat penting agar node secondary dapat mengejar ketertinggalan setelah gangguan dan mencegah kebutuhan resinkronisasi data penuh.

Jika sebuah secondary offline lebih lama daripada Replication Oplog Window yang tersedia, maka secondary tersebut harus disinkronisasi ulang dari awal. Dengan kata lain, Anda menginginkan nilai Replication Oplog Window yang lebih panjang daripada waktu maksimum sebuah replika mungkin tidak tersedia. Perhatikan bahwa nilai Replication Oplog Window sensitif terhadap lonjakan operasi tulis.

Untuk meningkatkan Replication Oplog Window, Anda dapat menambah ukuran koleksi oplog.

Status Performa

Performa secara langsung memengaruhi pengalaman pengguna aplikasi Anda dan biaya pengoperasian cluster. Cluster yang sehat beroperasi secara efisien terhadap beban kerjanya.

Di sini juga, mari kita lihat aspek performa kritis untuk dipantau.

Jumlah operasi saat ini sesuai ekspektasi 

Hal pertama yang saya suka periksa adalah apakah cluster menerima jumlah operasi yang diharapkan. Di sini, "yang diharapkan" mengasumsikan Anda mengetahui angkanya. Jika tidak, menelaah tren kueri selama satu jam, hari, minggu, dan seterusnya dapat memberikan pemahaman yang baik tentang apa yang diharapkan dan apakah ada puncak atau anomali yang terjadi. Puncak mingguan yang teratur pada waktu tertentu mungkin memerlukan penskalaan cluster secara proaktif.

Perhatikan laju operasi (baca, tulis, perintah). Lonjakan atau penurunan mendadak yang tidak terduga dapat mengindikasikan masalah, seperti masalah aplikasi, hambatan sumber daya, atau pola kueri yang tidak efisien. Untuk membantu Anda, atur peringatan pada jumlah operasi, yang dapat dilihat di bagian "Opcounters" pada metrik cluster.

Selain itu, informasi waktu nyata tentang laju operasi saat ini dapat ditemukan melalui "Real Time Tab".

Dapatkan pemahaman lebih dalam tentang kueri lambat 

Kueri yang memerlukan waktu eksekusi tidak biasa lama dikenal sebagai kueri lambat. Ini sering menunjukkan perlunya pengindeksan atau optimasi kueri. Selain itu, memantau operasi yang memerlukan pengurutan di memori sangat penting, karena dapat mengonsumsi sumber daya server yang signifikan dan menurunkan performa.

Tab "Query Insights" memungkinkan Anda melihat kueri, memfilternya berdasarkan kriteria, dan melakukan tindakan tambahan. Gunakan halaman ini untuk mengidentifikasi kueri mana yang perlu dioptimalkan dan mana yang mungkin perlu dijalankan di node lain atau pada waktu berbeda.

Indeks yang hilang

Penyebab paling umum dari kueri lambat di MongoDB adalah tidak adanya indeks yang sesuai. MongoDB dapat melakukan pemindaian koleksi (memeriksa setiap dokumen dalam koleksi) saat indeks tidak ada, tetapi ini adalah operasi yang sangat tidak efisien, terutama pada koleksi besar. Mengidentifikasi dan membuat indeks yang hilang sangat penting untuk menjaga performa kueri.

Tab "Performance Advisor" memiliki beberapa alat berharga untuk membantu Anda mengoptimalkan performa. Yang berikut ini adalah halaman "Create Indexes".

Status Cadangan

Replikasi sangat bermanfaat untuk mengurangi kehilangan data saat sumber daya, seperti disk server, hilang atau rusak. High availability bawaan cluster Anda akan menanggulangi sebagian besar kegagalan perangkat keras. Namun, strategi pencadangan yang andal tetap menjadi perlindungan terakhir terhadap kehilangan data. Cluster yang sehat memiliki sistem pencadangan dan pemulihan yang berfungsi dan telah diuji.

Seperti pada bagian lain, mari tinjau beberapa pertimbangan kunci untuk strategi pencadangan Anda.

Tentukan target pemulihan 

Tentukan Recovery Point Objective (RPO), yaitu jumlah kehilangan data maksimum yang dapat diterima, dan Recovery Time Objective (RTO), yaitu waktu maksimum yang diizinkan untuk memulihkan layanan. Target ini menentukan frekuensi dan metode pencadangan yang diperlukan.

Dasar-dasar pencadangan

Ada berbagai alat untuk mencadangkan data dengan MongoDB. Dimulai dari pembuangan sederhana data Anda menggunakan mongodump. Lalu, berlanjut ke pemanfaatan alat manajemen MongoDB untuk melakukan snapshot dan menyimpan operasi individual (oplog) guna merekonstruksi citra pada titik waktu mana pun. MongoDB Atlas mengintegrasikan alat-alat tersebut untuk cluster yang di-host, sementara MongoDB OpsManager melakukan fungsi serupa untuk cluster on-premises Anda.

Menyimpan banyak versi data sebagai cadangan biasanya memerlukan ruang lebih besar daripada database aslinya. Anda perlu memahami biayanya agar sesuai dengan kebutuhan. Latihan ini akan menghasilkan jadwal yang menampilkan jumlah snapshot yang diproduksi dan frekuensinya.

Melacak, mengakses, dan memulihkan cadangan

Jika Anda menggunakan MongoDB Atlas, verifikasi bahwa proses pencadangan terkelola berjalan dengan sukses, secara rutin menangkap snapshot, dan kebijakan retensi selaras dengan RPO Anda.

Lakukan pemulihan: Satu-satunya cara untuk benar-benar memastikan cadangan Anda valid adalah dengan melakukan uji pemulihan secara berkala. Tindakan ini memvalidasi seluruh alur pencadangan dan pemulihan, memastikan data dapat dipulihkan jika terjadi keadaan darurat.

Kesimpulan

Cluster MongoDB yang sehat ditandai oleh:

• Status replikasi yang optimal
• Performa yang efisien
• Cadangan yang andal

Pemantauan proaktif pada ketiga area ini, menganalisis performa kueri, dan menguji operasi pemulihan akan memastikan stabilitas dan umur panjang penerapan MongoDB Anda.