Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Menyiapkan replikasi log biner untuk Aurora My SQL
Menyiapkan SQL Replikasi Saya dengan Aurora SQL My melibatkan langkah-langkah berikut, yang dibahas secara rinci:
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 Saya SQL |
Untuk mengaktifkan logging biner pada cluster Aurora My DB SQL Atur parameter klaster DB Untuk mengubah parameter Jika Anda mengubah parameter Untuk informasi selengkapnya, silakan lihat Parameter klaster DB dan instans DB Amazon Aurora dan . |
RDSuntuk saya SQL |
Untuk mengaktifkan logging biner pada instans Amazon RDS DB Anda tidak dapat mengaktifkan pencatatan biner secara langsung untuk instans Amazon RDS DB, tetapi Anda dapat mengaktifkannya dengan melakukan salah satu hal berikut:
|
Saya SQL (eksternal) |
Untuk mengatur replikasi terenkripsi Untuk mereplikasi data dengan aman dengan Aurora My SQL versi 2, Anda dapat menggunakan replikasi terenkripsi. catatanJika Anda tidak perlu menggunakan replikasi terenkripsi, Anda dapat melewati langkah-langkah ini. Berikut ini adalah prasyarat untuk menggunakan replikasi terenkripsi:
Selama replikasi terenkripsi, cluster Aurora My SQL DB bertindak sebagai klien ke server database Saya. SQL Sertifikat dan kunci untuk Aurora SQL Klien saya ada dalam file dalam format.pem.
Untuk mengaktifkan logging biner pada SQL database saya eksternal
|
2. Pertahankan log biner pada sumber replikasi hingga tidak diperlukan lagi
Saat Anda menggunakan replikasi log SQL biner saya, Amazon RDS tidak 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 Saya SQL |
Untuk menyimpan log biner pada cluster Aurora My DB SQL Anda tidak memiliki akses ke file binlog untuk cluster Aurora SQL My DB. Akibatnya, Anda harus memilih kerangka waktu untuk menyimpan file binlog pada sumber replikasi Anda cukup lama untuk memastikan bahwa perubahan telah diterapkan ke replika Anda sebelum file binlog dihapus oleh Amazon. RDS Anda dapat menyimpan file binlog di cluster Aurora SQL My DB hingga 90 hari. Jika Anda menyiapkan replikasi dengan SQL database Saya atau RDS untuk instance My SQL DB sebagai replika, dan database tempat Anda membuat replika sangat besar, pilih kerangka waktu yang besar untuk menyimpan file binlog hingga salinan awal database ke replika selesai dan lag replika telah mencapai 0. Untuk mengatur rentang waktu retensi log biner, gunakan prosedur mysql.rds_set_configuration dan tentukan parameter konfigurasi Contoh berikut menetapkan periode retensi untuk file binlog menjadi 6 hari:
Setelah replikasi dimulai, Anda dapat memverifikasi bahwa perubahan telah diterapkan ke replika Anda dengan menjalankan perintah ( Jika pengaturan ini tidak ditentukan, default untuk Aurora My SQL adalah 24 (1 hari). Jika Anda menentukan nilai untuk |
RDSuntuk saya SQL |
Untuk mempertahankan log biner pada instans Amazon RDS DB Anda dapat menyimpan file log biner pada instans Amazon RDS DB dengan menyetel jam retensi binlog seperti halnya dengan cluster Aurora SQL My DB, yang dijelaskan di baris sebelumnya. Anda juga dapat menyimpan file binlog pada instans Amazon RDS DB dengan membuat replika baca untuk instans DB. Replika baca ini bersifat sementara dan hanya untuk mempertahankan file binlog. Setelah replika baca dibuat, panggil prosedur mysql.rds_stop_replication pada replika baca. Saat replikasi dihentikan, Amazon RDS tidak menghapus file binlog apa pun di sumber replikasi. Setelah Anda mengatur replikasi dengan replika permanen, Anda dapat menghapus replika baca saat lag replika (bidang |
Saya SQL (eksternal) |
Untuk mempertahankan log biner pada SQL database saya eksternal Karena file binlog di SQL database Saya eksternal tidak dikelola oleh AmazonRDS, file tersebut disimpan hingga Anda menghapusnya. Setelah replikasi dimulai, Anda dapat memverifikasi bahwa perubahan telah diterapkan ke replika Anda dengan menjalankan perintah ( |
3. Buat salinan atau dump sumber replikasi Anda
Anda menggunakan snapshot, klon, atau dump sumber replikasi Anda untuk memuat salinan dasar data Anda ke replika Anda. Kemudian Anda mulai mereplikasi dari titik itu.
Gunakan petunjuk berikut untuk membuat salinan atau dump sumber replikasi untuk mesin database Anda.
Mesin basis data | Petunjuk |
---|---|
Aurora Saya SQL |
Untuk membuat salinan cluster Aurora My DB SQL Pilih salah satu metode berikut:
Untuk menentukan nama dan posisi file binlog Pilih salah satu metode berikut:
Untuk membuat dump cluster Aurora SQL My DB Jika target replika Anda adalah SQL database Saya eksternal atau RDS untuk instance My SQL DB, maka Anda harus membuat file dump dari cluster Aurora DB Anda. Pastikan untuk menjalankan
|
RDSuntuk saya SQL |
Untuk membuat snapshot dari instans Amazon RDS DB Buat replika baca instans Amazon RDS DB Anda. Untuk informasi selengkapnya, lihat Membuat replika baca dalam Panduan Pengguna Amazon Relational Database Service.
|
Saya SQL (eksternal) |
Untuk membuat dump database eksternal Saya SQL
|
4. Muat dump ke target replika Anda (jika diperlukan)
Jika Anda berencana untuk memuat data dari dump SQL database Saya yang berada di luar AmazonRDS, Anda mungkin ingin membuat EC2 instance untuk menyalin file dump ke. Kemudian Anda dapat memuat data ke cluster DB atau instance DB Anda dari EC2 instance itu. Dengan menggunakan pendekatan ini, Anda dapat mengompres file dump sebelum menyalinnya ke EC2 instance untuk mengurangi biaya jaringan yang terkait dengan menyalin 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 My SQL DB baru sebagai target replika Anda, maka Anda tidak perlu memuat file dump:
-
Anda dapat memulihkan dari snapshot cluster DB untuk membuat cluster DB baru. Untuk informasi selengkapnya, lihat Memulihkan dari snapshot klaster DB.
-
Anda dapat mengkloning cluster DB sumber Anda untuk membuat cluster DB baru. Untuk informasi selengkapnya, lihat Mengkloning volume untuk klaster DB Amazon Aurora.
-
Anda dapat memigrasikan data dari snapshot instans DB ke cluster DB baru. Untuk informasi selengkapnya, lihat Migrasi data ke cluster Amazon Aurora My DB SQL.
Gunakan instruksi berikut untuk memuat dump sumber replikasi Anda ke target replika Anda untuk mesin database Anda.
Mesin basis data | Petunjuk |
---|---|
Aurora Saya SQL |
Untuk memuat dump ke cluster Aurora SQL My DB
|
RDSuntuk saya SQL |
Untuk memuat dump ke instans Amazon RDS DB
|
Saya SQL (eksternal) |
Untuk memuat dump ke database saya SQL eksternal Anda tidak dapat memuat snapshot DB atau snapshot cluster DB ke database Saya SQL eksternal. Sebagai gantinya, Anda harus menggunakan output dari perintah
|
5. Buat pengguna replikasi pada sumber replikasi Anda
Buat ID pengguna pada sumber yang digunakan hanya untuk replikasi. Contoh berikut adalah RDS untuk database My SQL atau eksternal My SQL source.
mysql>
CREATE USER 'repl_user
'@'domain_name
' IDENTIFIED BY 'password
';
Untuk database Aurora My SQL source, parameter cluster skip_name_resolve
DB diatur ke 1
(ON
) dan tidak dapat dimodifikasi, jadi Anda harus menggunakan alamat IP untuk host alih-alih nama domain. Untuk informasi selengkapnya, lihat skip_name_resolve
mysql>
CREATE USER 'repl_user
'@'IP_address
' IDENTIFIED BY 'password
';
Pengguna memerlukan hak akses REPLICATION CLIENT
dan REPLICATION SLAVE
. Berikan hak akses ini kepada pengguna.
Jika Anda perlu menggunakan replikasi terenkripsi, memerlukan SSL koneksi untuk pengguna replikasi. Misalnya, Anda dapat menggunakan salah satu pernyataan berikut untuk meminta SSL koneksi pada akun penggunarepl_user
.
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 sarankan Anda mengambil snapshot manual dari cluster Aurora My SQL DB atau RDS untuk target replika instans My SQL DB. 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 Saya SQL |
Untuk mengaktifkan replikasi dari cluster Aurora SQL My DB
Untuk menggunakan SSL enkripsi, tetapkan nilai akhir menjadi |
RDSuntuk saya SQL |
Untuk mengaktifkan replikasi dari instans Amazon RDS DB
Untuk menggunakan SSL enkripsi, tetapkan nilai akhir menjadi |
Saya SQL (eksternal) |
Untuk mengaktifkan replikasi dari database Saya SQL eksternal
|
Jika replikasi gagal, hal tersebut dapat mengakibatkan peningkatan besar I/O yang tidak disengaja pada replika, yang dapat menurunkan performa. Jika replikasi gagal atau tidak lagi diperlukan, Anda dapat menjalankan prosedur tersimpan mysql.rds_reset_external_master ) RDS SQL SQL atau mysql.rds_reset_external_source ) SQL SQL untuk menghapus konfigurasi replikasi.
Mengatur lokasi untuk menghentikan replikasi ke replika baca
Di Aurora My SQL versi 3.04 dan yang lebih tinggi, Anda dapat memulai replikasi dan kemudian menghentikannya di lokasi file log biner tertentu menggunakan prosedur yang disimpan. mysql.rds_start_replication_until (Aurora Versi saya 3) SQL
Untuk memulai replikasi ke replika baca dan menghentikan replikasi di lokasi tertentu
-
Menggunakan SQL klien Saya, sambungkan ke replika Aurora SQL My DB cluster sebagai pengguna utama.
-
Jalankan prosedur yang tersimpan di mysql.rds_start_replication_until (Aurora Versi saya 3) SQL.
Contoh berikut memulai replikasi dan mereplikasi perubahan hingga mencapai lokasi
120
di file binermysql-bin-changelog.000777
. Dalam skenario pemulihan bencana, asumsikan bahwa lokasi120
tepat sebelum bencana.call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120);
Replikasi berhenti secara otomatis ketika stop point tercapai. RDSPeristiwa berikut dihasilkan:Replication has been stopped since the replica reached the stop point specified by the
rds_start_replication_until stored procedure
.
Jika Anda menggunakan replikasi GTID berbasis, gunakan prosedur yang mysql.rds_start_replication_until_gtid (Aurora Versi saya 3) SQL disimpan alih-alih prosedur yang mysql.rds_start_replication_until (Aurora Versi saya 3) SQL disimpan. Untuk informasi lebih lanjut tentang replikasi GTID berbasis, lihatMenggunakan replikasi GTID berbasis.
7. Pantau replika Anda
Saat Anda mengatur SQL replikasi Saya dengan cluster Aurora SQL My DB, Anda harus memantau peristiwa failover untuk cluster Aurora SQL My DB ketika itu adalah target replika. Jika terjadi failover, maka klaster DB yang merupakan target replika Anda dapat dibuat ulang pada host baru dengan alamat jaringan yang berbeda. Untuk informasi tentang cara memantau peristiwa failover, lihat Bekerja dengan pemberitahuan RDS acara Amazon.
Anda juga dapat memantau seberapa jauh target replika berada di belakang sumber replikasi dengan menghubungkan ke target replika dan menjalankan perintah (SHOW SLAVE STATUS
Aurora My version 2) atau (SHOW REPLICA STATUS
Aurora My SQL version 3). SQL 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 SQL pernyataan, perubahan tersebut direplikasi ke target replikasi secara otomatis.
Jika Anda menggunakan AWS Management Console, the AWS CLI, atau RDS API untuk mengubah kata sandi utama pada sumber replikasi, perubahan tersebut tidak secara otomatis direplikasi ke target replikasi. Jika Anda ingin menyinkronkan pengguna master dan kata sandi master antara sistem sumber dan target, Anda harus membuat sendiri perubahan yang sama pada target replikasi.