Kasus penggunaan untuk replikasi multi-sumber Prasyarat untuk replikasi multi-sumber Konfigurasikan saluran replikasi multi-sumber pada cluster Aurora MySQL DB Gunakan filter dengan replikasi multi-sumber Memantau saluran replikasi multi-sumber Kelola prosedur penyimpanan replikasi multi-sumber Pertimbangan dan praktik terbaik Batasan Pemecahan masalah Contoh: Penyiapan multi-sumber lengkap dengan tiga sumber Sumber daya terkait

Konfigurasikan replikasi multi-sumber untuk Amazon Aurora MySQL

Dengan replikasi multi-sumber, Anda dapat mengatur cluster DB Amazon Aurora MySQL sebagai replika yang menerima peristiwa log biner dari lebih dari satu database MySQL sumber. Setiap sumber dapat berupa RDS untuk instance MySQL DB, cluster Aurora MySQL DB lainnya, atau database MySQL yang berjalan di luar Amazon RDS.

Multi-source replikasi didukung untuk cluster Aurora MySQL DB yang menjalankan versi mesin berikut:

Aurora MySQL 8.4.8 dan yang lebih tinggi

Untuk informasi selengkapnya tentang replikasi multi-sumber MySQL, lihat Multi-Source Replikasi MySQL dalam dokumentasi MySQL.

catatan

Multi-source replikasi pada Aurora MySQL menggunakan instance writer (primer) dari cluster Aurora DB sebagai target replikasi. Semua prosedur yang disimpan replikasi harus dipanggil saat terhubung ke instance penulis cluster.

Kasus penggunaan untuk replikasi multi-sumber

Pertimbangkan untuk menggunakan replikasi multi-sumber pada Aurora MySQL dalam kasus berikut:

Konsolidasi Shard — Aplikasi yang perlu menggabungkan atau menggabungkan data dari beberapa pecahan yang dihosting pada instans DB terpisah ke dalam satu cluster Aurora MySQL DB.
Pelaporan konsolidasi — Aplikasi yang perlu menghasilkan laporan dari data yang dikonsolidasikan dari berbagai sumber, memanfaatkan kemampuan penskalaan baca Aurora.
Long-term backup — Persyaratan untuk membuat cadangan data jangka panjang terkonsolidasi yang didistribusikan di antara beberapa inst MySQL-compatible ans DB.
Cross-engine Migrasi — Mengkonsolidasikan data dari beberapa RDS untuk instans MySQL atau server MySQL eksternal ke dalam satu cluster Aurora MySQL selama migrasi.
Multi-tenant agregasi — Mengkonsolidasikan beberapa database penyewa tunggal ke dalam cluster Aurora multi-penyewa untuk optimalisasi biaya dan manajemen yang disederhanakan.

Prasyarat untuk replikasi multi-sumber

Sebelum Anda mengonfigurasi replikasi multi-sumber pada cluster Aurora MySQL DB Anda, lengkapi prasyarat standar untuk replikasi log biner seperti yang dijelaskan dalamMenyiapkan replikasi log biner untuk Aurora MySQL. Ini termasuk mengaktifkan logging biner pada setiap sumber, mempertahankan log biner, membuat pengguna replikasi, dan membuat salinan atau dump dari setiap sumber. Untuk replikasi multi-sumber, ulangi langkah-langkah ini untuk setiap instance DB sumber.

Selain prasyarat standar, pastikan Anda memenuhi persyaratan berikut khusus untuk replikasi multi-sumber.

Verifikasi versi dan konfigurasi cluster target Aurora MySQL
- Cluster Aurora MySQL DB harus menjalankan versi engine yang didukung (Aurora MySQL 8.4.8 dan lebih tinggi).
- Aktifkan komit otomatis pada instance penulis Aurora MySQL. Atur autocommit parameter ke 1 dalam grup parameter cluster DB Anda.
Konfigurasikan konektivitas jaringan untuk setiap sumber

Untuk setiap instance sumber DB, pastikan bahwa instance penulis Aurora MySQL dapat terhubung ke sumber pada port yang ditentukan. Opsinya meliputi:
- Jika sumber dan target berada di VPC yang sama, konfigurasikan grup keamanan pada instance DB sumber untuk mengizinkan koneksi masuk pada port 3306 (atau port kustom Anda) dari grup keamanan cluster Aurora MySQL.
- Jika mereka berada di VPC yang berbeda, atur peering VPC atau gunakan gateway transit. Untuk informasi selengkapnya, lihat SEBUAH DB klaster dalam VPC yang diakses oleh instans EC2 di VPC yang berbeda.
- Jika sumbernya eksternal AWS, pastikan rute jaringan tersedia (misalnya, melalui atau koneksi VPN).

catatan

