Cara menggunakan mysql reset replication

Fitur-fitur replikasi Aurora MySQL merupakan kunci untuk ketersediaan dan kinerja yang tinggi dari klaster Anda. Aurora mempermudah penciptaan atau pengukuran ulang klaster dengan penyediaan hingga 15 Aurora Replica.

Semua replika bekerja dari data acuan yang sama. Jika beberapa instans basis data dalam status offline, yang lain akan tetap tersedia untuk melanjutkan pemrosesan kueri atau mengambil alih sebagai penulis jika diperlukan. Aurora secara otomatis akan menyebarkan koneksi hanya-baca Anda ke beberapa instans basis data, yang akan membantu klaster Aurora untuk mendukung beban kerja yang intensif untuk kueri.

Setelah itu, Anda dapat menemukan informasi tentang cara kerja replikasi Aurora MySQL dan cara menyesuaikan pengaturan replikasi untuk ketersediaan dan kinerja terbaik.

Setelah itu, Anda dapat mempelajari fitur replikasi untuk klaster Aurora menggunakan replikasi satu-master. Klaster seperti ini merupakan default untuk Aurora. Untuk informasi selengkapnya tentang klaster multi-master Aurora, lihat Bekerja dengan klaster multi-master Aurora.

Topik

• Menggunakan Aurora Replicas
• Opsi replikasi untuk Amazon Aurora MySQL
• Pertimbangan kinerja untuk replikasi Amazon Aurora MySQL
• Patching zero-downtime (ZDR) untuk Amazon Aurora MySQL
• Pemonitoran replikasi Amazon Aurora MySQL
• Pereplikasian klaster DB Amazon Aurora MySQLWilayah AWS
• Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi binlog)
• Penggunaan replikasi berbasis GTID untukAmazon Aurora MySQL

Menggunakan Aurora Replicas

Replika Aurora adalah titik akhir terpisah dalam klaster DB Aurora, paling baik digunakan untuk operasi baca penskalaan dan meningkatkan ketersediaan. Hingga 15 Aurora Replicas dapat didistribusikan di seluruh Zona Ketersediaan yang meliputi klaster DB di seluruhWilayah AWS. Meskipun volume klaster DB terdiri dari beberapa salinan data untuk klaster DB, data dalam volume klaster direpresentasikan sebagai volume tunggal yang logis ke instans primer dan Aurora Replica dalam klaster DB tersebut. Untuk informasi selengkapnya tentang Aurora Replica, lihat Aurora Replicas.

Aurora Replica berfungsi dengan baik untuk penyekalaan baca karena didedikasikan sepenuhnya untuk membaca operasi pada volume klaster Anda. Operasi tulis dikelola oleh instans primer. Karena volume klaster dibagikan di antara semua instans dalam klaster DB Aurora MySQL Anda, pekerjaan tambahan untuk mereplikasi salinan data untuk setiap Aurora Replica tidak diperlukan. Sebaliknya, replika baca MySQL harus memutar ulang, pada utas tunggal, semua operasi tulis dari instans DB sumber daya ke penyimpanan data lokal replika tersebut. Pembatasan ini dapat memengaruhi kemampuan dari replika baca MySQL untuk mendukung volume lalu lintas baca yang besar.

Dengan Aurora MySQL, saat sebuah Aurora Replica dihapus, titik akhir instansnya akan segera dibuang, dan Aurora Replica akan dibuang dari titik akhir pembaca. Jika ada pernyataan yang dijalankan dari Aurora Replica yang sudah dihapus, ada tiga menit masa tenggang. Pernyataan yang ada dapat diselesaikan dengan baik selama masa tenggang. Setelah masa tenggang berakhir, Aurora Replica akan dimatikan dan dihapus.

Aurora Replica untuk Aurora MySQL selalu menggunakan tingkat isolasi transaksi default REPEATABLE READ untuk operasi pada tabel InnoDB. Anda dapat menggunakan perintah SET TRANSACTION ISOLATION LEVEL untuk mengubah tingkat transaksi yang berlaku untuk instans utama dari sebuah klaster DB Aurora MySQL saja. Pembatasan ini bertujuan untuk menghindari kunci tingkat pengguna pada Aurora Replica, dan memungkinkan penyekalaan Aurora Replica untuk mendukung ribuan koneksi pengguna aktif sambil tetap menjaga lag replika seminimal mungkin.

Pernyataan DDL yang berjalan pada instans primer dapat menginterupsi koneksi basis data pada Aurora Replica terkait. Jika koneksi Aurora Replica secara aktif menggunakan sebuah objek basis data, seperti tabel, dan objek tersebut dimodifikasi pada instans primer menggunakan pernyataan DDL, koneksi Aurora Replica dapat terinterupsi.

Wilayah China (Ningxia) tidak mendukung replika baca lintas WIlayah.

Opsi replikasi untuk Amazon Aurora MySQL

Anda dapat mengatur replikasi dengan opsi-opsi berikut:

• Dua klaster DB Aurora MySQL berbedaWilayah AWS, dengan menciptakan sebuah replika baca lintas Wilayah dari sebuah klaster DB Aurora MySQL.

  Untuk informasi selengkapnya, lihat Pereplikasian klaster DB Amazon Aurora MySQLWilayah AWS.

• Dua klaster DB Aurora MySQL dalam hal yang samaWilayah AWS, menggunakan replikasi log (binlog) MySQL.

  Untuk informasi selengkapnya, lihat Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi binlog).

