Mencadangkan Data Dengan Amazon DocumentDB (Dengan Kompatibilitas MongoDB)

Amazon DocumentDB (dengan kompatibilitas MongoDB) adalah layanan basis data dokumen yang cepat, scalable, sangat tersedia, dan sepenuhnya dikelola yang mendukung beban kerja MongoDB. Anda dapat menggunakan kode aplikasi, driver, dan alat-alat MongoDB 3.6 yang sama untuk menjalankan, mengelola, dan menskalakan beban kerja di Amazon DocumentDB tanpa khawatir tentang pengelolaan infrastruktur yang di bawahnya. Sebagai basis data dokumen, Amazon DocumentDB membuatnya mudah untuk menyimpan, mengkueri, dan mengindeks data JSON. Tulisan ini memperkenalkan Anda untuk kemampuan pencadangan (backup) Amazon DocumentDB yang memungkinkan Anda untuk mengoptimalkan strategi pencadangan Anda untuk kebutuhan spesifik Anda.

AWS membangun Amazon DocumentDB untuk secara unik memecahkan tantangan Anda di sekitar ketersediaan, keandalan, daya tahan, skalabilitas, cadangan, dan banyak lagi. Dengan demikian, kami membangun beberapa kemampuan unik untuk menghilangkan pengangkatan berat yang tidak memiliki perbedaan dan membantu mengurangi biaya. Dengan peluncuran terbaru dari kemampuan untuk menyalin snapshot di AWS Region (lihat Menyalin Cluster Snapshot untuk informasi lebih lanjut), tulisan ini memperkenalkan Anda lebih luas untuk kemampuan pencadangan Amazon DocumentDB.

Tantangan yang dihadapi banyak pengembang ketika mengelola sendiri basisd ata adalah berurusan dengan usaha berat pencadangan basisdata mereka. Hal ini sering melibatkan penulisan skrip, pengujian alur kerja, penjadwalan untuk meminimalkan dampak pada sistem produksi, dan menerapkan solusi pengarsipan. Sebagai layanan basisdata sepenuhnya dikelola, Amazon DocumentDB membuat pencadangan sederhana dan menghilangkan rasa sakit dan komplikasi sehingga Anda dapat fokus pada membangun fungsi untuk pelanggan Anda.

Arsitektur

Amazon DocumentDB dibangun dari bawah ke atas menjadi layanan basisdata cloud-native. Komponen kunci dari arsitekturnya adalah pemisahan penyimpanan dan komputasi. Lapisan penyimpanan bertanggung jawab untuk secara otomatis streaming backup ke Amazon Simple Storage Service (Amazon S3), yang dirancang untuk daya tahan 99.999999999%. Karena pencadangan terjadi pada lapisan penyimpanan, instans komputasi di klaster Anda tidak berpartisipasi dalam pencadangan. Hasilnya adalah bahwa arsitektur Amazon DocumentDB membebaskan instans Anda untuk melakukan lebih banyak pekerjaan untuk pelanggan Anda, dan pencadangan tidak mempengaruhi kinerja basisdata. Diagram berikut menggambarkan arsitektur ini.

Aktif secara default

Sebagai layanan sepenuhnya dikelola, Amazon DocumentDB backup diaktifkan secara default untuk semua klaster. Ini memberi Anda snapshot harian selama jendela cadangan dan jendela retensi 24 jam di mana Anda dapat melakukan pemulihan titik waktu (point-in-time recovery PITR). Secara opsional, Anda dapat memperpanjang jendela penyimpanan hingga 35 hari. Untuk mengimbangi biaya jendela penyimpanan 24 jam default, kami memberikan ukuran cadangan sebesar ukuran cluster penyimpanan Anda secara gratis dalam sebulan. Misalnya, jika Anda memiliki cluster 8 TB, Anda akan menerima cadangan senilai 8 TB secara gratis. Karena pencadangan Amazon DocumentDB diaktifkan secara default dan memberikan setidaknya satu hari kemampuan PITR, Anda dapat yakin bahwa Anda tidak akan menyebarkan aplikasi untuk produksi tanpa cadangan diaktifkan.

Tidak ada dampak pencadangan

