Pertimbangan untuk Mengelola MongoDB

Di bawah ini adalah kutipan dari whitepaper kami “Manajemen MongoDB dan Otomatisasi dengan ClusterControl” yang dapat diunduh secara gratis.

Pertimbangan untuk Mengelola MongoDB

Redundansi Bawaan

Fitur utama MongoDB adalah redundansi bawaannya, dalam bentuk Replikasi. Jika Anda memiliki dua atau lebih node data, node tersebut dapat dikonfigurasi sebagai set replika, di mana semua data yang ditulis ke node Primer, direplikasi hampir secara real time ke node sekunder,

memastikan banyak salinan data. Dalam kasus failover Primer, node yang tersisa di set replika melakukan pemilihan dan mempromosikan pemenang menjadi Primer, sebuah proses yang biasanya memakan waktu 2-3 detik, dan menulis ke set replika dapat dilanjutkan. MongoDB juga menggunakan jurnal untuk penulisan yang lebih cepat dan lebih aman ke server atau kumpulan replika, dan juga menggunakan metode "kekhawatiran penulisan" yang melaluinya tingkat redundansi penulisan
dikonfigurasi.

Untuk menerapkan set replika secara manual, langkah-langkah tingkat tinggi adalah sebagai berikut:

1. Alokasikan satu host fisik atau virtual untuk setiap node database, dan instal klien baris perintah MongoDB di desktop Anda. Untuk konfigurasi set replika yang berlebihan, diperlukan minimal tiga node, setidaknya dua di antaranya akan menjadi node data. Satu node dalam kumpulan replika dapat dikonfigurasi sebagai arbiter:ini adalah proses mongod yang dikonfigurasi hanya untuk membuat kuorum dengan memberikan suara dalam pemilihan Primer bila diperlukan. Data tidak direplikasi ke proses arbiter.
2. Instal MongoDB di setiap node. Beberapa distribusi Linux menyertakan MongoDB Community Edition, tetapi perlu diketahui bahwa ini mungkin tidak menyertakan versi terbaru. MongoDB Enterprise hanya tersedia dengan mengunduh dari situs web MongoDB. Fungsi serupa dengan MongoDB Enterprise juga tersedia melalui Percona Server untuk MongoDB, pengganti untuk MongoDB Enterprise atau Community Edition.
3. Konfigurasikan file konfigurasi mongod.conf individu untuk set replika Anda, menggunakan "parameter replikasi". Jika Anda akan menggunakan file kunci untuk keamanan, konfigurasikan ini sekarang juga. Perhatikan bahwa menggunakan keamanan file kunci juga mengaktifkan otentikasi berbasis peran, jadi Anda juga perlu menambahkan pengguna dan peran untuk menggunakan server. Mulai ulang proses mongod di setiap server.
4. Pastikan konektivitas antar node. Anda harus memastikan bahwa node kumpulan replika MongoDB dapat berkomunikasi satu sama lain pada port 27017, dan juga klien Anda dapat terhubung ke setiap node kumpulan replika pada port yang sama.
5. Menggunakan klien baris perintah MongoDB, sambungkan ke salah satu server, dan jalankan rs.initiate() untuk menginisialisasi kumpulan replika Anda, diikuti oleh rs.add() untuk setiap node tambahan. rs.conf() dapat digunakan untuk melihat konfigurasi.

Meskipun langkah-langkah ini tidak serumit menerapkan dan mengonfigurasi sharded cluster MongoDB, atau membagi database relasional, langkah-langkah tersebut dapat memberatkan dan rentan terhadap kesalahan, terutama di lingkungan yang lebih besar.

Skalabilitas

MongoDB sering disebut sebagai perangkat lunak basis data "skala web", karena kapasitasnya untuk penskalaan secara horizontal. Seperti basis data relasional, MongoDB dapat diskalakan secara vertikal, cukup dengan memutakhirkan host fisik yang memiliki lebih banyak inti CPU, lebih banyak RAM, disk lebih cepat, atau bahkan meningkatkan kecepatan bus. Namun, penskalaan vertikal memiliki batasan, baik dalam hal rasio biaya-manfaat dan hasil yang semakin berkurang, dan batasan teknis. Untuk mengatasi hal ini, MongoDB memiliki fitur “auto-sharding”, yang memungkinkan database untuk dibagi ke banyak host (atau set replika, untuk redundansi). Meskipun sharding juga dimungkinkan pada platform relasional, kecuali dirancang untuk permulaan basis data, ini memerlukan desain ulang skema dan aplikasi utama, serta desain ulang aplikasi klien, menjadikannya proses yang membosankan, memakan waktu, dan rawan kesalahan.

Sharding MongoDB bekerja dengan memperkenalkan proses router, di mana klien terhubung ke cluster sharded, dan server konfigurasi, yang menyimpan metadata cluster, lokasi di cluster setiap dokumen. Ketika klien mengirimkan kueri ke proses router, pertama-tama ia merujuk ke server konfigurasi untuk mendapatkan lokasi dokumen, dan kemudian memperoleh hasil kueri langsung dari server individu atau
set replika (pecahan). Sharding dilakukan berdasarkan koleksi.

