Apa cara yang disarankan untuk mencadangkan kumpulan data besar di MongoDB? Katakanlah kita memiliki ukuran data dalam urutan 10TB - bagaimana Anda akan mendukungnya?
Kami sedang mempertimbangkan simpul set replika yang tersembunyi, mungkin tertunda. Penundaan akan melindungi kami dari tetes seluruh database yang tidak disengaja. Apakah ini solusi yang layak, dan opsi apa lagi yang akan Anda rekomendasikan untuk diselidiki?
Terima kasih!
Jawaban:
Dengan kebutuhan 10TB untuk didukung ini menjadi sedikit rumit.
Sementara anggota set replika yang tertunda dapat menyediakan cara yang relatif mudah untuk membantu Anda dengan operasi yang tidak disengaja, tidak ada pengganti untuk cadangan yang tepat, sangat mirip dengan RAID bukan pengganti untuk cadangan berbasis sistem file.
Itu sangat tergantung pada bagaimana pengaturan Anda terlihat.
Dengan 10TB, saya berasumsi Anda memiliki semacam SAN terlampir. Cara termudah untuk membuat cadangan MongoDB di lingkungan tersebut adalah untuk memastikan Anda telah mengaktifkan penjurnalan pada sistem file dan MongoDB dan cukup mengambil snapshot dari volume SAN dari salah satu dari kedua, mungkin yang tersembunyi untuk memastikan operasi Anda tidak akan terganggu. Ini biasanya hanya butuh beberapa detik, tapi tolong _membuat _bahwa jendela oplog replikasi Anda sudah cukup. Jika tidak, Anda mungkin perlu menyinkronkan kembali yang kedua.
Saya harus tidak setuju dengan RolandoMySQLDBA tentang penggunaan mongodump. Pertama-tama, itu memaksakan kunci di server. Meskipun mereka diangkat relatif cepat, jumlah kunci di sana mungkin bertambah dan mengganggu operasi Anda, kecuali dijalankan pada simpul tersembunyi atau ketika tidak ada preferensi baca yang mengenai yang kedua. Plus, itu tidak terlalu cepat. Saya berharap ini berjalan selama berjam-jam, setidaknya, kemungkinan besar akan lebih lama dari jendela cadangan Anda. Catatan: Selalu jalankan mongodump dengan --oplogopsi. Juga perlu diingat bahwa mongodump tidak membuat cadangan indeks, tetapi operasi untuk membuat indeks. Indeks-indeks tersebut harus dibuat ulang selama pemulihan, yang mungkin secara besar-besaran menambah waktu yang Anda perlukan untuk itu. Dari pengalaman saya, jika Anda harus mengembalikan database, Anda ingin memilikinya secepat mungkin. Poin lain mengapa mongodump tidak cocok untuk membuat cadangan 10TB.
Anda dapat melakukan snapshot LVM pada instance mongod yang sedang berjalan asalkan Anda mengaktifkan penjurnalan dalam mongod (dan dari pengalaman saya, tidak ada salahnya untuk mengaktifkannya di level FS juga). Namun, snapshot LVM datang dengan beberapa implikasi. Pertama, Anda jelas perlu memiliki cukup ruang disk yang dapat mengambil perubahan selama operasi pencadangan. Izinkan saya menjelaskannya.
Mari kita asumsikan Anda memiliki tingkat perubahan 500GB per jam. Dan Anda ingin cadangan Anda diblokir sebelum diunggah ke beberapa penyimpanan. Bahkan ketika menggunakan bzip2 paralel , kompresi 10TB akan membutuhkan beberapa jam untuk menyelesaikannya, hanya karena fakta bahwa kemungkinan besar throughput penyimpanan massal Anda akan menjadi faktor pembatas Anda. Mari kita asumsikan akan memakan waktu 2 jam untuk mengompres data ke 2TB. Jadi sekarang kita akan membutuhkan 2TB + 2 * 500GB total ruang disk kosong, 1TB diperlukan untuk snapshot LVM. Setidaknya ini akan menciptakan kebutuhan penyediaan sistem file Anda secara berlebihan30%. Jika Anda ingin memiliki margin keamanan yang tepat, ini dapat dengan mudah meningkat menjadi 60-70% (20% untuk faktor pemanfaatan 0,8 untuk sistem file asli, sama untuk ukuran snapshot ditambah ruang yang dibutuhkan untuk cadangan bzipped itu sendiri ). Di sebagian besar lingkungan produksi, itu tidak dapat diterima, karena ketentuan yang berlebihan akan statis (Anda tidak ingin skrip cadangan untuk memotong dengan LVM Anda secara dinamis, bukan?).
Sementara cadangan MMS memiliki beberapa fitur luar biasa (cadangan terus-menerus, pemulihan waktu dengan mudah), namun disertai dengan beberapa kelemahan serius: label harganya untuk penggunaan besar bisa dengan mudah mencapai ribuan. Dengan asumsi tingkat perubahan per jam sebesar 500GB pada 10TB itu, itu akan menjadi jumlah sedang enam digit untuk cadangan cloud . Bulanan.
Saran saya dia akan mengambil langganan perusahaan untuk server Anda karena memenuhi syarat untuk memiliki instance MMS premis, termasuk cadangan.
Berikut adalah opsi yang akan saya ambil dalam urutan preferensi.
Ada dua opsi
Jika Anda tidak keberatan dengan waktu henti, hal paling sederhana untuk dilakukan adalah
service mongod stopLakukan snapshot LVM atau kekuatan kasar cpdari folder data Mongo ke disk lain
service mongod startTentu saja, Anda tidak ingin downtime jika 10TB data ada di mesin mandiri.
Jika Anda memiliki set replika dengan tiga simpul, gunakan salah satu simpul untuk cadangan
{
"_id" : "myreplica",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "10.20.30.40:27017",
"priority" : 2
},
{
"_id" : 2,
"host" : "10.20.30.41:27017"
},
{
"_id" : 3,
"host" : "10.20.30.42:27017",
"priority" : 0,
"slaveDelay" : 3600
}
]
}Gunakan node dengan "_id' : 3semua cadangan fisik Anda. Karena itu, tidak ada downtime. Untuk mendapatkan snapshot tengah malam, Anda dapat meluncurkan cadangan pada pukul 1 pagi karena simpul tersembunyi 1 jam di belakang.
Tentu saja, kekurangannya adalah memiliki dua server lagi dengan masing-masing 10TB dan kewarasan sysadmin yang terancam.
Anda dapat menggunakan mongodump terhadap mesin mandiri tetapi Anda harus mengharapkan penurunan kinerja karena mongodump adalah program klien yang menggunakan koneksi seperti koneksi lainnya.
Jika Anda ingin cadangan point-in-time, Anda harus menggunakan
mongodump --oplog Cadangan BSON logis akan lebih kecil (terutama gzip atau bzip) daripada cadangan fisik.
Penggunaan mongodump --oplogterbaik akan dilakukan terhadap node tersembunyi. Dengan begitu, tidak ada kinerja yang menimpa Master.
Saya relatif baru untuk MongoDB (MongoDBA disengaja / insidental). Saya harap jawaban saya membantu.