• Instans DB RDS for MySQL sebagai sumber dan klaster DB Aurora MySQL, dengan membuat replika baca Aurora dari instans DB RDS for MySQL.

  Anda dapat menggunakan pendekatan ini untuk membawa perubahan data yang ada dan yang sedang berlangsung ke Aurora MySQL selama migrasi ke Aurora. Untuk informasi selengkapnya, lihat Memigrasikan data dari instans DB MySQL ke klaster DB Amazon Aurora MySQL menggunakan snapshot DB.

  Anda juga dapat menggunakan pendekatan ini untuk meningkatkan skalabilitas kueri baca untuk data Anda. Caranya adalah dengan melakukan kueri pada data menggunakan satu instans DB atau lebih dalam sebuah klaster Aurora MySQL baca saja. Untuk informasi selengkapnya, lihat Penggunaan Amazon Aurora untuk mengukur pembacaan database MySQL Anda.

• Klaster DB Aurora MySQL menjadi satuWilayah AWSdan hingga lima klaster DB Aurora MySQL baca saja Aurora di Wilayah yang berbeda, dengan menciptakan basis data global Aurora.

  Anda dapat menggunakan database global Aurora untuk mendukung aplikasi dengan jejak di seluruh dunia. Klaster DB Aurora MySQL utama memiliki instans Writer dan hingga 15 Aurora Replica. Klaster DB Aurora MySQL sekunder baca saja masing-masing dapat terdiri dari sebanyak 16 Aurora Replica. Untuk informasi selengkapnya, lihat Menggunakan Amazon Aurora global database.

Mem-boot ulang instans utama klaster DB Amazon Aurora juga secara otomatis mem-boot ulang Aurora Replica untuk klaster DB tersebut, untuk menetapkan kembali titik masuk yang menjamin konsistensi baca/tulis di seluruh klaster DB.

Pertimbangan kinerja untuk replikasi Amazon Aurora MySQL

Fitur berikut dapat membantu Anda menyesuaikan kinerja replikasi Aurora MySQL.

Mulai di Aurora MySQL 1.17.4, fitur kompresi log replika secara otomatis mengurangi bandwidth jaringan untuk pesan replikasi. Karena setiap pesan ditransmisikan ke semua Replika Aurora, manfaat yang diberikan lebih besar untuk klaster yang lebih besar. Fitur ini melibatkan beberapa overhead CPU pada node penulis untuk melakukan kompresi. Dengan demikian, fitur ini hanya tersedia pada kelas instans 8xlarge dan 16xlarge, yang memiliki kapasitas CPU yang tinggi. Fitur ini diaktifkan secara default pada kelas-kelas instans ini. Anda dapat mengontrol fitur ini dengan mematikan parameter aurora_enable_replica_log_compression. Misalnya, Anda dapat mematikan kompresi log replika untuk kelas instans yang lebih besar jika node penulis Anda berada sudah mendekati kapasitas maksimum CPU.

Mulai dari Aurora MySQL 1.17.4, fitur pemfilteran binlog secara otomatis akan mengurangi bandwidth jaringan untuk pesan replikasi. Karena Aurora Replica tidak menggunakan informasi binlog yang disertakan dalam pesan replikasi, data tersebut dihilangkan dari pesan yang dikirim ke node-node tersebut. Anda dapat mengontrol fitur ini dengan mengubah parameter aurora_enable_repl_bin_log_filtering. Parameter ini berada dalam kondisi menyala secara default. Karena optimisasi ini dimaksudkan supaya transparan, Anda dapat mematikan pengaturan ini hanya selama diagnosis atau pemecahan masalah untuk masalah yang terkait dengan replikasi. Misalnya, Anda dapat melakukannya untuk mencocokkan perilaku dari klaster Aurora MySQL lama yang tidak menyediakan fitur ini.

Patching zero-downtime (ZDR) untuk Amazon Aurora MySQL

Fitur mulai zero-downtime (ZDR) dapat mempertahankan beberapa atau semua koneksi aktif untuk instans DB selama beberapa jenis mulai ulang. ZDR berlaku untuk memulai ulang yang dilakukan Aurora secara otomatis untuk mengatasi kondisi kesalahan, misalnya saat replika mulai tertinggal terlalu jauh di belakang sumbernya.

Mekanisme ZDR beroperasi dengan dasar upaya terbaik. Versi Aurora MySQL, kelas instans, kondisi kesalahan, operasi SQL yang kompatibel, dan faktor lain yang menentukan penerapan ZDR dapat berubah sewaktu-waktu.

Di Aurora MySQL 1.* versi di mana ZDR tersedia, Anda mengaktifkan fitur ini dengan mengaktifkanaurora_enable_zdrparameter dalam grup parameter klaster klaster. ZDR untuk Aurora MySQL 2.* membutuhkan versi 2.10 dan lebih tinggi. ZDR tersedia di semua versi minor Aurora MySQL 3.*. Di Aurora MySQL versi 2 dan 3, mekanisme ZDR diaktifkan secara default dan Aurora tidak menggunakanaurora_enable_zdrparameter.

Aurora melaporkan di halaman Peristiwa terkait dengan mulai ulang zero-downtime. Aurora mencatat sebuah peristiwa ketika mencoba mulai ulang menggunakan mekanisme ZDR. Peristiwa ini menyatakan mengapa Aurora melakukan mulai ulang. Kemudian Aurora mencatat peristiwa lain ketika mulai ulang selesai. Peristiwa akhir ini melaporkan berapa lama proses mengambil, dan berapa banyak koneksi yang diawetkan atau dijatuhkan selama mulai ulang. Anda dapat berkonsultasi log kesalahan database untuk melihat rincian lebih lanjut tentang apa yang terjadi selama mulai ulang.

