Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner) - Amazon Aurora
Pengaturan replikasi dengan MySQL atau klaster DB Aurora lainnyaMenyinkronkan kata sandi antara sumber dan target replikasiMenghentikan replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnyaMenggunakan Amazon Aurora untuk menskalakan baca untuk basis data MySQL AndaMengoptimalkan replikasi log binerMenyiapkan binlog yang ditingkatkan

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

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

Karena Amazon Aurora MySQL kompatibel dengan MySQL, Anda dapat mengatur replikasi antara basis data MySQL dan klaster DB Amazon Aurora MySQL. Jenis replikasi ini menggunakan replikasi log biner MySQL, dan secara umum disebut sebagai replikasi binlog. Jika Anda menggunakan replikasi log biner dengan Aurora, sebaiknya basis data 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 instans DB Amazon RDS MySQL, basis data MySQL eksternal di luar Amazon RDS, atau klaster DB Aurora MySQL lainnya.

catatan

Anda tidak dapat menggunakan replikasi binlog ke atau dari jenis klaster Aurora DB tertentu. Secara khusus, replikasi binlog tidak tersedia untuk klaster Aurora Serverless v1. Jika pernyataan SHOW MASTER STATUS dan SHOW SLAVE STATUS (Aurora MySQL versi 2) atau (SHOW REPLICA STATUSAurora MySQL versi 3) tidak menghasilkan output, periksa apakah klaster yang Anda gunakan mendukung replikasi binlog.

Di Aurora MySQL versi 3, replikasi log biner tidak mereplikasi ke basis data sistem mysql. Kata sandi dan akun tidak direplikasi oleh replikasi binlog di Aurora MySQL versi 3. Oleh karena itu, pernyataan Bahasa Kontrol Data (DCL) seperti CREATE USER, GRANT, dan REVOKE tidak direplikasi.

Anda juga dapat mereplikasi dengan instans DB RDS for MySQL atau klaster DB Aurora MySQL di Wilayah AWS lainnya. Saat Anda melakukan replikasi Wilayah AWS, pastikan cluster DB dan instans DB Anda dapat diakses publik. Jika klaster DB MySQL Aurora berada di subnet privat di VPC Anda, gunakan peering VPC antar- Wilayah AWS. Untuk informasi selengkapnya, lihat klaster DB di VPC yang diakses oleh instans EC2 di VPC yang berbeda.

Jika Anda ingin mengonfigurasi replikasi antara cluster DB MySQL Aurora dan cluster DB MySQL Aurora Wilayah AWS di cluster lain, Anda dapat membuat cluster DB MySQL Aurora sebagai replika baca yang berbeda dari cluster DB sumber. Wilayah AWS Untuk informasi selengkapnya, lihat Mereplikasi klaster DB Amazon Aurora MySQL di seluruh Wilayah AWS.

Dengan Aurora MySQL versi 2 dan 3, Anda dapat mereplikasi antara Aurora MySQL dan 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 basis data eksternal. Untuk mempelajari cara melakukannya, lihat Menggunakan replikasi berbasis GTID untuk Amazon 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 tersebut, lihat mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL versi 3).

Awas

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 dengan MySQL atau klaster DB Aurora lainnya

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

1. Aktifkan pencatatan log biner pada sumber replikasi

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

3. Buat snapshot atau dump sumber replikasi Anda

4. Muat snapshot atau dump ke target replika Anda

5. Buat pengguna replikasi pada sumber replikasi Anda

6. Aktifkan replikasi pada target replika Anda

7. Pantau replika Anda

1. Aktifkan pencatatan log biner pada sumber replikasi

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

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

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

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

3. Buat snapshot atau dump sumber replikasi Anda

Anda dapat menggunakan snapshot atau dump sumber replikasi untuk memuat salinan acuan dasar data Anda ke replika Anda, lalu mulai mereplikasi dari titik tersebut.

Gunakan petunjuk berikut untuk membuat snapshot atau dump sumber replikasi untuk mesin basis data Anda.

4. Muat snapshot atau dump ke target replika Anda

Jika Anda berencana memuat data dari dump basis data MySQL yang berada di luar Amazon RDS, Anda sebaiknya membuat instans EC2 dan menyalin file dump ini ke dalamnya, lalu memuat data ke klaster DB atau instans DB Anda dari instans EC2 tersebut. 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.

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

5. Buat pengguna replikasi pada sumber replikasi Anda

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

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

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

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

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

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

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';

GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
catatan

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

6. Aktifkan replikasi pada target replika Anda

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

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

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

Mengatur lokasi untuk menghentikan replikasi ke replika baca

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

Untuk memulai replikasi ke replika baca dan menghentikan replikasi di lokasi tertentu

  1. Menggunakan klien MySQL, sambungkan ke replika Aurora MySQL DB cluster sebagai pengguna utama.

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

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

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

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

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

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 peristiwa Amazon RDS.

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.

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 AWS Management Console, 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 antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya

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

