Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Replikasi dengan Amazon Aurora MySQL Fitur-fitur replikasi Aurora MySQL merupakan kunci untuk ketersediaan dan performa yang tinggi dari klaster Anda. Aurora mempermudah pembuatan atau perubahan ukuran klaster dengan maksimal 15 Replika Aurora. Semua replika beroperasi dari data acuan yang sama. Jika beberapa instans basis data menjadi offline, yang lain akan tetap tersedia untuk melanjutkan pemrosesan kueri atau mengambil alih sebagai penulis jika diperlukan. Aurora akan secara otomatis menyebarkan koneksi hanya-baca Anda ke beberapa instans basis data, sehingga membantu klaster Aurora mendukung beban kerja sarat kueri. Dalam topik berikut, Anda dapat menemukan informasi tentang cara kerja replikasi Aurora MySQL dan cara menyesuaikan pengaturan replikasi untuk ketersediaan dan performa terbaik. **Topics** + [Menggunakan Replika Aurora](#AuroraMySQL.Replication.Replicas) + [Opsi replikasi untuk Amazon Aurora MySQL](#AuroraMySQL.Replication.Options) + [Pertimbangan performa untuk replikasi Amazon Aurora MySQL](#AuroraMySQL.Replication.Performance) + [Mengkonfigurasi filter replikasi dengan Aurora My SQL](AuroraMySQL.Replication.Filters.md) + [Memantau replikasi Amazon Aurora MySQL](#AuroraMySQL.Replication.Monitoring) + [Mereplikasi kluster DB MySQL Amazon Aurora Wilayah AWS](AuroraMySQL.Replication.CrossRegion.md) + [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md) + [Menggunakan replikasi GTID berbasis](mysql-replication-gtid.md) ## Menggunakan Replika Aurora Replika Aurora adalah titik akhir independen dalam klaster basis data Aurora, yang paling berguna untuk menskalakan operasi baca dan meningkatkan ketersediaan. Hingga 15 Replika Aurora dapat didistribusikan ke seluruh Zona Ketersediaan yang dicakup oleh sebuah klaster DB di satu Wilayah AWS. Meskipun volume klaster DB terdiri dari beberapa salinan data untuk klaster DB, data dalam volume klaster direpresentasikan sebagai volume logis tunggal untuk instans primer dan Replika Aurora dalam klaster DB tersebut. Untuk informasi selengkapnya tentang Replika Aurora, lihat [Replika Aurora](Aurora.Replication.md#Aurora.Replication.Replicas). Replika Aurora berfungsi dengan baik untuk penskalaan baca karena ditujukan sepenuhnya untuk operasi baca pada volume klaster Anda. Operasi tulis dikelola oleh instans primer. Karena volume klaster dibagikan di antara semua instans dalam klaster DB Aurora MySQL Anda, tidak diperlukan pekerjaan tambahan untuk mereplikasi salinan data untuk setiap Replika Aurora. Sebaliknya, replika baca MySQL harus mengulang, pada thread tunggal, semua operasi tulis dari instans DB sumber daya ke penyimpanan data lokalnya. Batasan ini dapat memengaruhi kemampuan replika baca MySQL untuk mendukung volume lalu lintas baca yang besar. Dengan Aurora MySQL, saat Replika Aurora dihapus, titik akhir instansnya akan segera dihapus, dan Replika Aurora akan dihapus dari titik akhir pembaca. Jika ada pernyataan yang berjalan di Replika Aurora yang dihapus, ada masa tenggang selama tiga menit. Pernyataan yang ada dapat diselesaikan sepenuhnya selama masa tenggang ini. Setelah masa tenggang berakhir, Replika Aurora akan dinonaktifkan dan dihapus. **penting** Replika Aurora untuk Aurora MySQL selalu menggunakan tingkat isolasi transaksi default `REPEATABLE READ` untuk operasi pada tabel InnoDB. Anda dapat menggunakan perintah `SET TRANSACTION ISOLATION LEVEL` untuk mengubah tingkat transaksi hanya untuk instans primer klaster DB Aurora MySQL. Pembatasan ini bertujuan untuk menghindari kunci tingkat pengguna pada Replika Aurora, dan memungkinkan penskalaan Replika Aurora untuk mendukung ribuan koneksi pengguna aktif sambil tetap menjaga lag replika seminimal mungkin. **catatan** Pernyataan DDL yang berjalan pada instans primer dapat menginterupsi koneksi basis data pada Replika Aurora terkait. Jika koneksi Replika Aurora secara aktif menggunakan objek basis data, seperti tabel, dan objek tersebut dimodifikasi pada instans primer menggunakan pernyataan DDL, koneksi Replika Aurora dapat terinterupsi. **catatan** Wilayah Tiongkok (Ningxia) tidak mendukung replika baca lintas Wilayah. ## Opsi replikasi untuk Amazon Aurora MySQL Anda dapat mengatur replikasi dengan opsi-opsi berikut: + Dua cluster DB MySQL Aurora berbeda Wilayah AWS, dengan membuat replika baca lintas wilayah dari cluster DB MySQL Aurora. Untuk informasi selengkapnya, lihat [Mereplikasi kluster DB MySQL Amazon Aurora Wilayah AWS](AuroraMySQL.Replication.CrossRegion.md). + Dua cluster Aurora MySQL DB yang sama, dengan menggunakan replikasi log biner MySQL ( Wilayah AWS binlog). Untuk informasi selengkapnya, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). + Instans DB RDS for MySQL sebagai sumber dan klaster DB Aurora MySQL, dengan membuat replika baca Aurora dari instans DB RDS for MySQL. Anda dapat menggunakan pendekatan ini untuk memindahkan perubahan data yang ada dan yang sedang berlangsung ke Aurora MySQL selama migrasi ke Aurora. Untuk informasi selengkapnya, lihat [Memigrasikan data dari instans DB RDS for MySQL ke klaster DB Amazon Aurora MySQL menggunakan replika baca Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md). Anda juga dapat menggunakan pendekatan ini untuk meningkatkan skalabilitas kueri baca untuk data Anda. Caranya adalah dengan mengueri data menggunakan satu atau beberapa instans DB dalam klaster Aurora MySQL hanya baca. Untuk informasi selengkapnya, lihat [Penskalaan bacaan untuk database MySQL Anda dengan Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). + Cluster DB MySQL Aurora dalam satu dan Wilayah AWS hingga lima cluster Aurora MySQL DB read-only Aurora di Wilayah yang berbeda, dengan membuat database global Aurora. Anda dapat menggunakan basis data global Aurora untuk mendukung aplikasi dengan jejak global. Klaster DB Aurora MySQL primer memiliki instans Penulis dan maksimal 15 Replika Aurora. Klaster DB Aurora MySQL sekunder hanya baca masing-masing dapat terdiri dari maksimal 16 Replika Aurora. Untuk informasi selengkapnya, lihat [Menggunakan Database Global Amazon Aurora](aurora-global-database.md). **catatan** Mem-boot ulang instance utama cluster Amazon Aurora DB juga secara otomatis me-reboot Aurora Replicas untuk cluster DB tersebut, untuk membangun kembali titik masuk yang menjamin konsistensi di seluruh cluster DB. read/write ## Pertimbangan performa untuk replikasi Amazon Aurora MySQL Fitur berikut dapat membantu Anda menyesuaikan performa replikasi Aurora MySQL. Fitur kompresi log replika secara otomatis mengurangi bandwidth jaringan untuk pesan replikasi. Karena setiap pesan ditransmisikan ke semua Replika Aurora, manfaat yang diberikan akan lebih besar untuk klaster yang lebih besar. Fitur ini memerlukan beberapa overhead CPU pada simpul penulis untuk melakukan kompresi. Fitur ini selalu diaktifkan di Aurora MySQL versi 2 dan versi 3. Fitur pemfilteran binlog secara otomatis mengurangi bandwidth jaringan untuk pesan replikasi. Karena Replika Aurora tidak menggunakan informasi binlog yang disertakan dalam pesan replikasi, data tersebut dihilangkan dari pesan yang dikirim ke simpul-simpul tersebut. Di Aurora MySQL versi 2, Anda dapat mengontrol fitur ini dengan mengubah parameter `aurora_enable_repl_bin_log_filtering`. Parameter ini aktif secara default. Karena optimisasi ini dimaksudkan agar bersifat transparan, Anda dapat menonaktifkan pengaturan ini hanya selama diagnosis atau pemecahan masalah yang terkait dengan replikasi. Misalnya, Anda dapat melakukannya untuk mencocokkan dengan perilaku klaster Aurora MySQL lama yang tidak menyediakan fitur ini. Pemfilteran Binlog selalu diaktifkan di Aurora MySQL versi 3. # Mengkonfigurasi filter replikasi dengan Aurora My SQL Anda dapat menggunakan filter replikasi untuk menentukan basis data dan tabel mana yang direplikasi dengan replika baca. Filter replikasi dapat menyertakan basis data dan tabel dalam replikasi atau mengecualikannya dari replikasi. Berikut ini adalah beberapa kasus penggunaan untuk filter replikasi: + Untuk mengurangi ukuran replika baca. Dengan filter replikasi, Anda dapat mengecualikan basis data dan tabel yang tidak diperlukan pada replika baca. + Untuk mengecualikan basis data dan tabel dari replika baca untuk alasan keamanan. + Untuk mereplikasi basis data yang berbeda dan tabel untuk kasus penggunaan tertentu di replika baca yang berbeda. Misalnya, Anda mungkin menggunakan replika baca khusus untuk analitik atau penyerpihan. + Untuk cluster DB yang telah membaca replika di berbagai Wilayah AWS, untuk mereplikasi database atau tabel yang berbeda dalam berbagai Wilayah AWS. + Untuk menentukan database dan tabel mana yang direplikasi dengan cluster Aurora My SQL DB yang dikonfigurasi sebagai replika dalam topologi replikasi masuk. Untuk informasi selengkapnya tentang konfigurasi ini, silakan lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). **Topics** + [Mengatur parameter penyaringan replikasi untuk Aurora My SQL](#AuroraMySQL.Replication.Filters.Configuring) + [Batasan penyaringan replikasi untuk Aurora My SQL](#AuroraMySQL.Replication.Filters.Limitations) + [Contoh penyaringan replikasi untuk Aurora My SQL](#AuroraMySQL.Replication.Filters.Examples) + [Melihat filter replikasi untuk replika baca](#AuroraMySQL.Replication.Filters.Viewing) ## Mengatur parameter penyaringan replikasi untuk Aurora My SQL Untuk mengonfigurasi filter replikasi, atur parameter berikut: + `binlog-do-db` – Mereplikasi perubahan ke log biner yang ditentukan. Ketika Anda mengatur parameter ini untuk klaster sumber binlog, hanya log biner yang ditentukan dalam parameter yang direplikasi. + `binlog-ignore-db` – Jangan mereplikasi ke log biner yang ditentukan. Ketika parameter `binlog-do-db` diatur untuk klaster sumber binlog, parameter ini tidak dievaluasi. + `replicate-do-db` – Mereplikasi perubahan ke basis data yang ditentukan. Ketika Anda mengatur parameter ini untuk klaster replika binlog, hanya basis data yang ditentukan dalam parameter yang direplikasi. + `replicate-ignore-db` – Jangan mereplikasi perubahan ke basis data yang ditentukan. Ketika parameter `replicate-do-db` diatur untuk klaster replika binlog, parameter ini tidak dievaluasi. + `replicate-do-table` – Mereplikasi perubahan ke tabel yang ditentukan. Ketika Anda menetapkan parameter ini untuk replika baca, hanya tabel yang ditentukan dalam parameter yang direplikasi. Selain itu, ketika parameter `replicate-ignore-db` atau `replicate-do-db` diatur, pastikan untuk menyertakan basis data yang mencakup tabel tertentu dalam replikasi dengan klaster replika binlog. + `replicate-ignore-table` – Jangan mereplikasi perubahan ke tabel yang ditentukan. Ketika parameter `replicate-do-table` diatur untuk klaster replika binlog, parameter ini tidak dievaluasi. + `replicate-wild-do-table` – Mereplikasi tabel berdasarkan basis data dan pola nama tabel yang ditentukan. Karakter wildcard `%` dan `_` didukung. Ketika parameter `replicate-ignore-db` atau `replicate-do-db` diatur, pastikan untuk menyertakan basis data yang mencakup tabel tertentu dalam replikasi dengan klaster replika binlog. + `replicate-wild-ignore-table` – Jangan mereplikasi tabel berdasarkan basis data dan pola nama tabel yang ditentukan. Karakter wildcard `%` dan `_` didukung. Ketika parameter `replicate-wild-do-table` atau `replicate-do-table` diatur untuk klaster replika binlog, parameter ini tidak dievaluasi. Parameter dievaluasi sesuai dengan urutannya dalam daftar. Untuk informasi selengkapnya tentang cara kerja parameter ini, lihat SQL Dokumentasi saya: + Untuk informasi umum, lihat [Opsi dan Variabel Server Replika](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html). + Untuk informasi tentang cara parameter pemfilteran replikasi basis data dievaluasi, lihat [Evaluation of Database-Level Replication and Binary Logging Options](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html). + Untuk informasi tentang cara parameter filter replikasi basis data dievaluasi, lihat [Evaluasi Opsi Replikasi Tingkat Tabel](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html). Secara default, masing-masing parameter ini memiliki nilai kosong. Pada setiap klaster binlog, Anda dapat menggunakan parameter ini untuk mengatur, mengubah, dan menghapus filter replikasi. Ketika Anda menetapkan salah satu parameter ini, pisahkan masing-masing filter dari yang lain dengan koma. Anda dapat menggunakan karakter wildcard `%` dan `_` dalam parameter `replicate-wild-do-table` dan `replicate-wild-ignore-table`. Parameter wildcard `%` mencocokkan jumlah karakter berapa pun, dan wildcard `_` hanya mencocokkan satu karakter. Format pencatatan log biner instans DB sumber penting untuk replikasi karena menentukan catatan perubahan data. Pengaturan parameter `binlog_format` menentukan apakah replikasi berbasis baris atau berbasis pernyataan. Untuk informasi selengkapnya, lihat [Mengkonfigurasi Aurora untuk database Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **catatan** Semua pernyataan bahasa definisi data (DDL) direplikasi sebagai pernyataan, terlepas dari `binlog_format` pengaturan pada instance DB sumber. ## Batasan penyaringan replikasi untuk Aurora My SQL Batasan berikut berlaku untuk penyaringan replikasi untuk Aurora My: SQL + Filter replikasi hanya didukung untuk Aurora SQL My versi 3. + Setiap parameter filter replikasi memiliki batas 2.000 karakter. + Koma tidak didukung dalam filter replikasi. + Filter replikasi tidak mendukung transaksi XA. Untuk informasi selengkapnya, lihat [Pembatasan Transaksi XA](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) di SQL dokumentasi Saya. ## Contoh penyaringan replikasi untuk Aurora My SQL Untuk mengonfigurasi filter replikasi untuk replika baca, modifikasi parameter filter replikasi dalam grup parameter klaster DB yang terkait dengan replika baca. **catatan** Anda tidak dapat memodifikasi grup parameter klaster DB default. Jika replika baca menggunakan grup parameter default, buat grup parameter baru dan kaitkan dengan replika baca tersebut. Untuk informasi selengkapnya tentang grup parameter klaster DB, lihat [](USER_WorkingWithParamGroups.md). Anda dapat mengatur parameter dalam grup parameter cluster DB menggunakan Konsol Manajemen AWS, AWS CLI, atau RDSAPI. Untuk informasi tentang mengatur parameter, lihat [Memodifikasi parameter dalam grup parameter DB di ](USER_WorkingWithParamGroups.Modifying.md). Ketika Anda mengatur parameter dalam grup parameter klaster DB, semua klaster DB yang terkait dengan grup parameter tersebut akan menggunakan pengaturan parameter. Jika Anda mengatur parameter filter replikasi dalam grup parameter klaster DB, pastikan bahwa grup parameter dikaitkan hanya dengan klaster replika baca. Biarkan parameter filter replikasi kosong untuk instans DB sumber. Contoh berikut mengatur parameter menggunakan AWS CLI. Contoh-contoh ini diatur `ApplyMethod` `immediate` agar perubahan parameter terjadi segera setelah CLI perintah selesai. Jika Anda ingin menerapkan perubahan tertunda setelah replika baca di-boot ulang, atur `ApplyMethod` ke `pending-reboot`. Contoh berikut mengatur filter replikasi: + [Including databases in replication](#rep-filter-in-dbs-ams) + [Including tables in replication](#rep-filter-in-tables-ams) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-ams) + [Excluding databases from replication](#rep-filter-ex-dbs-ams) + [Excluding tables from replication](#rep-filter-ex-tables-ams) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-ams) **Example Menyertakan basis data dalam replikasi** Contoh berikut menyertakan basis data `mydb1` dan `mydb2` dalam replikasi. Untuk Linux, macOS, atau Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` Untuk Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` **Example Menyertakan tabel dalam replikasi** Contoh berikut menyertakan tabel `table1` dan `table2` dalam `mydb1` basis data dalam replikasi. Untuk Linux, macOS, atau Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` Untuk Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` **Example Menyertakan tabel dalam replikasi menggunakan karakter wildcard** Contoh berikut menyertakan tabel dengan nama berawalan `order` dan `return` dalam basis data `mydb` dalam replikasi. Untuk Linux, macOS, atau Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` Untuk Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` **Example Mengecualikan basis data dari replikasi** Contoh berikut mengecualikan basis data `mydb5` dan `mydb6` dari replikasi. Untuk Linux, macOS, atau Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` Untuk Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate" ``` **Example Mengecualikan tabel dari replikasi** Contoh berikut mengecualikan tabel `table1` dalam basis data `mydb5` dan `table2` dalam basis data `mydb6` dari replikasi. Untuk Linux, macOS, atau Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` Untuk Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` **Example Mengecualikan tabel dari replikasi menggunakan karakter wildcard** Contoh berikut mengecualikan tabel dengan nama berawalan `order` dan `return` dalam basis data `mydb7` dari replikasi. Untuk Linux, macOS, atau Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` Untuk Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` ## Melihat filter replikasi untuk replika baca Anda dapat melihat filter replikasi untuk replika baca dengan cara berikut: + Memeriksa pengaturan parameter filter replikasi dalam grup parameter yang terkait dengan replika baca. Untuk petunjuk, silakan lihat [Melihat nilai parameter untuk grup parameter DB di ](USER_WorkingWithParamGroups.Viewing.md). + Di SQL klien Saya, sambungkan ke replika baca dan jalankan `SHOW REPLICA STATUS` pernyataan. Dalam output, bidang berikut menunjukkan filter replikasi untuk replika baca: + `Binlog_Do_DB` + `Binlog_Ignore_DB` + `Replicate_Do_DB` + `Replicate_Ignore_DB` + `Replicate_Do_Table` + `Replicate_Ignore_Table` + `Replicate_Wild_Do_Table` + `Replicate_Wild_Ignore_Table` Untuk informasi selengkapnya tentang bidang ini, lihat [Memeriksa Status Replikasi](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) di SQL Dokumentasi saya. ## Memantau replikasi Amazon Aurora MySQL Penskalaan baca dan ketersediaan yang tinggi tergantung dari waktu lag minimal. Anda dapat memantau seberapa jauh Aurora Replica tertinggal dari instance utama cluster DB MySQL Aurora Anda dengan memantau metrik Amazon. CloudWatch `AuroraReplicaLag` Metrik `AuroraReplicaLag` dicatat dalam setiap Replika Aurora. Instans primer DB juga merekam metrik `AuroraReplicaLagMaximum` dan `AuroraReplicaLagMinimum` Amazon CloudWatch. Metrik `AuroraReplicaLagMaximum` akan mencatat jumlah maksimum lag antara instans DB primer dan setiap Replika Aurora dalam klaster DB. Metrik `AuroraReplicaLagMinimum` akan mencatat jumlah minimum lag antara instans DB primer dan setiap Replika Aurora dalam klaster DB. Jika Anda membutuhkan nilai terbaru untuk lag Aurora Replica, Anda dapat memeriksa metrik `AuroraReplicaLag` di Amazon. CloudWatch Lag Replika Aurora juga dicatat pada setiap Replika Aurora dari klaster DB Aurora MySQL Anda dalam tabel `information_schema.replica_host_status`. Untuk informasi selengkapnya tentang tabel ini, lihat [information\$1schema.replica\$1host\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.replica_host_status). Untuk informasi selengkapnya tentang pemantauan instans dan CloudWatch metrik RDS, lihat. [Memantau metrik di klaster Amazon Aurora](MonitoringAurora.md) # Mereplikasi kluster DB MySQL Amazon Aurora Wilayah AWS Anda dapat membuat kluster DB MySQL Amazon Aurora sebagai replika baca di cluster DB sumber yang berbeda. Wilayah AWS Mengambil pendekatan ini dapat meningkatkan kemampuan pemulihan bencana Anda, memungkinkan Anda menskalakan operasi baca menjadi Wilayah AWS yang lebih dekat dengan pengguna Anda, dan membuatnya lebih mudah untuk bermigrasi dari satu Wilayah AWS ke yang lain. Anda dapat membuat replika baca klaster DB terenkripsi atau tidak terenkripsi. Replika baca harus dienkripsi jika klaster DB sumber dienkripsi. Untuk setiap klaster DB sumber, Anda dapat memiliki hingga lima klaster DB lintas Wilayah yang berupa replika baca. **catatan** Sebagai alternatif untuk replika baca lintas Wilayah, Anda dapat menskalakan operasi baca dengan waktu lag minimal dengan menggunakan basis data global Aurora. Database global Aurora memiliki cluster DB Aurora primer dalam satu Wilayah AWS dan hingga 10 cluster DB read-only sekunder di Wilayah yang berbeda. Setiap klaster DB sekunder dapat menyertakan hingga 16 (bukan 15) Replika Aurora. Replikasi dari klaster DB primer ke semua sekunder ditangani oleh lapisan penyimpanan Aurora, bukan oleh mesin basis data, sehingga waktu lag untuk mereplikasi perubahan menjadi minimal—biasanya, kurang dari 1 detik. Mengecualikan mesin basis data dari proses replikasi berarti bahwa mesin basis data dikhususkan untuk memproses beban kerja. Ini juga berarti bahwa Anda tidak perlu mengonfigurasi atau mengelola replikasi binlog (binlog biner) Aurora MySQL. Untuk mempelajari selengkapnya, lihat [Menggunakan Database Global Amazon Aurora](aurora-global-database.md). Saat Anda membuat replika baca cluster MySQL DB Aurora di tempat lain Wilayah AWS, Anda harus mengetahui hal berikut: + Klaster DB sumber Anda dan klaster DB replika baca lintas Wilayah Anda dapat memiliki hingga 15 Replika Aurora, di samping instans primer untuk klaster DB tersebut. Dengan menggunakan fungsi ini, Anda dapat menskalakan operasi baca untuk sumber Wilayah AWS dan target Wilayah AWS replikasi Anda. + Dalam sebuah skenario lintas Wilayah, terdapat lebih banyak waktu lag antara klaster DB sumber dan replika baca karena saluran jaringan yang lebih panjang antar- Wilayah AWS. + Data yang ditransfer untuk replikasi lintas Wilayah akan menimbulkan biaya transfer data Amazon RDS. Tindakan replikasi lintas Wilayah berikut menghasilkan biaya untuk data yang ditransfer dari Wilayah AWS sumber: + Saat Anda membuat replika baca, Amazon RDS mengambil snapshot dari cluster sumber dan mentransfer snapshot ke Wilayah AWS yang menyimpan replika baca. + Untuk setiap modifikasi data yang dibuat dalam database sumber, Amazon RDS mentransfer data dari wilayah sumber ke Wilayah AWS yang menyimpan replika baca. Untuk informasi selengkapnya tentang harga transfer data Amazon RDS, lihat [Harga Amazon Aurora](https://aws.amazon.com/rds/aurora/pricing/). + Anda dapat menjalankan beberapa tindakan pembuatan atau penghapusan konkuren untuk replika baca yang mengacu pada klaster DB sumber yang sama. Namun, Anda harus tetap berada dalam batasan lima replika baca untuk setiap klaster DB sumber. + Agar replikasi dapat beroperasi secara efektif, setiap replika baca harus memiliki jumlah sumber daya komputasi dan penyimpanan yang sama dengan klaster DB sumber. Jika Anda menskalakan klaster DB sumber, Anda juga harus menskalakan replika baca. **Topics** + [Sebelum Anda memulai](#AuroraMySQL.Replication.CrossRegion.Prerequisites) + [Membuat cluster DB replika baca lintas wilayah untuk Aurora My SQL](AuroraMySQL.Replication.CrossRegion.Creating.md) + [Mempromosikan replika baca ke cluster DB untuk Aurora My SQL](AuroraMySQL.Replication.CrossRegion.Promote.md) + [Memecahkan masalah Replika lintas wilayah untuk Amazon Aurora My SQL](AuroraMySQL.Replication.CrossRegion.Troubleshooting.md) ## Sebelum Anda memulai Sebelum Anda dapat membuat klaster DB Aurora MySQL yang merupakan replika baca lintas Wilayah, Anda harus mengaktifkan pencatatan log biner pada klaster DB Aurora MySQL sumber Anda. Replikasi lintas wilayah untuk Aurora MySQL menggunakan replikasi biner MySQL untuk mengulang perubahan pada klaster DB replika baca lintas Wilayah. Untuk mengaktifkan pencatatan log biner pada sebuah klaster DB Aurora MySQL, perbarui parameter `binlog_format` untuk klaster DB sumber Anda. Parameter `binlog_format` adalah parameter tingkat klaster yang berada dalam grup parameter klaster default. Jika klaster DB Anda menggunakan grup parameter klaster DB default, buat sebuah grup parameter klaster DB baru untuk memodifikasi pengaturan `binlog_format`. Kami sarankan Anda mengatur `binlog_format` ke `MIXED`. Namun, Anda juga dapat mengatur `binlog_format` ke `ROW` atau `STATEMENT` jika Anda memerlukan format binlog tertentu. Boot ulang klaster DB Aurora Anda agar perubahan dapat diterapkan. Untuk informasi selengkapnya tentang menggunakan pencatatan log biner dengan Aurora MySQL, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). Untuk informasi selengkapnya tentang memodifikasi parameter konfigurasi Aurora MySQL, lihat [Parameter klaster DB dan instans DB Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) dan [](USER_WorkingWithParamGroups.md). # Membuat cluster DB replika baca lintas wilayah untuk Aurora My SQL Anda dapat membuat klaster Aurora DB yang merupakan replika baca lintas wilayah dengan menggunakan, AWS Command Line Interface (AWS CLI) Konsol Manajemen AWS, atau Amazon. RDS API Anda dapat membuat replika baca klaster lintas Wilayah dari klaster DB yang terenkripsi atau tidak terenkripsi. Saat Anda membuat replika baca Lintas wilayah untuk Aurora My SQL dengan menggunakan, Konsol Manajemen AWS Amazon RDS membuat cluster DB di target Wilayah AWS, dan kemudian secara otomatis membuat instance DB yang merupakan instance utama untuk cluster DB tersebut. Saat Anda membuat replika baca lintas wilayah menggunakan AWS CLI or RDSAPI, pertama-tama Anda membuat cluster DB di target Wilayah AWS dan menunggu hingga menjadi aktif. Setelah aktif, Anda kemudian dapat membuat sebuah instans DB yang merupakan instans primer untuk klaster DB tersebut. Replikasi dimulai saat instans primer dari klaster DB replika baca menjadi tersedia. Gunakan prosedur berikut untuk membuat replika baca lintas wilayah dari cluster Aurora My DB. SQL Prosedur ini berfungsi untuk pembuatan replika baca dari klaster DB terenkripsi atau tidak terenkripsi. ## Konsol **Untuk membuat cluster Aurora My SQL DB yang merupakan replika baca lintas wilayah dengan Konsol Manajemen AWS** 1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Di sudut kanan atas Konsol Manajemen AWS, pilih Wilayah AWS yang menghosting cluster DB sumber Anda. 1. Di panel navigasi, pilih **Basis Data**. 1. Pilih klaster DB yang ingin Anda buat replika baca lintas Wilayahnya. 1. Untuk **Tindakan**, pilih **Buat replika baca lintas Wilayah**. 1. Pada halaman **Buat replika baca lintas wilayah**, pilih pengaturan opsi untuk klaster DB replika baca lintas Wilayah Anda, seperti yang dijelaskan dalam tabel berikut. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html) 1. Pilih **Buat** untuk membuat replika baca lintas Wilayah Anda untuk Aurora. ## AWS CLI **Untuk membuat cluster Aurora My SQL DB yang merupakan replika baca lintas wilayah dengan CLI** 1. Panggil AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)perintah di Wilayah AWS tempat Anda ingin membuat cluster DB replika baca. Sertakan `--replication-source-identifier` opsi dan tentukan Amazon Resource Name (ARN) dari cluster DB sumber untuk membuat replika baca. Untuk replikasi lintas Wilayah yang mengenkripsi klaster DB yang diidentifikasi berdasarkan `--replication-source-identifier`, tentukan opsi `--kms-key-id` dan opsi `--storage-encrypted`. **catatan** Anda dapat mengatur replikasi lintas Wilayah dari sebuah klaster DB yang tidak terenkripsi ke replika baca terenkripsi dengan menentukan `--storage-encrypted` dan menyediakan sebuah nilai untuk `--kms-key-id`. Anda tidak dapat menentukan parameter `--master-username` dan `--master-user-password`. Nilai tersebut diambil dari klaster DB sumber. Contoh kode berikut ini membuat sebuah replika baca di Wilayah us-east-1 dari sebuah snapshot klaster DB tidak terenkripsi di Wilayah us-west-2. Perintah ini dipanggil di Wilayah us-east-1. Contoh ini menentukan opsi `--manage-master-user-password` untuk menghasilkan kata sandi pengguna master dan mengelolanya di Secrets Manager. Untuk informasi selengkapnya, lihat [Manajemen kata sandi dengan dan AWS Secrets Manager](rds-secrets-manager.md). Alternatifnya, Anda dapat menggunakan opsi `--master-password` untuk menentukan dan mengelola kata sandi sendiri. Untuk Linux, macOS, atau Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Untuk Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Contoh kode berikut ini menciptakan sebuah replika baca di Region us-east-1 dari sebuah snapshot klaster DB terenkripsi di Region us-west-2. Perintah ini dipanggil di Wilayah us-east-1. Untuk Linux, macOS, atau Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster \ --kms-key-id my-us-east-1-key \ --storage-encrypted ``` Untuk Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ^ --kms-key-id my-us-east-1-key ^ --storage-encrypted ``` `--source-region`Opsi ini diperlukan untuk replikasi lintas wilayah antara Wilayah AWS GovCloud (AS-Timur) dan AWS GovCloud (AS-Barat), di mana cluster DB yang diidentifikasi oleh dienkripsi. `--replication-source-identifier` Untuk`--source-region`, tentukan Wilayah AWS cluster DB sumber. Jika `--source-region` tidak ditentukan, tentukan nilai `--pre-signed-url`. *Presigned URL* adalah URL yang berisi permintaan ditandatangani Signature Version 4 untuk `create-db-cluster` perintah yang dipanggil di sumber Wilayah AWS. Untuk mempelajari lebih lanjut tentang `pre-signed-url` opsi, lihat [ create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)di *Referensi AWS CLI Perintah*. 1. Periksa apakah cluster DB telah tersedia untuk digunakan dengan menggunakan AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)perintah, seperti yang ditunjukkan pada contoh berikut. ``` aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster ``` Saat hasil **`describe-db-clusters`** menunjukkan sebuah status dari `available`, ciptakan instans primer untuk klaster DB sehingga replikasi dapat dimulai. Untuk melakukannya, gunakan AWS CLI [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)perintah seperti yang ditunjukkan pada contoh berikut. Untuk Linux, macOS, atau Unix: ``` aws rds create-db-instance \ --db-cluster-identifier sample-replica-cluster \ --db-instance-class db.r5.large \ --db-instance-identifier sample-replica-instance \ --engine aurora-mysql ``` Untuk Windows: ``` aws rds create-db-instance ^ --db-cluster-identifier sample-replica-cluster ^ --db-instance-class db.r5.large ^ --db-instance-identifier sample-replica-instance ^ --engine aurora-mysql ``` Ketika instans DBdibuat dan tersedia, replikasi akan dimulai. Anda dapat menentukan apakah instans DB tersedia dengan memanggil AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)perintah. ## RDS API **Untuk membuat cluster Aurora My SQL DB yang merupakan replika baca lintas wilayah dengan API** 1. Panggil reateDBCluster operasi RDS API [C](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) di Wilayah AWS tempat Anda ingin membuat cluster DB replika baca. Sertakan `ReplicationSourceIdentifier` parameter dan tentukan Amazon Resource Name (ARN) dari cluster DB sumber untuk membuat replika baca. Untuk replikasi lintas Wilayah yang mengenkripsi klaster DB yang diidentifikasi berdasarkan `ReplicationSourceIdentifier`, tentukan parameter `KmsKeyId` dan atur parameter `StorageEncrypted` ke `true`. **catatan** Anda dapat mengatur replikasi lintas Wilayah dari sebuah klaster DB yang tidak terenkripsi ke replika baca terenkripsi dengan menentukan `StorageEncrypted` sebagai **true** dan menyediakan sebuah nilai untuk `KmsKeyId`. Dalam hal ini, Anda tidak perlu menentukan `PreSignedUrl`. Anda tidak perlu menyertakan parameter `MasterUsername` dan `MasterUserPassword` karena nilai-nilai tersebut diambil dari klaster DB sumber. Contoh kode berikut ini membuat sebuah replika baca di Wilayah us-east-1 dari sebuah snapshot klaster DB tidak terenkripsi di Wilayah us-west-2. Tindakan ini dipanggil di Wilayah us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Contoh kode berikut ini membuat sebuah replika baca di Wilayah us-east-1 dari sebuah snapshot klaster DB terenkripsi di Wilayah us-west-2. Tindakan ini dipanggil di Wilayah us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &KmsKeyId=my-us-east-1-key &StorageEncrypted=true &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBCluster %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4 %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Untuk replikasi lintas wilayah antara Wilayah AWS GovCloud (AS-Timur) dan AWS GovCloud (AS-Barat), di mana cluster DB yang diidentifikasi oleh `ReplicationSourceIdentifier` dienkripsi, juga tentukan parameternya. `PreSignedUrl` Presigned URL harus merupakan permintaan yang valid untuk `CreateDBCluster` API operasi yang dapat dilakukan di sumber Wilayah AWS yang berisi cluster DB terenkripsi untuk direplikasi. Pengidentifikasi KMS kunci digunakan untuk mengenkripsi replika baca, dan harus menjadi KMS kunci yang valid untuk tujuan. Wilayah AWS Untuk secara otomatis daripada secara manual menghasilkan presignedURL, gunakan AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)perintah dengan `--source-region` opsi sebagai gantinya. 1. Periksa apakah cluster DB telah tersedia untuk digunakan dengan menggunakan escribeDBClusters operasi RDS API [D](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html), seperti yang ditunjukkan pada contoh berikut. ``` https://rds.us-east-1.amazonaws.com/ ?Action=DescribeDBClusters &DBClusterIdentifier=sample-replica-cluster &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T002223Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426 ``` Saat hasil `DescribeDBClusters` menunjukkan status dari `available`, buat instans primer untuk klaster DB sehingga replikasi dapat dimulai. Untuk melakukannya, gunakan reateDBInstance tindakan RDS API [C](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) seperti yang ditunjukkan pada contoh berikut. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=sample-replica-cluster &DBInstanceClass=db.r5.large &DBInstanceIdentifier=sample-replica-instance &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T003808Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb ``` Ketika instans DB dibuat dan tersedia, replikasi akan dimulai. Anda dapat menentukan apakah instans DB tersedia dengan memanggil escribeDBInstances perintah AWS CLI [D](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html). ## Melihat Amazon Aurora Replika Lintas wilayah Saya SQL [Anda dapat melihat hubungan replikasi lintas wilayah untuk klaster Amazon Aurora SQL My DB Anda dengan memanggil [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)AWS CLI perintah atau operasi D. escribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) RDS API Dalam respons, lihat bidang `ReadReplicaIdentifiers` untuk menemukan pengidentifikasi klaster DB milik setiap klaster DB replika baca lintas Wilayah. Lihat `ReplicationSourceIdentifier` elemen untuk cluster DB sumber yang merupakan sumber replikasi. ARN # Mempromosikan replika baca ke cluster DB untuk Aurora My SQL Anda dapat mempromosikan replika SQL baca Aurora My ke cluster DB mandiri. Saat Anda mempromosikan replika SQL baca Aurora My, instance DB-nya di-boot ulang sebelum tersedia. Biasanya, Anda mempromosikan replika SQL baca Aurora My ke cluster DB mandiri sebagai skema pemulihan data jika cluster DB sumber gagal. Untuk melakukannya, pertama-tama buat replika baca lalu pantau klaster DB sumber untuk mengetahui kegagalan. Jika terjadi kegagalan, lakukan hal berikut: 1. Promosikan replika baca. 1. Arahkan lalu lintas basis data ke klaster DB yang dipromosikan. 1. Buat replika baca pengganti dengan klaster DB yang dipromosikan sebagai sumbernya. Saat Anda mempromosikan replika baca, replika baca tersebut menjadi klaster DB Aurora mandiri. Proses promosi dapat memakan waktu beberapa menit atau lebih lama, tergantung dari ukuran replika baca. Setelah Anda mempromosikan replika baca menjadi klaster DB baru, replika tersebut akan sama seperti klaster DB lainnya. Misalnya, Anda dapat membuat replika baca darinya dan melakukan operasi point-in-time pemulihan. Anda juga dapat membuat Replika Aurora untuk klaster DB. Karena klaster DB yang dipromosikan bukan lagi merupakan replika baca, Anda tidak dapat menggunakannya sebagai target replikasi. Langkah-langkah berikut menunjukkan proses umum untuk mempromosikan replika baca menjadi klaster DB: 1. Hentikan penulisan transaksi apa pun ke klaster DB sumber replika baca, lalu tunggu semua pembaruan yang akan dilakukan ke replika baca. Pembaruan basis data terjadi pada replika baca setelah pembaruan terjadi pada klaster DB sumber, dan lag replikasi ini dapat bervariasi secara signifikan. Gunakan metrik `ReplicaLag` untuk menentukan saat semua pembaruan sudah dilakukan pada replika baca. Metrik `ReplicaLag` mencatat jumlah waktu lag instans DB replika di belakang instans DB sumber. Saat metrik `ReplicaLag` mencapai `0`, replika baca telah menyamai instans DB sumber. 1. Promosikan replika baca dengan menggunakan opsi **Promosikan** di RDS konsol Amazon, AWS CLI perintah [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html), atau operasi [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html)Amazon RDSAPI. Anda memilih instans Aurora My SQL DB untuk mempromosikan replika baca. Setelah replika baca dipromosikan, cluster Aurora SQL My DB dipromosikan ke cluster DB mandiri. Instans DB dengan prioritas failover tertinggi akan dipromosikan menjadi instans DB primer untuk klaster DB. Instans DB lainnya menjadi Replika Aurora. **catatan** Proses promosi memakan waktu beberapa menit. Saat Anda mempromosikan replika baca, replikasi dihentikan dan instans DB di-boot ulang. Saat boot ulang selesai, replika baca tersedia sebagai klaster DB baru. ## Konsol **Untuk mempromosikan replika SQL baca Aurora My ke cluster DB** 1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Pada konsol, pilih **Instans**. Panel **Instans** akan muncul. 1. Dalam panel **Instans**, pilih replika baca yang ingin Anda promosikan. Replika baca muncul sebagai instance Aurora SQL My DB. 1. Untuk **Tindakan**, pilih **Promosikan replika baca**. 1. Pada halaman konfirmasi, pilih **Promosikan replika baca**. ## AWS CLI Untuk mempromosikan replika baca ke cluster DB, gunakan perintah AWS CLI [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html). **Example** Untuk Linux, macOS, atau Unix: ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier mydbcluster ``` Untuk Windows: ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier mydbcluster ``` ## RDS API Untuk mempromosikan replika baca ke cluster DB, hubungi [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html). # Memecahkan masalah Replika lintas wilayah untuk Amazon Aurora My SQL Di bagian berikut ini, Anda dapat menemukan daftar pesan kesalahan umum yang mungkin Anda temukan saat membuat replika baca lintas Wilayah Amazon Aurora, dan cara menyelesaikan kesalahan yang ditentukan. ## Cluster sumber [DB clusterARN] tidak mengaktifkan binlog Untuk mengatasi masalah ini, aktifkan pencatatan log biner pada klaster DB sumber. Untuk informasi selengkapnya, lihat [Sebelum Anda memulai](AuroraMySQL.Replication.CrossRegion.md#AuroraMySQL.Replication.CrossRegion.Prerequisites). ## Cluster sumber [DB clusterARN] tidak memiliki grup parameter cluster yang disinkronkan pada penulis Anda akan menerima kesalahan ini jika Anda telah memperbarui parameter klaster DB `binlog_format`, tetapi belum mem-boot ulang instans primer untuk klaster DB. Boot ulang instans primer (yaitu penulis) untuk klaster DB lalu coba lagi. ## Cluster sumber [DB clusterARN] sudah memiliki replika baca di wilayah ini Anda dapat memiliki hingga lima klaster DB lintas Wilayah yang berupa replika baca untuk setiap klaster DB sumber di Wilayah AWS mana pun. Jika Anda sudah memiliki jumlah maksimum replika baca pada klaster DB di Wilayah AWS tertentu, Anda harus menghapus yang sudah ada sebelum Anda dapat membuat klaster DB lintas Wilayah baru di Wilayah tersebut. ## Cluster DB [DB clusterARN] memerlukan upgrade mesin database untuk dukungan replikasi lintas wilayah Untuk mengatasi masalah ini, tingkatkan versi mesin basis data pada semua instans dalam klaster DB sumber ke versi mesin basis data terbaru, lalu coba buat lagi DB replika baca lintas Wilayah. # 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 STATUS`Aurora MySQL versi 3) tidak menghasilkan output, periksa apakah klaster yang Anda gunakan mendukung replikasi binlog. 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 dalam VPC yang diakses oleh instans EC2 dalam VPC yang sama](USER_VPC.Scenarios.md#USER_VPC.Scenario3). 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 kluster DB MySQL Amazon Aurora Wilayah AWS](AuroraMySQL.Replication.CrossRegion.md). Dengan Aurora MySQL versi 2 dan 3, Anda dapat mereplikasi antara Aurora MySQL dan sumber eksternal atau target yang menggunakan pengidentifikasi transaksi global () untuk replikasi. GTIDs 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 GTID berbasis](mysql-replication-gtid.md). Di Aurora MySQL versi 3.01 dan yang lebih tinggi, Anda dapat memilih cara menetapkan GTIDs transaksi yang direplikasi dari sumber yang tidak digunakan. GTIDs Untuk informasi tentang prosedur tersimpan yang mengontrol pengaturan tersebut, lihat [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versi 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). **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 . 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. # Menggunakan replikasi GTID berbasis Konten berikut menjelaskan cara menggunakan pengidentifikasi transaksi global (GTIDs) dengan replikasi log biner (binlog) di antara DB. antara SQL cluster Aurora My dan sumber eksternal. **catatan** Untuk Aurora, Anda dapat menggunakan fitur ini hanya dengan Aurora My SQL cluster yang menggunakan replikasi binlog ke atau dari database Saya eksternal. SQL Basis data lainnya mungkin berupa SQL instans Amazon RDS My, SQL database Saya lokal, atau klaster Aurora DB di tempat lain. Wilayah AWS Untuk mempelajari cara mengonfigurasi jenis replikasi semacam itu, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). Jika Anda menggunakan replikasi binlog dan tidak terbiasa dengan replikasi GTID berbasis dengan MySQL, lihat [Replikasi dengan pengidentifikasi transaksi global](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) di dokumentasi Saya. SQL GTIDreplikasi berbasis didukung untuk Aurora SQL My versi 2 dan 3. **Topics** + [Ikhtisar pengidentifikasi transaksi global () GTIDs](#mysql-replication-gtid.overview) + [Parameter untuk replikasi GTID berbasis](#mysql-replication-gtid.parameters) + [Mengaktifkan replikasi GTID berbasis untuk cluster Aurora My SQL](mysql-replication-gtid.configuring-aurora.md) + [Menonaktifkan replikasi berbasis GTID untuk klaster DB Aurora MySQL](mysql-replication-gtid.disabling.md) ## Ikhtisar pengidentifikasi transaksi global () GTIDs *Pengidentifikasi transaksi global (GTIDs)* adalah pengidentifikasi unik yang dihasilkan untuk transaksi Saya SQL yang berkomitmen. Anda dapat menggunakan GTIDs untuk membuat replikasi binlog lebih sederhana dan lebih mudah untuk memecahkan masalah. **catatan** Saat Aurora menyinkronkan data antar-instans DB dalam sebuah klaster, mekanisme replikasi tersebut tidak melibatkan log biner (binlog). Untuk Aurora MySQL, replikasi GTID berbasis hanya berlaku ketika Anda juga menggunakan replikasi binlog untuk mereplikasi ke dalam atau keluar dari cluster Aurora My SQL DB dari database eksternal yang kompatibel dengan Saya. SQL Saya SQL menggunakan dua jenis transaksi yang berbeda untuk replikasi binlog: + *GTIDTransaksi* — Transaksi yang diidentifikasi oleh aGTID. + *Transaksi anonim* — Transaksi yang tidak GTID ditetapkan. Dalam konfigurasi replikasi, GTIDs unik di semua instans DB. GTIDsmenyederhanakan konfigurasi replikasi karena ketika Anda menggunakannya, Anda tidak perlu merujuk ke posisi file log. GTIDsjuga memudahkan untuk melacak transaksi yang direplikasi dan menentukan apakah instance sumber dan replika konsisten. Anda biasanya menggunakan replikasi GTID berbasis dengan Aurora saat mereplikasi dari database eksternal yang kompatibel dengan SQL Saya ke dalam cluster Aurora. Anda dapat mengatur konfigurasi replikasi ini sebagai bagian dari migrasi dari RDS database lokal atau Amazon ke Aurora Milikku. SQL Jika database eksternal sudah menggunakanGTIDs, mengaktifkan replikasi GTID berbasis untuk cluster Aurora menyederhanakan proses replikasi. Anda mengonfigurasi replikasi GTID berbasis untuk klaster Aurora SQL My dengan terlebih dahulu menyetel parameter konfigurasi yang relevan dalam grup parameter cluster DB. Kemudian, hubungkan grup parameter tersebut dengan klaster. ## Parameter untuk replikasi GTID berbasis Gunakan parameter berikut untuk mengkonfigurasi replikasi GTID berbasis. | Parameter | Nilai valid | Deskripsi | | --- | --- | --- | | `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` menetapkan bahwa transaksi baru adalah transaksi anonim (yaitu, tidak memiliki GTIDs), dan transaksi harus anonim agar dapat direplikasi. `OFF_PERMISSIVE` menentukan bahwa transaksi baru adalah transaksi anonim, tetapi semua transaksi dapat direplikasi. `ON_PERMISSIVE`menetapkan bahwa transaksi baru adalah GTID transaksi, tetapi semua transaksi dapat direplikasi. `ON`menetapkan bahwa transaksi baru adalah GTID transaksi, dan transaksi harus berupa GTID transaksi yang akan direplikasi. | | `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF`memungkinkan transaksi melanggar GTID konsistensi. `ON`mencegah transaksi melanggar GTID konsistensi. `WARN`memungkinkan transaksi melanggar GTID konsistensi tetapi menghasilkan peringatan ketika pelanggaran terjadi. | **catatan** Dalam Konsol Manajemen AWS, `gtid_mode` parameter muncul sebagai`gtid-mode`. Untuk replikasi GTID berbasis, gunakan pengaturan ini untuk grup parameter cluster DB untuk cluster Aurora SQL My DB Anda: + `ON`dan hanya `ON_PERMISSIVE` berlaku untuk replikasi keluar dari cluster Aurora My. SQL Kedua nilai ini menyebabkan cluster Aurora DB Anda digunakan GTIDs untuk transaksi yang direplikasi ke database eksternal. `ON`mengharuskan database eksternal juga menggunakan replikasi GTID berbasis. `ON_PERMISSIVE`membuat replikasi GTID berbasis opsional pada database eksternal. + `OFF_PERMISSIVE`, jika diatur, artinya klaster DB Aurora Anda dapat menerima replikasi masuk dari basis data eksternal. Hal ini dapat dilakukan apakah database eksternal menggunakan replikasi GTID berbasis atau tidak. + `OFF`, jika disetel, berarti klaster Aurora DB Anda hanya menerima replikasi masuk dari database eksternal yang tidak menggunakan replikasi berbasis. GTID **Tip** Replikasi masuk adalah skenario replikasi binlog yang paling umum untuk klaster Aurora My. SQL Untuk replikasi yang masuk, kami sarankan Anda mengatur GTID mode ke. `OFF_PERMISSIVE` Pengaturan itu memungkinkan replikasi masuk dari database eksternal terlepas dari GTID pengaturan di sumber replikasi. Untuk informasi selengkapnya tentang grup parameter, lihat [](USER_WorkingWithParamGroups.md). # Mengaktifkan replikasi GTID berbasis untuk cluster Aurora My SQL Ketika replikasi GTID berbasis diaktifkan untuk cluster Aurora SQL My DB, GTID pengaturan berlaku untuk replikasi binlog masuk dan keluar. **Untuk mengaktifkan replikasi GTID berbasis untuk cluster Aurora My SQL** 1. Buat atau edit grup parameter klaster DB menggunakan pengaturan parameter berikut: + `gtid_mode` – `ON` atau `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Kaitkan grup parameter cluster DB dengan cluster Aurora MySQL. Untuk melakukannya, ikuti prosedur dalam [](USER_WorkingWithParamGroups.md). 1. (Opsional) Tentukan cara menetapkan GTIDs ke transaksi yang tidak menyertakannya. Untuk melakukannya, panggil prosedur yang tersimpan di [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versi 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). # Menonaktifkan replikasi berbasis GTID untuk klaster DB Aurora MySQL Anda dapat menonaktifkan replikasi berbasis GTID untuk klaster DB Aurora MySQL. Dengan begitu, artinya klaster Aurora tidak dapat melakukan replikasi binlog ke dalam atau keluar dengan basis data eksternal yang menggunakan replikasi berbasis GTID. **catatan** Dalam prosedur berikut, *replika baca* berarti target replikasi dalam konfigurasi Aurora dengan replikasi binlog ke atau dari basis data eksternal. Jadi, itu bukan instans DB Aurora Replica hanya-baca. Misalnya, saat sebuah klaster Aurora menerima replikasi masuk dari sebuah sumber eksternal, instans primer Aurora bertindak sebagai replika baca untuk replikasi binlog. Untuk detail selengkapnya tentang prosedur tersimpan yang disebutkan di bagian ini, lihat [Aurora Referensi prosedur SQL tersimpan saya](AuroraMySQL.Reference.StoredProcs.md). **Menonaktifkan replikasi berbasis GTID untuk klaster DB Aurora MySQL** 1. Pada replika Aurora, jalankan prosedur berikut: Untuk versi 3 ``` CALL mysql.rds_set_source_auto_position(0); ``` Untuk versi 2 ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Atur ulang `gtid_mode` ke `ON_PERMISSIVE`. 1. Pastikan grup parameter klaster DB yang terkait dengan klaster Aurora MySQL memiliki `gtid_mode` yang diatur ke `ON_PERMISSIVE`. Untuk informasi selengkapnya tentang cara mengatur parameter konfigurasi menggunakan grup parameter, lihat [](USER_WorkingWithParamGroups.md). 1. Mulai ulang klaster DB Aurora MySQL. 1. Atur ulang `gtid_mode` ke `OFF_PERMISSIVE`. 1. Pastikan grup parameter klaster DB yang terkait dengan klaster Aurora MySQL memiliki `gtid_mode` yang diatur ke `OFF_PERMISSIVE`. 1. Mulai ulang klaster DB Aurora MySQL. 1. Tunggu hingga semua transaksi GTID diterapkan pada instans primer Aurora. Untuk memeriksa apakah ini diterapkan, lakukan langkah-langkah berikut: 1. Pada instans primer Aurora, jalankan perintah `SHOW MASTER STATUS`. Output Anda harus mirip dengan output berikut. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` Perhatikan file dan posisi dalam output Anda. 1. Pada setiap replika baca, gunakan file dan informasi posisi dari contoh sumbernya pada langkah sebelumnya untuk menjalankan kueri berikut: Untuk versi 3 ``` SELECT SOURCE_POS_WAIT('file', position); ``` Untuk versi 2 ``` SELECT MASTER_POS_WAIT('file', position); ``` Misalnya, jika nama file `mysql-bin-changelog.000031` dan posisinya`107`, jalankan pernyataan berikut: Untuk versi 3 ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Untuk versi 2 ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` 1. Setel ulang parameter GTID untuk menonaktifkan replikasi berbasis GTID. 1. Pastikan grup parameter klaster DB yang terkait dengan klaster Aurora MySQL memiliki pengaturan parameter berikut ini: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Mulai ulang klaster DB Aurora MySQL.