Aurora MySQL의 이진수 로그 복제 설정
Aurora MySQL을 사용하여 MySQL 복제를 설정하는 단계는 다음에서 자세히 설명합니다.
목차
1. 복제 소스에 대한 이진 로깅 설정
다음 데이터베이스 엔진의 복제 소스에 대한 이진 로깅을 설정하는 방법의 지침을 확인합니다.
데이터베이스 엔진 | 지침 |
---|---|
Aurora MySQL |
Aurora MySQL DB 클러스터에 대한 이진 로깅을 설정하려면
자세한 내용은 Amazon Aurora DB 클러스터와 DB 인스턴스 파라미터 및 Amazon Aurora의 파라미터 그룹 단원을 참조하세요. |
RDS for MySQL |
Amazon RDS DB 인스턴스에 대한 이진 로깅을 설정하려면 Amazon RDS DB 인스턴스에 대한 이진 로깅을 직접 설정할 수 없지만, 다음 중 하나를 수행하여 설정할 수 있습니다.
|
MySQL(외부) |
암호화된 복제 설정 Aurora MySQL 버전 2를 사용하여 데이터를 안전하게 복제하려면 암호화된 복제를 사용하세요. 참고암호화된 복제를 사용할 필요가 없다면 이 단계를 건너 뛸 수 있습니다. 다음은 암호화된 복제를 사용하기 위한 사전 조건입니다.
암호화 복제 중, Aurora MySQL DB 클러스터는 MySQL 데이터베이스 서버의 클라이언트 역할을 합니다. Aurora MySQL 클라이언트 인증서와 키는 .pem 형식의 파일입니다.
외부 MySQL 데이터베이스에 대한 이진 로깅을 설정하려면
|
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 프로시저를 사용하여 다음 예에서는 binlog 파일의 보관 기간을 6일로 설정합니다.
복제를 시작한 후 복제본에 대해 이 설정을 지정하지 않으면 Aurora MySQL의 기본값은 24(1일)입니다.
|
RDS for MySQL |
Amazon RDS DB 인스턴스에 이진 로그를 보관하려면 이전 행에서 설명한 Aurora MySQL DB 클러스터와 마찬가지로 binlog 보관 시간을 설정하여 Amazon RDS DB 인스턴스에 바이너리 로그 파일을 보관할 수 있습니다. DB 인스턴스에 대한 읽기 전용 복제본을 생성하여 Amazon RDS DB 인스턴스에 binlog 파일을 보관할 수도 있습니다. 이 읽기 전용 복제본은 임시 복제본이며 binlog 파일 보관의 목적으로만 사용됩니다. 읽기 전용 복제본이 생성된 후 읽기 전용 복제본에서 mysql.rds_stop_replication 프로시저를 호출합니다. 복제가 중지된 동안 Amazon RDS에서는 복제 소스에서 binlog 파일을 삭제하지 않습니다. 영구 복제본을 사용하여 복제를 설정한 후 복제 소스와 영구 복제본 사이의 복제 지연( |
MySQL(외부) |
외부 MySQL 데이터베이스에 이진 로그를 보관하려면 외부 MySQL 데이터베이스의 binlog 파일은 Amazon RDS에서 관리하지 않으므로 삭제할 때까지 보관됩니다. 복제를 시작한 후 복제본에 대해 |
3. 복제 소스의 사본 또는 덤프 만들기
복제 소스의 스냅샷, 클론 또는 덤프는 데이터의 기본 사본을 복제본으로 로드하는 데 사용됩니다. 그런 다음 그 시점부터 복제를 시작합니다.
다음 지침에 따라 데이터베이스 엔진에 대한 복제 소스의 사본 또는 덤프를 생성하세요.
데이터베이스 엔진 | 지침 |
---|---|
Aurora MySQL |
Aurora MySQL DB 클러스터의 사본을 만들려면 다음 방법 중 한 가지를 선택하세요.
binlog 파일 이름과 위치를 확인하려면 다음 방법 중 한 가지를 선택하세요.
Aurora MySQL DB 클러스터의 덤프를 만들려면 복제본 대상이 외부 MySQL 데이터베이스 또는 RDS for MySQL DB 인스턴스인 경우, Aurora DB 클러스터에서 덤프 파일을 만들어야 합니다. 생성한 소스 DB 클러스터 사본에 대해
|
RDS for MySQL |
Amazon RDS DB 인스턴스의 스냅샷을 만들려면 Amazon RDS DB 인스턴스의 읽기 전용 복제본을 생성합니다. 자세한 내용은 Amazon Relational Database Service 사용 설명서의 읽기 전용 복제본 생성 단원을 참조하십시오.
|
MySQL(외부) |
외부 MySQL 데이터베이스의 스냅샷 생성
|
4. 복제본 대상으로 덤프를 로드합니다(필요한 경우).
Amazon RDS 외부에 있는 MySQL 데이터베이스 덤프에서 데이터를 로드할 계획이라면 덤프 파일을 복사할 EC2 인스턴스를 만드는 것이 좋습니다. 그런 다음 해당 EC2 인스턴스에서 DB 클러스터 또는 DB 인스턴스로 데이터를 로드할 수 있습니다. 이 방법을 사용하면 EC2 인스턴스에 덤프 파일을 복사하기 전에 압축하여 Amazon RDS에 데이터를 복사하는 것과 관련한 네트워크 비용을 줄일 수 있습니다. 또한 덤프 파일 또는 파일을 암호화하여 네트워크 간에 전송되는 데이터를 보호할 수 있습니다.
참고
복제본 대상으로 새로운 Aurora MySQL DB 클러스터를 만드는 경우 덤프 파일을 로드할 필요가 없습니다.
-
DB 클러스터 스냅샷에서 복원하여 새로운 DB 클러스터를 만들 수 있습니다. 자세한 내용은 DB 클러스터 스냅샷에서 복원 단원을 참조하십시오.
-
소스 DB 클러스터를 복제하여 새 DB 클러스터를 생성할 수 있습니다. 자세한 내용은 Aurora DB 클러스터에 대한 볼륨 복제 단원을 참조하십시오.
-
DB 인스턴스의 데이터를 새 DB 클러스터로 마이그레이션할 수 있습니다. 자세한 내용은 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션 단원을 참조하십시오.
데이터베이스 엔진의 복제본 대상에 복제 소스의 덤프를 로드하는 방법에 대한 다음 지침을 확인하세요.
데이터베이스 엔진 | 지침 |
---|---|
Aurora MySQL |
Aurora MySQL DB 클러스터로 덤프 로드
|
RDS for MySQL |
Amazon RDS DB 인스턴스로 덤프 로드
|
MySQL(외부) |
외부 MySQL 데이터베이스로 덤프 로드 DB 스냅샷 또는 DB 클러스터 스냅샷을 외부 MySQL 데이터베이스로 로드할 수 없습니다. 대신
|
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
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 클러스터에서 복제를 설정하려면
SSL 암호화를 사용하려면 최종 값을 |
RDS for MySQL |
Amazon RDS DB 인스턴스에서 복제를 설정하려면
SSL 암호화를 사용하려면 최종 값을 |
MySQL(외부) |
외부 MySQL 데이터베이스에서 복제를 설정하려면
|
복제가 실패하면 복제본에서 의도하지 않은 I/O가 크게 증가하여 성능이 저하될 수 있습니다. 복제가 실패하거나 더 이상 필요하지 않은 경우 mysql.rds_reset_external_master(Aurora MySQL 버전 2) 또는 mysql.rds_reset_external_source(Aurora MySQL 버전 3) 저장 프로시저를 실행하여 복제 구성을 제거할 수 있습니다.
읽기 전용 복제본에 대한 복제를 중지할 위치 설정
Aurora MySQL 버전 3.04 이상에서는 mysql.rds_start_replication_until(Aurora MySQL 버전 3) 저장 프로시저를 사용하여 복제를 시작한 다음 지정된 이진 로그 파일 위치에서 복제를 중지할 수 있습니다.
읽기 전용 복제본에 대한 복제를 시작하고 특정 위치에서 복제를 중지하려면
-
MySQL 클라이언트를 사용하여 Aurora MySQL DB 클러스터 복제본에 마스터 사용자로 연결합니다.
-
mysql.rds_start_replication_until(Aurora MySQL 버전 3) 저장 프로시저를 실행합니다.
다음 예제에서는 복제를 시작하고
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.rds_start_replication_until(Aurora MySQL 버전 3) 저장 프로시저를 사용하십시오. GTID 기반 복제에 대한 자세한 내용은 GTID 기반 복제 사용 단원을 참조하십시오.
7. 복제본 모니터링
Aurora MySQL DB 클러스터를 사용하여 MySQL 복제를 설정한 경우 복제본 대상인 Aurora MySQL DB 클러스터에 대한 장애 조치 이벤트를 모니터링해야 합니다. 장애 조치가 발생할 경우에는 복제본 대상인 DB 클러스터가 다른 네트워크 주소를 가진 새 호스트에서 다시 생성될 수도 있습니다. 장애 조치 이벤트를 모니터링하는 자세한 방법은 Amazon RDS 이벤트 알림 작업 단원을 참조하세요.
또한 복제본 대상에 연결하고 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를 사용하여 복제 소스의 마스터 암호를 변경하는 경우 이러한 변경 사항은 복제 대상에 자동으로 복제되지 않습니다. 소스 시스템과 타겟 시스템 간에 마스터 사용자 및 마스터 비밀번호를 동기화하려는 경우 복제 타겟을 직접 동일하게 변경해야 합니다.