# 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 인스턴스에 대한 이진 로깅을 직접 설정할 수 없지만, 다음 중 하나를 수행하여 설정할 수 있습니다.+ DB 인스턴스의 자동 백업을 설정합니다. DB 인스턴스를 생성할 때 자동 백업을 설정하거나 기존 DB 인스턴스를 수정하여 백업을 설정할 수 있습니다. 자세한 내용은 *Amazon RDS 사용 설명서*의 [DB 인스턴스 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html) 단원을 참조하세요.
+ DB 인스턴스의 읽기 전용 복제본을 생성합니다. 자세한 내용은 *Amazon RDS 사용 설명서*의 [읽기 전용 복제본 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)을 참조하십시오. | | MySQL(외부) | **암호화된 복제 설정**
Aurora MySQL 버전 2를 사용하여 데이터를 안전하게 복제하려면 암호화된 복제를 사용하세요. 암호화된 복제를 사용할 필요가 없다면 이 단계를 건너 뛸 수 있습니다.
다음은 암호화된 복제를 사용하기 위한 사전 조건입니다.+ 외부 MySQL 소스 데이터베이스에서 SSL(Secure Socket Layer)를 활성화해야 합니다.
+ Aurora MySQL DB 클러스터에 대해 클라이언트 키와 클라이언트 인증서를 준비해야 합니다.
암호화 복제 중, Aurora MySQL DB 클러스터는 MySQL 데이터베이스 서버의 클라이언트 역할을 합니다. Aurora MySQL 클라이언트 인증서와 키는 .pem 형식의 파일입니다.1. 암호화 복제를 준비해야 합니다. 외부 MySQL 소스 데이터베이스에서 SSL을 설정하지 않고 클라이언트 키와 클라이언트 인증서가 준비되지 않은 경우 MySQL 데이터베이스 서버의 SSL을 설정하고 필요한 클라이언트 키와 클라이언트 인증서를 생성합니다. 외부 소스에 SSL이 활성화되어 있으면 Aurora MySQL DB 클러스터에 클라이언트 키와 인증서를 제공합니다. 인증서와 키가 없다면, Aurora MySQL DB 클러스터에 대해 새 키와 인증서를 생성합니다. 클라이언트 인증서에 서명하려면, 외부 MySQL 소스 데이터베이스의 SSL을 구성할 때 사용하는 인증 기관(CA) 키가 있어야 합니다.
자세한 내용은 MySQL 설명서의 [openssl을 사용하여 SSL 인증서 및 키 생성](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html)을 참조하십시오.
인증 기관(CA) 인증서, 클라이언트 키, 클라이언트 인증서가 필요합니다.
2. SSL을 사용하여 마스터 사용자로 Aurora MySQL DB 클러스터에 연결하십시오.
SSL을 이용한 Aurora MySQL DB 클러스터 연결에 대한 자세한 정보는 [Aurora MySQL DB 클러스터에 대한 TLS 연결](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)를 참조하십시오.
3. `mysql.rds_import_binlog_ssl_material` 저장 프로시저를 실행하여 Aurora MySQL DB 클러스터로 SSL 정보를 가져오십시오.
`ssl_material_value` 파라미터에서, Aurora MySQL DB 클러스터의 정보를 올바른 JSON 페이로드에 삽입하십시오.
다음은 Aurora MySQL DB 클러스터에 SSL 정보를 가져오는 예제입니다. .pem 형식 파일은 본문 코드의 길이가 일반적으로 예제의 본문 코드 길이보다 깁니다. 
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');

자세한 내용은 [mysql.rds\_import\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) 및 [Aurora MySQL DB 클러스터에 대한 TLS 연결](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)(을)를 참조하세요. 프로시저를 실행한 후 파일에 암호를 저장합니다. 이 파일을 나중에 삭제하려면 [mysql.rds\_remove\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material) 저장 프로시저를 실행하면 됩니다.
**외부 MySQL 데이터베이스에 대한 이진 로깅을 설정하려면** 1. 명령 셸에서 mysql 서비스를 중지합니다. 
sudo service mysqld stop

2. `my.cnf` 파일을 편집합니다(이 파일은 보통 `/etc`에 있음). 
sudo vi /etc/my.cnf

`log_bin` 및 `server_id` 옵션을 `[mysqld]` 섹션에 추가합니다. `log_bin` 옵션은 이진 로그 파일에 대한 파일 이름 식별자를 제공합니다. `server_id` 옵션은 소스-복제본 관계에서 서버의 고유 식별자를 제공합니다.
암호화된 복제가 필요 없는 경우 binlog를 활성화하고 SSL을 설정하여 외부 MySQL 데이터베이스를 시작합니다.
다음은 암호화된 데이터와 관련된 `/etc/my.cnf` 파일 항목들입니다. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

