engine=innodb, algorithm=copy;
```
다음 섹션에서는 복제 설정, 복제 중지, 데이터베이스 읽기 규모 조정, binlog 복제 최적화, 향상된 binlog 설정을 설명합니다.
**Topics**
+ [Aurora MySQL의 이진수 로그 복제 설정](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [Aurora MySQL의 이진수 로그 복제 중지](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 규모 조정](AuroraMySQL.Replication.ReadScaling.md)
+ [Aurora MySQL의 이진수 로그 복제 최적화](binlog-optimization.md)
+ [Aurora MySQL에 대해 향상된 binlog 설정](AuroraMySQL.Enhanced.binlog.md)
# Aurora MySQL의 이진수 로그 복제 설정
Aurora MySQL을 사용하여 MySQL 복제를 설정하는 단계는 다음에서 자세히 설명합니다.
**Contents**
+ [1. 복제 소스에 대한 이진 로깅 설정](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. 더 이상 필요 없을 때까지 이진 로그를 복제 소스에 보관](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. 복제 소스의 사본 또는 덤프 만들기](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. 복제본 대상으로 덤프를 로드합니다(필요한 경우).](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. 복제 소스에 복제 사용자 생성](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. 복제본 대상에서 복제 설정](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [읽기 전용 복제본에 대한 복제를 중지할 위치 설정](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. 복제본 모니터링](#AuroraMySQL.Replication.MySQL.Monitor)
+ [복제 소스와 타겟 간 비밀번호 동기화](#AuroraMySQL.Replication.passwords)
## 1. 복제 소스에 대한 이진 로깅 설정
다음 데이터베이스 엔진의 복제 소스에 대한 이진 로깅을 설정하는 방법의 지침을 확인합니다.
| 데이터베이스 엔진 | 지침 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB 클러스터에 대한 이진 로깅을 설정하려면** `binlog_format` DB 클러스터 파라미터를 `ROW`, `STATEMENT`, `MIXED`로 설정합니다. 특정 binlog 형식이 필요하지 않는 한 `MIXED`로 설정하는 것이 좋습니다. (기본값은 `OFF`입니다.) `binlog_format` 파라미터를 변경하려면 사용자 지정 DB 클러스터 파라미터 그룹을 만들고 해당 사용자 지정 파라미터 그룹을 DB 클러스터와 연결합니다. 기본 DB 클러스터 파라미터 그룹에서는 파라미터를 변경할 수 없습니다. `binlog_format` 파라미터를 `OFF`에서 다른 값으로 변경하는 경우, Aurora DB 클러스터를 재부팅해야 변경 사항이 적용됩니다. 자세한 내용은 [Amazon Aurora DB 클러스터와 DB 인스턴스 파라미터](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) 및 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md)(을)를 참조하세요. |
| RDS for MySQL | **Amazon RDS DB 인스턴스에 대한 이진 로깅을 설정하려면** Amazon RDS DB 인스턴스에 대한 이진 로깅을 직접 설정할 수 없지만, 다음 중 하나를 수행하여 설정할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL(외부) | **암호화된 복제 설정** Aurora MySQL 버전 2를 사용하여 데이터를 안전하게 복제하려면 암호화된 복제를 사용하세요. 암호화된 복제를 사용할 필요가 없다면 이 단계를 건너 뛸 수 있습니다. 다음은 암호화된 복제를 사용하기 위한 사전 조건입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 암호화 복제 중, Aurora MySQL DB 클러스터는 MySQL 데이터베이스 서버의 클라이언트 역할을 합니다. Aurora MySQL 클라이언트 인증서와 키는 .pem 형식의 파일입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **외부 MySQL 데이터베이스에 대한 이진 로깅을 설정하려면** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 2. 더 이상 필요 없을 때까지 이진 로그를 복제 소스에 보관
MySQL 이진 로그 복제를 사용할 경우 Amazon RDS에서 복제 프로세스를 관리하지 않습니다. 따라서 변경 사항이 복제본에 적용된 이후까지 복제 소스의 binlog 파일이 보관되는지 확인해야 합니다. 이 유지 관리는 오류 발생 시 원본 데이터베이스를 복원하는 데 도움이 됩니다.
데이터베이스 엔진에 대한 바이너리 로그를 유지하려면 다음 지침을 따르세요.
| 데이터베이스 엔진 | 지침 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB 클러스터에 이진 로그를 보관하려면** Aurora MySQL DB 클러스터의 binlog 파일에 대한 액세스 권한이 없습니다. 따라서 Amazon RDS에서 binlog 파일을 삭제하기 이전에 변경 사항이 복제본에 적용되도록 복제 소스에 binlog 파일을 보관할 기간을 충분히 길게 선택해야 합니다. Aurora MySQL DB 클러스터에 binlog 파일을 최대 90일 동안 보관할 수 있습니다. MySQL 데이터베이스 또는 RDS for MySQL DB 인스턴스를 복제본으로 사용하여 복제를 설정하고 복제본을 생성할 데이터베이스가 매우 큰 경우, 복제본에 대한 데이터베이스의 초기 복사가 완료되고 복제 지연이 0에 도달할 때까지 binlog 파일을 보관하도록 기간을 길게 선택합니다. 바이너리 로그 보관 기간을 설정하려면 [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) 프로시저를 사용하여 `'binlog retention hours'` 구성 파라미터와 함께 DB 클러스터에 binlog 파일을 보관할 시간을 지정하세요. Aurora MySQL 버전 2.11.0 이상 및 버전 3의 최대 값은 2160(90일)입니다. 다음 예에서는 binlog 파일의 보관 기간을 6일로 설정합니다. CALL mysql.rds_set_configuration('binlog retention hours', 144); 복제를 시작한 후 복제본에 대해 `SHOW SLAVE STATUS`(Aurora MySQL 버전 2) 또는 `SHOW REPLICA STATUS`(Aurora MySQL version 3) 명령을 실행하고 `Seconds behind master` 필드를 확인하여 변경 사항이 복제본에 적용되었는지 확인할 수 있습니다. `Seconds behind master` 필드가 0이면 복제본 지연이 없습니다. 복제 지연이 없는 경우 `binlog retention hours` 구성 파라미터를 더 짧은 기간으로 설정하여 binlog 파일을 보관할 기간을 줄입니다. 이 설정을 지정하지 않으면 Aurora MySQL의 기본값은 24(1일)입니다. `'binlog retention hours'` 값을 최대값보다 높게 지정하면 Aurora MySQL은 해당 최대값을 사용합니다. |
| RDS for MySQL | **Amazon RDS DB 인스턴스에 이진 로그를 보관하려면** 이전 행에서 설명한 Aurora MySQL DB 클러스터와 마찬가지로 binlog 보관 시간을 설정하여 Amazon RDS DB 인스턴스에 바이너리 로그 파일을 보관할 수 있습니다. DB 인스턴스에 대한 읽기 전용 복제본을 생성하여 Amazon RDS DB 인스턴스에 binlog 파일을 보관할 수도 있습니다. 이 읽기 전용 복제본은 임시 복제본이며 binlog 파일 보관의 목적으로만 사용됩니다. 읽기 전용 복제본이 생성된 후 읽기 전용 복제본에서 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 프로시저를 호출합니다. 복제가 중지된 동안 Amazon RDS에서는 복제 소스에서 binlog 파일을 삭제하지 않습니다. 영구 복제본을 사용하여 복제를 설정한 후 복제 소스와 영구 복제본 사이의 복제 지연(`Seconds behind master` 필드)이 0에 도달한 경우 읽기 전용 복제본을 삭제할 수 있습니다. |
| MySQL(외부) | **외부 MySQL 데이터베이스에 이진 로그를 보관하려면** 외부 MySQL 데이터베이스의 binlog 파일은 Amazon RDS에서 관리하지 않으므로 삭제할 때까지 보관됩니다. 복제를 시작한 후 복제본에 대해 `SHOW SLAVE STATUS`(Aurora MySQL 버전 2) 또는 `SHOW REPLICA STATUS`(Aurora MySQL version 3) 명령을 실행하고 `Seconds behind master` 필드를 확인하여 변경 사항이 복제본에 적용되었는지 확인할 수 있습니다. `Seconds behind master` 필드가 0이면 복제본 지연이 없습니다. 복제 지연이 없는 경우 이전 binlog 파일을 삭제할 수 있습니다. |
## 3. 복제 소스의 사본 또는 덤프 만들기
복제 소스의 스냅샷, 클론 또는 덤프는 데이터의 기본 사본을 복제본으로 로드하는 데 사용됩니다. 그런 다음 그 시점부터 복제를 시작합니다.
다음 지침에 따라 데이터베이스 엔진에 대한 복제 소스의 사본 또는 덤프를 생성하세요.
| 데이터베이스 엔진 | 지침 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB 클러스터의 사본을 만들려면** 다음 방법 중 한 가지를 선택하세요. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **binlog 파일 이름과 위치를 확인하려면** 다음 방법 중 한 가지를 선택하세요. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Aurora MySQL DB 클러스터의 덤프를 만들려면** 복제본 대상이 외부 MySQL 데이터베이스 또는 RDS for MySQL DB 인스턴스인 경우, Aurora DB 클러스터에서 덤프 파일을 만들어야 합니다. 생성한 소스 DB 클러스터 사본에 대해 `mysqldump` 명령을 실행해야 합니다. 이는 덤프 시 잠금 고려 사항을 피하기 위한 것입니다. 원본 DB 클러스터에서 직접 덤프를 수행한 경우 덤프가 진행되는 동안 원본 테이블에 동시 쓰기가 발생하지 않도록 원본 테이블을 잠가야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Amazon RDS DB 인스턴스의 스냅샷을 만들려면** Amazon RDS DB 인스턴스의 읽기 전용 복제본을 생성합니다. 자세한 내용은 *Amazon Relational Database Service 사용 설명서*의 [읽기 전용 복제본 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) 단원을 참조하십시오. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL(외부) | **외부 MySQL 데이터베이스의 스냅샷 생성** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. 복제본 대상으로 덤프를 로드합니다(필요한 경우).
Amazon RDS 외부에 있는 MySQL 데이터베이스 덤프에서 데이터를 로드할 계획이라면 덤프 파일을 복사할 EC2 인스턴스를 만드는 것이 좋습니다. 그런 다음 해당 EC2 인스턴스에서 DB 클러스터 또는 DB 인스턴스로 데이터를 로드할 수 있습니다. 이 방법을 사용하면 EC2 인스턴스에 덤프 파일을 복사하기 전에 압축하여 Amazon RDS에 데이터를 복사하는 것과 관련한 네트워크 비용을 줄일 수 있습니다. 또한 덤프 파일 또는 파일을 암호화하여 네트워크 간에 전송되는 데이터를 보호할 수 있습니다.
**참고**
복제본 대상으로 새로운 Aurora MySQL DB 클러스터를 만드는 경우 덤프 파일을 로드할 필요가 없습니다.
DB 클러스터 스냅샷에서 복원하여 새로운 DB 클러스터를 만들 수 있습니다. 자세한 내용은 [DB 클러스터 스냅샷에서 복원](aurora-restore-snapshot.md) 섹션을 참조하세요.
소스 DB 클러스터를 복제하여 새 DB 클러스터를 생성할 수 있습니다. 자세한 내용은 [Aurora DB 클러스터에 대한 볼륨 복제](Aurora.Managing.Clone.md) 섹션을 참조하세요.
DB 인스턴스의 데이터를 새 DB 클러스터로 마이그레이션할 수 있습니다. 자세한 내용은 [Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션](AuroraMySQL.Migrating.md) 섹션을 참조하세요.
데이터베이스 엔진의 복제본 대상에 복제 소스의 덤프를 로드하는 방법에 대한 다음 지침을 확인하세요.
| 데이터베이스 엔진 | 지침 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB 클러스터로 덤프 로드** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Amazon RDS DB 인스턴스로 덤프 로드** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL(외부) | **외부 MySQL 데이터베이스로 덤프 로드** DB 스냅샷 또는 DB 클러스터 스냅샷을 외부 MySQL 데이터베이스로 로드할 수 없습니다. 대신 `mysqldump` 명령의 출력을 사용해야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 5. 복제 소스에 복제 사용자 생성
복제에 사용되는 사용자 ID를 생성할 수도 있습니다. 다음은 RDS for MySQL 또는 외부 MySQL 소스 데이터베이스의 예제입니다.
```
mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';
```
Aurora MySQL 소스 데이터베이스의 경우, `skip_name_resolve` DB 클러스터 파라미터는 `1`(`ON`)로 설정되며 수정할 수 없으므로 도메인 이름 대신 호스트의 IP 주소를 사용해야 합니다. 자세한 내용은 MySQL 설명서의 [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve)를 참조하세요.
```
mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';
```
사용자에게 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한이 필요합니다. 해당 사용자에게 이 권한을 부여합니다.
암호화된 복제를 사용해야 한다면, 복제 사용자에게 SSL 연결이 반드시 필요합니다. 예를 들어, 다음 문 중 하나를 사용하여 사용자 계정 `repl_user`에 대한 SSL 연결을 요구할 수 있습니다.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
```
```
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
```
**참고**
`REQUIRE SSL`이 포함되어 있지 않다면, 복제 연결이 자동으로 암호화되지 않은 연결로 돌아갈 수 있습니다.
## 6. 복제본 대상에서 복제 설정
복제를 설정하기 전에 Aurora MySQL DB 클러스터 또는 RDS for MySQL DB 인스턴스 복제본 대상의 스냅샷을 수동으로 생성하는 것이 좋습니다. 문제가 발생하여 DB 클러스터 또는 DB 인스턴스 복제본 대상을 통해 복제를 다시 설정해야 하는 경우, 데이터를 복제본 대상으로 다시 가져오는 대신 이 스냅샷에서 DB 클러스터 또는 DB 인스턴스를 복원할 수 있습니다.
데이터베이스 엔진에 대한 복제를 켜려면 다음 지침을 확인하세요.
| 데이터베이스 엔진 | 지침 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB 클러스터에서 복제를 설정하려면** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) SSL 암호화를 사용하려면 최종 값을 `0` 대신 `1`로 설정합니다. |
| RDS for MySQL | **Amazon RDS DB 인스턴스에서 복제를 설정하려면** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) SSL 암호화를 사용하려면 최종 값을 `0` 대신 `1`로 설정합니다. |
| MySQL(외부) | **외부 MySQL 데이터베이스에서 복제를 설정하려면** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
복제가 실패하면 복제본에서 의도하지 않은 I/O가 크게 증가하여 성능이 저하될 수 있습니다. 복제가 실패하거나 더 이상 필요하지 않은 경우 [mysql.rds\$1reset\$1external\$1master(Aurora MySQL 버전 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) 또는 [mysql.rds\$1reset\$1external\$1source(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) 저장 프로시저를 실행하여 복제 구성을 제거할 수 있습니다.
### 읽기 전용 복제본에 대한 복제를 중지할 위치 설정
Aurora MySQL 버전 3.04 이상에서는 [mysql.rds\$1start\$1replication\$1until(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 저장 프로시저를 사용하여 복제를 시작한 다음 지정된 이진 로그 파일 위치에서 복제를 중지할 수 있습니다.
**읽기 전용 복제본에 대한 복제를 시작하고 특정 위치에서 복제를 중지하려면**
1. MySQL 클라이언트를 사용하여 Aurora MySQL DB 클러스터 복제본에 마스터 사용자로 연결합니다.
1. [mysql.rds\$1start\$1replication\$1until(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 저장 프로시저를 실행합니다.
다음 예제에서는 복제를 시작하고 `120` 바이너리 로그 파일의 `mysql-bin-changelog.000777` 위치에 도달할 때까지 변경 사항을 복제합니다. 재해 복구 시나리오에서 `120`이 재해 직전 위치라고 가정합니다.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
중지 지점에 도달하면 복제가 자동으로 중지됩니다. `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure` RDS 이벤트가 생성됩니다.
GTID 기반 복제를 사용하는 경우 [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL 버전 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) 저장 프로시저 대신 [mysql.rds\$1start\$1replication\$1until(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 저장 프로시저를 사용하십시오. GTID 기반 복제에 대한 자세한 내용은 [GTID 기반 복제 사용](mysql-replication-gtid.md) 단원을 참조하십시오.
## 7. 복제본 모니터링
Aurora MySQL DB 클러스터를 사용하여 MySQL 복제를 설정한 경우 복제본 대상인 Aurora MySQL DB 클러스터에 대한 장애 조치 이벤트를 모니터링해야 합니다. 장애 조치가 발생할 경우에는 복제본 대상인 DB 클러스터가 다른 네트워크 주소를 가진 새 호스트에서 다시 생성될 수도 있습니다. 장애 조치 이벤트를 모니터링하는 자세한 방법은 [Amazon RDS 이벤트 알림 작업](USER_Events.md) 단원을 참조하세요.
또한 복제본 대상에 연결하고 `SHOW SLAVE STATUS`(Aurora MySQL 버전 2) 또는 `SHOW REPLICA STATUS`(Aurora MySQL 버전 3) 명령을 실행하여 복제본 대상이 복제 소스보다 얼마나 지연되는지 모니터링할 수 있습니다. 명령 출력의 `Seconds Behind Master` 필드는 복제본 대상이 소스보다 얼마나 지연되었는지 알려줍니다.
**중요**
DB 클러스터를 업그레이드하고 사용자 지정 파라미터 그룹을 지정하는 경우 업그레이드가 완료된 후 클러스터를 수동으로 재부팅해야 합니다. 이렇게 하면 클러스터가 새 사용자 지정 파라미터 설정을 사용하고 binlog 복제를 다시 시작합니다.
## 복제 소스와 타겟 간 비밀번호 동기화
SQL 문을 사용하여 복제 소스에서 사용자 계정 및 암호를 변경하면 해당 변경 사항이 복제 대상에 자동으로 복제됩니다.
AWS Management Console, AWS CLI 또는 RDS API를 사용하여 복제 소스의 마스터 암호를 변경하는 경우 이러한 변경 사항은 복제 대상에 자동으로 복제되지 않습니다. 소스 시스템과 타겟 시스템 간에 마스터 사용자 및 마스터 비밀번호를 동기화하려는 경우 복제 타겟을 직접 동일하게 변경해야 합니다.
# Aurora MySQL의 이진수 로그 복제 중지
MySQL DB 인스턴스, 외부 MySQL 데이터베이스 또는 다른 Aurora DB 클러스터와의 이진 로그 복제 중지 단계는 다음과 같으며, 이 주제의 뒷부분에 자세히 설명되어 있습니다.
[1. 복제본 대상의 이진 로그 복제 중단](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. 복제 소스에 대한 이진 로깅 해제](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. 복제본 대상의 이진 로그 복제 중단
데이터베이스 엔진의 바이너리 로그 복제를 중지하려면 다음 지침을 따르세요.
| 데이터베이스 엔진 | 지침 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB 클러스터 복제본 대상에 대한 이진 로그 복제를 중지하려면** 복제본 대상인 Aurora DB 클러스터에 연결하고 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 프로시저를 호출합니다. |
| RDS for MySQL | **Amazon RDS DB 인스턴스에 대한 이진 로그 복제를 중지하려면** 복제본 대상인 RDS DB 클러스터에 연결하고 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 프로시저를 호출합니다. |
| MySQL(외부) | **외부 MySQL 데이터베이스에서 이진 로그 복제를 중지하려면** MySQL 데이터베이스에 연결하고 `STOP SLAVE`(버전 5.7) 또는 `STOP REPLICA`(버전 8.0) 명령을 실행합니다. |
## 2. 복제 소스에 대한 이진 로깅 해제
데이터베이스 엔진의 복제 소스에서 바이너리 로깅을 비활성화하려면 다음 테이블의 지침을 따르세요.
| 데이터베이스 엔진 | 지침 |
| --- | --- |
| Aurora MySQL | **Amazon Aurora DB 클러스터에 대한 이진 로깅을 해제하려면** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **Amazon RDS DB 인스턴스에 대한 이진 로깅을 해제하려면** Amazon RDS DB 인스턴스에 대한 이진 로깅을 직접 해제할 수 없지만, 다음 중 하나를 수행하여 해제할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL(외부) | **외부 MySQL 데이터베이스에 대한 이진 로깅을 해제하려면** MySQL 데이터베이스에 연결하고 `STOP REPLICATION` 명령을 호출합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 규모 조정
MySQL DB 인스턴스에서 Amazon Aurora를 사용하여 Amazon Aurora의 읽기 조정 기능을 활용하고 MySQL DB 인스턴스에 대한 읽기 작업을 확장할 수 있습니다. Aurora을 사용하여 MySQL DB 인스턴스에 대한 읽기 조정을 수행하려면 Amazon Aurora MySQL DB 클러스터를 생성한 후 이 클러스터를 MySQL DB 인스턴스의 읽기 전용 복제본으로 설정합니다. 이러한 설정은 RDS for MySQL DB 인스턴스 또는 Amazon RDS 외부에서 실행 중인 MySQL 데이터베이스에 적용됩니다.
Amazon Aurora DB 클러스터 생성에 대한 자세한 정보는 [Amazon Aurora DB 클러스터 생성](Aurora.CreateInstance.md) 섹션을 참조하십시오.
MySQL DB 인스턴스와 Amazon Aurora DB 클러스터 간의 복제를 설정할 때는 다음 지침을 따라야 합니다.
+ Amazon Aurora DB 클러스터를 참조할 때 Amazon Aurora MySQL DB 클러스터 엔드포인트 주소를 사용합니다. 장애 조치가 발생하는 경우 Aurora DB 클러스터용 기본 인스턴스로 승격되는 Aurora MySQL 복제본에서 DB 클러스터 엔드포인트 주소가 계속 사용됩니다.
+ Binlog가 Aurora 복제본에 적용되었음을 확인할 때까지는 라이터 인스턴스에서 binlog를 유지 관리합니다. 이렇게 유지 관리해야 오류 발생 시 라이터 인스턴스를 복원할 수 있습니다.
**중요**
자체 관리형 복제를 사용하는 경우, 발생할 수 있는 복제 문제를 직접 모니터링하고 해결해야 합니다. 자세한 내용은 [읽기 전용 복제본 간 지연 문제 진단 및 해결](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag) 섹션을 참조하세요.
**참고**
Aurora MySQL DB 클러스터에서 복제를 시작하는 데 필요한 권한이 제한되고 Amazon RDS 마스터 사용자를 사용할 수 없습니다. 그러므로 [mysql.rds\$1set\$1external\$1master(Aurora MySQL 버전 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) 또는 [mysql.rds\$1set\$1external\$1source(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) 및 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 프로시저를 사용하여 Aurora MySQL DB 클러스터와 MySQL DB 인스턴스 간 복제를 설정해야 합니다.
## 외부 소스 인스턴스와 Aurora MySQL DB 인스턴스 간의 복제 시작
1. 원본 MySQL DB 인스턴스를 읽기 전용으로 설정합니다.
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. 원본 MySQL DB 인스턴스에서 `SHOW MASTER STATUS` 명령을 실행하여 binlog 위치를 확인합니다. 다음 예제와 비슷한 출력 결과를 얻습니다.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. `mysqldump`를 사용하여 외부 MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터베이스를 복사합니다. 매우 큰 데이터베이스의 경우 *Amazon Relational Database Service 사용 설명서*의 [가동 중지 시간을 줄이면서 Amazon RDS for MySQL 데이터베이스로 데이터 가져오기](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html)의 절차를 사용하는 것이 좋습니다.
대상 LinuxmacOS, 또는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
```
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
```
**참고**
`-p` 옵션과 입력한 암호 사이에 공백이 없어야 합니다.
`--host` 명령의 `--user (-u)`, `--port`, `-p` 및 `mysql` 옵션을 사용하여 Aurora DB 클러스터에 연결할 호스트 이름, 사용자 이름, 포트 및 비밀번호를 지정하십시오. 호스트 이름은 Amazon Aurora DB 클러스터 엔드포인트의 DNS 이름으로, 예를 들면 `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`입니다. Amazon RDS Management Console의 클러스터 세부 정보에서 엔드포인트 값을 찾을 수 있습니다.
1. 다시 원본 MySQL DB 인스턴스를 쓰기 가능한 상태로 설정합니다.
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
복제에 사용할 백업을 만드는 방법에 대한 자세한 내용은 MySQL 설명서에서 [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) 섹션을 참조하세요.
1. Amazon RDS Management Console에서 원본 MySQL 데이터베이스를 호스팅하는 서버의 IP 주소를 Amazon Aurora DB 클러스터용 VPC 보안 그룹에 추가합니다. VPC 보안 그룹 수정에 대한 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*의 [VPC용 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)을 참조하십시오.
Amazon Aurora DB 클러스터의 IP 주소에서의 연결을 허용하도록 로컬 네트워크를 구성하여 원본 MySQL 인스턴스와 통신할 수 있도록 해야 할 수도 있습니다. Amazon Aurora DB 클러스터의 IP 주소를 검색하려면 `host` 명령을 사용하십시오.
```
host aurora_endpoint_address
```
호스트 이름은 Amazon Aurora DB 클러스터 엔드포인트의 DNS 이름입니다.
1. 선택한 클라이언트를 사용하여 외부 MySQL 인스턴스에 연결하고 복제에 사용될 MySQL 사용자를 만듭니다. 이 계정은 오직 복제용으로만 사용되며 보안 향상을 위해 사용자의 도메인으로 제한되어야 합니다. 다음은 예제입니다.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. 외부 MySQL 인스턴스의 경우 복제 사용자에게 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다. 예를 들어 도메인의 '`REPLICATION CLIENT`' 사용자를 위해 모든 데이터베이스에서 `REPLICATION SLAVE` 및 `repl_user` 권한을 부여하려면 다음 명령을 실행합니다.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'
IDENTIFIED BY 'password';
```
1. 복제를 설정하기 전에 Aurora MySQL DB 클러스터의 수동 스냅샷을 읽기 전용 복제본으로 생성합니다. DB 클러스터와 복제를 읽기 복제본으로 다시 설정해야 할 경우, MySQL DB 인스턴스를 새로운 Aurora MySQL DB 클러스터로 가져오는 대신 이 스냅샷에서 Aurora MySQL DB 클러스터를 복원할 수 있습니다.
1. Amazon Aurora DB 클러스터를 복제본으로 만듭니다. Amazon Aurora DB 클러스터에 마스터 사용자로 연결하고 [mysql.rds\$1set\$1external\$1master(Aurora MySQL 버전 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) 또는 [mysql.rds\$1set\$1external\$1source(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) 및 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 프로시저를 사용하여 소스 MySQL 데이터베이스를 복제 소스로 식별합니다.
2단계에서 결정한 binlog 파일 이름과 위치를 사용합니다. 다음은 예입니다.
```
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. Amazon Aurora DB 클러스터에서 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 프로시저를 호출하여 복제를 시작합니다.
```
CALL mysql.rds_start_replication;
```
원본 MySQL DB 인스턴스와 Amazon Aurora DB 클러스터 간의 복제를 설정한 후에는 Aurora 복제본을 Amazon Aurora DB 클러스터에 추가할 수 있습니다. 그러고 나면 Aurora 복제본에 연결하여 데이터에 대한 읽기 조정을 수행할 수 있습니다. Aurora 복제본 생성에 대한 자세한 정보는 [DB 클러스터에 Aurora 복제본 추가](aurora-replicas-adding.md) 섹션을 참조하십시오.
# Aurora MySQL의 이진수 로그 복제 최적화
다음으로 Aurora MySQL에서 이진 로그 복제 성능을 최적화하고 관련 문제를 해결하는 방법을 배울 수 있습니다.
**작은 정보**
이 논의에서는 MySQL 이진 로그 복제 메커니즘과 작동 방식에 대해 잘 알고 있다고 가정합니다. 배경 정보는 MySQL 설명서의 [복제 구현](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) 단원을 참조하세요.
## 다중 스레드 이진 로그 복제
다중 스레드 이진 로그 복제를 사용하면 SQL 스레드가 릴레이 로그에서 이벤트를 읽고 SQL 작업자 스레드에서 적용하도록 이벤트를 대기열에 넣습니다. SQL 작업자 스레드는 조정자 스레드에서 관리합니다. 가능한 경우 이진 로그 이벤트가 병렬로 적용됩니다. 병렬 처리 수준은 버전, 파라미터, 스키마 설계 및 워크로드 특성을 비롯한 요인에 따라 달라집니다.
다중 스레드 이진 로그 복제는 Aurora MySQL 버전 3, Aurora MySQL 버전 2.12.1 이상에서 지원됩니다. 다중 스레드 복제본이 binlog 이벤트를 병렬로 효율적으로 처리하려면 멀티스레드 바이너리 로그 복제를 위한 소스를 구성해야 하며, 소스는 바이너리 로그 파일에 병렬 처리 정보가 포함된 버전을 사용해야 합니다.
Aurora MySQL DB 인스턴스가 binlog 복제를 사용하도록 구성된 경우 복제본 인스턴스는 Aurora MySQL 3.04 미만 버전에 기본적으로 단일 스레드 복제를 사용합니다. 다중 스레드 복제를 사용 설정하려면 `replica_parallel_workers` 파라미터를 사용자 지정 파라미터 그룹에서 `1`보다 큰 값으로 업데이트합니다.
Aurora MySQL 버전 3.04 이상에서는 복제가 기본적으로 다중 스레드로 설정되며 `replica_parallel_workers`가 `4`로 설정됩니다. 사용자 지정 파라미터 그룹에서 이 파라미터를 수정할 수 있습니다.
예기치 않은 중단에 대한 데이터베이스의 복원력을 높이려면 소스에서 GTID 복제를 사용 설정하고 복제본에서 GTID를 허용하는 것이 좋습니다. GTID 복제를 허용하려면 소스와 복제본 모두에서 `gtid_mode`를 `ON_PERMISSIVE`로 설정합니다. GTID 기반 복제에 대한 자세한 내용은 [GTID 기반 복제 사용](mysql-replication-gtid.md) 단원을 참조하십시오.
다음 구성 옵션을 사용하면 다중 스레드 복제를 세부 조정할 수 있습니다. 사용 정보는 *MySQL 참조 설명서*의 [복제, 이진 로깅 옵션 및 변수](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html)를 참조하세요. 다중 스레드 복제에 대한 자세한 내용은 MySQL 블로그 [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/) 섹션을 참조하시기 바랍니다.
최적의 파라미터 값은 여러 요인에 따라 달라집니다. 예를 들어 이진 로그 복제의 성능은 데이터베이스 워크로드 특성과 복제본이 실행 중인 DB 인스턴스 클래스의 영향을 받습니다. 따라서 프로덕션 인스턴스에 새 파라미터 설정을 적용하기 전에 이러한 구성 파라미터에 대한 모든 변경 사항을 철저히 테스트하는 것이 좋습니다.
+ `binlog_format recommended value` - 로 설정됨`ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking` - 권장 값은 `WRITESET`입니다.
+ `replica_preserve_commit_order`
+ `replica_parallel_type` - 권장 값은 `LOGICAL_CLOCK`입니다.
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction` - 권장 값은 `XXHASH64`입니다.
스키마 및 워크로드 특성은 병렬 복제에 영향을 미치는 요소입니다. 가장 일반적인 요소는 다음과 같습니다.
+ 프라이머리 키 없음 - RDS는 프라이머리 키가 없는 테이블에 대한 쓰기 세트 종속성을 설정할 수 없습니다. `ROW` 형식을 사용하면 소스에서 단일 전체 테이블 스캔으로 단일 다중 행 스테이트먼트를 수행할 수 있지만 복제본에서 행당 하나의 전체 테이블 스캔이 수정됩니다. 프라이머리 키가 없으면 복제 처리량이 크게 줄어듭니다.
+ 외부 키의 존재 - 외부 키가 있는 경우 Amazon RDS는 FK 관계의 테이블 병렬화에 쓰기 세트 종속성을 사용할 수 없습니다.
+ 트랜잭션 크기 - 단일 트랜잭션이 수십 또는 수백 메가바이트 또는 기가바이트에 걸쳐 있는 경우 작업자 스레드 중 하나와 조정자 스레드에서 해당 트랜잭션만 처리하는 데 오랜 시간이 걸릴 수 있습니다. 이 기간 동안 다른 모든 작업자 스레드는 이전 트랜잭션 처리를 완료한 후에도 유휴 상태로 유지될 수 있습니다.
Aurora MySQL 버전 3.06 이상에서는 보조 인덱스가 두 개 이상인 대규모 테이블의 트랜잭션을 복제할 때 binlog 복제본의 성능을 개선할 수 있습니다. 이 기능은 binlog 복제본에서 보조 인덱스 변경 사항을 병렬로 적용하는 스레드 풀을 도입합니다. 이 기능은 보조 인덱스 변경 사항을 적용하는 데 사용할 수 있는 총 병렬 스레드 수를 제어하는 `aurora_binlog_replication_sec_index_parallel_workers` DB 클러스터 파라미터에 의해 제어됩니다. 기본적으로 파라미터는 `0`(비활성화됨)로 설정됩니다. 이 기능을 활성화해도 인스턴스를 다시 시작할 필요가 없습니다. 이 기능을 활성화하려면 진행 중인 복제를 중지하고 원하는 수의 병렬 작업자 스레드를 설정한 다음 복제를 다시 시작하세요.
## binlog 복제 최적화
Aurora MySQL 2.10 이상에서 Aurora는 binlog I/O 캐시라는 최적화를 바이너리 로그 복제에 자동으로 적용합니다. 이 최적화는 가장 최근에 커밋된 binlog 이벤트를 캐싱하여 binlog 덤프 스레드 성능을 개선하고 binlog 소스 인스턴스에 대한 포그라운드 트랜잭션에 미치는 영향을 제한하도록 설계되었습니다.
**참고**
이 기능에 사용되는 메모리는 MySQL `binlog_cache` 설정과 독립적입니다.
이 기능은 `db.t2` 및 `db.t3` 인스턴스 클래스를 사용하는 Aurora DB 인스턴스에는 적용되지 않습니다.
이 최적화를 켜기 위해 구성 파라미터를 조정할 필요가 없습니다. 특히 이전 Aurora MySQL 버전에서 구성 파라미터 `aurora_binlog_replication_max_yield_seconds`를 0이 아닌 값으로 조정한 경우 현재 사용 가능한 버전에서 0으로 다시 설정하세요.
상태 변수 `aurora_binlog_io_cache_reads` 및 `aurora_binlog_io_cache_read_requests`는 binlog I/O 캐시의 데이터를 읽는 빈도를 모니터링하는 데 도움이 됩니다.
+ `aurora_binlog_io_cache_read_requests`는 캐시의 binlog I/O 읽기 요청 수를 보여줍니다.
+ `aurora_binlog_io_cache_reads`는 캐시의 정보를 검색하는 binlog I/O 읽기 수를 보여줍니다.
다음 SQL 쿼리는 캐시된 정보를 활용하는 binlog 읽기 요청의 백분율을 계산합니다. 이 경우 비율이 100에 가까울수록 더 좋습니다.
```
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 |
+---------------------------+
```
binlog I/O 캐시 기능에는 binlog 덤프 스레드와 관련된 새로운 지표도 포함됩니다. *덤프 스레드*는 새로운 binlog 복제본이 binlog 소스 인스턴스에 연결될 때 생성되는 스레드입니다.
덤프 스레드 지표는 60초 간격으로 접두사 `[Dump thread metrics]`를 사용하여 데이터베이스 로그에 인쇄됩니다. 지표에는 `Secondary_id`, `Secondary_uuid`, binlog 파일 이름 및 각 복제본에서 읽는 중인 위치와 같은 각 binlog 복제본에 대한 정보가 포함됩니다. 지표에는 복제 소스와 복제본 간의 거리(바이트)를 나타내는 `Bytes_behind_primary`도 포함됩니다. 이 지표는 복제본 I/O 스레드의 지연을 측정합니다. 이 수치는 binlog 복제본에서 `seconds_behind_master` 지표로 표시되는 복제본 SQL 적용자 스레드의 지연과 다릅니다. 이 거리의 감소 또는 증가를 확인하여 binlog 복제본이 소스를 따라 잡고 있는지, 뒤쳐지지 않는지 확인할 수 있습니다.
## 인 메모리 릴레이 로그
Aurora MySQL 버전 3.10 이상에서 Aurora는 복제 처리량을 개선하기 위해 인 메모리 릴레이 로그라고 하는 최적화를 도입합니다. 이 최적화는 메모리의 모든 중간 릴레이 로그 콘텐츠를 캐싱하여 릴레이 로그 I/O 성능을 향상시킵니다. 따라서 릴레이 로그 콘텐츠가 메모리에서 쉽게 액세스할 수 있으므로 스토리지 I/O 작업을 최소화하여 커밋 지연 시간을 줄입니다.
기본적으로 인 메모리 릴레이 로그 기능은 복제본이 다음 구성 중 하나를 충족할 때 Aurora 관리형 복제 시나리오(블루/그린 배포, Aurora-Aurora 복제 및 리전 간 복제본 포함)에 대해 자동으로 활성화됩니다.
+ 단일 스레드 복제 모드(replica\$1parallel\$1workers = 0)
+ GTID 모드가 활성화된 다중 스레드 복제:
+ 자동 위치 활성화
+ 복제본에서 GTID 모드가 ON으로 설정됨
+ replica\$1preserve\$1commit\$1order = ON인 파일 기반 복제
인 메모리 릴레이 로그 기능은 t3.large보다 큰 인스턴스 클래스에서 지원되지만 Aurora Serverless 인스턴스에서는 사용할 수 없습니다. 릴레이 로그 원형 버퍼의 고정 크기는 128MB입니다. 이 기능의 메모리 사용량을 모니터링하기 위해 다음 쿼리를 실행할 수 있습니다.
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
인 메모리 릴레이 로그 기능은 DB 클러스터 또는 인스턴스 수준에서 설정할 수 있는 aurora\$1in\$1memory\$1relaylog 파라미터에 의해 제어됩니다. 인스턴스를 다시 시작하지 않고도 이 기능을 동적으로 활성화하거나 비활성화할 수 있습니다.
1. 진행 중인 복제 중지
1. 파라미터 그룹에서 aurora\$1in\$1memory\$1relaylog를 ON(활성화) 또는 OFF(비활성화)로 설정합니다.
1. 복제 다시 시작
예제:
```
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;
```
aurora\$1in\$1memory\$1relaylog가 ON으로 설정된 경우에도 특정 조건에서는 인 메모리 릴레이 로그 기능이 비활성화될 수 있습니다. 다음 명령을 사용하여 기능의 현재 상태를 확인할 수도 있습니다.
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
기능이 예기치 않게 비활성화된 경우 다음을 실행하여 이유를 식별할 수 있습니다.
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
이 명령은 기능이 현재 비활성화된 이유를 설명하는 메시지를 반환합니다.
# Aurora MySQL에 대해 향상된 binlog 설정
향상된 binlog는 binlog를 켜서 발생하는 컴퓨팅 성능 오버헤드를 줄여 주는데, 이 오버헤드는 경우에 따라 최대 50% 까지 증가할 수 있습니다. 향상된 binlog를 사용하면 이러한 오버헤드를 약 13%로 줄일 수 있습니다. 오버헤드를 줄이기 위해 향상된 binlog는 바이너리 로그와 트랜잭션 로그를 스토리지에 병렬식으로 기록하여 트랜잭션 커밋 시 기록되는 데이터를 최소화합니다.
또한 향상된 binlog를 사용하면 커뮤니티 MySQL binlog에 비해 다시 시작 및 장애 조치 후 데이터베이스 복구 시간이 최대 99% 향상됩니다. 향상된 binlog는 기존 binlog 기반 워크로드와 호환되며 커뮤니티 MySQL binlog와 상호 작용하는 것과 동일한 방식으로 상호 작용합니다.
향상된 binlog는 Aurora MySQL 버전 3.03.1 이상에서 사용할 수 있습니다.
**Topics**
+ [향상된 binlog 파라미터 구성](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [기타 관련 파라미터](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [향상된 binlog와 커뮤니티 MySQL binlog의 차이점](#AuroraMySQL.Enhanced.binlog.differences)
+ [향상된 빈로그를 위한 Amazon CloudWatch 지표](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [향상된 빈로그의 제한 사항](#AuroraMySQL.Enhanced.binlog.limitations)
## 향상된 binlog 파라미터 구성
향상된 binlog 파라미터를 켜거나 끄면 커뮤니티 MySQL binlog와 향상된 binlog 간에 전환할 수 있습니다. 기존 binlog 소비자는 binlog 파일 시퀀스의 공백 없이 binlog 파일을 계속 읽고 사용할 수 있습니다.
향상된 binlog를 켜려면 다음 파라미터를 설정합니다.
| 파라미터 | Default | 설명 |
| --- | --- | --- |
| binlog\$1format | – | binlog\$1format 파라미터를 원하는 바이너리 로깅 형식으로 설정하여 향상된 binlog를 켭니다. binlog\$1format parameter가 OFF로 설정되어 있지 않은지 확인하세요. 자세한 내용은 [Aurora MySQL 이진 로깅 구성](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html)을 참조하세요. |
| aurora\$1enhanced\$1binlog | 0 | Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 이 파라미터를 1로 설정합니다. 이 파라미터의 값을 변경할 때 DBClusterParameterGroupStatus 값이 pending-reboot로 표시되면 라이터 인스턴스를 재부팅해야 합니다. |
| binlog\$1backup | 1 | 향상된 binlog를 켜려면 이 파라미터를 끄세요. 이렇게 하려면 이 파라미터의 값을 0으로 설정합니다. |
| binlog\$1replication\$1globaldb | 1 | 향상된 binlog를 켜려면 이 파라미터를 끄세요. 이렇게 하려면 이 파라미터의 값을 0으로 설정합니다. |
**중요**
향상된 binlog를 사용하는 경우에만 `binlog_backup` 및 `binlog_replication_globaldb` 파라미터를 끌 수 있습니다.
향상된 binlog를 끄려면 다음 파라미터를 설정합니다.
| 파라미터 | 설명 |
| --- | --- |
| aurora\$1enhanced\$1binlog | Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 이 파라미터를 0로 설정합니다. 이 파라미터의 값을 변경할 때 DBClusterParameterGroupStatus 값이 pending-reboot로 표시되면 라이터 인스턴스를 재부팅해야 합니다. |
| binlog\$1backup | 향상된 binlog를 끄려면 이 파라미터를 켜세요. 이렇게 하려면 이 파라미터의 값을 1으로 설정합니다. |
| binlog\$1replication\$1globaldb | 향상된 binlog를 끄려면 이 파라미터를 켜세요. 이렇게 하려면 이 파라미터의 값을 1으로 설정합니다. |
향상된 binlog가 켜져 있는지 확인하려면 MySQL 클라이언트에서 다음 명령을 사용하세요.
```
mysql>show status like 'aurora_enhanced_binlog';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)
```
향상된 binlog가 켜져 있을 경우 `aurora_enhanced_binlog`에 대한 출력이 `ACTIVE`로 표시됩니다.
## 기타 관련 파라미터
향상된 binlog를 켜면 다음 파라미터가 영향을 받습니다.
+ `max_binlog_size` 파라미터는 표시되지만 수정할 수는 없습니다. 향상된 binlog가 켜지면 기본값 `134217728`이 `268435456`으로 자동 조정됩니다.
+ 커뮤니티 MySQL binlog와 달리 향상된 binlog가 켜져 있을 때는 `binlog_checksum`이 동적 파라미터로 작동하지 않습니다. 이 파라미터에 대한 변경 사항을 적용하려면 `ApplyMethod`가 `immediate`인 경우에도 DB 클러스터를 수동으로 재부팅해야 합니다.
+ 향상된 binlog가 켜져 있을 때는 `binlog_order_commits` 파라미터에 설정한 값이 커밋 순서에 영향을 주지 않습니다. 커밋은 성능에 더 이상 영향을 주지 않고 항상 순서가 지정됩니다.
## 향상된 binlog와 커뮤니티 MySQL binlog의 차이점
향상된 binlog는 커뮤니티 MySQL binlog와 비교할 때 복제, 백업 및 Aurora Global Database와 다르게 상호 작용합니다. 향상된 binlog를 사용하기 전에 다음과 같은 차이점을 이해하는 것이 좋습니다.
+ 소스 DB 클러스터의 향상된 binlog 파일은 복제된 DB 클러스터에서 사용할 수 없습니다.
+ 향상된 binlog 파일은 Aurora 백업에 포함되지 않습니다. 따라서 DB 클러스터를 복원한 후에는 보존 기간이 설정되어 있더라도 소스 DB 클러스터의 향상된 binlog 파일을 사용할 수 없습니다.
+ Aurora 글로벌 데이터베이스와 함께 사용하면 프라이머리 DB 클러스터의 향상된 binlog 파일이 보조 리전의 DB 클러스터에 복제되지 않습니다.
****예시****
다음 예는 향상된 binlog와 커뮤니티 MySQL binlog 간의 차이점을 설명합니다.
**복원되거나 복제된 DB 클러스터에서**
향상된 binlog가 켜져 있으면 복원되거나 복제된 DB 클러스터에서 이전 binlog 파일을 사용할 수 없습니다. 복원 또는 복제 작업 후 binlog가 켜져 있으면 새 DB 클러스터는 1(mysql-bin-changelog.000001)부터 고유한 binlog 파일 시퀀스를 쓰기 시작합니다.
복원 또는 복제 작업 후에 향상된 binlog를 켜려면 복원되거나 복제된 DB 클러스터에서 필요한 DB 클러스터 파라미터를 설정하세요. 자세한 내용은 [향상된 binlog 파라미터 구성](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters) 단원을 참조하십시오.
**Example 예제: 향상된 binlog가 켜져 있을 때 수행되는 복제 또는 복원 작업**
소스 DB 클러스터:
```
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)
```
복원되거나 복제된 DB 클러스터에서는 향상된 binlog가 켜져 있을 때 binlog 파일이 백업되지 않습니다. binlog 데이터의 불연속성을 방지하기 위해 향상된 binlog를 켜기 전에 작성한 binlog 파일도 사용할 수 없습니다.
```
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 예제: 향상된 binlog가 꺼져 있을 때 수행되는 복제 또는 복원 작업**
소스 DB 클러스터:
```
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는 `mysql-bin-changelog.000003` 이후에 비활성화됩니다. 복원되거나 복제된 DB 클러스터에서는 향상된 binlog를 끈 후에 작성한 binlog 파일을 사용할 수 있습니다.
```
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)
```
**Amazon Aurora Global Database에서**
Amazon Aurora Global Database에서는 프라이머리 DB 클러스터의 binlog 데이터가 보조 DB 클러스터에 복제되지 않습니다. 크로스 리전 장애 조치 프로세스 후에는 새로 승격된 프라이머리 DB 클러스터에서 binlog 데이터를 사용할 수 없습니다. binlog가 켜져 있으면 새로 승격된 DB 클러스터는 1(mysql-bin-changelog.000001)부터 고유한 binlog 파일 시퀀스를 시작합니다.
장애 조치 후 향상된 binlog를 켜려면 보조 DB 클러스터에서 필수 DB 클러스터 파라미터를 설정해야 합니다. 자세한 내용은 [향상된 binlog 파라미터 구성](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters) 단원을 참조하십시오.
**Example 예제: 향상된 binlog가 켜져 있을 때 글로벌 데이터베이스 장애 조치 작업이 수행됩니다.**
이전 프라이머리 DB 클러스터(장애 조치 전):
```
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)
```
새 프라이머리 DB 클러스터(장애 조치 후):
향상된 binlog가 켜져 있을 때 binlog 파일은 보조 리전에 복제되지 않습니다. binlog 데이터의 불연속성을 방지하기 위해 향상된 binlog를 켜기 전에 작성한 binlog 파일은 사용할 수 없습니다.
```
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 예제: 향상된 binlog가 꺼져 있을 때 글로벌 데이터베이스 장애 조치 작업이 수행됩니다.**
소스 DB 클러스터:
```
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)
```
**복원되거나 복제된 DB 클러스터:**
향상된 binlog는 `mysql-bin-changelog.000003` 이후에 비활성화됩니다. 향상된 binlog를 끈 후 작성된 binlog 파일은 복제되며 새로 승격된 DB 클러스터에서 사용할 수 있습니다.
```
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)
```
## 향상된 빈로그를 위한 Amazon CloudWatch 지표
다음 Amazon CloudWatch 지표는 향상된 binlog가 켜진 경우에만 게시됩니다.
| CloudWatch 지표 | 설명 | 단위 |
| --- | --- | --- |
| ChangeLogBytesUsed | 향상된 binlog가 사용하는 스토리지 양입니다. | 바이트 |
| ChangeLogReadIOPs | 5분 간격 내에 향상된 binlog에서 수행된 읽기 I/O 작업의 수입니다. | 5분당 개수 |
| ChangeLogWriteIOPs | 5분 간격 내에 향상된 binlog에서 수행된 쓰기 디스크 I/O 작업의 수입니다. | 5분당 개수 |
## 향상된 빈로그의 제한 사항
향상된 binlog가 켜져 있는 경우 Amazon Aurora DB 클러스터에 다음과 같은 제한 사항이 적용됩니다.
+ 향상된 binlog는 Aurora MySQL 버전 3.03.1 이상에서만 지원됩니다.
+ 프라이머리 DB 클러스터에 작성된 향상된 binlog 파일은 복제되거나 복원된 DB 클러스터에 복사되지 않습니다.
+ Amazon Aurora Global Database와 함께 사용하면 프라이머리 DB 클러스터의 향상된 binlog 파일이 보조 DB 클러스터에 복제되지 않습니다. 따라서 장애 조치 프로세스 후에는 이전 binlog 데이터를 새 프라이머리 DB 클러스터에서 사용할 수 없습니다.
+ 다음 binlog 구성 파라미터는 무시됩니다.
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_max_flush_queue_time`
+ 데이터베이스에서 손상된 테이블을 삭제하거나 이름을 바꿀 수 없습니다. 이 테이블을 삭제하려면 지원에 문의하세요.
+ 향상된 binlog가 켜지면 binlog I/O 캐시가 비활성화됩니다. 자세한 내용은 [Aurora MySQL의 이진수 로그 복제 최적화](binlog-optimization.md) 단원을 참조하십시오.
**참고**
향상된 binlog는 binlog I/O 캐시와 유사한 읽기 성능 향상 및 더 나은 쓰기 성능 개선을 제공합니다.
+ 역추적 기능은 지원되지 않습니다. 다음과 같은 조건에서는 향상된 binlog를 DB 클러스터에서 켤 수 없습니다.
+ 현재 역추적 기능이 활성화된 DB 클러스터.
+ 이전에 역추적 기능이 활성화되었지만 비활성화되지 않은 DB 클러스터
+ 역추적 기능이 활성화된 소스 DB 클러스터 또는 스냅샷에서 복원된 DB 클러스터.
# GTID 기반 복제 사용
아래 내용에서는 Aurora MySQL 클러스터와 외부 소스 간 이진 로그(binlog) 복제를 통해 전역 트랜잭션 식별자(GTID)를 사용하는 방법이 나와 있습니다.
**참고**
Aurora의 경우 외부 MySQL 데이터베이스로 또는 외부 MySQL 데이터베이스로부터 binlog 복제를 사용하는 Aurora MySQL 클러스터에서만 이 기능을 사용할 수 있습니다. 다른 데이터베이스는 Amazon RDS MySQL 인스턴스, 온프레미스 MySQL 데이터베이스 또는 다른 AWS 리전의 Aurora DB 클러스터일 수 있습니다. 이러한 종류의 복제를 구성하는 방법에 대해 알아보려면 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 단원을 참조하세요.
binlog 복제를 사용하고 있지만 MySQL을 사용한 GTID 기반 복제에 대해 잘 알지 못하는 경우 MySQL 설명서의 [전역 트랜잭션 식별자를 사용한 복제](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html)를 참조하세요.
Aurora MySQL 버전 2 및 3에서 GTID 기반 복제가 지원됩니다.
**Topics**
+ [전역 트랜잭션 식별자(GTID) 개요](#mysql-replication-gtid.overview)
+ [GTID 기반 복제 파라미터](#mysql-replication-gtid.parameters)
+ [Aurora MySQL 클러스터에 대한 GTID 기반 복제 활성화](mysql-replication-gtid.configuring-aurora.md)
+ [Aurora MySQL DB 클러스터에 대해 GTID 기반 복제 비활성화](mysql-replication-gtid.disabling.md)
## 전역 트랜잭션 식별자(GTID) 개요
*전역 트랜잭션 ID(GTIDs)* are unique identifiers generated for committed MySQL transactions. GTID를 사용해 binlog 복제 관련 문제를 더 간편하게 해결할 수 있습니다.
**참고**
Aurora가 클러스터 내 DB 인스턴스 간에 데이터를 동기화하는 경우 이 복제 메커니즘은 이진 로그(binlog)를 수반하지 않습니다. Aurora MySQL의 경우 GTID 기반 복제는 binlog 복제를 사용해 외부 MySQL 호환 데이터베이스로부터 Aurora MySQL DB 클러스터 안 또는 밖으로 복제할 때만 적용됩니다.
MySQL은 binlog 복제에 다음 두 가지 유형의 트랜잭션을 사용합니다.
+ *GTID 트랜잭션* – GTID로 식별되는 트랜잭션.
+ *익명 트랜잭션* – GTID가 할당되지 않은 트랜잭션.
복제 구성의 GTID는 모든 DB 인스턴스에서 고유합니다. GTID를 사용하면 로그 파일 위치를 참조할 필요가 없기 때문에 복제 구성이 간편해집니다. 또한 GTID를 사용하면 복제된 트랜잭션을 추적하고 소스 인스턴스 및 복제본이 일치하는지를 쉽게 확인할 수 있습니다.
외부 MySQL 호환 데이터베이스에서 Aurora 클러스터로 복제할 때 일반적으로 Aurora에서 GTID 기반 복제를 사용합니다. 온프레미스 또는 Amazon RDS 데이터베이스를 Aurora MySQL로 마이그레이션하는 절차의 일부로 이 복제 구성을 설정할 수 있습니다. 외부 데이터베이스에서 이미 GTID를 사용하는 경우 Aurora 클러스터에 대해 GTID 기반 복제를 활성화하면 복제 프로세스가 간소화됩니다.
먼저 DB 클러스터 파라미터 그룹에 있는 해당 구성 파라미터를 설정하여 Aurora MySQL 클러스터에 대해 GTID 기반 복제를 구성합니다. 그런 다음 이 파라미터 그룹을 클러스터와 연결합니다.
## GTID 기반 복제 파라미터
다음 파라미터를 사용하여 GTID 기반 복제를 구성할 수 있습니다.
| 파라미터 | 유효한 값 | 설명 |
| --- | --- | --- |
| `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF`는 새 트랜잭션을 익명 트랜잭션(GTID가 없음)으로 지정하며, 트랜잭션을 복제하려면 익명이어야 합니다. `OFF_PERMISSIVE`는 새 트랜잭션을 익명 트랜잭션(GTID가 없음)으로 지정하지만, 모든 트랜잭션을 복제할 수 있습니다. `ON_PERMISSIVE`는 새 트랜잭션을 GTID 트랜잭션으로 지정하지만, 모든 트랜잭션을 복제할 수 있습니다. `ON`은 새 트랜잭션을 GTID 트랜잭션으로 지정하고, 트랜잭션을 복제하려면 GTID 트랜잭션이어야 합니다. |
| `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF`는 트랜잭션이 GTID 일관성을 위반하는 것을 허용합니다. `ON`은 트랜잭션이 GTID 일관성을 위반하지 않도록 합니다. `WARN`은 트랜잭션이 GTID 일관성을 위반하는 것을 허용하지만, 위반이 발생할 경우 경고를 생성합니다. |
**참고**
AWS Management Console 콘솔에서 `gtid_mode` 파라미터는 `gtid-mode`로 표시됩니다.
GTID 기반 복제의 경우 Aurora MySQL DB 클러스터의 DB 클러스터 파라미터 그룹에 대해 이 설정을 사용하십시오.
+ `ON` 및 `ON_PERMISSIVE`는 Aurora MySQL 클러스터에서 밖으로 복제하는 경우에만 적용됩니다. 이 두 값으로 인해 외부 데이터베이스로 복제되는 트랜잭션에 대해 Aurora DB 클러스터가 GTID를 사용하게 됩니다. `ON`은 외부 데이터베이스에서도 GTID 기반 복제를 사용할 것을 요구합니다. `ON_PERMISSIVE`로 인해 외부 데이터베이스에서 GTID 기반 복제는 선택 사항이 됩니다.
+ `OFF_PERMISSIVE`가 설정된 경우 이는 Aurora DB 클러스터가 외부 데이터베이스에서 안으로 복제하는 것을 수락할 수 있음을 뜻합니다. 외부 데이터베이스가 GTID 기반 복제를 사용하든 사용하지 않든 이렇게 할 수 있습니다.
+ `OFF`가 설정된 경우 이는 Aurora DB 클러스터가 GTID 기반 복제를 사용하지 않는 외부 데이터베이스에서 안으로 복제하는 것만을 수락할 수 있음을 뜻합니다.
**작은 정보**
안으로 복제하는 것은 Aurora MySQL 클러스터에 가장 흔한 binlog 복제 시나리오입니다. 안으로 복제하는 경우 GTID 모드를 `OFF_PERMISSIVE`로 설정하는 것이 좋습니다. 이 설정을 통해 복제 원본의 GTID 설정에 관계없이 외부 데이터베이스에서 안으로 복제하는 것이 가능해집니다.
파라미터 그룹에 대한 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오.
# Aurora MySQL 클러스터에 대한 GTID 기반 복제 활성화
GTID 기반 복제가 Aurora MySQL DB 클러스터에 대해 활성화되면 GTID 설정은 인바운드 및 아웃바운드 binlog 복제본 모두에 적용됩니다.
**Aurora MySQL 클러스터에 대한 GTID 기반 복제를 활성화하려면**
1. 다음 파라미터 설정을 사용해 DB 클러스터 파라미터 그룹을 생성 또는 편집하십시오.
+ `gtid_mode` – `ON` 또는 `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
1. DB 클러스터 파라미터 그룹을 Aurora MySQL 클러스터와 연결합니다. 이 작업을 수행하려면 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md)의 절차를 따르세요.
1. (선택 사항) GTID를 포함하지 않는 트랜잭션에 GTID를 할당하는 방법을 지정합니다. 이렇게 하려면 [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions(Aurora MySQL 버전 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions)에서 저장 프로시저를 호출하면 됩니다.
# Aurora MySQL DB 클러스터에 대해 GTID 기반 복제 비활성화
Aurora MySQL DB 클러스터에 대한 GTID 기반 복제를 비활성화합니다. 이렇게 하면 Aurora 클러스터가 GTID 기반 복제를 사용하는 외부 데이터베이스에 대해 인바운드 또는 아웃바운드 binlog 복제를 수행할 수 없습니다.
**참고**
다음 절차에서 *읽기 전용 복제본*은 외부 데이터베이스로의 또는 외부 데이터베이스로부터의 binlog 복제를 포함한 Aurora 구성의 복제 대상을 의미합니다. 읽기 전용 Aurora 복제본 DB 인스턴스를 뜻하는 것은 아닙니다. 예를 들어 Aurora 클러스터가 외부 원본에서 안으로의 복제를 수락하는 경우 Aurora 기본 인스턴스는 binlog 복제에 대해 읽기 전용 복제본의 역할을 합니다.
이 단원에 언급된 저장 프로시저에 대한 자세한 내용은 [Aurora MySQL 저장 프로시저 참조](AuroraMySQL.Reference.StoredProcs.md) 단원을 참조하십시오.
**Aurora MySQL DB 클러스터에 대해 GTID 기반 복제를 비활성화하려면**
1. Aurora 복제본에서 다음 프로시저를 실행합니다.
버전 3의 경우
```
CALL mysql.rds_set_source_auto_position(0);
```
버전 2의 경우
```
CALL mysql.rds_set_master_auto_position(0);
```
1. `gtid_mode`를 `ON_PERMISSIVE`로 재설정합니다.
1. Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 `gtid_mode`가 `ON_PERMISSIVE`로 설정되어 있는지 확인합니다.
파라미터 그룹을 사용한 구성 파라미터 설정에 대한 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오.
1. Aurora MySQL 클러스터를 다시 시작합니다
1. `gtid_mode`를 `OFF_PERMISSIVE`로 재설정합니다.
1. Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 `gtid_mode`가 `OFF_PERMISSIVE`로 설정되어 있는지 확인합니다.
1. Aurora MySQL 클러스터를 다시 시작합니다
1. Aurora 기본 인스턴스에서 모든 GTID 트랜잭션이 적용될 때까지 기다립니다. 이러한 사항이 적용되었는지 확인하려면 다음 단계를 수행합니다.
1. Aurora 기본 인스턴스에서 `SHOW MASTER STATUS` 명령을 실행합니다.
출력이 다음 출력과 유사해야 합니다.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
출력에서 파일 및 위치를 메모합니다.
1. 각 읽기 전용 복제본에서 이전 단계의 소스 인스턴스의 파일 및 위치 정보를 사용하여 다음 쿼리를 실행합니다.
버전 3의 경우
```
SELECT SOURCE_POS_WAIT('file', position);
```
버전 2의 경우
```
SELECT MASTER_POS_WAIT('file', position);
```
예를 들어 파일 이름이 `mysql-bin-changelog.000031`이고 위치가 `107`일 경우 다음 문을 실행합니다.
버전 3의 경우
```
SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107);
```
버전 2의 경우
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
1. GTID 기반 복제를 비활성화하도록 GTID 파라미터를 재설정합니다.
1. Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 다음과 같이 파라미터가 설정되어 있는지 확인합니다.
+ `gtid_mode` – `OFF`
+ `enforce_gtid_consistency` – `OFF`
1. Aurora MySQL 클러스터를 다시 시작합니다