Parameter yang sangat penting di sini, untuk tujuan kinerja, adalah "kunci shard", bidang terindeks atau bidang gabungan yang ada di setiap dokumen dalam koleksi. Inilah yang mendefinisikan distribusi tulis di seluruh pecahan koleksi. Dengan demikian, kunci pecahan yang dipilih dengan buruk dapat memiliki efek yang sangat merugikan pada kinerja. Misalnya, kunci shard murni berbasis deret waktu dapat mengakibatkan semua penulisan ke satu simpul untuk waktu yang lama. Namun, kunci pecahan yang di-hash, sementara mendistribusikan penulisan secara merata di seluruh pecahan, dapat memengaruhi kinerja baca karena kumpulan hasil diambil dari banyak node.

Arbiter

Arbiter MongoDB adalah proses mongod yang telah dikonfigurasi untuk tidak bertindak sebagai node data, tetapi untuk menyediakan hanya fungsi voting ketika replika set Primer akan dipilih, untuk memutuskan hubungan dan menjaga terhadap suara yang terbelah. Seorang arbiter tidak boleh menjadi Primer, karena tidak memegang salinan data atau menerima penulisan. Meskipun dimungkinkan untuk memiliki lebih dari satu arbiter dalam satu set replika, umumnya tidak disarankan.

Anggota Kumpulan Replika Tertunda

Anggota kumpulan replika yang tertunda menambahkan tingkat redundansi tambahan, mempertahankan status yang beberapa detik di belakang Utama. Karena anggota yang tertunda adalah "cadangan bergulir" atau snapshot "historis" yang berjalan dari kumpulan data, mereka dapat membantu memulihkan dari berbagai jenis kesalahan manusia.

Anggota yang tertunda adalah anggota kumpulan replika "tersembunyi", tidak terlihat oleh aplikasi klien, sehingga tidak dapat ditanyakan secara langsung. Mereka juga mungkin tidak menjadi Utama selama operasi normal, dan harus dikonfigurasi ulang secara manual jika akan digunakan untuk memulihkan dari kesalahan.

Cadangan

Mencadangkan kumpulan replika atau sharded cluster dilakukan melalui utilitas baris perintah "mongodump". Saat digunakan dengan parameter --oplog, ini membuat dump database yang menyertakan oplog, untuk membuat snapshot point-in-time dari status instance mongod. Menggunakan mongorestore dengan parameter --replayOplog, Anda kemudian dapat sepenuhnya memulihkan status data pada saat pencadangan selesai, menghindari inkonsistensi.

Untuk persyaratan pencadangan yang lebih lanjut, alat pihak ketiga yang disebut “mongodbconsistent-backup” - juga berbasis baris perintah - tersedia yang menyediakan pencadangan yang sepenuhnya konsisten dari klaster sharding, prosedur yang rumit, mengingat basis data sharding didistribusikan di beberapa host.

Pemantauan

Ada sejumlah alat komersial, baik resmi maupun tidak resmi, tersedia di pasar untuk memantau MongoDB. Alat-alat ini, secara umum, adalah utilitas manajemen produk tunggal, dengan fokus pada MongoDB secara eksklusif. Banyak yang hanya fokus pada aspek spesifik tertentu, seperti manajemen koleksi dalam arsitektur MongoDB yang ada, atau pada pencadangan, atau pada penerapan. Tanpa perencanaan yang tepat, hal ini dapat menyebabkan situasi di mana proliferasi alat tambahan harus diterapkan dan dikelola di lingkungan Anda.

Alat baris perintah yang disediakan dengan MongoDB, "mongotop" dan "mongostat" dapat memberikan tampilan mendetail tentang kinerja lingkungan Anda, dan dapat digunakan untuk mendiagnosis masalah. Selain itu, klien baris perintah MongoDB "mongo" juga dapat menjalankan "rs.status()" - atau dalam sharded cluster "sh.status() - untuk melihat status replika set atau cluster dan host anggotanya. Perintah “db.stats()” mengembalikan dokumen yang membahas penggunaan penyimpanan dan volume data, dan keduanya setara untuk koleksi, serta panggilan lain untuk mengakses banyak metrik internal.

Sinopsis

Ini telah menjadi sinopsis singkat pertimbangan untuk mengelola MongoDB. Meskipun pada tingkat yang begitu tinggi, harus segera menjadi jelas bahwa meskipun dimungkinkan untuk mengelola set replika atau sharded cluster dari baris perintah menggunakan alat yang tersedia, ini tidak skala di lingkungan dengan banyak set replika atau dengan produksi besar. kluster terpotong. Dalam lingkungan menengah hingga besar yang terdiri dari banyak host
dan database, dengan cepat menjadi tidak layak untuk mengelola semuanya dengan alat dan skrip baris perintah. Sementara alat dan skrip internal dapat dikembangkan untuk menyebarkan dan memelihara lingkungan, ini menambah beban pengelolaan pengembangan baru, sistem kontrol revisi, dan proses. Upgrade sederhana dari server database dapat menjadi proses yang kompleks jika perubahan alat diperlukan untuk mendukung database baru
versi server.

Tetapi tanpa alat dan skrip internal, bagaimana kita mengotomatisasi dan mengelola cluster MongoDB? Unduh whitepaper untuk mempelajari caranya!