Pencadangan memiliki dampak nol pada kinerja cluster dan mengkonsumsi nol I/O atau sumber daya komputasi. Arsitektur cloud-native Amazon DocumentDB memisahkan penyimpanan dan menghitung komponen, dan backup terus mengalir dari volume penyimpanan. Karena backup tidak memerlukan penggunaan instans komputasi Anda, tidak ada dampak pada kinerja instans komputasi, yang menghilangkan kebutuhan untuk pembuatan lebih instans komputasi. Demikian pula, Anda dapat mengambil snapshot manual kapan saja tanpa khawatir tentang dampak aplikasi Anda.

Pemulihan titik waktu hingga 35 hari

Amazon DocumentDB memungkinkan Anda untuk menyesuaikan jendela cadangan klaster Anda dari 1-35 hari. Periode penyimpanan cadangan adalah durasi waktu di mana semua modifikasi ke basisdata dicatat untuk memungkinkan Anda untuk melakukan PITR hingga hitungan detik, ke klaster baru. Meskipun periode retensi default adalah 24 jam, Anda dapat menyesuaikan periode retensi setiap saat, hingga 35 hari, melalui konsol Amazon DocumentDB atau AWS Command Line Interface (AWS CLI). Anda juga dapat mengurangi periode penyimpanan kapan saja. Untuk informasi lebih lanjut, lihat Memulihkan ke Titik dalam Waktu.

Snapshot untuk retensi jangka panjang

Selain melakukan PITRs, Anda dapat mengambil snapshot manual dan mengarsipkannya selama yang Anda inginkan. Snapshot manual yang berada dalam periode penyimpanan cadangan adalah gratis. Ketika snapshot di luar periode retensi cadangan, biaya cadangan penuh adalah $0,02 per GB per bulan (harga bervariasi per Region, lihat harga Amazon DocumentDB). Anda juga dapat berbagi snapshot antar akun dalam Region dan menyalin snapshot dalam akun yang sama di seluruh Region untuk pemulihan bencana atau untuk membuat lingkungan pengembangan. Untuk informasi lebih lanjut, lihat Menyalin Snapshot Cluster.

Mengenkripsi cadangan Anda

Ketika Anda mengenkripsi klaster Anda menggunakan kunci AWS Key Management Service (AWS KMS), Amazon DocumentDB secara otomatis mengenkripsi cadangan dan snapshot terus menerus menggunakan kunci KMS yang sama yang Anda gunakan untuk mengenkripsi klaster Anda. Anda juga dapat memulihkan snapshot yang tidak dienkripsi sebagai cluster terenkripsi.

Memantau dan mengoptimalkan biaya

Anda dapat menggunakan metrik Amazon CloudWatch TotalBackupStorageBilled, SnapsHotStorageUsed, dan BackuPrestitionPeriodStorageDigunakanuntuk meninjau dan memantau jumlah penyimpanan cadangan Amazon DocumentDB Anda gunakan. Kasus penggunaan di bagian ini memberi Anda lebih baik pemahaman tentang bagaimana harga cadangan bekerja dan bagaimana mengoptimalkan biaya. Untuk informasi lebih lanjut, lihat Pemantauan Amazon DocumentDB dengan CloudWatch.

BackupRetentionPeriodStorageUsed merepresentasikan jumlah penyimpanan cadangan yang digunakan untuk menyimpan cadangan terus menerus pada waktu saat ini. Nilai metrik ini tergantung pada ukuran volume klaster dan jumlah perubahan yang Anda buat selama periode penyimpanan. Namun, untuk tujuan penagihan, metrik tidak melebihi ukuran volume cluster selama periode penyimpanan. Misalnya, jika ukuran klaster Anda adalah 100 GiB dan periode retensi Anda adalah 4 hari, nilai maksimum untuk BackupRetentionPeriodStorageUsed adalah 200 GiB (100 GiB + 100 GiB). Snapshot otomatis tidak dihitung terhadap penggunaan penyimpanan cadangan Anda. Jumlah penyimpanan cadangan yang ditagih untuk data dalam jendela penyimpanan tergantung pada berapa banyak perubahan dalam cluster Anda, seperti pembaruan dan penghapusan. Penyimpanan cadangan yang dapat ditagih dalam periode retensi cadangan bisa sesedikit 0 atau setinggi 100 GiB, bahkan jika ukuran perubahan cluster melebihi 100 GiB. Diagram berikut menggambarkan periode retensi snapshot otomatis.

