Ikhtisar solusi pemulihan data untuk ApsaraDB for MongoDB - ApsaraDB for MongoDB

ApsaraDB for MongoDB menyediakan beberapa solusi pemulihan data untuk skenario yang berbeda.

Pulihkan data ke instans ApsaraDB for MongoDB

Penting

Sebelum memulihkan data ke instans baru:

Instans baru harus memiliki versi utama database yang sama dengan instans sumber. Pilih zona yang mendukung versi tersebut — zona yang tersedia bervariasi tergantung pada versinya (Catatan penggunaan).
Instans baru harus memiliki kapasitas penyimpanan minimal sama dengan instans sumber.
Backup yang dibuat sebelum peningkatan versi utama tidak dapat dipulihkan ke versi baru tersebut.
Secara default, instans baru yang dibuat untuk pemulihan data menjalankan versi minor kernel terbaru.
Jika instans Anda berisi koleksi time series (MongoDB 5.0 atau lebih baru), pemulihan pada titik waktu tertentu (point-in-time recovery) mungkin mengalami masalah selama fase replay oplog.

Solusi	Arsitektur instans	Tujuan pemulihan	Cakupan pemulihan	Skenario
Pulihkan satu atau beberapa database dari instans ApsaraDB for MongoDB	Replica set instance yang menggunakan cloud disk Sharded cluster instance yang menggunakan cloud disk	Instans asal	Semua database Beberapa database	Memulihkan koleksi atau dokumen yang tidak sengaja dihapus.
	Replica set instance yang menggunakan local disk dan menjalankan MongoDB 4.0 atau 4.2 Catatan Wilayah yang didukung dan batasan lainnya tercantum dalam Catatan penggunaan.	Instans baru	Semua database Beberapa database	Memulihkan koleksi atau dokumen yang tidak sengaja dihapus.
Buat instans baru dari titik cadangan	Standalone instance Replica set instance	Instans baru	Semua database Beberapa database Catatan Pemulihan parsial hanya didukung pada instans berbasis local disk.	Cocok ketika ketepatan waktu data tidak kritis.
Buat instans baru menggunakan point-in-time recovery	Replica set instance	Instans baru	Semua database Beberapa database Catatan Pemulihan parsial hanya didukung pada instans berbasis local disk.	Memulihkan data instans ke titik waktu tertentu.
Buat instans baru menggunakan point-in-time recovery	Sharded cluster instance	Instans baru	Semua database	Memulihkan data instans ke titik waktu tertentu.
Pemulihan data cross-region	Replica set instance yang menggunakan cloud disk Sharded cluster instance yang menggunakan cloud disk	Instans baru	Semua database	Memulihkan backup cross-region ke instans baru di wilayah tempat backup disimpan, untuk kepatuhan atau disaster recovery.

Pulihkan data ke database yang dikelola sendiri

Untuk memulihkan data ke database yang dikelola sendiri, unduh terlebih dahulu backup dari instans ApsaraDB for MongoDB Anda (Unduh file backup).

Solusi

Arsitektur instans

Catatan penggunaan

Pulihkan cadangan logis ke database yang dikelola sendiri

Replica set instance yang menjalankan MongoDB 4.2 atau lebih lama dan menggunakan local SSD.
Sharded cluster instance yang menjalankan MongoDB 4.2 atau lebih lama dan menggunakan local SSD.

Selalu gunakan versi mongorestore yang kompatibel dengan versi MongoDB Anda — versi lama mungkin tidak mendukung database yang lebih baru (mongorestore).

Pulihkan data dari backup local disk

Replica set instance yang memenuhi kondisi berikut:

Enkripsi Data Transparan (TDE) dinonaktifkan untuk instans tersebut (Aktifkan TDE).
Mesin penyimpanan instans tersebut adalah WiredTiger atau RocksDB.

Tidak ada.

FAQ

Bagaimana cara memulihkan data dari titik waktu sebelumnya?

Rentang waktu ke mana Anda dapat memulihkan data instans bergantung pada periode retensi data backup Anda. Jika ingin memulihkan data dari titik waktu yang lebih awal, lihat Backup retensi jangka panjang.

Berapa lama waktu yang dibutuhkan untuk memulihkan data ke instans baru?

Waktu yang diperlukan untuk memulihkan data ke instans baru bergantung pada tipe penyimpanan, volume data backup, volume oplog yang perlu direplay, dan spesifikasi instans baru. Biasanya berkisar antara beberapa menit hingga beberapa jam.

Pemulihan lengkap terdiri dari tiga tahap berikut. Waktu pemulihan total merupakan jumlah dari ketiga tahap tersebut:

Tahap	Deskripsi	Berkaitan dengan volume data
Create a new instance	Membuat dan mengonfigurasi instans target sesuai spesifikasi yang Anda pilih.	Tidak
Restore a full backup	Memulihkan data backup penuh ke instans baru.	Sangat bergantung pada tipe penyimpanan. Lihat bagian berikut.
Restore an incremental backup (oplog replay)	Menjalankan ulang (replay) data inkremental yang dihasilkan antara titik backup penuh dan titik waktu target ke instans baru.	Ya