암호화된 복제가 필요하다면, SSL과 binlogs를 활성화시켜 외부 MySQL 데이터베이스를 시작합니다.
`/etc/my.cnf` 파일 항목에는 MySQL 데이터베이스 서버의 .pem 파일 위치가 포함되어 있습니다. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem

또한 MySQL DB 인스턴스의 `sql_mode` 옵션을 0으로 설정하거나, my.cnf 파일에 이 옵션이 포함되어서는 안 됩니다.
외부 MySQL 데이터베이스 레코드에 연결되어 있는 동안 외부 MySQL 데이터베이스의 이진수 로그 위치를 기록합니다. 
mysql> SHOW MASTER STATUS;

다음과 유사하게 출력되어야 합니다: 
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000031 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

자세한 내용은 MySQL 설명서에서 [Setting the replication source configuration](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html) 섹션을 참조하세요.
3. mysql 서비스를 시작합니다. 
sudo service mysqld start
| ## 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\_set\_configuration](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\_stop\_replication](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 클러스터의 사본을 만들려면**
다음 방법 중 한 가지를 선택하세요.+ 스냅샷에서 DB 클러스터를 복원합니다. Amazon Aurora DB 클러스터의 DB 클러스터 스냅샷을 생성합니다. 자세한 내용은 [DB 클러스터 스냅샷 생성](USER_CreateSnapshotCluster.md) 섹션을 참조하세요. 방금 만든 DB 클러스터 스냅샷에서 복원하여 새 Aurora DB 클러스터를 생성합니다.
복원된 DB 클러스터의 DB 파라미터 그룹을 원래 DB 클러스터와 동일하게 유지해야 합니다. 이렇게 해야 DB 클러스터 사본에 이진수 로깅이 활성화됩니다. 자세한 내용은 [DB 클러스터 스냅샷에서 복원](aurora-restore-snapshot.md) 섹션을 참조하세요.
+ DB 클러스터를 복제합니다. 자세한 내용은 [Aurora DB 클러스터에 대한 볼륨 복제](Aurora.Managing.Clone.md) 섹션을 참조하세요.
**binlog 파일 이름과 위치를 확인하려면**
다음 방법 중 한 가지를 선택하세요.+ AWS Management Console: **데이터베이스**를 선택하고 새로운 Aurora DB 클러스터의 기본 인스턴스(라이터)를 선택하여 세부 정보를 표시합니다. [**Recent Events**]로 스크롤합니다. binlog 파일 이름과 위치를 포함한 이벤트 메시지가 표시됩니다. 이벤트 메시지의 형식은 다음과 같습니다. 
Binlog position from crash recovery is {{binlog-file-name}} {{binlog-position}}
복제 시작 위치에 해당하는 binlog 파일 이름 및 위치 값을 저장합니다.
+ 다음 예제와 같이 [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) AWS CLI 명령을 직접적으로 호출합니다. 
aws rds describe-events

{
    "Events": [
        {
            "EventCategories": [],
            "SourceType": "db-instance",
            "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance",
            "Date": "2016-10-28T19:43:46.862Z",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278",
            "SourceIdentifier": "sample-restored-instance"
        }
    ]
}

+ MySQL 오류 로그에서 마지막 MySQL binlog 파일 위치를 확인합니다.
**Aurora MySQL DB 클러스터의 덤프를 만들려면**
복제본 대상이 외부 MySQL 데이터베이스 또는 RDS for MySQL DB 인스턴스인 경우, Aurora DB 클러스터에서 덤프 파일을 만들어야 합니다.
생성한 소스 DB 클러스터 사본에 대해 `mysqldump` 명령을 실행해야 합니다. 이는 덤프 시 잠금 고려 사항을 피하기 위한 것입니다. 원본 DB 클러스터에서 직접 덤프를 수행한 경우 덤프가 진행되는 동안 원본 테이블에 동시 쓰기가 발생하지 않도록 원본 테이블을 잠가야 합니다.1. MySQL 클라이언트를 사용하여 DB 클러스터에 연결
2. `mysqldump` 명령을 실행합니다. 예제: 
PROMPT> mysqldump --databases {{database_name}} --single-transaction
--order-by-primary -r backup.sql -u {{local_user}}s -p

