View a markdown version of this page

Konfigurasikan replikasi tertunda dengan Amazon Aurora MySQL - Amazon Aurora
Kasus penggunaan untuk replikasi tertundaKonfigurasikan replikasi eksternal dengan penundaanUbah replikasi tertunda untuk replika baca yang adaMenetapkan lokasi untuk menghentikan replikasi ke replika bacaPromosikan replika yang telah dibacaTopik terkait

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Konfigurasikan replikasi tertunda dengan Amazon Aurora MySQL

Anda dapat menggunakan replikasi tertunda sebagai strategi pemulihan bencana dengan Aurora MySQL. Dengan replikasi tertunda, Anda menentukan jumlah waktu minimum, dalam detik, untuk menunda replikasi dari sumber ke replika baca. Jika terjadi bencana, seperti tabel yang terhapus secara tidak sengaja, Anda menyelesaikan langkah-langkah berikut untuk memulihkan dari bencana dengan cepat:

  1. Hentikan replikasi ke replika baca sebelum sumber mengirimkan perubahan yang menyebabkan bencana. Gunakan prosedur yang tersimpan di mysql.rds_stop_replication untuk menghentikan replikasi.

  2. Mulai replikasi dan tentukan bahwa replikasi berhenti secara otomatis di lokasi file log. Anda menentukan lokasi tepat sebelum bencana menggunakan prosedur tersimpan mysql.rds_start_replication_until(Aurora MySQL versi 3).

  3. Promosikan replika baca menjadi cluster DB sumber baru dengan menggunakan instruksi diMempromosikan replika baca ke cluster DB untuk Aurora MySQL.

catatan

Aurora MySQL mendukung replikasi tertunda untuk versi 8.4.8 dan lebih tinggi.

  • Gunakan prosedur yang tersimpan untuk mengonfigurasi replikasi tertunda. Anda tidak dapat mengonfigurasi replikasi tertunda dengan Konsol Manajemen AWS AWS CLI, the, atau Amazon RDS API.

  • Anda dapat menggunakan replikasi berdasarkan pengidentifikasi transaksi global (GTID) dalam konfigurasi replikasi tertunda pada Aurora MySQL versi 8.4.8 dan yang lebih tinggi.

  • Jika Anda menggunakan GTID-based replikasi, gunakan prosedur ter mysql.rds_start_replication_until_gtid (Aurora MySQL versi 3) simpan alih-alih prosedur mysql.rds_start_replication_until(Aurora MySQL versi 3) tersimpan.

  • Aurora MySQL mendukung replikasi multi-sumber dengan hingga 15 saluran. Gunakan varian _for_channel prosedur untuk mengonfigurasi replikasi tertunda pada saluran tertentu.

Kasus penggunaan untuk replikasi tertunda

Replikasi tertunda pada Aurora MySQL berlaku untuk replikasi berbasis log biner. Ini termasuk replikasi dari cluster DB penulis Aurora MySQL ke replika binlog, dari sumber MySQL eksternal ke cluster Aurora MySQL DB, atau melintasi saluran replikasi multi-sumber. Ini tidak berlaku untuk Replika Aurora dalam satu cluster DB, karena mereka dibaca dari penyimpanan cluster bersama daripada dari log biner. Kasus penggunaan umum meliputi yang berikut:

  • Pemulihan bencana dari kesalahan operator — Pertahankan replika binlog yang tertinggal sumber dengan interval yang ditetapkan. Jika pernyataan destruktif berjalan secara tidak sengaja (misalnya, menjatuhkan tabel), hentikan replikasi pada replika yang tertunda sebelum sumber menerapkan perubahan. Kemudian putar ke depan tepat sebelum acara menggunakan mysql.rds_start_replication_until(Aurora MySQL versi 3) ataumysql.rds_start_replication_until_gtid (Aurora MySQL versi 3). Akhirnya, promosikan replika. Pendekatan ini menyediakan jalur pemulihan yang lebih cepat daripada pemulihan point-in-time, yang memerlukan pemulihan kerusakan dan pemutaran ulang log biner.

  • Perlindungan terhadap kerusakan data logis — Replika yang tertunda juga melindungi terhadap penerapan aplikasi yang salah atau migrasi yang secara bertahap merusak data. Karena replika memegang status pra-korupsi selama penundaan, Anda dapat memulihkan sebelum transaksi yang salah diterapkan.

  • Versi utama dan blue/green peningkatan — Simpan replika binlog yang tertunda selama peningkatan atau blue/green penerapan sebagai jaring pengaman, sehingga Anda dapat kembali ke keadaan yang diketahui baik jika peningkatan menimbulkan masalah.

  • Ubah pengambilan data (CDC) dari sumber eksternal — Saat Anda menelan perubahan ke cluster Aurora MySQL DB dari sumber MySQL eksternal, penundaan yang disengaja memberi Anda buffer terkontrol sebelum perubahan diterapkan di hilir.

  • Inspeksi historis tanpa pemulihan — Kueri replika yang tertunda untuk melihat seperti apa data Anda di waktu sebelumnya. Ini berguna untuk men-debug, mengaudit, atau menyelidiki apa yang berubah, tanpa menyediakan klon atau menjalankan pemulihan point-in-time.

  • Menguji perilaku aplikasi di bawah jeda replikasi — Gunakan penundaan yang digelembungkan secara artifisial untuk memvalidasi bagaimana aplikasi Anda berperilaku saat replika tertinggal, dan untuk menjalankan tes regresi untuk kondisi sensitif lag, tanpa harus menghasilkan beban berat untuk mereproduksi lag.