Catatan

Saat Anda membuat instans dari titik backup, pemulihan inkremental tidak diperlukan, sehingga tahap ketiga dikecualikan. Saat menggunakan point-in-time recovery untuk membuat instans, data direplay hingga titik yang Anda tentukan, sehingga tahap ketiga termasuk. Tabel berikut membagi lebih lanjut tahap Create a new instance untuk kedua tipe penyimpanan.

Instans berbasis cloud disk

Pemulihan penuh untuk instans berbasis cloud disk menggunakan snapshot cloud disk. Data dipulihkan dengan memasang (mount) snapshot, sehingga tahap ini sebagian besar tidak bergantung pada volume data.

Perkiraan berikut menggunakan replica set instance dengan 4 core dan 8 GB sebagai lingkungan referensi:

Tahap	Perkiraan durasi
Create a new instance	10 hingga 15 menit
Restore a full backup (snapshot mounting)	Biasanya 5 hingga 10 menit dan sebagian besar tidak bergantung pada volume data.
Start and initialize the instance	2 hingga 5 menit
Restore an incremental backup (oplog replay)	Bergantung pada volume data inkremental dan kompleksitas kontennya. Lihat Faktor yang memengaruhi waktu pemulihan.

Contoh: Untuk replica set instance berbasis cloud disk dengan 4 core dan 8 GB, membuat instans dari titik backup biasanya memakan waktu 20 hingga 30 menit, baik volume datanya 20 GB maupun 1 TB. Menggunakan point-in-time recovery untuk membuat instans memerlukan waktu replay tambahan berdasarkan volume oplog yang dihasilkan antara titik backup dan titik waktu target.

Instans berbasis local disk

Pemulihan penuh untuk instans berbasis local disk pertama-tama mengunduh set backup dari backup storage. Setelah itu, set tersebut didekompresi di node target. Durasi bergantung pada ukuran set backup dan jumlah file data.

Perkiraan berikut menggunakan replica set instance dengan 4 core dan 8 GB sebagai lingkungan referensi:

Tahap	Perkiraan durasi
Create a new instance	10 hingga 15 menit
Download the full backup set	Laju referensi adalah 50 hingga 200 GB per jam, tergantung spesifikasi instans dan kondisi jaringan.
Decompress the full backup set	Bergantung pada jumlah file data. Lihat catatan berikut.
Download the oplog	Laju referensi adalah 50 hingga 200 GB per jam.
Replay the oplog	Bergantung pada volume data inkremental dan kompleksitas kontennya. Lihat Faktor yang memengaruhi waktu pemulihan.

Catatan

Waktu dekompresi ditentukan terutama oleh jumlah file data dalam set backup, bukan hanya ukurannya. Semakin banyak koleksi dan indeks, semakin banyak file data dan semakin lama proses dekompresi. Dekompresi biasanya memakan waktu beberapa menit untuk instans tipikal. Untuk instans dengan ratusan ribu koleksi dan indeks, dekompresi bisa memakan waktu beberapa jam atau lebih. Hal ini diharapkan. Untuk informasi lebih lanjut, lihat Masalah performa akibat terlalu banyak database dan koleksi. Jika instans Anda memiliki banyak koleksi dan memerlukan pemulihan cepat, gunakan instans berbasis cloud disk.

Contoh: Pertimbangkan replica set instance berbasis local disk dengan 4 core, 8 GB, dan data 200 GB. Untuk membuat instans dari titik backup, asumsikan laju unduh 100 GB per jam dan sekitar 30 menit untuk dekompresi. Pemulihan end-to-end memakan waktu sekitar 3 jam. Menggunakan point-in-time recovery untuk membuat instans juga memerlukan waktu untuk mengunduh dan menjalankan ulang oplog.

Catatan

Durasi di atas merupakan perkiraan empiris dan bukan merupakan komitmen layanan. Jika tugas pemulihan tidak menunjukkan kemajuan dalam periode yang lama, kirimkan tiket untuk menghubungi dukungan teknis.

Faktor yang memengaruhi waktu pemulihan

