# Amazon Aurora MySQL에 대한 다중 소스 복제 구성
다중 소스 복제를 사용하면 Amazon Aurora MySQL DB 클러스터를 둘 이상의 소스 MySQL 데이터베이스로부터 바이너리 로그 이벤트를 수신하는 복제본으로 설정할 수 있습니다. 각 소스는 RDS for MySQL DB 인스턴스, 다른 Aurora MySQL DB 클러스터 또는 Amazon RDS 외부에서 실행 중인 MySQL 데이터베이스일 수 있습니다.
다중 소스 복제는 다음 엔진 버전을 실행하는 Aurora MySQL DB 클러스터에 지원됩니다.
+ Aurora MySQL 8.4.8 이상
MySQL 다중 소스 복제에 대한 자세한 내용은 MySQL 설명서의 [MySQL 다중 소스 복제](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html)를 참조하세요.
**참고**
Aurora MySQL의 다중 소스 복제는 Aurora DB 클러스터의 라이터(기본) 인스턴스를 복제 대상으로 사용합니다. 모든 복제 저장 프로시저는 클러스터의 라이터 인스턴스에 연결된 상태에서 호출해야 합니다.
## 다중 소스 복제 사용 사례
Aurora MySQL의 다중 소스 복제는 다음과 같은 경우에 사용하는 것이 좋습니다.
+ **샤드 통합** – 별도의 DB 인스턴스에 호스팅된 여러 샤드의 데이터를 단일 Aurora MySQL DB 클러스터로 병합하거나 결합해야 하는 애플리케이션.
+ **통합 보고** – Aurora의 읽기 규모 조정 기능을 활용하여 여러 소스에서 통합된 데이터로 보고서를 생성해야 하는 애플리케이션.
+ **장기 백업** – 여러 MySQL 호환 DB 인스턴스에 분산된 데이터의 통합 장기 백업을 생성하기 위한 요구 사항.
+ **엔진 간 마이그레이션** – 마이그레이션 중에 여러 RDS for MySQL 인스턴스 또는 외부 MySQL 서버의 데이터를 단일 Aurora MySQL 클러스터로 통합.
+ **다중 테넌트 집계** – 비용 최적화 및 관리 간소화를 위해 여러 단일 테넌트 데이터베이스를 다중 테넌트 Aurora 클러스터로 통합.
## 다중 소스 복제를 위한 사전 요구 사항
Aurora MySQL DB 클러스터에서 다중 소스 복제를 구성하기 전에 [Aurora MySQL의 이진수 로그 복제 설정](AuroraMySQL.Replication.MySQL.SettingUp.md)에 설명된 대로 바이너리 로그 복제를 위한 표준 사전 조건을 완료합니다. 여기에는 각 소스에서 바이너리 로깅 활성화, 바이너리 로그 유지, 복제 사용자 생성, 각 소스의 복사본 또는 덤프 생성이 포함됩니다. 다중 소스 복제의 경우 각 소스 DB 인스턴스에 대해 이 단계를 반복합니다.
표준 사전 조건 외에도 다음과 같은 다중 소스 복제 관련 요구 사항을 충족해야 합니다.
+ Aurora MySQL 대상 클러스터 버전 및 구성 확인
+ Aurora MySQL DB 클러스터가 지원되는 엔진 버전(Aurora MySQL 8.4.8 이상)을 실행해야 합니다.
+ Aurora MySQL 라이터 인스턴스에서 자동 커밋을 활성화합니다. DB 클러스터 파라미터 그룹의 `autocommit` 파라미터를 `1`로 설정합니다.
+ 각 소스의 네트워크 연결 구성
각 소스 DB 인스턴스에서 Aurora MySQL 라이터 인스턴스가 지정된 포트의 소스에 연결할 수 있는지 확인합니다. 옵션에는 다음이 포함됩니다.
+ 소스와 대상이 모두 동일한 VPC에 있는 경우 소스 DB 인스턴스의 보안 그룹을 구성하여 Aurora MySQL 클러스터의 보안 그룹에서 들어오는 포트 3306(또는 사용자 지정 포트)의 인바운드 연결을 허용합니다.
+ 소스와 대상이 서로 다른 VPC에 있는 경우 VPC 피어링을 설정하거나 Transit Gateway를 사용합니다. 자세한 내용은 [VPC에 있는 DB 클러스터에 다른 VPC에 있는 EC2 인스턴스가 액세스](USER_VPC.Scenarios.md#USER_VPC.Scenario3) 섹션을 참조하세요.
+ 소스가 AWS 외부에 있는 경우 네트워크 경로를 사용할 수 있는지 확인합니다(예: VPN 연결을 통해).
**참고**
다중 소스 복제에는 여러 소스가 포함되므로 각 소스에 대한 연결을 독립적으로 확인해야 합니다. 보안 그룹 및 라우팅이 모든 소스 엔드포인트를 동시에 수용하는지 확인합니다.
## Aurora MySQL DB 클러스터에서 다중 소스 복제 채널 구성
Aurora MySQL에서 다중 소스 복제 채널을 구성하는 것은 단일 소스 복제 구성과 비슷합니다. 다중 소스 복제의 경우 먼저 소스 인스턴스에서 바이너리 로깅을 활성화하고, 소스에서 Aurora MySQL 클러스터로 데이터를 가져온 다음 바이너리 로그 좌표 또는 GTID 자동 위치 지정을 사용하여 각 소스에서 복제를 시작합니다.
**중요**
모든 다중 소스 복제 저장 프로시저는 Aurora MySQL DB 클러스터의 **라이터 인스턴스**에 연결된 상태에서 직접적으로 호출해야 합니다. 장애 조치가 발생하면 새 라이터 인스턴스에 다시 연결해야 합니다.
### 1단계: 소스 DB 인스턴스에서 Aurora MySQL 클러스터로 데이터 가져오기
각 소스 DB 인스턴스에 대해 다음 단계를 수행합니다.
1. 소스 DB 인스턴스에서 현재 바이너리 로그 파일 및 위치를 확인합니다.
```
SHOW BINARY LOG STATUS;
```
```
SHOW MASTER STATUS;
```
출력 예시:
```
+----------------------------+----------+
| File | Position |
+----------------------------+----------+
| mysql-bin-changelog.000031 | 107 |
+----------------------------+----------+
```
`File` 및 `Position` 값을 기록합니다. 이들 값은 이후 단계에서 필요합니다.
1. `mysqldump`를 사용하여 소스 DB 인스턴스에서 Aurora MySQL 클러스터로 데이터베이스를 복사합니다.
```
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}}'
```
**작은 정보**
대규모 데이터베이스의 경우 AWS DMS를 사용하거나 스냅샷을 생성하고 복원하여 데이터 전송 시간을 단축하는 것이 좋습니다.
1. 데이터 가져오기가 완료되면 이전에 읽기 전용으로 설정한 경우 소스 DB 인스턴스에서 쓰기를 다시 활성화할 수 있습니다.
### 2단계: 소스 DB 인스턴스에서 Aurora MySQL 클러스터로 복제 시작
각 소스 DB 인스턴스에서 Aurora MySQL DB 클러스터의 **라이터 인스턴스**에 연결하고 저장 프로시저를 실행하여 채널에서 복제를 구성하고 시작합니다.
```
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}}');
```
소스 DB 인스턴스가 GTID 기반 복제를 사용하는 경우 바이너리 로그 좌표를 지정하는 대신 자동 위치 지정을 사용할 수 있습니다.
```
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}}');
```
**참고**
GTID 자동 위치 지정을 사용하는 경우 `gtid_mode` 및 `enforce_gtid_consistency` 파라미터가 모든 소스 인스턴스와 Aurora MySQL 클러스터에서 일관되게 구성되었는지 확인합니다.
각 소스 DB 인스턴스에 대해 이 단계를 반복하여 각 인스턴스에 고유한 채널 이름을 지정합니다(예: `channel_1`, `channel_2`, `channel_3`).
## 다중 소스 복제와 함께 필터 사용
복제 필터를 사용하여 Aurora MySQL 다중 소스 복제본으로 복제할 데이터베이스 및 테이블을 지정할 수 있습니다. 복제 필터에 대한 자세한 정보는 [Aurora MySQL을 사용한 복제 필터 구성](AuroraMySQL.Replication.Filters.md) 섹션을 참조하세요. 다음은 다중 소스 복제에 사용할 수 있는 추가 채널 수준 필터 기능에 대한 설명입니다.
다중 소스 복제를 사용하면 두 가지 수준에서 복제 필터를 구성할 수 있습니다.
+ **글로벌 필터** – 모든 채널에 적용됩니다. Aurora MySQL DB 클러스터 파라미터 그룹(예: `replicate-do-db`, `replicate-ignore-db`)을 사용하여 설정합니다.
+ **채널 수준 필터** – 특정 채널에만 적용되며 해당 채널에 대한 글로벌 필터를 재정의합니다.
+ 채널 수준 필터를 변경한 후 복제를 다시 시작해야 합니다.
+ 채널별 필터가 구성되지 않은 경우 Aurora MySQL은 해당 채널에 글로벌 필터를 적용합니다.
+ 필터가 전체적으로 그리고 채널 수준에서 모두 적용되는 경우 해당 채널에는 채널 수준 필터만 적용됩니다.
## 다중 소스 복제 채널 모니터링
다음 방법을 사용하여 Aurora MySQL 다중 소스 복제본의 개별 채널을 모니터링할 수 있습니다.
### SHOW REPLICA STATUS 사용
Aurora MySQL DB 클러스터의 라이터 인스턴스에 연결하고 다음을 실행합니다.
```
-- View status for all channels
SHOW REPLICA STATUS\G
-- View status for a specific channel
SHOW REPLICA STATUS FOR CHANNEL '{{channel_1}}'\G
```
모니터링할 주요 필드:
| 필드 | 설명 |
| --- | --- |
| Replica\_IO\_Running | 채널의 I/O 스레드가 실행 중인지 여부 |
| Replica\_SQL\_Running | 채널의 SQL 스레드가 실행 중인지 여부 |
| Seconds\_Behind\_Source | 채널의 초 단위 복제 지연 |
| Last\_IO\_Error | 채널에서 발생한 마지막 I/O 오류 |
| Last\_SQL\_Error | 채널에서 발생한 마지막 SQL 오류 |
| Source\_Log\_File | 소스에서 읽는 현재 바이너리 로그 파일 |
| Exec\_Source\_Log\_Pos | SQL 스레드가 적용한 바이너리 로그 내의 위치 |
### CloudWatch 지표 사용
각 복제 채널에 대한 `ReplicationChannelLag` CloudWatch 지표를 모니터링합니다. 이 지표는 60초 기간의 채널별 복제 지연 데이터를 제공하며 15일 동안 사용할 수 있습니다. 복제 채널 지연을 찾으려면 Aurora DB 클러스터 인스턴스 식별자와 복제 채널 이름을 차원으로 사용하세요. 지연이 특정 임계값을 초과할 때 알림을 받도록 CloudWatch 경보를 구성할 수 있습니다. 자세한 내용은 [Amazon Aurora 클러스터에서 지표 모니터링](MonitoringAurora.md) 섹션을 참조하세요.
## 다중 소스 복제 저장 프로시저 관리
저장 프로시저를 사용하여 다중 소스 복제 채널을 설정하고 관리하는 방법에 대한 자세한 내용은 [다중 소스 복제 관리](mysql-stored-proc-multi-source-replication.md) 섹션을 참조하세요.
## 고려 사항 및 모범 사례
바이너리 로그 형식, 병렬 워커, 향상된 Binlog를 포함한 일반적인 복제 최적화 권장 사항은 [Aurora MySQL의 이진수 로그 복제 최적화](binlog-optimization.md) 섹션을 참조하세요. 다음 고려 사항은 다중 소스 복제에만 해당됩니다.
### 리소스 계획
여러 복제 채널을 실행하는 경우 복제본에 할당된 총 복제 스레드 수는 (`replica_parallel_workers` \+ 1 조정자 스레드) × 채널 수입니다. 예를 들어 기본 `replica_parallel_workers` 값이 4이고 채널이 10개인 경우 Aurora MySQL은 50개의 복제 스레드를 할당합니다. 총 소스 처리량 및 채널 수에 따라 더 큰 DB 인스턴스 클래스(예: db.r6g.2xlarge 이상)를 사용하는 것이 좋습니다. 각 채널에는 동일한 수의 병렬 워커가 할당됩니다. MySQL은 채널별로 다른 병렬 워커 수 설정을 지원하지 않습니다.
### 충돌 방지
MySQL 다중 소스 복제는 충돌 감지 또는 해결을 제공하지 않습니다. 서로 다른 소스의 변경 사항이 충돌하지 않는지 확인해야 합니다. 일반적인 전략은 다음과 같습니다.
+ 각 소스가 서로 다른 데이터베이스 또는 테이블 세트에 데이터를 씁니다.
+ 복제 필터(`replicate-do-db`)를 사용하여 각 채널이 담당하는 데이터베이스만 복제하도록 합니다.
+ 필요한 경우 `replicate-rewrite-db` 옵션을 사용하여 소스의 스키마 이름을 복제본의 다른 이름으로 다시 매핑합니다.
다중 소스 복제본에 직접 연결하는 애플리케이션의 쓰기 충돌을 방지하려면 Aurora MySQL 클러스터에서 읽기 전용 모드를 활성화합니다. `CALL mysql.rds_set_read_only(1);`
### 운영 모범 사례
+ **한 번에 한 채널** – 관리 작업(예: 구성 변경, 오류 건너뛰기 또는 복제 시작/중지)을 한 번에 한 채널에서 수행합니다. 서로 다른 연결에서 여러 채널을 동시에 변경하지 마세요.
+ **채널별 지연 모니터링** – `ReplicationChannelLag` CloudWatch 지표를 사용하여 각 채널의 복제 지연을 모니터링합니다.
+ **소스 장애 조치 처리** – 소스 DB 인스턴스가 장애 조치되는 경우(예: Amazon RDS Multi-AZ 장애 조치) 복제 채널이 I/O 오류와 함께 중지될 수 있습니다. 소스를 다시 사용할 수 있게 되면
+ `mysql.rds_start_replication_for_channel`을 직접적으로 호출하여 복제를 재개합니다.
+ 오류 1236이 발생하면(로그 파일을 찾을 수 없음) `mysql.rds_next_source_log_for_channel`을 직접적으로 호출하여 다음 바이너리 로그 파일로 이동합니다.
+ **Aurora 라이터 장애 조치** – Aurora MySQL 라이터 인스턴스가 리더로 장애 조치되면 복제 채널 구성이 클러스터의 공유 스토리지에 보존됩니다. 장애 조치가 완료되면 새 라이터 인스턴스에서 복제 스레드가 자동으로 다시 시작됩니다.
## 제한 사항
다음 제한 사항은 Aurora MySQL 다중 소스 복제에만 적용됩니다. 일반적인 MySQL 다중 소스 복제 제한 사항(예: 채널별 병렬 워커 구성)은 MySQL 설명서의 [MySQL 다중 소스 복제](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html)를 참조하세요.
+ 다중 소스 복제는 Aurora MySQL 버전 8.4.8 이상에서만 지원됩니다.
+ Aurora MySQL은 다중 소스 복제본에 대해 최대 **15개 채널** 구성을 지원합니다.
## 문제 해결
일반적인 복제 문제 해결은 [ Amazon Aurora MySQL 복제 문제](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL) 섹션을 참조하세요. 다음은 다중 소스 복제 관련 문제 해결 참고 사항입니다.
### 스냅샷 복원 후 채널 구성이 복원되지 않음
DB 클러스터 스냅샷에는 다중 소스 채널 구성이 포함되지 않습니다. 스냅샷에서 복원한 후:
+ `mysql.rds_set_external_source_for_channel` 또는 `mysql.rds_set_external_source_with_auto_position_for_channel`을 사용하여 각 채널을 재구성합니다.
+ GTID 자동 위치 지정을 사용하는 경우 복제본은 중단된 위치에서 자동으로 재개될 수 있습니다.
+ 바이너리 로그 파일 위치를 사용하는 경우 소스의 바이너리 로그를 복원된 클러스터에 마지막으로 적용된 트랜잭션과 비교하여 현재 위치를 확인합니다.
### 하나 이상의 채널에서 복제 지연 증가
+ 라이터 인스턴스의 CPU 및 I/O 지표를 확인합니다. 리소스 사용률이 높으면 인스턴스 클래스를 스케일 업합니다.
+ SQL 스레드 처리량을 개선하려면 `replica_parallel_workers`를 늘리는 것이 좋습니다.
+ 채널에서 SQL 스레드를 차단할 수 있는 장기 실행 트랜잭션 또는 DDL 작업이 없는지 확인합니다.
+ 복제 과정에서 대량의 이벤트를 처리 후 폐기할 수 있는 충돌하는 필터 구성이 있는지 확인합니다.
## 예제: 3개의 소스가 포함된 전체 다중 소스 설정
다음 예제에서는 Aurora MySQL DB 클러스터를 3개의 RDS for MySQL 소스 인스턴스의 다중 소스 복제본으로 구성하는 방법을 보여줍니다.
### 1단계: 각 소스에 바이너리 로그 위치 기록
각 소스에 연결하고 바이너리 로그 좌표를 기록합니다.
```
-- 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
```
### 2단계: 각 소스에서 데이터 가져오기
```
# 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
```
### 3단계: 복제 채널 구성 및 시작
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');
```
### 4단계: 복제 상태 확인
```
SHOW REPLICA STATUS\G
```
각 채널에 대해 다음을 확인합니다.
+ `Replica_IO_Running: Yes`
+ `Replica_SQL_Running: Yes`
+ `Seconds_Behind_Source: 0`(또는 낮은 값)
## 관련 리소스
+ [MySQL 다중 소스 복제](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html) – MySQL 설명서
+ [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) – Aurora 사용 설명서
+ [Aurora MySQL의 이진수 로그 복제 최적화](binlog-optimization.md) – Aurora 사용 설명서
+ [Aurora MySQL을 사용한 복제 필터 구성](AuroraMySQL.Replication.Filters.md) – Aurora 사용 설명서
+ [GTID 기반 복제 사용](mysql-replication-gtid.md) – Aurora 사용 설명서