Menyiapkan replikasi log biner untuk Aurora MySQL - Amazon Aurora

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

Menyiapkan replikasi log biner untuk Aurora MySQL

Pengaturan replikasi MySQL dengan Aurora MySQL memerlukan langkah-langkah berikut, yang dibahas secara terperinci:

1. Aktifkan pencatatan log biner pada sumber replikasi

Temukan petunjuk tentang cara mengaktifkan pencatatan log biner pada sumber replikasi untuk mesin basis data Anda.

2. Pertahankan log biner pada sumber replikasi hingga tidak diperlukan lagi

Jika Anda menggunakan replikasi log biner MySQL, Amazon RDS tidak akan mengelola proses replikasi. Akibatnya, Anda harus memastikan bahwa file binlog pada sumber replikasi Anda dipertahankan hingga perubahan sudah diterapkan ke replika. Dengan mempertahankannya, Anda akan dapat memulihkan basis data sumber Anda jika terjadi kegagalan.

Gunakan petunjuk berikut untuk mempertahankan log biner untuk mesin basis data Anda.

3. Buat salinan atau dump sumber replikasi Anda

Anda menggunakan snapshot, klon, atau dump sumber replikasi Anda untuk memuat salinan dasar data Anda ke replika Anda. Kemudian Anda mulai mereplikasi dari titik itu.

Gunakan petunjuk berikut untuk membuat salinan atau dump sumber replikasi untuk mesin database Anda.

4. Muat dump ke target replika Anda (jika diperlukan)

Jika Anda berencana untuk memuat data dari dump database MySQL yang berada di luar Amazon RDS, Anda mungkin ingin membuat instans EC2 untuk menyalin file dump ke. Kemudian Anda dapat memuat data ke cluster DB atau instans DB Anda dari instans EC2 itu. Dengan menggunakan pendekatan ini, Anda dapat mengompresi file dump sebelum menyalinnya ke instans EC2 untuk mengurangi biaya jaringan yang terkait dengan penyalinan data ke Amazon RDS. Anda juga dapat mengenkripsi file dump untuk mengamankan data saat data tersebut ditransfer melewati jaringan.

catatan

Jika Anda membuat cluster Aurora MySQL DB baru sebagai target replika Anda, maka Anda tidak perlu memuat file dump:

Gunakan instruksi berikut untuk memuat dump sumber replikasi Anda ke target replika Anda untuk mesin database Anda.

5. Buat pengguna replikasi pada sumber replikasi Anda

Buat ID pengguna pada sumber yang digunakan hanya untuk replikasi. Contoh berikut adalah untuk RDS untuk MySQL atau database sumber MySQL eksternal.

mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';

Untuk database sumber MySQL Aurora, parameter cluster skip_name_resolve DB diatur ke 1 (ON) dan tidak dapat dimodifikasi, jadi Anda harus menggunakan alamat IP untuk host alih-alih nama domain. Untuk informasi selengkapnya, lihat skip_name_resolve di dokumentasi MySQL.

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

Pengguna memerlukan hak akses REPLICATION CLIENT dan REPLICATION SLAVE. Berikan hak akses ini kepada pengguna.

Jika Anda perlu menggunakan replikasi terenkripsi, wajibkan koneksi SSL untuk pengguna replikasi. Misalnya, Anda dapat menggunakan salah satu pernyataan berikut untuk meminta koneksi SSL di akun repl_user pengguna.

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
catatan

Jika REQUIRE SSL tidak disertakan, koneksi replikasi dapat kembali ke koneksi yang tidak terenkripsi tanpa peringatan.

6. Aktifkan replikasi pada target replika Anda

Sebelum Anda mengaktifkan replikasi, kami menyarankan agar Anda mengambil snapshot manual klaster DB Aurora MySQL atau target replika instans DB RDS for MySQL. Jika masalah muncul dan Anda harus membuat ulang replikasi dengan klaster DB atau target replika instans DB, Anda dapat memulihkan klaster DB atau instans DB dari snapshot ini daripada harus mengimpor data ke dalam target replika Anda lagi.

Gunakan petunjuk berikut untuk mengaktifkan replikasi untuk mesin basis data Anda.

Jika replikasi gagal, itu dapat mengakibatkan peningkatan besar yang tidak disengaja I/O pada replika, yang dapat menurunkan kinerja. Jika replikasi gagal atau tidak lagi diperlukan, Anda dapat menjalankan prosedur tersimpan mysql.rds_reset_external_master versi 2) atau mysql.rds_reset_external_source ( 3) untuk menghapus konfigurasi replikasi.

Mengatur lokasi untuk menghentikan replikasi ke replika baca

Di Aurora MySQL versi 3.04 dan yang lebih tinggi, Anda dapat memulai replikasi lalu menghentikannya di lokasi file log biner yang ditentukan menggunakan prosedur tersimpan mysql.rds_start_replication_until (Aurora MySQL versi 3).

Untuk memulai replikasi ke replika baca dan menghentikan replikasi di lokasi tertentu
  1. Menggunakan klien MySQL, sambungkan ke replika Aurora MySQL DB cluster sebagai pengguna utama.

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

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

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

Replikasi berhenti secara otomatis ketika stop point tercapai. Peristiwa RDS berikut dibuat: Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Jika Anda menggunakan replikasi berbasis GTID, gunakan prosedur tersimpan mysql.rds_start_replication_until_gtid (Aurora MySQL versi 3), bukan prosedur tersimpan mysql.rds_start_replication_until (Aurora MySQL versi 3). Untuk informasi selengkapnya tentang replikasi berbasis GTID, lihat Menggunakan replikasi GTID berbasis.

7. Pantau replika Anda

Saat Anda mengatur replikasi MySQL dengan klaster DB Aurora MySQL, Anda harus memantau peristiwa failover untuk klaster DB Aurora MySQL jika klaster DB ini merupakan target replika. Jika terjadi failover, maka klaster DB yang merupakan target replika Anda dapat dibuat ulang pada host baru dengan alamat jaringan yang berbeda. Untuk informasi tentang cara memantau peristiwa failover, lihat Bekerja dengan pemberitahuan RDS acara Amazon.

Anda juga dapat memantau seberapa jauh target replika tertinggal di belakang sumber replikasi dengan terhubung ke target replika dan menjalankan perintah SHOW SLAVE STATUS (Aurora MySQL versi 2) atau SHOW REPLICA STATUS (Aurora MySQL versi 3). Dalam output perintah, bidang Seconds Behind Master akan memberi tahu Anda seberapa jauh target replika tertinggal di belakang sumber.

penting

Jika Anda memutakhirkan cluster DB dan menentukan grup parameter khusus, pastikan untuk me-reboot cluster secara manual setelah pemutakhiran selesai. Melakukannya membuat cluster menggunakan pengaturan parameter kustom baru Anda, dan memulai ulang replikasi binlog.

Menyinkronkan kata sandi antara sumber dan target replikasi

Saat Anda mengubah akun pengguna dan kata sandi pada sumber replikasi menggunakan pernyataan SQL, perubahan tersebut direplikasi ke target replikasi secara otomatis.

Jika Anda menggunakan Konsol Manajemen AWS, the AWS CLI, atau RDS API untuk mengubah kata sandi utama pada sumber replikasi, perubahan tersebut tidak secara otomatis direplikasi ke target replikasi. Jika Anda ingin menyinkronkan pengguna master dan kata sandi master antara sistem sumber dan target, Anda harus membuat sendiri perubahan yang sama pada target replikasi.