3. 덤프 파일을 만든 후 DB 클러스터 사본을 삭제할 수 있습니다. | | 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) 단원을 참조하십시오.1. 읽기 전용 복제본에 연결하고 [mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 프로시저를 실행하여 복제를 중지합니다.
2. 읽기 전용 복제본이 **중지**된 동안 읽기 전용 복제본에 연결하고 `SHOW SLAVE STATUS`(Aurora MySQL 버전 2) 또는 `SHOW REPLICA STATUS`(Aurora MySQL 버전 3) 명령을 실행합니다. `Relay_Master_Log_File` 필드에서 현재 이진 로그 파일 이름을 검색하고 `Exec_Master_Log_Pos` 필드에서 로그 파일 위치를 검색합니다. 복제를 시작할 때에 대비하여 해당 값을 저장합니다.
3. 읽기 전용 복제본을 **중지됨** 상태로 유지하면서 읽기 전용 복제본의 DB 스냅샷을 생성합니다. 자세한 내용은 *Amazon Relational Database Service 사용 설명서*의 [DB 스냅샷 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) 단원을 참조하십시오.
4. 읽기 전용 복제본을 삭제합니다. | | MySQL(외부) | **외부 MySQL 데이터베이스의 스냅샷 생성**1. 덤프를 생성하기 전에 덤프의 binlog 위치가 소스 인스턴스의 최신 데이터와 일치하는지 확인해야 합니다. 이렇게 하려면 먼저 다음 명령을 사용하여 인스턴스에 대한 쓰기 작업을 중지해야 합니다. 
mysql> FLUSH TABLES WITH READ LOCK;

2. 다음과 같이 `mysqldump` 명령을 사용하여 MySQL 데이터베이스의 덤프를 생성합니다. 
PROMPT> sudo mysqldump --databases {{database_name}} --master-data=2  --single-transaction \
--order-by-primary -r backup.sql -u {{local_user}} -p

3. 덤프를 생성한 후 다음 명령을 사용하여 MySQL 데이터베이스에서 테이블의 잠금을 해제합니다. 
mysql> UNLOCK TABLES;
| ## 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 클러스터로 덤프 로드** 1. `mysqldump` 명령의 출력을 복제 소스에서 Aurora MySQL DB 클러스터에도 연결 가능한 위치로 복사합니다.
2. `mysql` 명령을 사용하여 Aurora MySQL DB 클러스터에 연결합니다. 다음은 예제입니다. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. `mysql` 프롬프트에서 `source` 명령을 실행하고 데이터베이스 덤프 파일의 이름을 전달하여 Aurora MySQL DB 클러스터로 데이터를 로드합니다. 예를 들면 다음과 같습니다. 
mysql> source backup.sql;
| | RDS for MySQL | **Amazon RDS DB 인스턴스로 덤프 로드**1. `mysqldump` 명령의 출력을 복제 소스에서 MySQL DB 인스턴스에도 연결 가능한 위치로 복사합니다.
2. `mysql` 명령을 사용하여 MySQL DB 인스턴스에 연결합니다. 다음은 예제입니다. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. `mysql` 프롬프트에서 `source` 명령을 실행하고 데이터베이스 덤프 파일의 이름을 전달하여 MySQL DB 인스턴스로 데이터를 로드합니다. 예를 들면 다음과 같습니다. 
mysql> source backup.sql;
| | MySQL(외부) | **외부 MySQL 데이터베이스로 덤프 로드**
DB 스냅샷 또는 DB 클러스터 스냅샷을 외부 MySQL 데이터베이스로 로드할 수 없습니다. 대신 `mysqldump` 명령의 출력을 사용해야 합니다.1. `mysqldump` 명령의 출력을 복제 소스에서 MySQL 데이터베이스에도 연결 가능한 위치로 복사합니다.
2. `mysql` 명령을 사용하여 MySQL 데이터베이스에 연결합니다. 다음은 예제입니다. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. `mysql` 프롬프트에서 `source` 명령을 실행하고 데이터베이스 덤프 파일의 이름을 전달하여 MySQL 데이터베이스로 데이터를 로드합니다. 다음은 예제입니다. 
mysql> source backup.sql;
| ## 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\_name\_resolve](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 클러스터에서 복제를 설정하려면** 1. 복제를 수행할 시작 위치를 찾습니다. binlog 파일 이름과 binlog 위치가 필요합니다.
DB 클러스터 복제본 대상이 다음에서 생성된 경우 DB 클러스터 스냅샷 또는 클론 - [3. 복제 소스의 사본 또는 덤프 만들기](#AuroraMySQL.Replication.MySQL.CreateSnapshot)에 나와 있듯이, 새로운 DB 클러스터의 최신 이벤트에서 binlog 파일 이름과 위치를 검색합니다. DB 스냅샷 - 복제 소스의 스냅샷을 생성했을 때 `SHOW SLAVE STATUS`(Aurora MySQL 버전 2) 또는 `SHOW REPLICA STATUS`(Aurora MySQL 버전 3) 명령에서 binlog 파일 이름과 위치를 검색했습니다.
2. DB 클러스터에 연결하고 다음 절차를 호출하여 이전 단계의 이진 로그 파일 이름 및 위치를 사용하여 복제 소스로 복제를 시작합니다. [mysql.rds\_set\_external\_source(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) [mysql.rds\_set\_external\_master(Aurora MySQL 버전 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)(모든 버전)
다음은 Aurora MySQL 버전 3에 대한 예입니다. 
CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

SSL 암호화를 사용하려면 최종 값을 `0` 대신 `1`로 설정합니다. | | RDS for MySQL | **Amazon RDS DB 인스턴스에서 복제를 설정하려면** 1. DB 스냅샷에서 DB 인스턴스 복제본 대상을 생성한 경우 복제 시작 위치에 해당하는 binlog 파일 및 binlog 위치가 필요합니다. 복제 소스의 스냅샷을 생성했을 때 `SHOW SLAVE STATUS`(Aurora MySQL 버전 2) 또는 `SHOW REPLICA STATUS`(Aurora MySQL 버전 3) 명령에서 이러한 값을 검색했습니다.
2. 복제 소스를 사용하여 복제를 시작하려면 DB 인스턴스에 연결하고 [mysql.rds\_set\_external\_master(Aurora MySQL 버전 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) 또는 [mysql.rds\_set\_external\_source(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) 및 [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 프로시저를 호출합니다. 이전 단계의 바이너리 로그 파일 이름 및 위치를 사용합니다. 다음은 예입니다. 
CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

SSL 암호화를 사용하려면 최종 값을 `0` 대신 `1`로 설정합니다. | | MySQL(외부) | **외부 MySQL 데이터베이스에서 복제를 설정하려면** 1. 복제 시작 위치에 해당하는 binlog 파일 및 binlog 위치를 검색합니다. 복제 소스의 스냅샷을 생성했을 때 `SHOW SLAVE STATUS`(Aurora MySQL 버전 2) 또는 `SHOW REPLICA STATUS`(Aurora MySQL 버전 3) 명령에서 이러한 값을 검색했습니다. `mysqldump` 명령을 `--master-data=2` 옵션과 함께 실행하여 그 출력으로 외부 MySQL 복제본 대상을 채운 경우 binlog 파일 및 binlog 위치는 출력에 포함되어 있습니다. 다음은 예입니다. 
--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;

2. 외부 MySQL 복제본 대상에 연결하고 `CHANGE MASTER TO` 및 `START SLAVE`(Aurora MySQL 버전 2) 또는 `START REPLICA`(Aurora MySQL 버전 3)를 실행하여 이전 단계의 바이너리 로그 파일 이름과 위치를 사용하여 복제 소스로 복제를 시작합니다. 
CHANGE MASTER TO
  MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com',
  MASTER_PORT = 3306,
  MASTER_USER = 'repl_user',
  MASTER_PASSWORD = 'password',
  MASTER_LOG_FILE = 'mysql-bin-changelog.000031',
  MASTER_LOG_POS = 107;
-- And one of these statements depending on your engine version:
START SLAVE; -- Aurora MySQL version 2
START REPLICA; -- Aurora MySQL version 3
| 복제가 실패하면 복제본에서 의도하지 않은 I/O가 크게 증가하여 성능이 저하될 수 있습니다. 복제가 실패하거나 더 이상 필요하지 않은 경우 [mysql.rds\_reset\_external\_master(Aurora MySQL 버전 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) 또는 [mysql.rds\_reset\_external\_source(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) 저장 프로시저를 실행하여 복제 구성을 제거할 수 있습니다. ### 읽기 전용 복제본에 대한 복제를 중지할 위치 설정 Aurora MySQL 버전 3.04 이상에서는 [mysql.rds\_start\_replication\_until(Aurora MySQL 버전 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 저장 프로시저를 사용하여 복제를 시작한 다음 지정된 이진 로그 파일 위치에서 복제를 중지할 수 있습니다. **읽기 전용 복제본에 대한 복제를 시작하고 특정 위치에서 복제를 중지하려면** 1. MySQL 클라이언트를 사용하여 Aurora MySQL DB 클러스터 복제본에 마스터 사용자로 연결합니다. 1. [mysql.rds\_start\_replication\_until(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\_start\_replication\_until\_gtid(Aurora MySQL 버전 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) 저장 프로시저 대신 [mysql.rds\_start\_replication\_until(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를 사용하여 복제 소스의 마스터 암호를 변경하는 경우 이러한 변경 사항은 복제 대상에 자동으로 복제되지 않습니다. 소스 시스템과 타겟 시스템 간에 마스터 사용자 및 마스터 비밀번호를 동기화하려는 경우 복제 타겟을 직접 동일하게 변경해야 합니다.