Karena replikasi multi-sumber melibatkan beberapa sumber, Anda harus memverifikasi konektivitas ke setiap sumber secara independen. Pastikan grup keamanan dan routing mengakomodasi semua titik akhir sumber secara bersamaan.

Konfigurasikan saluran replikasi multi-sumber pada cluster Aurora MySQL DB

Mengkonfigurasi saluran replikasi multi-sumber pada Aurora MySQL mirip dengan mengkonfigurasi replikasi sumber tunggal. Untuk replikasi multi-sumber, pertama-tama Anda mengaktifkan logging biner pada instance sumber, mengimpor data dari sumber ke cluster Aurora MySQL, dan kemudian memulai replikasi dari setiap sumber menggunakan koordinat log biner atau posisi otomatis GTID.

penting

Semua prosedur penyimpanan replikasi multi-sumber harus dipanggil saat terhubung ke instance penulis cluster Aurora MySQL DB. Jika failover terjadi, Anda harus menyambung kembali ke instance penulis baru.

Langkah 1: Impor data dari instance DB sumber ke cluster Aurora MySQL

Lakukan langkah-langkah berikut untuk setiap instance DB sumber.

Tentukan file log biner saat ini dan posisi pada instance DB sumber.

Untuk MySQL 8.4


SHOW BINARY LOG STATUS;

Untuk MySQL 8.0 dan sebelumnya


SHOW MASTER STATUS;

Contoh output:


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

Catat nil Position ai-nilai File dan. Anda membutuhkannya di langkah selanjutnya.

Salin database dari instance DB sumber ke cluster Aurora MySQL menggunakanmysqldump.


mysqldump --databases database_name \
  --single-transaction \
  --compress \
  --order-by-primary \
  -u RDS_user_name \
  -p'RDS_password' \
  --host=source-endpoint.region.rds.amazonaws.com | mysql \
  --host=aurora-cluster-endpoint.cluster-xxxxxx.region.rds.amazonaws.com \
  --port=3306 \
  -u aurora_user_name \
  -p'aurora_password'

Tip

Untuk database besar, pertimbangkan untuk menggunakan AWS DMS atau membuat snapshot dan memulihkan untuk mengurangi waktu transfer data.

Setelah impor data selesai, Anda dapat mengaktifkan kembali penulisan pada instance DB sumber jika sebelumnya Anda telah menyetelnya ke read-only.

Langkah 2: Mulai replikasi dari instance DB sumber ke cluster Aurora MySQL

Untuk setiap instance sumber DB, sambungkan ke instance penulis cluster Aurora MySQL DB dan jalankan prosedur tersimpan untuk mengonfigurasi dan memulai replikasi pada saluran.

Opsi A: Menggunakan posisi file log biner


CALL mysql.rds_set_external_source_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  'mysql-bin-changelog.000031',
  107,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');

Opsi B: Menggunakan posisi otomatis GTID

Jika instans DB sumber Anda menggunakan GTID-based replikasi, Anda dapat menggunakan penentuan posisi otomatis alih-alih menentukan koordinat log biner:


CALL mysql.rds_set_external_source_with_auto_position_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  0,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');

catatan

Saat menggunakan posisi otomatis GTID, pastikan enforce_gtid_consistency parameter gtid_mode dan dikonfigurasi secara konsisten di semua instance sumber dan cluster Aurora MySQL.

Ulangi langkah-langkah ini untuk setiap instance DB sumber, tentukan nama saluran unik untuk masing-masing (misalnya,channel_1,channel_2,channel_3).

Gunakan filter dengan replikasi multi-sumber

Anda dapat menggunakan filter replikasi untuk menentukan database dan tabel mana yang direplikasi ke replika multi-sumber Aurora MySQL. Untuk informasi selengkapnya tentang filter replikasi, lihatMengonfigurasi filter replikasi dengan Aurora MySQL. Berikut ini menjelaskan kemampuan filter tingkat saluran tambahan yang tersedia dengan replikasi multi-sumber.

Dengan replikasi multi-sumber, Anda dapat mengonfigurasi filter replikasi pada dua tingkat:

Filter global — Terapkan ke semua saluran. Atur menggunakan grup parameter cluster Aurora MySQL DB (misalnya,replicate-do-db,replicate-ignore-db).
Channel-level filter — Terapkan hanya ke saluran tertentu, mengesampingkan filter global untuk saluran tersebut.

Perilaku kunci

Anda harus memulai ulang replikasi setelah mengubah filter tingkat saluran.
Jika tidak ada filter khusus saluran yang dikonfigurasi, Aurora MySQL menerapkan filter global untuk saluran tersebut.
Jika filter diterapkan secara global dan pada tingkat saluran, hanya filter tingkat saluran yang diterapkan untuk saluran tersebut.

Memantau saluran replikasi multi-sumber