Tipe penyimpanan: Pemulihan penuh untuk instans berbasis cloud disk memasang snapshot. Ini jauh lebih cepat daripada mengunduh dan mendekompresi data untuk instans berbasis local disk.
Ukuran set backup: Backup yang lebih besar memerlukan waktu lebih lama untuk diunduh pada instans berbasis local disk. Faktor ini tidak memengaruhi instans berbasis cloud disk.
Jumlah file data: Lebih banyak koleksi dan indeks meningkatkan waktu dekompresi untuk instans berbasis local disk.
Spesifikasi instans baru: Lebih banyak core CPU, memori, dan IOPS disk mempercepat unduhan, dekompresi, dan replay oplog. Memulihkan volume data besar ke instans ber-spesifikasi rendah memakan waktu jauh lebih lama.
Volume oplog: Untuk point-in-time recovery, titik waktu target yang lebih jauh dari titik backup penuh memerlukan lebih banyak data oplog untuk direplay. Hal ini meningkatkan waktu pemulihan.
Kompleksitas konten oplog: Transaksi multi-dokumen dalam oplog harus direplay secara serial dan tidak dapat dipercepat melalui paralelisasi. Dokumen besar dan pembaruan hotspot menyebabkan amplifikasi tulis tambahan. Untuk beban kerja tulis yang kompleks, spesifikasi instans yang lebih tinggi mungkin tidak secara signifikan meningkatkan kecepatan replay.
Laju tulis instans sumber: Untuk point-in-time recovery, laju tulis sumber yang lebih tinggi menghasilkan lebih banyak data oplog dalam periode yang sama. Hal ini meningkatkan waktu replay.
Instans sharded cluster: Config Server, shard, dan node mongos dari instans sharded cluster dipulihkan secara paralel. Waktu penyelesaian bergantung pada komponen terlambat. Biasanya tidak lebih cepat daripada instans replica set dengan volume data yang sama.

Rekomendasi untuk mengurangi waktu pemulihan

Lebih baik gunakan instans berbasis cloud disk. Pemulihan penuh hanya memakan waktu beberapa menit dan tidak terpengaruh oleh volume data atau jumlah koleksi.
Pilih spesifikasi instans baru yang tidak lebih rendah daripada instans sumber. Hal ini mencegah bottleneck spesifikasi selama pemulihan.
Lebih baik buat instans dari titik backup. Jika bisnis Anda memungkinkan, gunakan titik backup yang paling dekat dengan titik waktu target. Hal ini mengurangi atau menghilangkan waktu replay oplog.
Batasi jumlah koleksi dan indeks. Segera hapus koleksi dan indeks yang tidak digunakan untuk secara signifikan mengurangi waktu dekompresi pada instans berbasis local disk.
Aktifkan Backup frekuensi tinggi. Hal ini memperpendek interval antara titik backup dan titik waktu target, sehingga mengurangi volume oplog yang perlu direplay.

Bagaimana cara memulihkan data backup ke instans sumber?

Untuk instans sharded cluster berbasis cloud disk, Anda dapat menggunakan fitur pemulihan database dan tabel untuk memulihkan data ke instans sumber. Untuk informasi lebih lanjut, lihat Pulihkan satu atau beberapa database dari instans ApsaraDB for MongoDB.

Jika instans Anda tidak mendukung pemulihan data ke instans sumber menggunakan fitur pemulihan database dan tabel, Anda dapat memulihkan data backup ke instans baru. Setelah itu, Anda dapat mengalihkan titik akhir dan nomor port instans sumber dan instans baru, atau menggunakan Data Transmission Service (DTS) untuk memigrasikan data dari instans baru ke instans sumber.

Untuk mengubah titik akhir dan port instans, lihat Modify the endpoint and port.
Untuk informasi lebih lanjut tentang migrasi data menggunakan DTS, lihat Solusi migrasi untuk database MongoDB yang dikelola sendiri atau instans ApsaraDB for MongoDB.

Bagaimana cara memulihkan file backup yang telah diunduh ke instans ApsaraDB for MongoDB?

Anda tidak dapat langsung memulihkan file backup yang telah diunduh ke instans ApsaraDB for MongoDB. Anda dapat terlebih dahulu memulihkan data ke database yang dikelola sendiri, lalu menggunakan DTS untuk memigrasikan data tersebut ke instans ApsaraDB for MongoDB. Untuk informasi lebih lanjut tentang migrasi data menggunakan DTS, lihat Solusi migrasi untuk database MongoDB yang dikelola sendiri atau instans ApsaraDB for MongoDB.

Jika tipe instans saya tidak mendukung pengunduhan file backup, bagaimana cara memulihkan data ke database yang dikelola sendiri?

Anda dapat menggunakan DTS untuk memigrasikan data instans ke database yang dikelola sendiri. Untuk informasi lebih lanjut, lihat Solusi migrasi untuk database MongoDB yang dikelola sendiri atau instans ApsaraDB for MongoDB.
Anda dapat menggunakan alat backup dan pemulihan native MongoDB, Mongodump dan Mongorestore, untuk mencadangkan dan memulihkan instans.

Mengapa ID shard dari instans sharded cluster yang dikloning berbeda dari output perintah sh.status()?

Config Server dari instans sharded cluster menyimpan metadata routing untuk semua koleksi yang di-shard, termasuk koleksi config.collections dan config.chunks. Dokumen dalam koleksi ini berisi bidang seperti shard: 'shard01' yang mengidentifikasi shard tempat data tersebut berada. Pemulihan kloning memerlukan data routing lengkap dari instans sumber, sehingga ID shard sumber (nama shard) harus dipertahankan. Akibatnya, ID shard dari instans yang dikloning berbeda dari nama shard yang ditampilkan dalam output sh.status().

Anda dapat memetakannya dengan membandingkan Shard ID (replicaSetName) pada halaman detail instans di Konsol dengan output sh.status(). Pemetaan ini tetap tidak berubah setelah pemulihan.