Meskipun koneksi tetap utuh setelah operasi ZDR yang sukses, beberapa variabel dan fitur diinisialisasi ulang. Jenis informasi berikut ini tidak dipertahankan melalui mulai ulang disebabkan oleh mulai ulang zero-downtime:

• Variabel global. Aurora mengembalikan variabel sesi, tetapi tidak mengembalikan variabel global setelah mulai ulang.

• Variabel status. Secara khusus, nilai uptime yang dilaporkan oleh status mesin diatur ulang.

• LAST_INSERT_ID.

• Status auto_increment dalam memori untuk tabel. Status kenaikan otomatis dalam memori diinisialisasi ulang. Untuk informasi lebih lanjut tentang nilai kenaikan otomatis, lihat Manual Referensi MySQL.

• Informasi diagnostik dari tabel INFORMATION_SCHEMA dan PERFORMANCE_SCHEMA. Informasi diagnostik ini juga muncul dalam output perintah seperti SHOW PROFILE dan SHOW PROFILES.

Tabel berikut menunjukkan versi, peran instans, kelas instans, dan keadaan lain yang menentukan apakah Aurora dapat menggunakan mekanisme ZDR saat memulai ulang instans DB di klaster Anda.

Pemonitoran replikasi Amazon Aurora MySQL

Penyekalaan baca dan ketersediaan yang tinggi tergantung dari waktu lag minimal. Anda dapat memonitor seberapa jauh sebuah Aurora Replica tertinggal di belakang instans primer dari klaster DB Aurora MySQL Anda dengan memonitor Amazon CloudWatch AuroraReplicaLagmetrik. Metrik AuroraReplicaLag direkam dalam setiap Aurora Replica.

Instans DB primer juga mencatatAuroraReplicaLagMaximumdanAuroraReplicaLagAmazon CloudWatch metrik. Metrik AuroraReplicaLagMaximum akan merekam jumlah maksimum lag antara instans DB primer dan setiap Aurora Replica dalam klaster DB. Metrik AuroraReplicaLag akan merekam jumlah minimum lag antara instans DB primer dan setiap Aurora Replica dalam klaster DB.

Jika Anda memerlukan nilai terbaru dari lag Aurora Replica, Anda dapat melakukan kueri pada tabel recrystallisations pada instans utama dalam klaster DB Aurora MySQL Anda dan memeriksa nilai dalam kolom Replica_lag_in_msec. Nilai kolom ini disediakan untuk Amazon CloudWatch sebagai nilai untukAuroraReplicaLagmetrik. Lag Aurora Replica juga direkam pada setiap Aurora Replica dalam tabel INFORMATION_SCHEMA.REPLICA_HOST_STATUS dalam klaster DB Aurora MySQL Anda.

Untuk informasi lebih lanjut tentang memantau instans RDS dan CloudWatch metrik, lihatMetrik pemantauan di klaster Amazon Aurora.

Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi binlog)

Karena Amazon Aurora MySQL kompatibel dengan MySQL, Anda dapat mengatur replikasi antara database MySQL dan klaster DB Amazon Aurora MySQL. Jenis replikasi ini menggunakan replikasi biner log MySQL, dan secara umum disebut sebagai replikasi binlog. Jika Anda menggunakan replikasi binlog dengan Aurora, sebaiknya database MySQL Anda menjalankan MySQL versi 5.5 atau yang lebih baru. Anda dapat mengatur replikasi jika klaster DB Aurora MySQL Anda merupakan sumber replikasi atau replika. Anda dapat mereplikasi dengan sebuah instans DB Amazon RDS , sebuah basis data MySQL eksternal pada Amazon RDS, atau klaster DB Aurora MySQL lainnya.

Anda tidak dapat menggunakan replikasi binlog ke atau dari jenis klaster Aurora tertentu. Secara khusus, replikasi binlog tidak tersedia untukAurora Serverless v1dan klaster multi-master. JikaSHOW MASTER STATUSdanSHOW SLAVE STATUS(Aurora MySQL versi 1 dan 2)SHOW REPLICA STATUS(Aurora MySQL versi 3) pernyataan mengembalikan tidak ada output, periksa bahwa cluster yang Anda gunakan adalah salah satu yang mendukung replikasi binlog.

Anda juga dapat mereplikasi dengan sebuah instans DB RDS for MySQL atau klaster DB Aurora MySQL di klaster DB lainnyaWilayah AWS. Saat Anda melakukan replikasiWilayah AWS, pastikan klaster DB dan instans DB Anda dapat diakses oleh publik. Jika cluster Aurora MySQL DB berada di subnet pribadi di VPC Anda, gunakan VPC peering antaraWilayah AWS. Untuk informasi selengkapnya, lihat DBgugusdalam VPC yang diakses oleh instans EC2 dalam VPC yang berbeda.

Jika Anda ingin mengonfigurasi replikasi antara sebuah klaster DB Aurora MySQL dan sebuah klaster DB Aurora MySQL di wilayah lainnya, Anda dapat menciptakan sebuah klaster DB Aurora MySQL sebagai sebuah replika baca di wilayah lainnyaWilayah AWSdari klaster DB sumber. Untuk informasi selengkapnya, lihat Pereplikasian klaster DB Amazon Aurora MySQLWilayah AWS.

