Semua data yang dibuang mongodumpharus dibaca ke dalam memori oleh server MongoDB. Perlu juga dicatat bahwa mongodumpmencadangkan data dan definisi indeks; waktu untuk memulihkan juga dapat secara signifikan lebih lama dibandingkan dengan pendekatan lain karena mongorestoreakan perlu untuk membuat ulang setiap indeks sekunder setelah data dimuat.
Seperti dicatat dalam dokumentasi MongoDB , mongodumpberguna untuk mencadangkan dan memulihkan penyebaran kecil tetapi tidak ideal untuk menangkap cadangan penuh sistem yang lebih besar:
Ketika terhubung ke instance MongoDB, mongodump dapat mempengaruhi kinerja mongod. Jika data Anda lebih besar dari memori sistem, kueri akan mendorong set kerja memori, menyebabkan kesalahan halaman.
Server mandiri membatasi opsi cadangan Anda jika Anda juga ingin agar penyebaran Anda tersedia saat mengambil cadangan.
Berikut adalah beberapa pendekatan yang disarankan agar paling direkomendasikan:
Pendekatan # 1: Gunakan layanan cadangan cloud
Untuk solusi jangka pendek termudah, saya akan mempertimbangkan untuk menggunakan layanan pencadangan cloud komersial seperti MongoDB Cloud Manager . MongoDB Cloud Manager menyediakan pencadangan berkelanjutan dengan snapshot terjadwal dan kebijakan penyimpanan (lihat Persiapan Pencadangan untuk info lebih lanjut). Layanan cloud juga menghindari Anda harus menggunakan server / infrastruktur tambahan, jadi meskipun Anda berencana untuk melakukannya di masa depan, ini adalah solusi jangka pendek yang bermanfaat.
Pendekatan umum adalah:
Sebagai manfaat tambahan, Cloud Manager juga mencakup agen pemantauan yang dapat menangkap riwayat metrik dari penerapan Anda dan memungkinkan Anda untuk mengonfigurasi peringatan.
Pendekatan # 2: Ubah penyebaran Anda menjadi set replika dan cadangan dari sekunder tersembunyi
Pendekatan ini membutuhkan penyediaan beberapa infrastruktur tambahan, tetapi melepaskan dampak cadangan dari server utama Anda. Biasanya set replika disediakan dengan setidaknya tiga anggota untuk ketersediaan tinggi dan failover otomatis, tetapi jika satu-satunya tujuan Anda adalah cadangan, Anda dapat menggunakan konfigurasi dua server yang kurang ideal.
Pendekatan umum adalah:
- Menyediakan server kedua yang akan digunakan untuk cadangan
- Ubah server mandiri Anda menjadi set replika .
- Tambahkan server cadangan Anda sebagai sekunder tersembunyi dengan prioritas 0 (tidak akan pernah menjadi utama) dan 0 suara.
- Gunakan salah satu metode cadangan yang didukung untuk mengambil cadangan di sekunder tersembunyi Anda. Metode cadangan terdaftar dalam urutan umum rekomendasi: snapshot sistem file (jika didukung oleh konfigurasi Anda) atau salinan file (dengan asumsi Anda berhenti
mongod) lebih disukai mongodump.
- (idealnya) menambahkan data lain yang mengandung data sekunder jika Anda menginginkan manfaat ketersediaan tinggi & failover dari konfigurasi set replika.
Pendekatan # 3: Gunakan snapshot sistem file (jika tersedia & sesuai)
Strategi cadangan yang kurang berdampak daripada saat ini Anda mongodumpakan menggunakan snapshot sistem file , dengan asumsi Anda memiliki sistem file yang mendukung snapshot (dan semua data dan file jurnal Anda berada dalam satu volume sehingga Anda dapat memperoleh snapshot yang konsisten dari running mongod). Kelebihan dari snapshot sistem file adalah bahwa semua data tidak harus dibaca ke dalam memori mongod, namun snapshot masih dapat berdampak (terutama ketika membuat snapshot awal pada sistem yang sibuk). Snapshots berturut-turut lebih efisien dan kurang berdampak, tetapi masih bukan solusi cadangan lengkap karena snapshots bersifat lokal untuk server Anda (dan Anda hanya memiliki standalone saat ini).
Peringatan
Pendekatan # 1 dan # 2 keduanya memungkinkan replikasi diaktifkan untuk memfasilitasi cadangan. Replikasi akan menambahkan beberapa I / O lokal tambahan pada server utama Anda karena semua operasi penulisan dicatat dalam koleksi tertutup khusus yang disebut oplog (log operasi) .
Anda telah menyebutkan kemungkinan kebutuhan untuk sharding di masa depan, tetapi sebelum melakukannya saya akan mengisolasi beban kerja MongoDB Anda dari proses lain yang berbagi server yang sama. Jika Anda dapat mengubah strategi cadangan Anda menjadi sesuatu yang lebih efisien daripada mongodump, menghapus pertentangan sumber daya, dan menangkap beberapa riwayat metrik dasar untuk ditinjau ... Anda mungkin menemukan bahwa sharding belum diperlukan.