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.
| Mesin basis data | Petunjuk |
|---|---|
|
Aurora MySQL |
Untuk mengaktifkan pencatatan log biner pada klaster DB Aurora MySQL Atur parameter klaster DB Untuk mengubah parameter Jika Anda mengubah parameter Untuk informasi lebih lanjut, lihat Parameter klaster DB dan instans DB Amazon Aurora dan . |
|
RDS for MySQL |
Untuk mengaktifkan pencatatan log biner pada instans DB Amazon RDS Anda tidak dapat mengaktifkan pencatatan log biner secara langsung pada instans DB Amazon RDS, tetapi Anda dapat mengaktifkannya dengan melakukan salah satu hal berikut ini:
|
|
MySQL (eksternal) |
Untuk mengatur replikasi terenkripsi Untuk mereplikasi data secara aman dengan Aurora MySQL versi 2, Anda dapat menggunakan replikasi terenkripsi. catatanJika Anda tidak perlu menggunakan replikasi terenkripsi, Anda dapat melewati langkah-langkah ini. Berikut ini adalah prasyarat untuk menggunakan replikasi terenkripsi:
Selama replikasi terenkripsi, klaster DB Aurora MySQL berperan sebagai klien untuk server basis data MySQL. Sertifikat dan kunci untuk klien Aurora MySQL ada di dalam file dengan format .pem.
Untuk mengaktifkan pencatatan log biner pada basis data MySQL eksternal
|
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.
| Mesin basis data | Petunjuk |
|---|---|
|
Aurora MySQL |
Untuk mempertahankan log biner pada klaster DB Aurora MySQL Anda tidak memiliki akses ke file binlog untuk klaster DB Aurora MySQL. Oleh karena itu, Anda harus memilih rentang waktu yang sesuai untuk mempertahankan file binlog pada sumber replikasi Anda untuk memastikan bahwa perubahan sudah diterapkan pada replika Anda sebelum file binlog dihapus oleh Amazon RDS. Anda dapat mempertahankan file binlog pada klaster DB Aurora MySQL hingga 90 hari. Jika Anda mengatur replikasi dengan basis data MySQL atau instans DB RDS for MySQL sebagai replika, dan basis data yang Anda buat sebagai replika berukuran sangat besar, pilih rentang waktu yang lama untuk mempertahankan file binlog hingga salinan awal basis data ke replika selesai dan lag replika telah mencapai 0. Untuk mengatur rentang waktu retensi log biner, gunakan prosedur mysql.rds_set_configuration dan tentukan parameter konfigurasi Contoh berikut menetapkan periode retensi untuk file binlog menjadi 6 hari:
Setelah replikasi dimulai, Anda dapat memverifikasi bahwa perubahan telah diterapkan ke replika Anda dengan menjalankan perintah Jika pengaturan ini tidak ditentukan, nilai default untuk Aurora MySQL adalah 24 (1 hari). Jika Anda menentukan nilai untuk |
|
RDS for MySQL |
Untuk mempertahankan log biner pada instans DB Amazon RDS Anda dapat mempertahankan file log biner pada instans DB Amazon RDS dengan mengatur jam retensi binlog sama seperti klaster DB Aurora MySQL, yang sudah dijelaskan dalam baris sebelumnya. Anda juga dapat mempertahankan file binlog pada instans DB Amazon RDS dengan membuat replika baca untuk instans DB. Replika baca ini bersifat sementara dan hanya untuk mempertahankan file binlog. Setelah replika baca dibuat, panggil prosedur mysql.rds_stop_replication pada replika baca. Saat replikasi dihentikan, Amazon RDS tidak akan menghapus file binlog mana pun pada sumber replikasi. Setelah Anda mengatur replikasi dengan replika permanen, Anda dapat menghapus replika baca saat lag replika (bidang |
|
MySQL (eksternal) |
Untuk mempertahankan log biner pada basis data MySQL eksternal Karena file binlog pada basis data MySQL eksternal tidak dikelola oleh Amazon RDS, file ini akan dipertahankan hingga Anda menghapusnya. Setelah replikasi dimulai, Anda dapat memverifikasi bahwa perubahan telah diterapkan ke replika Anda dengan menjalankan perintah |
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.
| Mesin database | Petunjuk |
|---|---|
|
Aurora MySQL |
Untuk membuat salinan cluster DB MySQL Aurora Pilih salah satu metode berikut:
Untuk menentukan nama dan posisi file binlog Pilih salah satu metode berikut:
Untuk membuat dump cluster DB MySQL Aurora Jika target replika Anda adalah database MySQL eksternal atau RDS untuk instance MySQL DB, maka Anda harus membuat file dump dari cluster Aurora DB Anda. Pastikan untuk menjalankan
|
|
RDS for MySQL |
Untuk membuat snapshot instans DB Amazon RDS Buat replika baca instans DB Amazon RDS Anda. Untuk informasi selengkapnya, lihat Membuat replika baca dalam Panduan Pengguna Amazon Relational Database Service.
|
|
MySQL (eksternal) |
Untuk membuat dump basis data MySQL eksternal
|
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:
-
Anda dapat memulihkan dari snapshot cluster DB untuk membuat cluster DB baru. Untuk informasi selengkapnya, lihat Memulihkan dari snapshot klaster DB.
-
Anda dapat mengkloning cluster DB sumber Anda untuk membuat cluster DB baru. Untuk informasi selengkapnya, lihat Mengkloning volume untuk klaster DB Amazon Aurora.
-
Anda dapat memigrasikan data dari snapshot instans DB ke cluster DB baru. Untuk informasi selengkapnya, lihat Migrasi data ke cluster Amazon Aurora My DB SQL.
Gunakan instruksi berikut untuk memuat dump sumber replikasi Anda ke target replika Anda untuk mesin database Anda.
| Mesin database | Petunjuk |
|---|---|
|
Aurora MySQL |
Untuk memuat dump ke cluster DB MySQL Aurora
|
|
RDS for MySQL |
Untuk memuat dump ke instans DB Amazon RDS
|
|
MySQL (eksternal) |
Untuk memuat dump ke basis data MySQL eksternal Anda tidak dapat memuat snapshot DB atau snapshot klaster DB ke dalam basis data MySQL eksternal. Sebagai gantinya, Anda harus menggunakan output dari perintah
|
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
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.
| Mesin basis data | Petunjuk |
|---|---|
|
Aurora MySQL |
Untuk mengaktifkan replikasi dari klaster DB Aurora MySQL
Untuk menggunakan enkripsi SSL, tetapkan nilai akhir menjadi |
|
RDS for MySQL |
Untuk mengaktifkan replikasi dari instans DB Amazon RDS
Untuk menggunakan enkripsi SSL, tetapkan nilai akhir menjadi |
|
MySQL (eksternal) |
Untuk mengaktifkan replikasi dari basis data MySQL eksternal
|
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
-
Menggunakan klien MySQL, sambungkan ke replika Aurora MySQL DB cluster sebagai pengguna utama.
-
Jalankan prosedur yang tersimpan di mysql.rds_start_replication_until (Aurora MySQL versi 3).
Contoh berikut memulai replikasi dan mereplikasi perubahan hingga mencapai lokasi
120di file binermysql-bin-changelog.000777. Dalam skenario pemulihan bencana, asumsikan bahwa lokasi120tepat 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.