2. Nonaktifkan pencatatan log biner pada sumber replikasi

1. Hentikan replikasi log biner pada target replika

Gunakan petunjuk berikut untuk menghentikan replikasi log biner untuk mesin basis data Anda.

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.

Menggunakan Amazon Aurora untuk menskalakan baca untuk basis data 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 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.

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.

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_set_external_master (Aurora MySQL versi 2) atau mysql.rds_set_external_source (Aurora MySQL versi 3) dan 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;

  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 basis data dari instans DB MySQL eksternal ke klaster DB Amazon Aurora MySQL menggunakan mysqldump. Untuk basis data yang sangat besar, Anda sebaiknya menggunakan prosedur dalam Mengimpor data ke instans DB MySQL atau MariaDB dengan waktu henti yang lebih singkat dalam 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
    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.

  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 cadangan untuk digunakan dengan replikasi, lihat Backing up a source or replica by making it read only dalam dokumentasi MySQL.

  5. 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 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.

  6. 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'@'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 basis data bagi pengguna 'repl_user' untuk domain Anda, jalankan perintah berikut.

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

  8. 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.

  9. Jadikan klaster DB Amazon Aurora sebagai replika. Hubungkan ke klaster DB Amazon Aurora sebagai pengguna master dan identifikasi basis data MySQL sumber sebagai master replikasi dengan menggunakan prosedur mysql.rds_set_external_master (Aurora MySQL versi 2) atau mysql.rds_set_external_source (Aurora MySQL versi 3) dan mysql.rds_start_replication.

    Gunakan nama file log master dan posisi log master yang Anda tentukan pada Langkah 2. Berikut adalah contohnya.

    For Aurora MySQL version 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:
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, panggil prosedur 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.

Mengoptimalkan replikasi log biner

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 dalam dokumentasi MySQL.

Replikasi log biner multithreaded (Aurora MySQL versi 3)

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.

Ketika instance Aurora MySQL dikonfigurasi untuk menggunakan replikasi log biner, secara default instance replika menggunakan replikasi single-threaded untuk versi MySQL Aurora yang lebih rendah dari 3,04. Untuk mengaktifkan replikasi multi-thread, Anda memperbarui parameter replica_parallel_workers ke nilai yang lebih besar dari nol 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.

Opsi konfigurasi berikut dapat membantu Anda menyesuaikan replikasi multi-thread. Untuk informasi penggunaan, lihat Replication and Binary Logging Options and Variables dalam Panduan Referensi MySQL.

Konfigurasi yang optimal akan bergantung 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_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

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.

Anda juga dapat menggunakan parameter ini sebagai variabel global, di mana n adalah jumlah thread pekerja paralel:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Mengoptimalkan replikasi binlog (Aurora MySQL 2.10 dan lebih tinggi)

Di Aurora MySQL 2.10 dan lebih tinggi, Aurora secara otomatis menerapkan optimisasi yang dikenal sebagai cache I/O binlog ke replikasi log biner. 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 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 I/O binlog.

  • aurora_binlog_io_cache_read_requests menunjukkan jumlah permintaan baca I/O binlog dari cache.

  • aurora_binlog_io_cache_reads: menunjukkan jumlah baca I/O 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 cache I/O binlog juga menyertakan metrik baru yang terkait dengan thread 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 thread I/O 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.

Mengoptimalkan replikasi binlog (Aurora MySQL versi 2 hingga 2.09)

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

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

catatan

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

Gambaran umum buffer baca besar dan optimisasi hasil maks

Anda mungkin mengalami penurunan performa replikasi log biner saat thread dump log biner mengakses volume klaster Aurora sementara klaster ini memproses sejumlah besar transaksi. Anda dapat menggunakan parameter 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 mana aurora_binlog_replication_max_yield_seconds disetel ke nilai yang lebih besar dari 0 dan file binlog terkini thread dump berstatus aktif. Dalam hal ini, thread dump log biner menunggu hingga beberapa detik agar file binlog saat ini diisi oleh transaksi. Periode tunggu ini menghindari pertentangan yang dapat timbul dari replikasi setiap binlog peristiwa secara individual. Namun, hal ini akan meningkatkan lag replika untuk replika log biner. Replika tersebut dapat tertinggal di belakang sumber dengan jumlah detik yang sama seperti pengaturan aurora_binlog_replication_max_yield_seconds.

File binlog terkini adalah file binlog yang sedang dibaca oleh thread dump untuk melakukan replikasi. Kami menganggap bahwa file binlog aktif jika file binlog ini memperbarui atau terbuka untuk diperbarui oleh transaksi masuk. Setelah Aurora MySQL mengisi file binlog aktif, MySQL membuat dan beralih ke file binlog baru. File binlog lama menjadi tidak aktif. File ini tidak diperbarui oleh transaksi masuk lagi.