Konfigurasikan replikasi eksternal dengan penundaan

Untuk mengkonfigurasi sumber eksternal dengan replikasi tertunda, gunakan prosedur ter mysql.rds_set_source_eksternal_dengan_delay (Aurora MySQL versi 8.4.8 dan lebih tinggi) simpan. Untuk informasi selengkapnya tentang semua prosedur yang disimpan replikasi, lihatMengkonfigurasi, memulai, dan menghentikan replikasi log biner (binlog).

Contoh (saluran default): 

CALL mysql.rds_set_external_source_with_delay(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600);

Contoh (saluran tertentu): 

CALL mysql.rds_set_external_source_with_delay_for_channel(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600,
  'channel_1');

Parameter:

host_name

Nama host atau alamat IP dari sumber eksternal.

host_port

Nomor port dari sumber eksternal.

replication_user_name

Pengguna replikasi pada sumber eksternal.

replication_user_password

Kata sandi untuk pengguna replikasi.

mysql_binary_log_file_name

Nama file log biner pada sumber eksternal.

mysql_binary_log_file_location

Posisi dalam file log biner untuk memulai replikasi.

ssl_encryption

Setel parameter ini 1 untuk mengaktifkan enkripsi SSL untuk koneksi replikasi, atau 0 untuk menonaktifkan enkripsi SSL.

delay

Penundaan minimum dalam detik (0—259.200).

channel

(hanya untuk varian saluran) Nama saluran untuk replikasi multi-sumber.

Kendala:

  • Aurora MySQL mendukung maksimal 15 saluran replikasi.

  • Setiap saluran harus mereplikasi dari sumber yang berbeda (kombinasi host:port).

  • Penundaan harus antara 0 dan 259.200 detik (72 jam).

  • Hentikan replikasi sebelum memodifikasi konfigurasi saluran.

Ubah replikasi tertunda untuk replika baca yang ada

Untuk mengubah replikasi tertunda untuk replika baca yang ada, jalankan prosedur tersimpan mysql.rds_set_source_delay (Aurora MySQL versi 8.4.8 dan lebih tinggi). Untuk informasi selengkapnya tentang semua prosedur yang disimpan replikasi, lihatMengkonfigurasi, memulai, dan menghentikan replikasi log biner (binlog).

Untuk memodifikasi replikasi tertunda untuk replika baca yang ada:

  1. Menggunakan klien MySQL, sambungkan ke replika baca sebagai pengguna admin.

  2. Gunakan prosedur yang tersimpan di mysql.rds_stop_replication untuk menghentikan replikasi.

  3. Jalankan prosedur tersimpan mysql.rds_set_source_delay (Aurora MySQL versi 8.4.8 dan lebih tinggi).

  4. Gunakan prosedur yang tersimpan di mysql.rds_start_replication untuk memulai replikasi.

Contoh (saluran default): 

CALL mysql.rds_set_source_delay(3600);

Contoh (saluran tertentu): 

CALL mysql.rds_set_source_delay_for_channel(3600, 'channel_1');

Ini menentukan bahwa replikasi ke replika baca tertunda setidaknya satu jam (3.600 detik). Nilai penundaan harus antara 0 dan 259.200 detik (72 jam).

catatan

Hentikan replikasi sebelum mengatur penundaan. Jika replikasi sedang berjalan, Anda menerima kesalahan yang meminta Anda untuk menelepon mysql.rds_stop_replication (atau mysql.rds_stop_replication_for_channel untuk saluran tertentu) terlebih dahulu.

Menetapkan lokasi untuk menghentikan replikasi ke replika baca

Setelah menghentikan replikasi ke replika baca, Anda dapat memulai replikasi dan kemudian menghentikannya di lokasi file log biner yang ditentukan menggunakan prosedur tersimpan mysql.rds_start_replication_until(Aurora MySQL versi 3).

Untuk memulai replikasi dan berhenti di lokasi tertentu:

  1. Menggunakan klien MySQL, sambungkan ke replika baca sebagai pengguna admin.

  2. Jalankan prosedur tersimpan mysql.rds_start_replication_until(Aurora MySQL versi 3).

Contoh:

CALL mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

Ini memulai replikasi dan mereplikasi perubahan hingga mencapai lokasi 120 dalam file log mysql-bin-changelog.000777 biner. Dalam skenario pemulihan bencana, asumsikan bahwa lokasi 120 tepat sebelum bencana.

Replikasi berhenti secara otomatis ketika Aurora MySQL mencapai titik berhenti. Aurora MySQL menghasilkan peristiwa berikut:Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Jika Anda menggunakan GTID-based replikasi, gunakan prosedur ter mysql.rds_start_replication_until_gtid (Aurora MySQL versi 3) simpan sebagai gantinya.

Promosikan replika yang telah dibaca

Setelah replikasi dihentikan, dalam skenario pemulihan bencana, Anda dapat mempromosikan replika baca menjadi cluster DB sumber baru. Untuk informasi tentang mempromosikan replika baca, lihat Mempromosikan replika baca ke cluster DB untuk Aurora MySQL.

Topik terkait