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

ApsaraDB for MongoDB menyediakan beberapa solusi pemulihan data untuk berbagai skenario.

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	Rentang pemulihan	Skenario
Pulihkan satu atau beberapa database dari instans ApsaraDB for MongoDB	Instans replica set yang menggunakan cloud disk Instans kluster sharded yang menggunakan cloud disk	Instans asal	Semua database Beberapa database	Memulihkan koleksi atau dokumen yang tidak sengaja dihapus.
	Instans replica set 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 set cadangan	Instans standalone Instans replica set	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	Instans replica set	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	Instans kluster sharded	Instans baru	Semua database	Memulihkan data instans ke titik waktu tertentu.
Pemulihan data cross-region	Instans replica set yang menggunakan cloud disk Instans kluster sharded yang menggunakan cloud disk	Instans baru	Semua database	Memulihkan cadangan cross-region ke instans baru di wilayah tempat cadangan 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

Instans replica set yang menjalankan MongoDB 4.2 atau lebih lama dan menggunakan local SSD.
Instans kluster sharded yang menjalankan MongoDB 4.2 atau lebih lama dan menggunakan local SSD.

Gunakan selalu versi mongorestore yang kompatibel dengan versi MongoDB Anda—versi lama mungkin tidak mendukung database versi baru (mongorestore).

Pulihkan data dari backup local disk

Instans replica set 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 sebelumnya, lihat Backup retensi jangka panjang.

Bagaimana cara memulihkan data backup ke instans sumber?

Untuk instans kluster sharded berbasis cloud disk, Anda dapat menggunakan fitur pemulihan database dan tabel untuk memulihkan data ke instans sumber. Untuk informasi selengkapnya, 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 menukar titik akhir dan nomor port antara 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 Ubah titik akhir dan port.
Untuk informasi selengkapnya 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 Data Transmission Service (DTS) untuk memigrasikan data tersebut ke instans ApsaraDB for MongoDB. Untuk informasi selengkapnya 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 Data Transmission Service (DTS) untuk memigrasikan data instans ke database yang dikelola sendiri. Untuk informasi selengkapnya, 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 kluster sharded yang dikloning berbeda dari output perintah sh.status()?

Instans yang dikloning mewarisi seluruh data routing dari instans sumber, termasuk ID shard-nya (nama shard). Dokumen-dokumen dalam koleksi tersebut berisi bidang seperti shard: 'shard01' yang mengidentifikasi shard tempat data tersebut berada. Hal ini menyebabkan ketidaksesuaian antara ID shard yang dipertahankan dan nama shard yang ditampilkan dalam output sh.status() dari instans yang dikloning.

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