Backup dan pemulihan untuk Amazon RDS

Amazon RDS menyertakan fitur untuk mengotomatiskan pencadangan database. Amazon RDS menciptakan snapshot volume penyimpanan instans basis data Anda, mencadangkan seluruh instans DB, bukan basis data individu. Dengan menggunakan Amazon RDS, Anda dapat membuat jendela cadangan untuk pencadangan otomatis, membuat snapshot instans database, dan berbagi dan menyalin snapshot di seluruh Wilayah dan akun.

Amazon RDS menyediakan dua opsi berbeda untuk mencadangkan dan memulihkan instans DB Anda:

• Pencadangan otomatis menyediakan point-in-time pemulihan (PITR) instans DB Anda. Backup diaktifkan secara default saat Anda membuat instans DB.

  Amazon RDS melakukan pencadangan harian penuh data Anda selama jendela cadangan yang Anda tentukan saat Anda membuat instans DB. Anda dapat mengonfigurasi periode penyimpanan hingga 35 hari untuk pencadangan otomatis. Amazon RDS juga mengunggah log transaksi untuk instans DB ke Amazon S3 setiap 5 menit. Amazon RDS menggunakan cadangan harian Anda bersama dengan log transaksi database Anda untuk memulihkan instans DB Anda. Anda dapat memulihkan instans ke detik berapa pun selama periode retensi, hinggaLatestRestorableTime (biasanya, lima menit terakhir).

  Untuk menemukan waktu pemulihan terbaru untuk instans DB Anda, gunakan panggilanDescribeDBInstances API. Atau lihat tab Deskripsi untuk database di konsol Amazon RDS.

  Saat Anda memulai PITR, log transaksi digabungkan dengan cadangan harian yang paling tepat untuk memulihkan instans DB Anda ke waktu yang diminta.

• Snapshot DB adalah pencadangan yang dapat Anda gunakan untuk memulihkan instans DB Anda ke status yang diketahui sesering yang Anda suka. Anda kemudian dapat mengembalikan ke keadaan itu kapan saja. Anda dapat menggunakan konsol Amazon RDS atau panggilanCreateDBSnapshot API untuk membuat snapshot DB. Snapshot ini disimpan sampai Anda menggunakan konsol atau panggilanDeleteDBSnapshot API untuk menghapusnya secara eksplisit.

Kedua opsi cadangan ini didukung untuk Amazon RDS diAWS Backup, yang juga menyediakan fitur lainnya. PertimbangkanAWS Backup untuk menggunakan untuk menyiapkan paket cadangan standar untuk database Amazon RDS Anda, dan gunakan opsi pencadangan instans yang dimulai pengguna saat rencana cadangan untuk database tertentu bersifat unik.

Amazon RDS mencegah akses langsung ke penyimpanan dasar yang digunakan oleh instans DB. Ini juga mencegah Anda mengekspor database secara langsung pada instans DB RDS ke disk lokalnya. Dalam beberapa kasus, Anda dapat menggunakan fungsi backup dan restore asli menggunakan utilitas klien. Misalnya, Anda dapat menggunakan perintah mysqldump dengan database MySQL Amazon RDS untuk mengekspor database ke mesin klien lokal Anda. Dalam beberapa kasus, Amazon RDS juga menyediakan opsi tambahan untuk melakukan pencadangan asli dan pemulihan database. Misalnya, Amazon RDS menyediakan prosedur tersimpan untuk mengekspor dan mengimpor cadangan database RDS dari database SQL Server.

Pastikan untuk menguji proses pemulihan database Anda secara menyeluruh dan dampaknya terhadap klien database sebagai bagian dari pendekatan pencadangan dan pemulihan keseluruhan Anda.

Menggunakan data DNS CNAME untuk mengurangi dampak klien selama pemulihan database

Saat Anda memulihkan database dengan menggunakan snapshot instans PITR atau DB RDS, instans DB baru dengan titik akhir baru akan dibuat. Dengan cara ini, Anda dapat membuat beberapa instans DB dari snapshot DB tertentu atau titik waktu. Ada pertimbangan khusus saat Anda memulihkan instans DB RDS untuk mengganti instans DB RDS langsung. Misalnya, Anda harus menentukan bagaimana Anda akan mengarahkan klien database yang ada ke instance baru dengan gangguan dan modifikasi minimal. Anda juga harus memastikan kontinuitas dan konsistensi dalam data dalam database dengan mempertimbangkan waktu data yang dipulihkan dan waktu pemulihan ketika instance baru mulai menerima penulisan.

Anda dapat membuat data DNS CNAME terpisah yang mengarah ke titik akhir instans DB Anda dan meminta klien Anda menggunakan nama DNS ini. Kemudian Anda dapat memperbarui CNAME untuk menunjuk ke titik akhir baru yang dipulihkan tanpa harus memperbarui klien database Anda.

Atur Time to Live (TTL) untuk catatan CNAME Anda ke nilai yang sesuai. TTL yang Anda tentukan menentukan berapa lama rekaman di-cache dengan resolver DNS sebelum permintaan lain dibuat. Penting untuk dicatat bahwa beberapa resolver atau aplikasi DNS mungkin tidak menghormati TTL, dan mereka mungkin menyimpan catatan lebih lama dari TTL. Untuk Amazon Route 53, jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi lebih lanjut, lihat Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda.

Aplikasi dan sistem operasi klien mungkin juga menyimpan informasi DNS yang harus Anda siram atau restart untuk memulai permintaan resolusi DNS baru dan mengambil catatan CNAME yang diperbarui.

Saat Anda memulai pemulihan database dan mengalihkan lalu lintas ke instans yang dipulihkan, verifikasi bahwa semua klien Anda menulis ke instans yang dipulihkan, bukan instans sebelumnya. Arsitektur data Anda mungkin mendukung pemulihan database Anda, memperbarui DNS untuk mengalihkan lalu lintas ke instans yang dipulihkan, dan kemudian memulihkan data apa pun yang mungkin masih ditulis ke instans sebelumnya. Jika ini bukan masalahnya, Anda dapat menghentikan instans yang ada sebelum memperbarui data DNS CNAME. Maka semua akses berasal dari instance Anda yang baru dipulihkan. Ini untuk sementara dapat menyebabkan masalah koneksi untuk beberapa klien database Anda yang dapat Anda tangani secara individual. Untuk mengurangi dampak klien, Anda dapat melakukan pemulihan database selama jendela pemeliharaan.

Tulis aplikasi Anda untuk menangani kegagalan koneksi database dengan anggun dengan percobaan ulang menggunakan backoff eksponensial. Hal ini memungkinkan aplikasi Anda untuk pulih ketika koneksi database menjadi tidak tersedia selama pemulihan tanpa menyebabkan aplikasi Anda tiba-tiba mogok.

Setelah menyelesaikan proses pemulihan, Anda dapat menyimpan instans sebelumnya dalam keadaan berhenti. Atau Anda dapat menggunakan aturan grup keamanan untuk membatasi lalu lintas ke instans sebelumnya sampai Anda puas bahwa itu tidak lagi diperlukan. Untuk pendekatan penonaktifan bertahap, pertama-tama batasi akses ke database yang berjalan oleh grup keamanan. Anda akhirnya dapat menghentikan instans saat tidak lagi diperlukan. Akhirnya, ambil snapshot instans basis data dan hapus.