SnapsHotStorageUsed mewakili jumlah penyimpanan cadangan yang digunakan untuk menyimpan snapshot manual di luar periode retensi cadangan. Snapshot manual yang diambil dalam periode penyimpanan tidak dihitung terhadap penyimpanan cadangan Anda. Ukuran setiap snapshot adalah ukuran volume cluster pada saat Anda mengambil snapshot.

Nilai SnapsHotStorageUsed tergantung pada jumlah snapshot yang Anda simpan dan ukuran setiap snapshot. Misalnya, Anda memiliki satu snapshot di luar periode penyimpanan dan ukuran volume cluster adalah 100 GiB ketika snapshot diambil. Jumlah SnapsHotStorageUsed adalah 100 GiB. Diagram berikut membandingkan periode retensi untuk snapshot otomatis dan manual.

Untuk mengaitkan dua contoh sebelumnya bersama-sama, TotalBackupStorageBilling mewakili jumlah BackuPretentionPeriodStorageUsed dan SnapsHotStorageUsed, dikurangi jumlah penyimpanan cadangan gratis sama dengan ukuran cluster volume untuk 1 hari. Misalnya, jika ukuran cluster Anda adalah 100 GiB, Anda memiliki periode retensi 4 hari, dan Anda memiliki satu snapshot di luar periode retensi, maksimum TotalBackupStorageBilled adalah 200 GiB = 100 GiB (ukuran klaster) + 0-100 GiB (BackupRetentionPeriodStorageUsed ) + 100 GiB ( SnapshotStorageUsed ) – 100 GiB (ukuran klaster). Metrik ini dihitung secara independen untuk setiap klaster Amazon DocumentDB setiap jam.

Untuk mengoptimalkan biaya, pertimbangkan skenario di mana Anda mengambil snapshot manual setiap hari selama periode 30 hari. Jika jendela penyimpanan Anda adalah 1 hari, BackuPrestitionPeriodStorageUsed akan menjadi 2.900 GiB (29 * 100 GiB — snapshot manual untuk hari ini termasuk dalam jendela penyimpanan dan tidak diperhitungkan dalam BackuPretentionPeriodStorageUsed ).

Dalam skenario ini, Anda dapat mengoptimalkan biaya dengan meningkatkan periode penyimpanan hingga 30 hari. Jika Anda memperpanjang periode penyimpanan hingga 30 hari, cadangan maksimum Anda paling banyak 100 GiB. Jika data di klaster tidak berubah selama periode penyimpanan 30 hari, Anda tidak membayar apa pun untuk pencadangan. Selain itu, daripada snapshot manual harian, yang 29 kali lebih mahal, Anda sekarang dapat melakukan PITR kapan saja dengan jendela cadangan 31 hari Anda.

Untuk mengendalikan biaya, Anda dapat memantau jumlah penyimpanan yang dikonsumsi oleh pencadangan berkelanjutan dan snapshot manual yang bertahan di luar periode penyimpanan. Anda dapat mengurangi interval penyimpanan cadangan dan menghapus snapshot manual bila tidak diperlukan lagi.

Mencadangkan, memulihkan, mengimpor, dan mengekspor data

Terlepas dari kemampuan sepenuhnya dikelola yang disediakan oleh Amazon DocumentDB, Anda juga dapat menggunakan peralatanmongodump, mongorestore, mongoexport, dan mongoimport untuk membuat cadangan atau memindahkan data masuk dan keluar dari klaster Amazon DocumentDB Anda. Untuk informasi lebih lanjut, lihat Mencadangkan, Memulihkan, Mengimpor, dan Mengekspor Data.

Ringkasan

Amazon DocumentDB menyediakan Anda dengan sejumlah kemampuan yang membantu Anda mencadangkan dan mengembalikan data Anda berdasarkan kasus penggunaan Anda. Untuk informasi lebih lanjut, lihat Praktik Terbaik untuk Amazon DocumentDB. Jika Anda baru untuk Amazon DocumentDB, lihat Memulai dengan Amazon DocumentDB. Jika Anda berencana untuk bermigrasi ke Amazon DocumentDB, lihat Migrasi ke Amazon DocumentDB.

Tentang Penulis

Joseph Idziorek adalah Manajer Produk Utama di Amazon Web Services.

Artikel ini diterjemahkan dari Backing up data dengan Amazon DocumentDB (dengan kompatibilitas MongoDB) dan ditulis oleh Joseph Idziorek.