Anda dapat memantau saluran individual pada replika multi-sumber Aurora MySQL menggunakan metode berikut.

Gunakan STATUS TAMPILKAN REPLIKA

Hubungkan ke instance penulis cluster Aurora MySQL DB dan jalankan:


-- View status for all channels
SHOW REPLICA STATUS\G

-- View status for a specific channel
SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G

Bidang kunci untuk dipantau:

Bidang	Deskripsi
`Replica_IO_Running`	Apakah I/O thread untuk saluran sedang berjalan
`Replica_SQL_Running`	Apakah thread SQL untuk saluran sedang berjalan
`Seconds_Behind_Source`	Jeda replikasi dalam hitungan detik untuk saluran
`Last_IO_Error`	Kes I/O alahan terakhir ditemui di saluran
`Last_SQL_Error`	Kesalahan SQL terakhir ditemui di saluran
`Source_Log_File`	File log biner saat ini sedang dibaca dari sumber
`Exec_Source_Log_Pos`	Posisi dalam log biner yang telah diterapkan oleh utas SQL

Gunakan CloudWatch metrik

Pantau ReplicationChannelLag CloudWatch metrik untuk setiap saluran replikasi. Metrik ini menyediakan data jeda replikasi per saluran dengan periode 60 detik dan tersedia selama 15 hari. Untuk menemukan jeda saluran replikasi, gunakan pengidentifikasi instans cluster Aurora DB dan nama saluran replikasi sebagai dimensi. Anda dapat mengonfigurasi CloudWatch alarm untuk menerima pemberitahuan ketika lag melebihi ambang batas tertentu. Untuk informasi selengkapnya, lihat Memantau metrik di klaster Amazon Aurora.

Kelola prosedur penyimpanan replikasi multi-sumber

Untuk informasi tentang menggunakan prosedur tersimpan untuk mengatur dan mengelola saluran replikasi multi-sumber Anda, lihatMengelola replikasi multi-sumber.

Pertimbangan dan praktik terbaik

Untuk rekomendasi pengoptimalan replikasi umum termasuk format log biner, pekerja paralel, dan Binlog yang Ditingkatkan, lihatMengoptimalkan replikasi log biner untuk Aurora MySQL. Pertimbangan berikut khusus untuk replikasi multi-sumber.

Perencanaan sumber daya

Saat menjalankan beberapa saluran replikasi, jumlah total utas replikasi yang dialokasikan pada replika adalah: (replica_parallel_workers+ 1 utas koordinator) × jumlah saluran. Misalnya, dengan replica_parallel_workers nilai default 4 dan 10 saluran, Aurora MySQL mengalokasikan 50 utas replikasi. Pertimbangkan untuk menggunakan kelas instance DB yang lebih besar (seperti db.r6g.2xlarge atau lebih besar) berdasarkan throughput sumber total dan jumlah saluran Anda. Setiap saluran menerima jumlah pekerja paralel yang sama. MySQL tidak mendukung pengaturan jumlah pekerja paralel yang berbeda per saluran.

Menghindari konflik

Replikasi multi-sumber MySQL tidak menyediakan deteksi atau resolusi konflik. Anda harus memastikan bahwa perubahan dari sumber yang berbeda tidak bertentangan. Strategi umum meliputi:

Setiap sumber menulis ke database atau set tabel yang berbeda.
Gunakan filter replikasi (replicate-do-db) untuk memastikan setiap saluran hanya mereplikasi database yang menjadi tanggung jawabnya.
Gunakan replicate-rewrite-db opsi untuk memetakan ulang nama skema dari sumber ke nama yang berbeda pada replika, jika diperlukan.

Untuk mencegah penulisan yang saling bertentangan dari aplikasi yang terhubung langsung ke replika multi-sumber, aktifkan mode baca-saja pada cluster Aurora MySQL: CALL mysql.rds_set_read_only(1);

Praktik terbaik operasional

Satu saluran pada satu waktu — Lakukan operasi manajemen (seperti perubahan konfigurasi, melewatkan kesalahan, atau starting/stopping replikasi) pada satu saluran pada satu waktu. Hindari perubahan bersamaan ke beberapa saluran dari koneksi yang berbeda.
Monitor jeda per saluran — Pantau jeda replikasi untuk setiap saluran menggunakan ReplicationChannelLag CloudWatch metrik.
Penanganan failover sumber — Jika instans DB sumber gagal over (misalnya, Multi-AZ failover Amazon RDS), saluran replikasi mungkin berhenti dengan kesalahan. I/O Setelah sumber tersedia lagi:
- Panggil mysql.rds_start_replication_for_channel untuk melanjutkan replikasi.
- Jika kesalahan 1236 terjadi (file log tidak ditemukan), panggil mysql.rds_next_source_log_for_channel untuk maju ke file log biner berikutnya.
Failover penulis Aurora - Jika instance penulis Aurora MySQL gagal dialihkan ke pembaca, konfigurasi saluran replikasi dipertahankan pada penyimpanan bersama cluster. Setelah failover selesai, thread replikasi akan dimulai ulang secara otomatis pada instance penulis baru.