Dengan Aurora MySQL 2.04 dan yang lebih tinggi, Anda dapat mereplikasi antara Aurora MySQL dan sebuah sumber atau target eksternal yang menggunakan pengidentifikasi transaksi global (GTID) untuk replikasi. Pastikan parameter terkait GTID dalam klaster DB Aurora MySQL tersebut memiliki pengaturan yang kompatibel dengan status GTID dari basis data eksternal. Untuk mempelajari cara melakukannya, lihat Penggunaan replikasi berbasis GTID untukAmazon Aurora MySQL. Di Aurora MySQL versi 3.01 dan yang lebih tinggi, Anda dapat memilih cara menetapkan GTID ke transaksi yang direplikasi dari sumber yang tidak menggunakan GTID. Untuk informasi tentang prosedur tersimpan yang mengontrol pengaturan itu, lihatmysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL versi 3 dan lebih tinggi).

Saat Anda mereplikasi antara Aurora MySQL dan MySQL, pastikan Anda hanya menggunakan tabel InnoDB. Jika Anda memiliki tabel MyISAM yang ingin Anda replikasi, Anda dapat mengonversinya menjadi InnoDB sebelum mengatur replikasi dengan perintah berikut.

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

Pengaturan replikasi MySQL dengan Aurora MySQL melibatkan langkah-langkah berikut, yang dibahas secara terperinci dalam topik ini:

1. Aktifkan log biner pada sumber replikasi

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

3. Ciptakan sebuah snapshot dari sumber replikasi Anda

4. Muat snapshot ke dalam target replika Anda

5. Buat pengguna replikasi pada sumber replikasi Anda

6. Aktifkan replikasi pada target replika Anda

7. Monitor replika Anda

Pengaturan replikasi dengan MySQL atau klaster DB Aurora lainnya

Untuk mengatur replikasi Aurora dengan MySQL, lakukan langkah-langkah berikut.

1. Aktifkan log biner pada sumber replikasi

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

2. Simpan 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. Pemeliharaan ini membantu Anda memulihkan basis data sumber Anda meski terjadi kegagalan.

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

CALL mysql.rds_set_configuration('binlog retention hours', 144);

3. Ciptakan sebuah snapshot dari sumber replikasi Anda

Anda dapat menggunakan sebuah snapshot dari sumber replikasi untuk memuat salinan data dasar ke replika Anda, agar kemudian dapat mulai mereplikasi dari titik tersebut.

Gunakan petunjuk berikut untuk menciptakan sebuah snapshot dari sumber replikasi untuk mesin basis data Anda.

4. Muat snapshot ke dalam target replika Anda

Jika Anda berencana memuat data dari dump database MySQL yang berada di luar Amazon RDS, Anda mungkin ingin membuat instans EC2 untuk menyalin file dump, lalu memuat data ke klaster DB atau instans DB Anda dari instans EC2 tersebut. Dengan menggunakan pendekatan ini, Anda dapat mengompres file pembuangan sebelum menyalinnya ke instans EC2 untuk mengurangi biaya jaringan yang terkait dengan penyalinan data ke Amazon RDS. Anda juga dapat mengenkripsi file atau file-file pembuanganuntuk mengamankan data karena data tersebut ditransfer ke seluruh jaringan.

Gunakan petunjuk berikut untuk memuat snapshot dari sumber replikasi ke dalam target replika untuk mesin basis data Anda.

5. Buat pengguna replikasi pada sumber replikasi Anda

Buat sebuah ID pengguna pada sumber yang digunakan untuk replikasi saja. Berikut adalah contohnya.

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

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

Jika Anda perlu menggunakan replikasi terenkripsi, diperlukan koneksi SSL untuk pengguna replikasi. Misalnya, Anda dapat menggunakan salah satu dari pernyataan berikut untuk mensyaratkan koneksi SSL pada akun pengguna repl_user.

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';

GRANT USAGE ON *.* TO 'repl_user'@'<domain_name>' REQUIRE SSL;

Jika REQUIRE SSL tidak disertakan, koneksi replikasi dapat kembali ke koneksi yang tidak terenkripsi secara diam-diam.

6. Aktifkan replikasi pada target replika Anda

Sebelum Anda mengaktifkan replikasi, kami menyarankan agar Anda mengambil sebuah snapshot manual dari klaster DB Aurora MySQL atau target replika instans DB RDS for MySQL. Jika masalah muncul dan Anda harus membangun 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 dalam I/O yang tidak disengaja pada replika, yang dapat menurunkan kinerja. Jika replikasi gagal atau tidak lagi diperlukan, Anda dapat menjalankanmysql.rds_reset_external_masterdisimpan prosedur untuk menghapus konfigurasi replikasi.

7. Monitor replika Anda

Saat Anda mengatur replikasi MySQL dengan sebuah klaster DB Aurora MySQL, Anda harus memantau peristiwa failover pada klaster DB Aurora MySQL saat klaster DB merupakan target replika. Jika terjadi failover, maka klaster DB yang merupakan target replika Anda dapat diciptakan ulang pada sebuah host baru dengan sebuah alamat jaringan yang berbeda. Untuk informasi tentang cara pemonitoran peristiwa failover, lihat Bekerja dengan pemberitahuan kejadian Amazon RDS.

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

Penghentian replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya

Untuk menghentikan replikasi binlog dengan sebuah instans DB MySQL, database MySQL eksternal, atau klaster DB Aurora lainnya, ikuti langkah-langkah ini, yang dibahas secara terperinci dalam topik ini.

1. Hentikan replikasi log biner pada target replika

2. Matikan log biner pada sumber replikasi

1. Hentikan replikasi log biner pada target replika

