engine=innodb, algorithm=copy;
```
Di bagian berikut, siapkan replikasi, hentikan replikasi, skala pembacaan untuk database Anda, optimalkan replikasi binlog, dan siapkan binlog yang disempurnakan.
**Topics**
+ [Menyiapkan replikasi log biner untuk Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [Menghentikan replikasi log biner untuk Aurora MySQL](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [Penskalaan bacaan untuk database MySQL Anda dengan Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md)
+ [Mengoptimalkan replikasi log biner untuk Aurora MySQL](binlog-optimization.md)
+ [Menyiapkan binlog yang disempurnakan untuk Aurora MySQL](AuroraMySQL.Enhanced.binlog.md)
# Menyiapkan replikasi log biner untuk Aurora MySQL
Pengaturan replikasi MySQL dengan Aurora MySQL memerlukan langkah-langkah berikut, yang dibahas secara terperinci:
**Contents**
+ [1. Aktifkan pencatatan log biner pada sumber replikasi](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. Pertahankan log biner pada sumber replikasi hingga tidak diperlukan lagi](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. Buat salinan atau dump sumber replikasi Anda](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. Muat dump ke target replika Anda (jika diperlukan)](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. Buat pengguna replikasi pada sumber replikasi Anda](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. Aktifkan replikasi pada target replika Anda](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [Mengatur lokasi untuk menghentikan replikasi ke replika baca](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. Pantau replika Anda](#AuroraMySQL.Replication.MySQL.Monitor)
+ [Menyinkronkan kata sandi antara sumber dan target replikasi](#AuroraMySQL.Replication.passwords)
## 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 `binlog_format` ke `ROW`, `STATEMENT`, atau `MIXED`. `MIXED` direkomendasikan kecuali jika Anda membutuhkan format binlog tertentu. (Nilai default-nya adalah `OFF`.) Untuk mengubah parameter `binlog_format`, buat grup parameter klaster DB kustom dan kaitkan grup parameter kustom tersebut dengan klaster DB Anda. Anda tidak dapat mengubah parameter dalam grup parameter klaster DB default. Jika Anda mengubah parameter `binlog_format` dari `OFF` ke nilai lainnya, boot ulang klaster DB Aurora Anda agar perubahan dapat diterapkan. Untuk informasi lebih lanjut, lihat [Parameter klaster DB dan instans DB Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) dan [](USER_WorkingWithParamGroups.md). |
| 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (eksternal) | **Untuk mengatur replikasi terenkripsi** Untuk mereplikasi data secara aman dengan Aurora MySQL versi 2, Anda dapat menggunakan replikasi terenkripsi. Jika Anda tidak perlu menggunakan replikasi terenkripsi, Anda dapat melewati langkah-langkah ini. Berikut ini adalah prasyarat untuk menggunakan replikasi terenkripsi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Untuk mengaktifkan pencatatan log biner pada basis data MySQL eksternal** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 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\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) dan tentukan parameter konfigurasi `'binlog retention hours'` bersama dengan jumlah jam untuk mempertahankan file binlog di klaster DB. Nilai maksimum untuk Aurora MySQL versi 2.11.0 dan lebih tinggi dan versi 3 adalah 2160 (90 hari). Contoh berikut menetapkan periode retensi untuk file binlog menjadi 6 hari: CALL mysql.rds_set_configuration('binlog retention hours', 144); Setelah replikasi dimulai, Anda dapat memverifikasi bahwa perubahan telah diterapkan ke replika Anda dengan menjalankan perintah `SHOW SLAVE STATUS` (Aurora MySQL versi 2) atau `SHOW REPLICA STATUS` (Aurora MySQL versi 3) pada replika Anda dan memeriksa bidang `Seconds behind master`. Jika bidang `Seconds behind master` adalah 0, maka tidak ada lag replika. Jika tidak ada lag replika, kurangi durasi waktu retensi file binlog dengan mengatur parameter konfigurasi `binlog retention hours` ke rentang waktu yang lebih kecil. Jika pengaturan ini tidak ditentukan, nilai default untuk Aurora MySQL adalah 24 (1 hari). Jika Anda menentukan nilai untuk `'binlog retention hours'` yang lebih tinggi dari nilai maksimum, maka Aurora MySQL menggunakan nilai maksimum. |
| 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\$1stop\$1replication](mysql-stored-proc-replicating.md#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 `Seconds behind master`) antara sumber replikasi dan replika permanen Anda mencapai 0. |
| 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 `SHOW SLAVE STATUS` (Aurora MySQL versi 2) atau `SHOW REPLICA STATUS` (Aurora MySQL versi 3) pada replika Anda dan memeriksa bidang `Seconds behind master`. Jika bidang `Seconds behind master` adalah 0, maka tidak ada lag replika. Saat tidak ada lag replika, Anda dapat menghapus file binlog lama. |
## 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Untuk menentukan nama dan posisi file binlog** Pilih salah satu metode berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **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 `mysqldump` perintah terhadap salinan cluster DB sumber Anda yang Anda buat. Ini untuk menghindari pertimbangan penguncian saat mengambil dump. Jika dump diambil pada cluster DB sumber secara langsung, akan perlu untuk mengunci tabel sumber untuk mencegah penulisan bersamaan kepada mereka saat dump sedang berlangsung. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) dalam *Panduan Pengguna Amazon Relational Database Service*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (eksternal) | **Untuk membuat dump basis data MySQL eksternal** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 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](aurora-restore-snapshot.md).
Anda dapat mengkloning cluster DB sumber Anda untuk membuat cluster DB baru. Untuk informasi selengkapnya, lihat [Mengkloning volume untuk klaster DB Amazon Aurora](Aurora.Managing.Clone.md).
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](AuroraMySQL.Migrating.md).
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** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Untuk memuat dump ke instans DB Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| 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 `mysqldump`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 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\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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.
| Mesin basis data | Petunjuk |
| --- | --- |
| Aurora MySQL | **Untuk mengaktifkan replikasi dari klaster DB Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Untuk menggunakan enkripsi SSL, tetapkan nilai akhir menjadi `1` bukan `0`. |
| RDS for MySQL | **Untuk mengaktifkan replikasi dari instans DB Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Untuk menggunakan enkripsi SSL, tetapkan nilai akhir menjadi `1` bukan `0`. |
| MySQL (eksternal) | **Untuk mengaktifkan replikasi dari basis data MySQL eksternal** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
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\$1reset\$1external\$1master versi 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) atau [mysql.rds\$1reset\$1external\$1source ( 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) 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\$1start\$1replication\$1until (Aurora MySQL versi 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
**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.
1. Jalankan prosedur yang tersimpan di [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versi 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
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\$1start\$1replication\$1until\$1gtid (Aurora MySQL versi 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid), bukan prosedur tersimpan [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versi 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Untuk informasi selengkapnya tentang replikasi berbasis GTID, lihat [Menggunakan replikasi GTID berbasis](mysql-replication-gtid.md).
## 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](USER_Events.md).
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.
# Menghentikan replikasi log biner untuk Aurora MySQL
Untuk menghentikan replikasi binlog dengan instans DB MySQL, basis data 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](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. Nonaktifkan pencatatan log biner pada sumber replikasi](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. Hentikan replikasi log biner pada target replika
Gunakan petunjuk berikut untuk menghentikan replikasi log biner untuk mesin basis data Anda.
| Mesin basis data | Petunjuk |
| --- | --- |
| Aurora MySQL | **Untuk menghentikan replikasi log biner pada target replika klaster DB Aurora MySQL** Hubungkan ke klaster DB Aurora yang merupakan target replika, dan panggil prosedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| RDS for MySQL | **Untuk menghentikan replikasi log biner pada instans DB Amazon RDS** Hubungkan ke instans DB RDS yang merupakan target replika dan panggil prosedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| MySQL (eksternal) | **Untuk menghentikan replikasi log biner pada basis data MySQL eksternal** Hubungkan ke basis data MySQL dan jalankan perintah `STOP SLAVE` (versi 5.7) atau `STOP REPLICA` (versi 8.0). |
## 2. Nonaktifkan pencatatan log biner pada sumber replikasi
Gunakan petunjuk dalam tabel berikut untuk menonaktifkan pencatatan log biner pada sumber replikasi untuk mesin basis data Anda.
| Mesin basis data | Petunjuk |
| --- | --- |
| Aurora MySQL | **Untuk menonaktifkan pencatatan log biner pada klaster DB Amazon Aurora** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **Untuk menonaktifkan pencatatan log biner pada instans DB Amazon RDS** Anda tidak dapat menonaktifkan pencatatan log biner secara langsung pada instans DB Amazon RDS, tetapi Anda dapat menonaktifkannya dengan melakukan hal berikut ini: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (eksternal) | **Untuk menonaktifkan pencatatan log biner pada basis data MySQL eksternal** Hubungkan ke basis data MySQL dan panggil perintah `STOP REPLICATION`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# Penskalaan bacaan untuk database MySQL Anda dengan Amazon Aurora
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 menskalakan baca untuk instans DB MySQL Anda, buat klaster DB Amazon Aurora MySQL dan jadikan klaster DB ini sebagai replika baca instans DB MySQL Anda. Hal ini berlaku untuk satu instans DB RDS for MySQL, atau basis data MySQL yang dijalankan secara eksternal di luar Amazon RDS.
Untuk informasi tentang cara membuat klaster DB Amazon Aurora, lihat [Membuat klaster DB Amazon Aurora](Aurora.CreateInstance.md).
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 ke klaster DB Amazon Aurora MySQL Anda. Jika terjadi failover, maka Replika Aurora 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 binlog tersebut telah diterapkan ke Replika Aurora. Dengan mempertahankannya, Anda akan dapat memulihkan instans penulis Anda jika terjadi kegagalan.
**penting**
Saat menggunakan replikasi yang dikelola sendiri, Anda bertanggung jawab untuk memantau dan menyelesaikan masalah replikasi yang mungkin terjadi. Untuk informasi selengkapnya, lihat [Mendiagnosis dan mengatasi jeda di antara replika baca](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).
**catatan**
Izin yang diperlukan untuk memulai replikasi pada klaster DB Aurora MySQL dibatasi dan tidak tersedia untuk pengguna master Amazon RDS Anda. Oleh karena itu, Anda harus menggunakan prosedur [mysql.rds\$1set\$1external\$1master 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) atau [mysql.rds\$1set\$1external\$1source (RDS )](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) dan [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) untuk mengatur replikasi antara klaster DB Aurora MySQL dan instans DB MySQL Anda.
## Mulai replikasi antara instans sumber eksternal dan klaster DB Aurora MySQL
1. Buat instans DB MySQL sumber menjadi hanya baca:
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. 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
------------------------------------
```
1. Salin basis data dari instans DB MySQL eksternal ke klaster DB Amazon Aurora MySQL menggunakan `mysqldump`. Untuk database yang sangat besar, Anda mungkin ingin menggunakan prosedur dalam [Mengimpor data ke database Amazon RDS for MySQL dengan pengurangan waktu henti di Panduan Pengguna Amazon *Relational* Database](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) Service.
Untuk Linux, macOS, atau Unix:
```
mysqldump \
--databases \
--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 ^
--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
```
**catatan**
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, misalnya, `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`. Anda dapat menemukan nilai titik akhir dalam detail klaster di Konsol Manajemen Amazon RDS.
1. 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 cadangan untuk digunakan dengan replikasi, lihat [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) dalam dokumentasi MySQL.
1. Dalam Konsol Manajemen Amazon RDS, tambahkan alamat IP server yang meng-host basis data MySQL sumber ke grup keamanan VPC untuk klaster DB Amazon Aurora. Untuk informasi selengkapnya tentang memodifikasi grup keamanan VPC, lihat [Grup keamanan untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dalam *Panduan Pengguna Amazon Virtual Private Cloud*.
Anda juga mungkin harus mengonfigurasi jaringan lokal Anda untuk mengizinkan koneksi dari alamat IP klaster DB Amazon Aurora Anda agar klaster DB ini 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.
1. Dengan menggunakan klien pilihan Anda, hubungkan ke instans MySQL eksternal dan buat akun pengguna MySQL yang akan digunakan untuk replikasi. Akun ini digunakan hanya untuk replikasi dan harus dibatasi pada domain Anda untuk meningkatkan keamanan. Berikut adalah contohnya.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. 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 basis data bagi pengguna '`repl_user`' untuk domain Anda, jalankan perintah berikut.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'
IDENTIFIED BY 'password';
```
1. Ambil snapshot manual klaster DB Aurora MySQL untuk dijadikan sebagai replika baca sebelum mengatur replikasi. Jika Anda harus membuat ulang replikasi dengan 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 klaster DB Aurora MySQL baru.
1. Jadikan klaster DB Amazon Aurora sebagai replika. Connect ke cluster Amazon Aurora DB sebagai pengguna utama dan identifikasi sumber database MySQL sebagai sumber replikasi dengan menggunakan atau dan prosedur. [mysql.rds\$1set\$1external\$1master 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) [mysql.rds\$1set\$1external\$1source (RDS )](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)
Gunakan nama file binlog dan posisi yang Anda tentukan di Langkah 2. Berikut adalah contohnya.
```
For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. Pada klaster DB Amazon Aurora, panggil prosedur [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) untuk memulai replikasi.
```
CALL mysql.rds_start_replication;
```
Setelah Anda membuat replikasi antara instans DB MySQL sumber dan klaster DB Amazon Aurora, Anda dapat menambahkan Replika Aurora ke klaster DB Amazon Aurora Anda. Kemudian, Anda dapat terhubung ke Replika Aurora untuk menskalakan baca data Anda. Untuk informasi tentang cara membuat Replika Aurora, lihat [Menambahkan Replika Aurora ke klaster DB](aurora-replicas-adding.md).
# Mengoptimalkan replikasi log biner untuk Aurora MySQL
Dari informasi berikut, Anda dapat mempelajari cara mengoptimalkan performa replikasi log biner dan memecahkan masalah terkait di Aurora MySQL.
**Tip**
Diskusi ini mengasumsikan bahwa Anda sudah mengenal mekanisme replikasi log biner MySQL dan cara kerjanya. Untuk informasi latar belakang, lihat [Replication Implementation](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) dalam dokumentasi MySQL.
## Replikasi log biner multithreaded
Dengan replikasi log biner multi-thread, thread SQL membaca peristiwa dari log relai dan mengantrekannya agar thread pekerja SQL dapat diterapkan. Thread pekerja SQL dikelola oleh thread koordinator. Peristiwa log biner diterapkan secara paralel jika memungkinkan. Tingkat paralelisme tergantung pada faktor-faktor termasuk versi, parameter, desain skema, dan karakteristik beban kerja.
Replikasi log biner multithreaded didukung di Aurora MySQL versi 3, dan di Aurora MySQL versi 2.12.1 dan lebih tinggi. Agar replika multithreaded dapat memproses peristiwa binlog secara paralel secara efisien, Anda harus mengonfigurasi sumber untuk replikasi log biner multithreaded, dan sumber harus menggunakan versi yang menyertakan informasi paralelisme pada file log binernya.
Ketika instance Aurora MySQL DB dikonfigurasi untuk menggunakan replikasi log biner, secara default instance replika menggunakan replikasi single-threaded untuk versi Aurora MySQL yang lebih rendah dari 3,04. Untuk mengaktifkan replikasi multithreaded, Anda memperbarui `replica_parallel_workers` parameter ke nilai yang lebih besar daripada `1` di grup parameter kustom Anda.
Untuk Aurora MySQL versi 3.04 dan lebih tinggi, replikasi multithreaded secara default, dengan disetel ke. `replica_parallel_workers` `4` Anda dapat memodifikasi parameter ini di grup parameter kustom Anda.
Untuk meningkatkan ketahanan database Anda terhadap penghentian yang tidak terduga, kami sarankan Anda mengaktifkan replikasi GTID pada sumber dan mengizinkan replika. GTIDs Untuk memungkinkan replikasi GTID, atur `gtid_mode` ke `ON_PERMISSIVE` sumber dan replika. Untuk informasi selengkapnya tentang replikasi, lihat [Menggunakan replikasi GTID berbasis](mysql-replication-gtid.md).
Opsi konfigurasi berikut dapat membantu Anda menyesuaikan replikasi multi-thread. Untuk informasi penggunaan, lihat [Replication and Binary Logging Options and Variables](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) dalam *Panduan Referensi MySQL*. Untuk informasi selengkapnya tentang replikasi multithreaded, lihat MySQL Blog [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/) the Parallel Applier with WriteSet-based Dependency Tracking.
Nilai parameter optimal tergantung pada beberapa faktor. Misalnya, performa replikasi log biner dipengaruhi oleh karakteristik beban kerja basis data Anda dan kelas instans DB tempat replika berjalan. Oleh karena itu, kami menyarankan Anda menguji secara menyeluruh semua perubahan pada parameter konfigurasi ini sebelum menerapkan pengaturan parameter baru ke instance produksi:
+ `binlog_format recommended value`— diatur ke `ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking`Nilai yang direkomendasikan adalah `WRITESET`
+ `replica_preserve_commit_order`
+ `replica_parallel_type`Nilai yang direkomendasikan adalah `LOGICAL_CLOCK`
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction`Nilai yang direkomendasikan adalah `XXHASH64`
Karakteristik skema dan beban kerja Anda adalah faktor yang memengaruhi replikasi secara paralel. Faktor yang paling umum adalah sebagai berikut.
+ Tidak adanya kunci utama - RDS tidak dapat menetapkan ketergantungan writeset untuk tabel tanpa kunci primer. Dengan `ROW` format, pernyataan multi-baris tunggal dapat dicapai dengan pemindaian tabel penuh tunggal pada sumbernya, tetapi menghasilkan satu pemindaian tabel penuh per baris yang dimodifikasi pada replika. Tidak adanya kunci primer secara signifikan mengurangi throughput replikasi.
+ Kehadiran kunci asing - Jika kunci asing ada, Amazon RDS tidak dapat menggunakan dependensi writeset untuk paralelisme tabel dengan hubungan FK.
+ Ukuran transaksi — Jika satu transaksi mencakup puluhan atau ratusan megabyte atau gigabyte, thread koordinator dan salah satu thread pekerja mungkin menghabiskan waktu lama hanya memproses transaksi itu. Selama waktu itu, semua thread pekerja lainnya mungkin tetap menganggur setelah mereka selesai memproses transaksi mereka sebelumnya.
Di Aurora MySQL versi 3.06 dan lebih tinggi, Anda dapat meningkatkan kinerja replika log biner saat mereplikasi transaksi untuk tabel besar dengan lebih dari satu indeks sekunder. Fitur ini memperkenalkan kumpulan utas untuk menerapkan perubahan indeks sekunder secara paralel pada replika binlog. Fitur ini dikendalikan oleh parameter cluster `aurora_binlog_replication_sec_index_parallel_workers` DB, yang mengontrol jumlah total thread paralel yang tersedia untuk menerapkan perubahan indeks sekunder. Parameter diatur ke `0` (dinonaktifkan) secara default. Mengaktifkan fitur ini tidak memerlukan instance restart. Untuk mengaktifkan fitur ini, hentikan replikasi yang sedang berlangsung, atur jumlah thread parallel worker yang diinginkan, lalu mulai replikasi lagi.
## Mengoptimalkan replikasi binlog
Di Aurora MySQL 2.10 dan yang lebih tinggi, Aurora secara otomatis menerapkan optimasi yang dikenal sebagai cache binlog untuk replikasi log biner. I/O Dengan membuat cache peristiwa binlog yang paling baru di-commit, optimisasi ini dirancang untuk meningkatkan performa thread dump binlog sambil membatasi dampak pada transaksi latar depan di instans sumber binlog.
**catatan**
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 optimisasi ini. Secara khusus, jika Anda telah menyesuaikan parameter konfigurasi `aurora_binlog_replication_max_yield_seconds` ke nilai bukan nol di versi MySQL Aurora sebelumnya, atur kembali ke nol untuk versi yang tersedia saat ini.
Variabel status `aurora_binlog_io_cache_reads` dan `aurora_binlog_io_cache_read_requests` membantu Anda memantau seberapa sering data dibaca dari I/O cache binlog.
+ `aurora_binlog_io_cache_read_requests`menunjukkan jumlah permintaan I/O baca binlog dari cache.
+ `aurora_binlog_io_cache_reads`menunjukkan jumlah I/O pembacaan binlog yang mengambil informasi dari cache.
Kueri SQL berikut menghitung persentase permintaan baca binlog yang memanfaatkan informasi cache. Dalam hal ini, makin dekat rasionya ke 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 I/O cache binlog juga menyertakan metrik baru yang terkait dengan utas dump binlog. *Thread dump* adalah thread yang dibuat saat replika binlog baru terhubung ke instans sumber binlog.
Metrik thread dump dicetak ke log basis data setiap 60 detik dengan awalan `[Dump thread metrics]`. Metrik ini mencakup informasi untuk setiap replika binlog seperti `Secondary_id`, `Secondary_uuid`, nama file binlog, dan posisi yang dibaca setiap replika. Metrik ini juga mencakup `Bytes_behind_primary` yang merepresentasikan jarak dalam byte antara sumber replikasi dan replika. Metrik ini mengukur lag I/O utas replika. Angka tersebut berbeda dengan lag thread pengaplikasi SQL replika, yang direpresentasikan oleh metrik `seconds_behind_master` pada replika binlog. Anda dapat menentukan apakah replika binlog mengimbangi atau tertinggal di belakang sumber dengan memeriksa apakah jaraknya berkurang atau bertambah.
## Log relai dalam memori
Di Aurora MySQL versi 3.10 dan lebih tinggi, Aurora memperkenalkan pengoptimalan yang dikenal sebagai log relai dalam memori untuk meningkatkan throughput replikasi. Optimalisasi ini meningkatkan I/O kinerja log relai dengan menyimpan semua konten log relai perantara di memori. Akibatnya, ini mengurangi latensi komit dengan meminimalkan I/O operasi penyimpanan karena konten log relai tetap mudah diakses di memori.
Secara default, fitur log relai dalam memori diaktifkan secara otomatis untuk skenario replikasi yang dikelola Aurora (termasuk penerapan biru-hijau, replikasi Aurora-Aurora, dan replika lintas wilayah) ketika replika memenuhi salah satu konfigurasi ini:
+ Mode replikasi ulir tunggal (replica\$1parallel\$1workers = 0)
+ Replikasi multi-utas dengan mode GTID diaktifkan:
+ Posisi otomatis diaktifkan
+ Mode GTID diatur ke ON pada replika
+ Replikasi berbasis file dengan replica\$1preserve\$1commit\$1order = ON
Fitur log relai dalam memori didukung pada kelas instance yang lebih besar dari t3.large, tetapi tidak tersedia pada instance. Aurora Serverless Buffer melingkar log relay memiliki ukuran tetap 128 MB. Untuk memantau konsumsi memori fitur ini, Anda dapat menjalankan kueri berikut:
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
Fitur log relai dalam memori dikendalikan oleh parameter aurora\$1in\$1memory\$1relaylog, yang dapat diatur pada cluster DB atau tingkat instans. Anda dapat mengaktifkan atau menonaktifkan fitur ini secara dinamis tanpa memulai ulang instance Anda:
1. Hentikan replikasi yang sedang berlangsung
1. Setel aurora\$1in\$1memory\$1relaylog ke ON (untuk mengaktifkan) atau OFF (untuk menonaktifkan) di grup parameter
1. Mulai ulang replikasi
Contoh:
```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```
Bahkan ketika aurora\$1in\$1memory\$1relaylog disetel ke ON, fitur log relai dalam memori mungkin masih dinonaktifkan dalam kondisi tertentu. Untuk memverifikasi status fitur saat ini, Anda dapat menggunakan perintah berikut:
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
Jika fitur ini tiba-tiba dinonaktifkan, Anda dapat mengidentifikasi alasannya dengan menjalankan:
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
Perintah ini mengembalikan pesan yang menjelaskan mengapa fitur saat ini dinonaktifkan.
# Menyiapkan binlog yang disempurnakan untuk Aurora MySQL
Binlog yang ditingkatkan akan mengurangi overhead performa komputasi yang disebabkan oleh pengaktifan binlog, yang dapat mencapai hingga 50% dalam kasus tertentu. Dengan binlog yang ditingkatkan, overhead ini dapat dikurangi menjadi sekitar 13%. Untuk mengurangi overhead, binlog yang ditingkatkan menulis log biner dan transaksi ke penyimpanan secara paralel, yang meminimalkan data yang ditulis pada waktu commit transaksi.
Menggunakan binlog yang ditingkatkan juga meningkatkan waktu pemulihan basis data setelah mulai ulang dan failover hingga 99% dibandingkan dengan binlog MySQL komunitas. Binlog yang ditingkatkan kompatibel dengan beban kerja berbasis binlog yang ada, dan Anda berinteraksi dengannya dengan cara yang sama seperti Anda berinteraksi dengan binlog MySQL komunitas.
Binlog yang ditingkatkan tersedia di Aurora MySQL versi 3.03.1 dan lebih tinggi.
**Topics**
+ [Mengonfigurasi parameter binlog yang ditingkatkan](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [Parameter terkait lainnya](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [Perbedaan antara binlog yang ditingkatkan dan binlog MySQL komunitas](#AuroraMySQL.Enhanced.binlog.differences)
+ [CloudWatch Metrik Amazon untuk binlog yang disempurnakan](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [Batasan binlog yang ditingkatkan](#AuroraMySQL.Enhanced.binlog.limitations)
## Mengonfigurasi parameter binlog yang ditingkatkan
Anda dapat beralih antara binlog MySQL komunitas dan binlog yang ditingkatkan dengan mengaktifkan/menonaktifkan parameter binlog yang ditingkatkan. Konsumen binlog yang ada dapat terus membaca dan mengonsumsi file binlog tanpa kesenjangan dalam urutan file binlog.
Untuk mengaktifkan binlog yang disempurnakan, atur parameter berikut:
| Parameter | Default | Deskripsi |
| --- | --- | --- |
| binlog\$1format | – | Atur parameter binlog\$1format ke format pencatatan log biner pilihan Anda untuk mengaktifkan binlog yang ditingkatkan. Pastikan binlog\$1format parameter tidak diatur ke OFF. Untuk informasi selengkapnya, lihat [Mengonfigurasi pencatatan log biner Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). |
| aurora\$1enhanced\$1binlog | 0 | Tetapkan nilai parameter ini ke 1 dalam grup parameter klaster DB yang terkait dengan klaster Aurora MySQL. Ketika Anda mengubah nilai parameter ini, Anda harus melakukan boot ulang instans penulis ketika nilai DBClusterParameterGroupStatus ditampilkan sebagai pending-reboot. |
| binlog\$1backup | 1 | Nonaktifkan parameter ini untuk mengaktifkan binlog yang ditingkatkan. Untuk melakukannya, tetapkan nilai parameter ini ke 0. |
| binlog\$1replication\$1globaldb | 1 | Nonaktifkan parameter ini untuk mengaktifkan binlog yang ditingkatkan. Untuk melakukannya, tetapkan nilai parameter ini ke 0. |
**penting**
Anda dapat menonaktifkan `binlog_replication_globaldb` parameter `binlog_backup` dan hanya ketika Anda menggunakan binlog yang ditingkatkan.
Untuk mematikan binlog yang disempurnakan, atur parameter berikut:
| Parameter | Deskripsi |
| --- | --- |
| aurora\$1enhanced\$1binlog | Tetapkan nilai parameter ini ke 0 dalam grup parameter klaster DB yang terkait dengan klaster Aurora MySQL. Setiap kali Anda mengubah nilai parameter ini, Anda harus melakukan boot ulang instans penulis ketika nilai DBClusterParameterGroupStatus ditampilkan sebagai pending-reboot. |
| binlog\$1backup | Aktifkan parameter ini saat Anda menonaktifkan binlog yang ditingkatkan. Untuk melakukannya, tetapkan nilai parameter ini ke 1. |
| binlog\$1replication\$1globaldb | Aktifkan parameter ini saat Anda menonaktifkan binlog yang ditingkatkan. Untuk melakukannya, tetapkan nilai parameter ini ke 1. |
Untuk memeriksa apakah binlog yang ditingkatkan diaktifkan, gunakan perintah berikut di klien MySQL:
```
mysql>show status like 'aurora_enhanced_binlog';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)
```
Saat binlog yang ditingkatkan diaktifkan, output-nya akan menampilkan `ACTIVE` untuk `aurora_enhanced_binlog`.
## Parameter terkait lainnya
Saat Anda mengaktifkan binlog yang ditingkatkan, parameter berikut akan terpengaruh:
+ Parameter `max_binlog_size` terlihat, tetapi tidak dapat dimodifikasi. Nilai default-nya, `134217728`, secara otomatis disesuaikan menjadi `268435456` saat binlog yang ditingkatkan diaktifkan.
+ Tidak seperti di binlog MySQL komunitas, `binlog_checksum` tidak bertindak sebagai parameter dinamis ketika binlog yang ditingkatkan diaktifkan. Agar perubahan pada parameter ini berlaku, Anda harus melakukan boot ulang klaster DB secara manual bahkan jika `ApplyMethod` adalah `immediate`.
+ Nilai yang Anda tetapkan pada parameter `binlog_order_commits` tidak berpengaruh pada urutan commit saat binlog yang ditingkatkan diaktifkan. Commit selalu diperintahkan tanpa implikasi performa lebih lanjut.
## Perbedaan antara binlog yang ditingkatkan dan binlog MySQL komunitas
Binlog yang ditingkatkan berinteraksi secara berbeda dengan klon, cadangan, dan basis data global Aurora jika dibandingkan dengan binlog MySQL komunitas. Sebaiknya Anda memahami perbedaan berikut sebelum menggunakan binlog yang ditingkatkan.
+ File binlog yang ditingkatkan dari klaster DB sumber tidak tersedia di klaster DB yang dikloning.
+ File binlog yang ditingkatkan tidak disertakan dalam cadangan Aurora. Oleh karena itu, file binlog yang ditingkatkan dari klaster DB sumber tidak tersedia setelah memulihkan klaster DB meskipun ada periode retensi yang ditetapkan padanya.
+ Ketika digunakan dengan basis data global Aurora, file binlog yang ditingkatkan untuk klaster DB primer tidak direplikasi ke klaster DB di wilayah sekunder.
****Contoh****
Contoh berikut menggambarkan perbedaan antara binlog yang ditingkatkan dan binlog MySQL komunitas.
**Pada klaster DB yang dipulihkan atau dikloning**
Saat binlog yang ditingkatkan diaktifkan, file binlog historis tidak tersedia di klaster DB yang dipulihkan atau dikloning. Setelah operasi pemulihan atau kloning, jika binlog dihidupkan, cluster DB baru mulai menulis urutan file binlognya sendiri, mulai dari 1 (.000001)mysql-bin-changelog.
Untuk mengaktifkan binlog yang ditingkatkan setelah operasi pemulihan atau kloning, atur parameter klaster DB yang diperlukan pada klaster DB yang dipulihkan atau dikloning. Untuk informasi selengkapnya, lihat [Mengonfigurasi parameter binlog yang ditingkatkan](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Contoh: Operasi klon atau pemulihan dilakukan saat binlog yang ditingkatkan dihidupkan**
Klaster DB Sumber:
```
mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Pada klaster DB yang dipulihkan atau dikloning, file binlog tidak akan dicadangkan saat binlog yang ditingkatkan diaktifkan. Untuk menghindari diskontinuitas dalam data binlog, file binlog yang ditulis sebelum binlog yang ditingkatkan diaktifkan juga tidak akan tersedia.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example Contoh: Operasi klon atau pemulihan dilakukan saat binlog yang ditingkatkan dimatikan**
Klaster DB sumber:
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Binlog yang disempurnakan dinonaktifkan setelahnya`mysql-bin-changelog.000003`. Pada klaster DB yang dipulihkan atau dikloning, file binlog yang ditulis setelah binlog yang ditingkatkan dinonaktifkan akan tersedia.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Pada basis data global Amazon Aurora**
Pada basis data global Amazon Aurora, data binlog klaster DB primer tidak direplikasi ke klaster DB sekunder. Setelah proses failover lintas Wilayah, data binlog tidak tersedia di klaster DB primer yang baru dipromosikan. Jika binlog dihidupkan, cluster DB yang baru dipromosikan memulai urutan file binlognya sendiri, mulai dari 1 (mysql-bin-changelog.000001).
Untuk mengaktifkan binlog yang ditingkatkan setelah failover, Anda harus mengatur parameter klaster DB yang diperlukan pada klaster DB sekunder. Untuk informasi selengkapnya, lihat [Mengonfigurasi parameter binlog yang ditingkatkan](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Contoh: Operasi failover database global dilakukan saat binlog yang ditingkatkan diaktifkan**
Klaster DB primer lama (sebelum failover):
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Klaster DB primer baru (setelah failover):
File binlog tidak direplikasi ke wilayah sekunder saat binlog yang ditingkatkan diaktifkan. Untuk menghindari diskontinuitas dalam data binlog, file binlog yang ditulis sebelum binlog yang ditingkatkan diaktifkan tidak akan tersedia.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example Contoh: Operasi failover database global dilakukan saat binlog yang disempurnakan dimatikan**
Klaster DB Sumber:
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
**Klaster DB yang dipulihkan atau dikloning:**
Binlog yang disempurnakan dinonaktifkan setelahnya`mysql-bin-changelog.000003`. File binlog yang ditulis setelah binlog yang ditingkatkan dinonaktifkan akan direplikasi dan tersedia di klaster DB yang baru dipromosikan.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)
```
## CloudWatch Metrik Amazon untuk binlog yang disempurnakan
CloudWatch Metrik Amazon berikut diterbitkan hanya ketika binlog yang disempurnakan diaktifkan.
| CloudWatch metrik | Deskripsi | Unit |
| --- | --- | --- |
| ChangeLogBytesUsed | Jumlah penyimpanan yang digunakan oleh binlog yang ditingkatkan. | Byte |
| ChangeLogReadIOPs | Jumlah operasi I/O baca yang dilakukan di binlog yang ditingkatkan dalam interval 5 menit. | Hitungan per 5 menit |
| ChangeLogWriteIOPs | Jumlah operasi I/O disk tulis yang dilakukan di binlog yang ditingkatkan dalam interval 5 menit. | Hitungan per 5 menit |
## Batasan binlog yang ditingkatkan
Batasan berikut berlaku untuk klaster Amazon Aurora DB saat binlog yang ditingkatkan diaktifkan.
+ Binlog yang ditingkatkan hanya didukung di Aurora MySQL version3.03.1 dan yang lebih tinggi.
+ File binlog yang ditingkatkan yang ditulis pada klaster DB primer tidak disalin ke klaster DB yang dikloning atau dipulihkan.
+ Saat digunakan dengan basis data global Amazon Aurora, file binlog yang ditingkatkan untuk klaster DB primer tidak direplikasi ke klaster DB sekunder. Oleh karena itu, setelah proses failover, data binlog historis tidak tersedia di klaster DB primer yang baru.
+ Parameter konfigurasi binlog berikut diabaikan:
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_max_flush_queue_time`
+ Anda tidak dapat menghapus atau mengganti nama tabel yang rusak dalam basis data. Untuk menjatuhkan tabel ini, Anda dapat menghubungi Dukungan.
+ Cache I/O binlog dinonaktifkan saat binlog yang ditingkatkan diaktifkan. Untuk informasi selengkapnya, lihat [Mengoptimalkan replikasi log biner untuk Aurora MySQL](binlog-optimization.md).
**catatan**
Binlog yang ditingkatkan memberikan peningkatan performa baca yang serupa dengan cache I/O binlog dan peningkatan performa tulis yang lebih baik.
+ Fitur pelacakan mundur tidak didukung. Binlog yang ditingkatkan tidak dapat diaktifkan di klaster DB dalam kondisi berikut:
+ Klaster DB dengan fitur pelacakan mundur saat ini diaktifkan.
+ Cluster DB tempat fitur backtrack sebelumnya diaktifkan, tetapi sekarang dinonaktifkan.
+ Klaster DB dipulihkan dari klaster DB sumber atau snapshot dengan fitur pelacakan mundur diaktifkan.