

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

# Konfigurasikan replikasi multi-sumber untuk Amazon Aurora MySQL
<a name="AuroraMySQL.Replication.MultiSource"></a>

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 ](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html) 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
<a name="AuroraMySQL.Replication.MultiSource.UseCases"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Prerequisites"></a>

Sebelum Anda mengonfigurasi replikasi multi-sumber pada cluster Aurora MySQL DB Anda, lengkapi prasyarat standar untuk replikasi log biner seperti yang dijelaskan dalam[Menyiapkan replikasi log biner untuk Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md). 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](USER_VPC.Scenarios.md#USER_VPC.Scenario3).
  + 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
<a name="AuroraMySQL.Replication.MultiSource.Configure"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Configure.Step1"></a>

Lakukan langkah-langkah berikut untuk setiap instance DB sumber.

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

   ```
   SHOW BINARY LOG STATUS;
   ```

   ```
   SHOW MASTER STATUS;
   ```

   Contoh output:

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

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

1. Salin database dari instance DB sumber ke cluster Aurora MySQL menggunakan`mysqldump`.

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

1. 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
<a name="AuroraMySQL.Replication.MultiSource.Configure.Step2"></a>

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

```
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}}');
```

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
<a name="AuroraMySQL.Replication.MultiSource.Filters"></a>

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, lihat[Mengonfigurasi filter replikasi dengan Aurora MySQL](AuroraMySQL.Replication.Filters.md). 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.
+ 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
<a name="AuroraMySQL.Replication.MultiSource.Monitoring"></a>

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

### Gunakan STATUS TAMPILKAN REPLIKA
<a name="AuroraMySQL.Replication.MultiSource.Monitoring.ShowReplicaStatus"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Monitoring.CloudWatch"></a>

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](MonitoringAurora.md).

## Kelola prosedur penyimpanan replikasi multi-sumber
<a name="AuroraMySQL.Replication.MultiSource.StoredProcedures"></a>

Untuk informasi tentang menggunakan prosedur tersimpan untuk mengatur dan mengelola saluran replikasi multi-sumber Anda, lihat[Mengelola replikasi multi-sumber](mysql-stored-proc-multi-source-replication.md).

## Pertimbangan dan praktik terbaik
<a name="AuroraMySQL.Replication.MultiSource.Considerations"></a>

Untuk rekomendasi pengoptimalan replikasi umum termasuk format log biner, pekerja paralel, dan Binlog yang Ditingkatkan, lihat[Mengoptimalkan replikasi log biner untuk Aurora MySQL](binlog-optimization.md). Pertimbangan berikut khusus untuk replikasi multi-sumber.

### Perencanaan sumber daya
<a name="AuroraMySQL.Replication.MultiSource.Considerations.Resources"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Considerations.Conflicts"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Considerations.Operational"></a>
+ **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
<a name="AuroraMySQL.Replication.MultiSource.Limitations"></a>

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 ](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html) 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
<a name="AuroraMySQL.Replication.MultiSource.Troubleshooting"></a>

Untuk pemecahan masalah replikasi umum, lihat[Beberapa masalah replikasi Amazon Aurora MySQL](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL). Berikut ini adalah catatan pemecahan masalah khusus replikasi multi-sumber.

### Konfigurasi saluran tidak dipulihkan setelah pemulihan snapshot
<a name="AuroraMySQL.Replication.MultiSource.Troubleshooting.Snapshot"></a>

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` atau`mysql.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
<a name="AuroraMySQL.Replication.MultiSource.Troubleshooting.Lag"></a>
+ 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
<a name="AuroraMySQL.Replication.MultiSource.Example"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Example.Step1"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Example.Step2"></a>

```
# 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
<a name="AuroraMySQL.Replication.MultiSource.Example.Step3"></a>

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
<a name="AuroraMySQL.Replication.MultiSource.Example.Step4"></a>

```
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
<a name="AuroraMySQL.Replication.MultiSource.RelatedResources"></a>
+ [ Multi-Source Replikasi MySQL ](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html) — Dokumentasi MySQL
+ [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md)— Panduan Pengguna Aurora
+ [Mengoptimalkan replikasi log biner untuk Aurora MySQL](binlog-optimization.md)— Panduan Pengguna Aurora
+ [Mengonfigurasi filter replikasi dengan Aurora MySQL](AuroraMySQL.Replication.Filters.md)— Panduan Pengguna Aurora
+ [Menggunakan GTID-based replikasi](mysql-replication-gtid.md)— Panduan Pengguna Aurora