Temukan petunjuk tentang cara menghentikan replikasi log biner untuk mesin database Anda.

2. Matikan log biner pada sumber replikasi

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

Penggunaan Amazon Aurora untuk mengukur pembacaan database MySQL Anda

Anda dapat menggunakan Amazon Aurora dengan instans DB MySQL Anda untuk memanfaatkan kemampuan penskalaan baca Amazon Aurora dan memperluas beban kerja baca untuk instans DB MySQL Anda. Untuk menggunakan Aurora untuk menskala baca instans DB MySQL Anda, buat klaster DB Amazon Aurora MySQL dan buat menjadi replika baca dari instans DB MySQL Anda. Ini berlaku untuk satu instans DB RDS for MySQL, atau sebuah database MySQL yang dijalankan secara eksternal pada Amazon RDS.

Untuk informasi tentang penciptaan sebuah klaster DB Amazon Aurora, lihat Membuat klaster Amazon Aurora DB.

Saat Anda mengatur replikasi antara instans DB MySQL dan klaster DB Amazon Aurora Anda, pastikan untuk mengikuti panduan ini:

• Gunakan alamat titik akhir klaster DB Amazon Aurora saat Anda merujuk pada klaster DB Amazon Aurora MySQL Anda. Jika terjadi failover, maka Aurora Replica yang dipromosikan ke instans primer untuk klaster DB Aurora MySQL akan terus menggunakan alamat titik akhir klaster DB.

• Pertahankan binlog pada instans penulis Anda hingga Anda memverifikasi bahwa mereka telah diterapkan ke Aurora Replica. Pemeliharaan ini untuk memastikan agar Anda dapat memulihkan instans penulis Anda meski terjadi kegagalan.

Izin yang dibutuhkan untuk memulai replikasi pada sebuah klaster DB Amazon Aurora MySQL bersifat terbatas dan tidak tersedia pada pengguna utama Amazon RDS Anda. Karena itu, Anda harus menggunakan prosedur mysql_rds_set_external_master dan mysql_rds_start_replication Amazon RDS untuk mengatur replikasi antara klaster DB Amazon Aurora MySQL dan instans DB MySQL Anda.

Pemulaian replikasi antara instans sumber eksternal dan instans DB MySQL pada Amazon RDS

1. Buat instans DB MySQL sumber menjadi baca saja:

   mysql> FLUSH TABLES WITH READ LOCK;
   mysql> SET GLOBAL read_only = ON;
   

2. Jalankan perintah SHOW MASTER STATUS pada instans DB MySQL sumber untuk menentukan lokasi binlog. Anda akan menerima output yang serupa dengan contoh berikut:

   File                        Position
   ------------------------------------
    mysql-bin-changelog.000031      107
   ------------------------------------
   

3. Salin database dari instans DB MySQL eksternal ke klaster DB Amazon Aurora MySQL eksternal menggunakan mysqldump. Untuk database yang sangat besar, Anda mungkin ingin menggunakan prosedur di Mengimpor data ke instans DB MySQL atau MariaDB dengan waktu henti yang berkurang di Panduan Pengguna Amazon Relational Database Service.

   Untuk Linux, macOS, atau Unix:

   mysqldump \
       --databases <database_name> \
       --single-transaction \
       --compress \
       --order-by-primary \
       -u <local_user> \
       -p <local_password> | mysql \
           --host aurora_cluster_endpoint_address \
           --port 3306 \
           -u <RDS_user_name> \
           -p <RDS_password> 

   Untuk Windows:

   mysqldump ^
       --databases <database_name> ^
       --single-transaction ^
       --compress ^
       --order-by-primary ^
       -u <local_user> ^
       -p <local_password> | mysql ^
           --host aurora_cluster_endpoint_address ^
           --port 3306 ^
           -u <RDS_user_name> ^
           -p <RDS_password>

   Pastikan tidak ada spasi antara opsi -p dan kata sandi yang dimasukkan.

   Gunakan opsi --host, --user (-u), --port dan -p dalam perintah mysql untuk menentukan nama host, nama pengguna, port, dan kata sandi untuk terhubung ke klaster DB Aurora Anda. Nama host adalah nama DNS dari titik akhir klaster DB Amazon Aurora, sebagai contoh, mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com. Anda dapat menemukan nilai titik akhir dalam detail klaster di Amazon RDS Management Console.

4. Buat instans DB MySQL sumber menjadi dapat ditulis lagi:

   mysql> SET GLOBAL read_only = OFF;
   mysql> UNLOCK TABLES;
   

   Untuk informasi lebih lanjut tentang cara membuat backup untuk digunakan dengan replikasi, lihat Backing up a source or replica by making it read only di dokumentasi MySQL.

5. Dalam Amazon RDS Management Console, tambahkan alamat IP peladen yang menjadi host database MySQL sumber ke grup keamanan VPC untuk klaster DB Amazon Aurora. Untuk informasi selengkapnya tentang memodifikasi grup kerahasiaan VPC, lihat Grup keamanan untuk VPC Anda dalam Panduan Pengguna Amazon Virtual Private Cloud.

   Mungkin Anda juga harus mengonfigurasi jaringan lokal Anda untuk mengizinkan koneksi dari alamat IP klaster DB Amazon Aurora Anda, agar dapat berkomunikasi dengan instans MySQL sumber Anda. Untuk menemukan alamat IP klaster DB Amazon Aurora, gunakan perintah host.

   host <aurora_endpoint_address>

   Nama host adalah nama DNS dari titik akhir klaster DB Amazon Aurora.