Batasan

Batasan berikut khusus untuk replikasi multi-sumber Aurora MySQL. Untuk batasan replikasi multi-sumber MySQL umum (seperti konfigurasi pekerja paralel per saluran), lihat Multi-Source Replikasi MySQL dalam dokumentasi MySQL.

Multi-source replikasi hanya didukung pada Aurora MySQL versi 8.4.8 dan lebih tinggi.
Aurora MySQL mendukung konfigurasi maksimum 15 saluran untuk replika multi-sumber.

Pemecahan masalah

Untuk pemecahan masalah replikasi umum, lihatBeberapa masalah replikasi Amazon Aurora MySQL. Berikut ini adalah catatan pemecahan masalah khusus replikasi multi-sumber.

Konfigurasi saluran tidak dipulihkan setelah pemulihan snapshot

Snapshot cluster DB tidak menyertakan konfigurasi saluran multi-sumber. Setelah Anda memulihkan dari snapshot:

Konfigurasikan ulang setiap saluran menggunakan mysql.rds_set_external_source_for_channel ataumysql.rds_set_external_source_with_auto_position_for_channel.
Jika menggunakan posisi otomatis GTID, replika dapat secara otomatis melanjutkan dari tempat tinggalnya.
Jika menggunakan posisi file log biner, tentukan posisi saat ini dengan membandingkan log biner sumber dengan transaksi terakhir yang diterapkan pada cluster yang dipulihkan.

Kelambatan replikasi meningkat pada satu atau lebih saluran

Periksa CPU dan I/O metrik instance penulis. Jika pemanfaatan sumber daya tinggi, tingkatkan kelas instance.
Pertimbangkan meningkatkan replica_parallel_workers untuk meningkatkan throughput thread SQL.
Verifikasi bahwa tidak ada transaksi yang berjalan lama atau operasi DDL pada saluran yang mungkin memblokir utas SQL.
Periksa konfigurasi filter yang saling bertentangan yang dapat menyebabkan replikasi diproses dan kemudian buang sejumlah besar peristiwa.

Contoh: Penyiapan multi-sumber lengkap dengan tiga sumber

Contoh berikut menunjukkan konfigurasi cluster Aurora MySQL DB sebagai replika multi-sumber dari tiga RDS untuk instance sumber MySQL.

Langkah 1: Rekam posisi log biner pada setiap sumber

Hubungkan ke setiap sumber dan catat koordinat log biner:


-- On source 1 (orders-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000045, Position: 3892

-- On source 2 (inventory-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000012, Position: 1567

-- On source 3 (analytics-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000078, Position: 9421

Langkah 2: Impor data dari setiap sumber


# Import from source 1
mysqldump --databases orders_db --single-transaction --compress \
 -u admin -p --host=orders-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 2
mysqldump --databases inventory_db --single-transaction --compress \
 -u admin -p --host=inventory-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 3
mysqldump --databases analytics_db --single-transaction --compress \
 -u admin -p --host=analytics-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

Langkah 3: Konfigurasikan dan mulai saluran replikasi

Hubungkan ke instance penulis Aurora MySQL:


-- Configure channel for source 1 (orders)
CALL mysql.rds_set_external_source_for_channel(
 'orders-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000045', 3892, 0, 'orders_channel'
);

-- Configure channel for source 2 (inventory)
CALL mysql.rds_set_external_source_for_channel(
 'inventory-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000012', 1567, 0, 'inventory_channel'
);

-- Configure channel for source 3 (analytics)
CALL mysql.rds_set_external_source_for_channel(
 'analytics-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000078', 9421, 0, 'analytics_channel'
);

-- Start all channels
CALL mysql.rds_start_replication_for_channel('orders_channel');
CALL mysql.rds_start_replication_for_channel('inventory_channel');
CALL mysql.rds_start_replication_for_channel('analytics_channel');

Langkah 4: Verifikasi status replikasi


SHOW REPLICA STATUS\G

Konfirmasikan bahwa untuk setiap saluran:

Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 0(atau nilai rendah)

Sumber daya terkait

Multi-Source Replikasi MySQL — Dokumentasi MySQL
Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)— Panduan Pengguna Aurora
Mengoptimalkan replikasi log biner untuk Aurora MySQL— Panduan Pengguna Aurora
Mengonfigurasi filter replikasi dengan Aurora MySQL— Panduan Pengguna Aurora
Menggunakan GTID-based replikasi— Panduan Pengguna Aurora

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Replikasi tertunda

Penerusan tulis lokal