catatan

Sebelum menyesuaikan parameter ini, ukur latensi dan throughput transaksi Anda dari waktu ke waktu. Anda mungkin menemukan bahwa performa 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 parameter aurora_binlog_read_buffer_size dan aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

Thread 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.

catatan

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

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

aurora_binlog_replication_max_yield_seconds

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

catatan

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, thread dump hanya mulai memberikan hasil saat file binlog saat ini mencapai ukuran maksimum 128 MB dan dirotasi ke file baru.

Parameter terkait

Gunakan parameter klaster DB berikut untuk mengaktifkan optimisasi binlog.

Parameter Default Nilai Valid Deskripsi
aurora_binlog_use_large_read_buffer 1 0, 1 Opsi untuk mengaktifkan fitur peningkatan replikasi. Jika nilainya 1, thread dump log biner menggunakan aurora_binlog_read_buffer_size untuk replikasi log biner; jika tidak, ukuran buffer default (8K) digunakan. Tidak digunakan di Aurora MySQL versi 3.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Ukuran buffer baca yang digunakan oleh thread dump log biner saat parameter aurora_binlog_use_large_read_buffer disetel ke 1. Tidak digunakan di Aurora MySQL versi 3.
aurora_binlog_replication_max_yield_seconds 0 0-36000

Untuk Aurora MySQL versi 2.07.*, nilai maksimum yang diterima adalah 45. Anda dapat menyetelnya ke nilai yang lebih tinggi pada versi 2.09 dan yang lebih baru.

Untuk versi 2, parameter ini hanya berfungsi jika parameter aurora_binlog_use_large_read_buffer diatur menjadi 1.

Mengaktifkan mekanisme hasil maksimal untuk replikasi log biner

Anda dapat mengaktifkan optimisasi hasil maksimal replikasi log biner sebagai berikut. Hal ini akan meminimalkan latensi untuk transaksi pada instans sumber binlog. Namun, Anda mungkin mengalami lag replikasi yang lebih tinggi.

Untuk mengaktifkan optimisasi binlog hasil maksimal untuk klaster Aurora MySQL

  1. Buat atau edit 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 klaster DB dengan klaster Aurora MySQL yang berfungsi sebagai sumber binlog. Untuk melakukannya, ikuti prosedur dalam Bekerja dengan grup parameter.

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

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    Output Anda harus seperti yang berikut ini. 

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

Menonaktifkan optimisasi hasil maksimal replikasi log biner

Anda dapat menonaktifkan optimisasi hasil maksimal replikasi log biner sebagai berikut. Hal ini akan meminimalkan lag replikasi. Namun, Anda mungkin mengalami latensi yang lebih tinggi untuk transaksi pada instans sumber binlog.

Untuk menonaktifkan optimisasi 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. 

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    Output Anda harus seperti yang 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 seperti yang berikut ini. 

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

Menyiapkan binlog yang ditingkatkan

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.

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 ditingkatkan
Parameter Default Deskripsi
binlog_format – Atur parameter binlog_format ke format pencatatan log biner pilihan Anda untuk mengaktifkan binlog yang ditingkatkan. Pastikan binlog_format parameter tidak diatur ke OFF. Untuk informasi selengkapnya, lihat Mengonfigurasi pencatatan log biner Aurora MySQL.
aurora_enhanced_binlog 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_backup 1 Nonaktifkan parameter ini untuk mengaktifkan binlog yang ditingkatkan. Untuk melakukannya, tetapkan nilai parameter ini ke 0.
binlog_replication_globaldb 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 menonaktifkan binlog yang ditingkatkan
Parameter Deskripsi
aurora_enhanced_binlog 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_backup Aktifkan parameter ini saat Anda menonaktifkan binlog yang ditingkatkan. Untuk melakukannya, tetapkan nilai parameter ini ke 1.
binlog_replication_globaldb 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.

contoh Operasi kloning atau pemulihan yang dilakukan saat binlog yang ditingkatkan diaktifkan

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)
contoh Operasi kloning atau pemulihan yang dilakukan saat binlog yang ditingkatkan dinonaktifkan

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)

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.

contoh Operasi failover basis data 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)
contoh Operasi failover basis data global dilakukan ketika binlog yang ditingkatkan dinonaktifkan

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:

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
ChangeLogReadIOP Jumlah operasi I/O baca yang dilakukan di binlog yang ditingkatkan dalam interval 5 menit. Hitungan per 5 menit
ChangeLogWriteIOP 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 AWS Support.

  • Cache I/O binlog dinonaktifkan saat binlog yang ditingkatkan diaktifkan. Untuk informasi selengkapnya, lihat Mengoptimalkan replikasi log biner.

    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.