6. Dengan menggunakan klien pilihan Anda, hubungkan ke instans MySQL eksternal dan buat akun pengguna MySQL yang akan digunakan untuk replikasi. Akun ini digunakan semata-mata untuk replikasi dan harus dibatasi pada domain Anda untuk meningkatkan keamanan. Berikut adalah contoh.

   CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';

7. Untuk instans MySQL eksternal, berikan hak akses REPLICATION CLIENT dan REPLICATION SLAVE kepada pengguna replikasi Anda. Misalnya, untuk memberikan hak akses REPLICATION CLIENT dan REPLICATION SLAVE pada semua database untuk pengguna 'repl_user' bagi domain Anda, jalankan perintah berikut.

   GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
       IDENTIFIED BY '<password>'; 

8. Ambil sebuah snapshot manual dari klaster DB Aurora MySQL untuk dijadikan sebagai replika baca sebelum mengatur replikasi. Jika Anda harus membangun ulang replikasi dengan sebuah klaster DB sebagai replika baca, Anda dapat memulihkan klaster DB Aurora MySQL dari snapshot ini daripada harus mengimpor data dari instans DB MySQL ke dalam sebuah klaster DB Aurora MySQL baru.

9. Jadikan klaster DB Amazon Aurora sebagai replika. Hubungkan ke klaster DB Amazon Aurora sebagai pengguna master dan identifikasi database MySQL sumber sebagai master replikasi dengan menggunakan prosedur mysql_rds_set_external_master. Gunakan nama file log master dan posisi log master yang Anda tentukan pada Langkah 2. Berikut adalah contoh.

   For Aurora MySQL version 1 and 2:
   CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,
       'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
   
   For Aurora MySQL version 3 and higher:
   CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306,
       'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
   

10. Pada klaster DB Amazon Aurora, terbitkan prosedur mysql_rds_start_replication untuk memulai replikasi.

    CALL mysql.rds_start_replication; 

Setelah Anda membangun replikasi antara instans DB MySQL sumber dan klaster DB Amazon Aurora, Anda dapat menambahkan Aurora Replica ke klaster DB Amazon Aurora Anda. Kemudian Anda dapat terhubung ke Aurora Replica untuk menskalakan baca data Anda. Untuk informasi tentang penciptaan sebuah Aurora Replica, lihat Menambahkan Aurora Replica ke klaster DB.

Mengoptimalkan replikasi log biner

Berikut, Anda dapat belajar bagaimana mengoptimalkan kinerja replikasi log biner dan memecahkan masalah terkait di Aurora MySQL.

Diskusi ini menganggap bahwa Anda sudah familiar dengan mekanisme replikasi log biner MySQL dan cara kerjanya. Untuk informasi latar belakang, lihat Implementasi replikasi dalam dokumentasi MySQL.

Replikasi log biner multiutas (Aurora MySQL versi 3 dan lebih tinggi)

Dengan replikasi log biner multithreaded, thread SQL membaca peristiwa dari log relai dan mengantrekannya untuk thread pekerja SQL untuk diterapkan. Thread SQL pekerja dikelola oleh thread koordinator. Peristiwa log biner diterapkan secara parallel bila memungkinkan.

Ketika instance Aurora MySQL dikonfigurasi untuk menggunakan replikasi log biner, secara default instance replika menggunakan replikasi single-threaded. Untuk mengaktifkan replikasi multithreaded, Anda memperbaruireplica_parallel_workersparameter ke nilai yang lebih besar dari nol dalam grup parameter kustom Anda.

Opsi konfigurasi berikut dapat membantu Anda menyesuaikan replikasi multiutas. Untuk informasi penggunaan, lihatReplikasi dan Opsi Logging Biner dan Variabeldi dalamMySQL.

Konfigurasi optimal tergantung pada beberapa faktor. Misalnya, kinerja untuk replikasi log biner dipengaruhi oleh karakteristik beban kerja database Anda dan kelas instans DB yang sedang dijalankan replika. Oleh karena itu, kami menyarankan Anda menguji secara menyeluruh semua perubahan pada parameter konfigurasi ini sebelum menerapkan pengaturan parameter baru ke instans produksi.

• replica_parallel_workers

• replica_parallel_type

• replica_preserve_commit_order

• binlog_transaction_dependency_tracking

• binlog_transaction_dependency_history_size

• binlog_group_commit_sync_delay

• binlog_group_commit_sync_no_delay_count

Mengoptimalkan replikasi binlog (Aurora MySQL 2.10 dan lebih tinggi)

Dalam Aurora MySQL 2.10 dan lebih tinggi, Aurora secara otomatis menerapkan optimasi dikenal sebagai binlog I/O cache ke replikasi log biner. Dengan membuat cache peristiwa binlog yang paling baru dilakukan, pengoptimalan ini dirancang untuk meningkatkan kinerja utas sampah binlog sambil membatasi dampak pada transaksi latar depan pada instance sumber binlog.

Memori yang digunakan untuk fitur ini tidak bergantung pada pengaturan binlog_cache MySQL.

Fitur ini tidak berlaku untuk instans Aurora DB yang menggunakan kelas instans db.t2 dan db.t3.

Anda tidak perlu menyesuaikan parameter konfigurasi apa pun untuk mengaktifkan pengoptimalan ini. Secara khusus, jika Anda menyesuaikan parameter konfigurasi aurora_binlog_replication_max_yield_seconds ke nilai non-nol di versi Aurora MySQL sebelumnya, atur kembali ke nol untuk Aurora MySQL 2.10 dan lebih tinggi.

Variabel status aurora_binlog_io_cache_reads dan aurora_binlog_io_cache_read_requests tersedia di Aurora MySQL 2.10 dan lebih tinggi. Variabel status ini membantu Anda untuk memantau seberapa sering data dibaca dari cache binlog I/O.

• aurora_binlog_io_cache_read_requestsmenunjukkan jumlah permintaan baca I/O binlog dari cache.

• aurora_binlog_io_cache_readsmenunjukkan jumlah pembacaan I/O binlog yang mengambil informasi dari cache.

Kueri SQL berikut menghitung persentase binlog membaca permintaan yang mengambil keuntungan dari informasi cache. Dalam hal ini, makin dekat rasionya hingga 100, makin baik.

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

Fitur cache I/O binlog juga menyertakan metrik baru yang terkait dengan utas dump binlog. Utas dumpadalah utas yang dibuat saat replika binlog baru terhubung ke instans sumber binlog.

Metrik utas dump dicetak ke log database setiap 60 detik dengan awalan [Dump thread metrics]. Metrik mencakup informasi untuk setiap replika binlog seperti Secondary_id, Secondary_uuid, nama file binlog, dan posisi yang dibaca setiap replika. Metrik juga mencakup Bytes_behind_primary mewakili jarak dalam byte antara sumber replikasi dan replika. Metrik ini mengukur lag utas I/O replika. Angka tersebut berbeda dengan lag dari replika SQL applier thread, yang diwakili oleh metrik seconds_behind_master pada replika binlog. Anda dapat menentukan apakah replika binlog mengejar sumber atau tertinggal dengan memeriksa apakah jaraknya berkurang atau bertambah.

Mengoptimalkan replikasi binlog (Aurora MySQL 2.04.5 hingga 2.09)

Untuk mengoptimalkan replikasi log biner untuk Aurora MySQL, Anda menyesuaikan parameter pengoptimalan tingkat klaster berikut. Parameter ini membantu Anda menentukan keseimbangan yang tepat antara latensi pada instans sumber binlog dan jeda replikasi.

• aurora_binlog_use_large_read_buffer

• aurora_binlog_read_buffer_size

• aurora_binlog_replication_max_yield_seconds

Untuk klaster yang kompatibel dengan MySQL 5.7, Anda dapat menggunakan parameter ini di Aurora MySQL versi 2.04.5 hingga 2.09.*. Dalam Aurora MySQL 2.10.0 dan lebih tinggi, parameter ini digantikan oleh optimasi cache I/O binlog dan Anda tidak perlu menggunakannya.

Untuk klaster yang kompatibel dengan MySQL 5.6, Anda dapat menggunakan parameter ini di Aurora MySQL versi 1.17.6 dan terbaru.

Topik

• Ikhtisar buffer baca besar dan pengoptimalan hasil maks
• Parameter terkait
• Mengaktifkan mekanisme hasil maksimal untuk replikasi log biner
• Menonaktifkan optimasi hasil maksimal replikasi log biner
• Menonaktifkan buffer baca besar

Ikhtisar buffer baca besar dan pengoptimalan hasil maks

Anda mungkin mengalami penurunan kinerja replikasi log biner saat utas dump log biner mengakses volume klaster Aurora saat klaster memproses sejumlah besar transaksi. Anda bisa menggunakan parameternya aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds, dan aurora_binlog_read_buffer_size untuk membantu meminimalkan jenis pertentangan ini.

Misalkan Anda memiliki situasi di manaaurora_binlog_replication_max_yield_secondsdiatur ke lebih besar dari 0 dan file binlog saat ini dari thread dump aktif. Dalam hal ini, utas dump log biner menunggu hingga beberapa detik untuk file binlog saat ini diisi oleh transaksi. Periode tunggu ini menghindari pertentangan yang dapat timbul dari mereplikasi setiap binlog peristiwa secara individual. Namun, melakukannya meningkatkan lag replika untuk replika log biner. Replika tersebut dapat jatuh di belakang sumber dengan jumlah detik yang sama sebagai pengaturan aurora_binlog_replication_max_yield_seconds.

File binlog saat ini berarti file binlog yang sedang dibaca oleh utas dump untuk melakukan replikasi. Kami menganggap bahwa file binlog aktif ketika file binlog memperbarui atau terbuka untuk diperbarui oleh transaksi masuk. Setelah Aurora MySQL mengisi file binlog aktif, MySQL menciptakan dan beralih ke file binlog baru. File binlog lama menjadi tidak aktif. Hal ini tidak diperbarui oleh transaksi masuk lagi.

Sebelum menyesuaikan parameter ini, ukur latensi dan throughput transaksi Anda dari waktu ke waktu. Anda mungkin menemukan bahwa kinerja replikasi log biner stabil dan memiliki latensi rendah bahkan jika ada pertentangan sesekali.

aurora_binlog_use_large_read_buffer

Jika parameter ini diatur ke 1, Aurora MySQL mengoptimalkan replikasi log biner berdasarkan pengaturan parameter aurora_binlog_read_buffer_size dan aurora_binlog_replication_max_yield_seconds. Jika aurora_binlog_use_large_read_buffer adalah 0, Aurora MySQL mengabaikan nilai-nilai parameter aurora_binlog_read_buffer_size dan aurora_binlog_replication_max_yield_seconds.

Utas dump log biner dengan buffer baca yang lebih besar meminimalkan jumlah operasi I/O baca dengan membaca lebih banyak peristiwa untuk setiap I/O. Parameter aurora_binlog_read_buffer_size mengatur ukuran buffer baca. Buffer baca yang besar dapat mengurangi pertentangan log biner untuk beban kerja yang menghasilkan data binlog dalam jumlah besar.

Parameter ini hanya berpengaruh ketika klaster juga memiliki pengaturan aurora_binlog_use_large_read_buffer=1.

Meningkatkan ukuran buffer baca tidak memengaruhi kinerja replikasi log biner. Utas dump log biner tidak menunggu pembaruan transaksi untuk mengisi buffer baca.

Jika beban kerja Anda memerlukan latensi transaksi yang rendah, dan Anda dapat mentolerir beberapa jeda replikasi, Anda dapat meningkatkan parameter aurora_binlog_replication_max_yield_seconds. Parameter ini mengontrol properti hasil maksimum dari replikasi log biner di klaster Anda.

Parameter ini hanya berpengaruh ketika klaster juga memiliki pengaturan aurora_binlog_use_large_read_buffer=1.

Aurora MySQL mengenali perubahan apa pun pada nilai parameter aurora_binlog_replication_max_yield_seconds segera. Anda tidak perlu memulai ulang instans DB. Namun, saat Anda mengaktifkan pengaturan ini, utas dump hanya mulai menghasilkan saat file binlog saat ini mencapai ukuran maksimum 128 MB dan diputar ke file baru.

Parameter terkait

Gunakan parameter klaster DB berikut untuk mengaktifkan optimasi binlog.

Mengaktifkan mekanisme hasil maksimal untuk replikasi log biner

Anda dapat mengaktifkan optimasi hasil maksimal replikasi log biner sebagai berikut. Melakukannya meminimalkan latensi untuk transaksi pada instance sumber binlog. Namun, Anda mungkin mengalami jeda replikasi yang lebih tinggi.

Untuk mengaktifkan pengoptimalan binlog hasil maksimal untuk klaster MySQL Aurora

1. Ciptakan atau edit sebuah grup parameter klaster DB menggunakan pengaturan parameter berikut:

   • aurora_binlog_use_large_read_buffer: aktifkan dengan nilai ON atau 1.

   • aurora_binlog_replication_max_yield_seconds: tentukan nilai lebih besar dari 0.

2. Kaitkan grup parameter cluster DB dengan cluster Aurora MySQL yang berfungsi sebagai sumber binlog. Untuk melakukannya, ikuti prosedurnya di Bekerja dengan grup parameter.

3. Konfirmasikan bahwa perubahan parameter berlaku. Untuk melakukannya, jalankan kueri berikut pada instans sumber binlog berikut.

   SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

   Output Anda harus serupa dengan berikut ini.

   +---------------------------------------+-----------------------------------------------+
   | @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
   +---------------------------------------+-----------------------------------------------+
   |                                     1 |                                            45 |
   +---------------------------------------+-----------------------------------------------+
   

Menonaktifkan optimasi hasil maksimal replikasi log biner

Anda dapat menonaktifkan optimasi hasil maksimal replikasi log biner sebagai berikut. Melakukannya meminimalkan jeda replikasi. Namun, Anda mungkin mengalami latensi yang lebih tinggi untuk transaksi pada instans sumber binlog.

Untuk menonaktifkan pengoptimalan binlog hasil maksimal untuk klaster Aurora MySQL

1. Pastikan grup parameter klaster DB yang terkait dengan klaster Aurora MySQL memiliki aurora_binlog_replication_max_yield_seconds yang diatur ke 0. Untuk informasi selengkapnya tentang cara mengatur parameter konfigurasi menggunakan grup parameter, lihat Bekerja dengan grup parameter.

2. Konfirmasikan bahwa perubahan parameter berlaku. Untuk melakukannya, jalankan kueri berikut pada instans sumber binlog berikut.

   SELECT @@aurora_binlog_replication_max_yield_seconds;

   Output Anda harus serupa dengan berikut ini.

   +-----------------------------------------------+
   | @@aurora_binlog_replication_max_yield_seconds |
   +-----------------------------------------------+
   |                                             0 |
   +-----------------------------------------------+
   

Menonaktifkan buffer baca besar

Anda dapat menonaktifkan seluruh fitur buffer baca besar sebagai berikut.

Untuk menonaktifkan buffer baca log biner besar untuk klaster Aurora MySQL

1. Atur ulang aurora_binlog_use_large_read_buffer ke OFF atau 0.

   Pastikan grup parameter klaster DB yang terkait dengan klaster Aurora MySQL memiliki aurora_binlog_use_large_read_buffer yang diatur ke 0. Untuk informasi selengkapnya tentang cara mengatur parameter konfigurasi menggunakan grup parameter, lihat Bekerja dengan grup parameter.

2. Pada instans sumber binlog, jalankan kueri berikut.

   SELECT @@ aurora_binlog_use_large_read_buffer;

   Output Anda harus serupa dengan berikut ini.

   +---------------------------------------+
   | @@aurora_binlog_use_large_read_buffer |
   +---------------------------------------+
   |                                     0 |
   +---------------------------------------+
   

Menyinkronkan kata sandi antara sumber replikasi dan target

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

Jika Anda menggunakanAWS Management Console, yangAWS CLI, atau API RDS untuk mengubah kata sandi utama pada sumber replikasi, perubahan tersebut tidak secara otomatis direplikasi ke target replikasi. Jika Anda ingin menyinkronkan master user dan master password antara sumber dan sistem target, Anda harus membuat perubahan yang sama pada target replikasi sendiri.