Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제 - Amazon Aurora

Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제

Amazon Aurora MySQL는 MySQL과 호환되기 때문에 MySQL 데이터베이스와 Amazon Aurora MySQL DB 클러스터 사이에 복제를 설정할 수 있습니다. 이러한 유형의 복제는 MySQL 이진 로그 복제를 사용하며 binlog 복제라고 합니다. Aurora에서 이진 로그 복제를 사용하는 경우 MySQL 데이터베이스에서 MySQL 버전 5.5 이상을 실행하는 것이 좋습니다. Aurora MySQL DB 클러스터가 복제 소스 또는 복제본인 경우 복제를 설정할 수 있습니다. Amazon RDS MySQL DB 인스턴스, Amazon RDS 외부의 MySQL 데이터베이스 또는 다른 Aurora MySQL DB 클러스터를 사용하여 복제할 수 있습니다.

참고

특정 유형의 Aurora DB 클러스터에서 안팎으로의 binlog 복제를 사용할 수 없습니다. 구체적으로는 Aurora Serverless v1 클러스터에 binlog 복제를 사용할 수 없습니다. SHOW MASTER STATUSSHOW SLAVE STATUS(Aurora MySQL 버전 2) 또는 SHOW REPLICA STATUS(Aurora MySQL 버전 3) 문이 출력을 반환하지 않는 경우 사용 중인 클러스터가 binlog 복제를 지원하는지 확인하세요.

Aurora MySQL 버전 3에서는 이진 로그 복제를 사용하여 mysql 시스템 데이터베이스에 복제할 수 없습니다. Aurora MySQL 버전 3에서 binlog 복제에 의해 암호와 계정이 복제되지 않습니다. 따라서 CREATE USER, GRANT, REVOKE와 같은 데이터 제어 언어(DCL) 문은 복제되지 않습니다.

다른 AWS 리전의 RDS for MySQL DB 인스턴스 또는 Aurora MySQL DB 클러스터를 사용하여 복제할 수도 있습니다. AWS 리전 간 복제를 수행할 경우 DB 클러스터와 DB 인스턴스에 공개 액세스가 가능한지 확인합니다. Aurora MySQL DB 클러스터가 VPC의 프라이빗 서브넷에 있는 경우 AWS 리전 간에 VPC 피어링을 사용합니다. 자세한 내용은 VPC에 있는 DB 클러스터에 다른 VPC에 있는 EC2 인스턴스가 액세스 단원을 참조하십시오.

Aurora MySQL DB 클러스터와 다른 AWS 리전의 Aurora MySQL DB 클러스터 간에 복제를 구성하려면 소스 DB 클러스터와 다른 AWS 리전에 Aurora MySQL DB 클러스터를 읽기 전용 복제본으로 생성합니다. 자세한 내용은 여러 AWS 리전에 걸쳐 Amazon Aurora MySQL DB 클러스터 복제 단원을 참조하십시오.

Aurora MySQL 버전 2 및 3에서는 Aurora MySQL과 외부 원본 또는 복제를 위해 전역 트랜잭션 식별자(GTID)를 사용하는 대상 간에 복제 작업을 할 수 있습니다. Aurora MySQL DB 클러스터에 있는 GTID 관련 파라미터에 외부 데이터베이스의 GTID 상태와 호환되는 설정이 있어야 합니다. 이 작업을 수행하는 방법은 GTID 기반 복제 사용 단원을 참조하세요. Aurora MySQL 버전 3.01 이상에서는 GTID를 사용하지 않는 소스에서 복제되는 트랜잭션에 GTID를 할당하는 방법을 선택할 수 있습니다. 해당 설정을 제어하는 저장 프로시저에 대한 자세한 내용은 mysql.rds_assign_gtids_to_anonymous_transactions(Aurora MySQL 버전 3) 섹션을 참조하세요.

주의

Aurora MySQL과 MySQL 간에 복제할 경우 InnoDB 테이블만 사용해야 합니다. 복제할 MyISAM 테이블이 있는 경우 다음 명령을 사용하여 복제를 설정하기 전에 해당 테이블을 InnoDB로 변환할 수 있습니다.

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

MySQL 또는 다른 Aurora DB 클러스터를 사용한 복제 설정

Aurora MySQL을 사용하여 MySQL 복제를 설정하는 단계는 다음에서 자세히 설명합니다.

1. 복제 소스에 대한 이진 로깅 설정

2. 더 이상 필요 없을 때까지 이진 로그를 복제 소스에 보관

3. 복제 소스의 스냅샷 또는 덤프 만들기

4. 복제본 대상으로 스냅샷 또는 덤프 로드

5. 복제 소스에 복제 사용자 생성

6. 복제본 대상에서 복제 설정

7. 복제본 모니터링

1. 복제 소스에 대한 이진 로깅 설정

다음 데이터베이스 엔진의 복제 소스에 대한 이진 로깅을 설정하는 방법의 지침을 확인합니다.

2. 더 이상 필요 없을 때까지 이진 로그를 복제 소스에 보관

MySQL 이진 로그 복제를 사용할 경우 Amazon RDS에서 복제 프로세스를 관리하지 않습니다. 따라서 변경 사항이 복제본에 적용된 이후까지 복제 소스의 binlog 파일이 보관되는지 확인해야 합니다. 이 유지 관리는 오류 발생 시 원본 데이터베이스를 복원하는 데 도움이 됩니다.

데이터베이스 엔진에 대한 바이너리 로그를 유지하려면 다음 지침을 따르세요.

3. 복제 소스의 스냅샷 또는 덤프 만들기

복제 소스의 스냅샷 또는 덤프는 데이터의 기본 사본을 복제본으로 로드한 후 해당 지점에서 복제를 시작하는 데 사용됩니다.

다음 지침에 따라 데이터베이스 엔진에 대한 복제 소스의 스냅샷 또는 덤프를 생성하세요.

4. 복제본 대상으로 스냅샷 또는 덤프 로드

Amazon RDS 외부에 있는 MySQL 데이터베이스 덤프에서 데이터를 로드할 계획이라면 EC2 인스턴스를 생성하여 덤프 파일을 복사한 후 해당 EC2 인스턴스에서 DB 클러스터 또는 DB 인스턴스로 데이터를 로드할 수 있습니다. 이 방법을 사용하면 EC2 인스턴스에 덤프 파일을 복사하기 전에 압축하여 Amazon RDS에 데이터를 복사하는 것과 관련한 네트워크 비용을 줄일 수 있습니다. 또한 덤프 파일 또는 파일을 암호화하여 네트워크 간에 전송되는 데이터를 보호할 수 있습니다.

다음 데이터베이스 엔진의 복제본 대상에 복제 소스의 스냅샷 또는 덤프를 로드하는 방법에 대한 지침을 확인하세요.

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 CLIENTREPLICATION 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 인스턴스를 복원할 수 있습니다.

데이터베이스 엔진에 대한 복제를 켜려면 다음 지침을 확인하세요.

복제가 실패하면 복제본에서 의도하지 않은 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) 저장 프로시저를 사용하여 복제를 시작한 다음 지정된 이진 로그 파일 위치에서 복제를 중지할 수 있습니다.

읽기 전용 복제본에 대한 복제를 시작하고 특정 위치에서 복제를 중지하려면
  1. MySQL 클라이언트를 사용하여 Aurora MySQL DB 클러스터 복제본에 마스터 사용자로 연결합니다.

  2. 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 필드는 복제본 대상이 소스보다 얼마나 지연되었는지 알려줍니다.

복제 소스와 타겟 간 비밀번호 동기화

SQL 문을 사용하여 복제 소스에서 사용자 계정 및 암호를 변경하면 해당 변경 사항이 복제 대상에 자동으로 복제됩니다.

AWS Management Console, AWS CLI 또는 RDS API를 사용하여 복제 소스의 마스터 암호를 변경하는 경우 이러한 변경 사항은 복제 대상에 자동으로 복제되지 않습니다. 소스 시스템과 타겟 시스템 간에 마스터 사용자 및 마스터 비밀번호를 동기화하려는 경우 복제 타겟을 직접 동일하게 변경해야 합니다.

Aurora와 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터 간의 복제 중지

MySQL DB 인스턴스, 외부 MySQL 데이터베이스 또는 다른 Aurora DB 클러스터와의 이진 로그 복제 중지 단계는 다음과 같으며, 이 주제의 뒷부분에 자세히 설명되어 있습니다.

1. 복제본 대상의 이진 로그 복제 중단

2. 복제 소스에 대한 이진 로깅 해제

1. 복제본 대상의 이진 로그 복제 중단

데이터베이스 엔진의 바이너리 로그 복제를 중지하려면 다음 지침을 따르세요.

2. 복제 소스에 대한 이진 로깅 해제

데이터베이스 엔진의 복제 소스에서 바이너리 로깅을 비활성화하려면 다음 테이블의 지침을 따르세요.

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 클러스터 생성 단원을 참조하십시오.

MySQL DB 인스턴스와 Amazon Aurora DB 클러스터 간의 복제를 설정할 때는 다음 지침을 따라야 합니다.

  • Amazon Aurora DB 클러스터를 참조할 때 Amazon Aurora MySQL DB 클러스터 엔드포인트 주소를 사용합니다. 장애 조치가 발생하는 경우 Aurora DB 클러스터용 기본 인스턴스로 승격되는 Aurora MySQL 복제본에서 DB 클러스터 엔드포인트 주소가 계속 사용됩니다.

  • Binlog가 Aurora 복제본에 적용되었음을 확인할 때까지는 라이터 인스턴스에서 binlog를 유지 관리합니다. 이렇게 유지 관리해야 오류 발생 시 라이터 인스턴스를 복원할 수 있습니다.

중요

자체 관리형 복제를 사용하는 경우, 발생할 수 있는 복제 문제를 직접 모니터링하고 해결해야 합니다. 자세한 내용은 읽기 전용 복제본 간 지연 문제 진단 및 해결 단원을 참조하십시오.

참고

Aurora MySQL DB 클러스터에서 복제를 시작하는 데 필요한 권한이 제한되고 Amazon RDS 마스터 사용자를 사용할 수 없습니다. 그러므로 mysql.rds_set_external_master(Aurora MySQL 버전 2) 또는 mysql.rds_set_external_source(Aurora MySQL 버전 3)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;
  2. 원본 MySQL DB 인스턴스에서 SHOW MASTER STATUS 명령을 실행하여 binlog 위치를 확인합니다. 다음 예제와 비슷한 출력 결과를 얻습니다.

    File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------
  3. mysqldump를 사용하여 외부 MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터베이스를 복사합니다. 초대형 데이터베이스의 경우 Amazon Relational Database Service 사용 설명서가동 중지 시간을 단축하여 MySQL 또는 MariaDB DB 인스턴스로 데이터 가져오기 절차를 사용하려고 할 수도 있습니다.

    대상 LinuxmacOS, 또는Unix:

    mysqldump \ --databases <database_name> \ --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 <database_name> ^ --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, -pmysql 옵션을 사용하여 Aurora DB 클러스터에 연결할 호스트 이름, 사용자 이름, 포트 및 비밀번호를 지정하십시오. 호스트 이름은 Amazon Aurora DB 클러스터 엔드포인트의 DNS 이름으로, 예를 들면 mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com입니다. Amazon RDS Management Console의 클러스터 세부 정보에서 엔드포인트 값을 찾을 수 있습니다.

  4. 다시 원본 MySQL DB 인스턴스를 쓰기 가능한 상태로 설정합니다.

    mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES;

    복제에 사용할 백업을 만드는 방법에 대한 자세한 내용은 MySQL 설명서에서 Backing up a source or replica by making it read only 섹션을 참조하세요.

  5. Amazon RDS Management Console에서 원본 MySQL 데이터베이스를 호스팅하는 서버의 IP 주소를 Amazon Aurora DB 클러스터용 VPC 보안 그룹에 추가합니다. VPC 보안 그룹 수정에 대한 자세한 내용은 Amazon Virtual Private Cloud 사용 설명서VPC용 보안 그룹을 참조하십시오.

    Amazon Aurora DB 클러스터의 IP 주소에서의 연결을 허용하도록 로컬 네트워크를 구성하여 원본 MySQL 인스턴스와 통신할 수 있도록 해야 할 수도 있습니다. Amazon Aurora DB 클러스터의 IP 주소를 검색하려면 host 명령을 사용하십시오.

    host aurora_endpoint_address

    호스트 이름은 Amazon Aurora DB 클러스터 엔드포인트의 DNS 이름입니다.

  6. 선택한 클라이언트를 사용하여 외부 MySQL 인스턴스에 연결하고 복제에 사용될 MySQL 사용자를 만듭니다. 이 계정은 오직 복제용으로만 사용되며 보안 향상을 위해 사용자의 도메인으로 제한되어야 합니다. 다음은 예제입니다.

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
  7. 외부 MySQL 인스턴스의 경우 복제 사용자에게 REPLICATION CLIENTREPLICATION SLAVE 권한을 부여합니다. 예를 들어 도메인의 'REPLICATION CLIENT' 사용자를 위해 모든 데이터베이스에서 REPLICATION SLAVErepl_user 권한을 부여하려면 다음 명령을 실행합니다.

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
  8. 복제를 설정하기 전에 Aurora MySQL DB 클러스터의 수동 스냅샷을 읽기 전용 복제본으로 생성합니다. DB 클러스터와 복제를 읽기 복제본으로 다시 설정해야 할 경우, MySQL DB 인스턴스를 새로운 Aurora MySQL DB 클러스터로 가져오는 대신 이 스냅샷에서 Aurora MySQL DB 클러스터를 복원할 수 있습니다.

  9. Amazon Aurora DB 클러스터를 복제본으로 만듭니다. 마스터 사용자로서 Amazon Aurora DB 클러스터에 연결하고 mysql.rds_set_external_master(Aurora MySQL 버전 2) 또는 mysql.rds_set_external_source(Aurora MySQL 버전 3)mysql.rds_start_replication 프로시저를 사용하여 소스 MySQL 데이터베이스를 식별합니다.

    2단계에서 결정한 마스터 로그 파일 이름과 마스터 로그 위치를 사용합니다. 다음은 예입니다.

    For Aurora MySQL version 2: CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3: CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
  10. Amazon Aurora DB 클러스터에서 mysql.rds_start_replication 프로시저를 호출하여 복제를 시작합니다.

    CALL mysql.rds_start_replication;

원본 MySQL DB 인스턴스와 Amazon Aurora DB 클러스터 간의 복제를 설정한 후에는 Aurora 복제본을 Amazon Aurora DB 클러스터에 추가할 수 있습니다. 그러고 나면 Aurora 복제본에 연결하여 데이터에 대한 읽기 조정을 수행할 수 있습니다. Aurora 복제본 생성에 대한 자세한 정보는 DB 클러스터에 Aurora 복제본 추가 단원을 참조하십시오.

이진 로그 복제 최적화하기

다음으로 Aurora MySQL에서 이진 로그 복제 성능을 최적화하고 관련 문제를 해결하는 방법을 배울 수 있습니다.

작은 정보

이 논의에서는 MySQL 이진 로그 복제 메커니즘과 작동 방식에 대해 잘 알고 있다고 가정합니다. 배경 정보는 MySQL 설명서의 복제 구현 단원을 참조하세요.

다중 스레드 이진 로그 복제

다중 스레드 이진 로그 복제를 사용하면 SQL 스레드가 릴레이 로그에서 이벤트를 읽고 SQL 작업자 스레드에서 적용하도록 이벤트를 대기열에 넣습니다. SQL 작업자 스레드는 코디네이터 스레드에서 관리합니다. 가능한 경우 이진 로그 이벤트가 병렬로 적용됩니다.

다중 스레드 이진 로그 복제는 Aurora MySQL 버전 3, Aurora MySQL 버전 2.12.1 이상에서 지원됩니다.

Aurora MySQL DB 인스턴스가 binlog 복제를 사용하도록 구성된 경우 복제본 인스턴스는 Aurora MySQL 3.04 미만 버전에 기본적으로 단일 스레드 복제를 사용합니다. 다중 스레드 복제를 사용 설정하려면 replica_parallel_workers 파라미터를 사용자 정의 파라미터 그룹에서 0보다 큰 값으로 업데이트합니다.

Aurora MySQL 버전 3.04 이상에서는 복제가 기본적으로 다중 스레드로 설정되며 replica_parallel_workers4로 설정됩니다. 사용자 지정 파라미터 그룹에서 이 파라미터를 수정할 수 있습니다.

다음 구성 옵션을 사용하면 다중 스레드 복제를 세부 조정할 수 있습니다. 사용 정보는 MySQL 참조 설명서복제, 이진 로깅 옵션 및 변수를 참조하세요.

최적의 구성은 여러 요인에 따라 달라집니다. 예를 들어 이진 로그 복제의 성능은 데이터베이스 워크로드 특성과 복제본이 실행 중인 DB 인스턴스 클래스의 영향을 받습니다. 따라서 프로덕션 인스턴스에 새 파라미터 설정을 적용하기 전에 이러한 구성 파라미터에 대한 모든 변경 사항을 철저히 테스트하는 것이 좋습니다.

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

Aurora MySQL 버전 3.06 이상에서는 보조 인덱스가 두 개 이상인 대규모 테이블의 트랜잭션을 복제할 때 binlog 복제본의 성능을 개선할 수 있습니다. 이 기능은 binlog 복제본에서 보조 인덱스 변경 사항을 병렬로 적용하는 스레드 풀을 도입합니다. 이 기능은 보조 인덱스 변경 사항을 적용하는 데 사용할 수 있는 총 병렬 스레드 수를 제어하는 aurora_binlog_replication_sec_index_parallel_workers DB 클러스터 파라미터에 의해 제어됩니다. 기본적으로 파라미터는 0(비활성화됨)로 설정됩니다. 이 기능을 활성화해도 인스턴스를 다시 시작할 필요가 없습니다. 이 기능을 활성화하려면 진행 중인 복제를 중지하고 원하는 수의 병렬 작업자 스레드를 설정한 다음 복제를 다시 시작하세요.

이 파라미터를 글로벌 변수로 사용할 수도 있습니다. 여기서 n은 병렬 작업자 스레드 수입니다.

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

binlog 복제 최적화(Aurora MySQL 2.10 이상)

Aurora MySQL 2.10 이상에서 Aurora는 binlog I/O 캐시라는 최적화를 바이너리 로그 복제에 자동으로 적용합니다. 이 최적화는 가장 최근에 커밋된 binlog 이벤트를 캐싱하여 binlog 덤프 스레드 성능을 개선하고 binlog 소스 인스턴스에 대한 포그라운드 트랜잭션에 미치는 영향을 제한하도록 설계되었습니다.

참고

이 기능에 사용되는 메모리는 MySQL binlog_cache 설정과 독립적입니다.

이 기능은 db.t2db.t3 인스턴스 클래스를 사용하는 Aurora DB 인스턴스에는 적용되지 않습니다.

이 최적화를 켜기 위해 구성 파라미터를 조정할 필요가 없습니다. 특히 이전 Aurora MySQL 버전에서 구성 파라미터 aurora_binlog_replication_max_yield_seconds를 0이 아닌 값으로 조정하는 경우 Aurora MySQL 2.10 이상에서는 0으로 다시 설정해야 합니다.

상태 변수 aurora_binlog_io_cache_readsaurora_binlog_io_cache_read_requests는 Aurora MySQL 2.10 이상에서 사용할 수 있습니다. 이러한 상태 변수는 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 복제본이 소스를 따라 잡고 있는지, 뒤쳐지지 않는지 확인할 수 있습니다.

binlog 복제 최적화(Aurora MySQL 2~2.09)

Aurora MySQL에 대한 이진 로그 복제를 최적화하려면 다음 클러스터 수준 최적화 매개 변수를 조정합니다. 이러한 파라미터는 binlog 원본 인스턴스의 지연 시간과 복제 지연 사이의 적절한 균형을 지정하는 데 도움이 됩니다.

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

참고

MySQL 5.7 호환 클러스터의 경우 Aurora MySQL 버전 2부터 2.09.*까지 이러한 파라미터를 사용할 수 있습니다. Aurora MySQL 2.10.0 이상에서는 이러한 파라미터가 binlog I/O 캐시 최적화로 대체되므로 사용할 필요가 없습니다.

대용량 읽기 버퍼 및 최대 수율 최적화 개요

클러스터가 많은 수의 트랜잭션을 처리하는 동안 이진 로그 덤프 스레드가 Aurora 클러스터 볼륨에 액세스할 때 이진 로그 복제 성능이 저하될 수 있습니다. 파라미터 aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds, 및 aurora_binlog_read_buffer_size를 사용하여 이러한 유형의 문제를 최소화할 수 있습니다.

aurora_binlog_replication_max_yield_seconds가 0보다 큰 값으로 설정되고 덤프 스레드의 현재 binlog 파일이 활성 상태인 상황을 가정해 보겠습니다. 이 경우 기존 binlog 파일을 트랜잭션으로 채울 때까지 이진 로그 덤프 스레드가 지정한 시간(초)까지 대기합니다. 이 대기 기간은 각 binlog 이벤트를 개별적으로 복제하여 발생할 수 있는 문제를 방지합니다. 그러나 이러면 이진 로그 복제본에 대한 복제 지연이 증가합니다. 이러한 복제본은 aurora_binlog_replication_max_yield_seconds 설정과 동일한 시간(초)만큼 소스의 뒤떨어질 수 있습니다.

현재 binlog 파일은 덤프 스레드가 복제를 수행하기 위해 현재 읽고 있는 binlog 파일을 의미합니다. binlog 파일이 업데이트되거나 들어오는 트랜잭션에 의해 업데이트되도록 열려 있을 때 binlog 파일이 활성 상태인 것으로 간주됩니다. Aurora MySQL이 활성 binlog 파일을 채운 후 MySQL은 새 binlog 파일을 생성하고 전환합니다. 이전 binlog 파일이 비활성 상태가 됩니다. 더 이상 들어오는 트랜잭션에 의해 업데이트되지 않습니다.

참고

이러한 파라미터를 조정하기 전에 시간에 따른 트랜잭션 지연 시간 및 처리량을 측정하십시오. 이진 로그 복제 성능이 안정적이며 가끔 경합이 발생하더라도 대기 시간이 짧다는 것을 알 수 있을 것입니다.

aurora_binlog_use_large_read_buffer

이 매개 변수를 1로 설정하면 Aurora MySQL는 파라미터 aurora_binlog_read_buffer_sizeaurora_binlog_replication_max_yield_seconds의 설정에 따라 이진 로그 복제를 최적화합니다. aurora_binlog_use_large_read_buffer가 0이면 Aurora MySQL은 aurora_binlog_read_buffer_sizeaurora_binlog_replication_max_yield_seconds 파라미터의 값을 무시합니다.

aurora_binlog_read_buffer_size

더 큰 읽기 버퍼가 있는 이진 로그 덤프 스레드는 각 I/O에 대해 더 많은 이벤트를 읽음으로써 읽기 I/O 작업 수를 최소화합니다. 파라미터 aurora_binlog_read_buffer_size는 읽기 버퍼 크기를 설정합니다. 대용량 읽기 버퍼는 대량의 binlog 데이터를 생성하는 워크로드에 대한 이진 로그 경합을 줄여줄 수 있습니다.

참고

이 파라미터는 클러스터에 설정 aurora_binlog_use_large_read_buffer=1이 있는 경우에만 영향을 줍니다.

읽기 버퍼의 크기를 늘려도 이진 로그 복제 성능에 영향을 주지 않습니다. 이진 로그 덤프 스레드는 읽기 버퍼를 채우기 위해 트랜잭션을 업데이트할 때까지 기다리지 않습니다.

aurora_binlog_replication_max_yield_seconds

워크로드에 낮은 트랜잭션 대기 시간이 필요하고 일부 복제 지연을 허용할 수 있는 경우 aurora_binlog_replication_max_yield_seconds 파라미터를 늘릴 수 있습니다. 이 매개 변수는 클러스터에서 이진 로그 복제의 최대 수율 속성을 제어합니다.

참고

이 파라미터는 클러스터에 설정 aurora_binlog_use_large_read_buffer=1이 있는 경우에만 영향을 줍니다.

Aurora MySQL 는 aurora_binlog_replication_max_yield_seconds 파라미터 값에 대한 모든 변경 사항을 즉시 인식합니다. DB 인스턴스를 다시 시작할 필요가 없습니다. 그러나 이 설정을 설정하면 현재 binlog 파일이 최대 크기인 128MB에 도달하고 새 파일로 회전될 때에 한하여 덤프 스레드가 생성되기 시작합니다.

관련 파라미터

binlog 최적화를 활성화하려면 다음 DB 클러스터 파라미터를 사용합니다.

파라미터 기본값 유효한 값 설명
aurora_binlog_use_large_read_buffer 1 0, 1 복제 개선 기능을 켜기 위한 스위치. 값이 1이면 바이너리 로그 덤프 스레드는 바이너리 로그 복제에 aurora_binlog_read_buffer_size를 사용합니다. 그렇지 않으면 기본 버퍼 크기(8K)가 사용됩니다. Aurora MySQL 버전 3에서 사용되지 않습니다.
aurora_binlog_read_buffer_size 5242880 8192-536870912 파라미터 aurora_binlog_use_large_read_buffer가 1로 설정된 경우 이진 로그 덤프 스레드가 사용하는 버퍼 크기를 읽습니다. Aurora MySQL 버전 3에서 사용되지 않습니다.
aurora_binlog_replication_max_yield_seconds 0 0-36000

Aurora MySQL 버전 2.07*에서 허용되는 최댓값은 45입니다. 2.09 및 그 이후 버전에서 더 높은 값으로 조정할 수 있습니다.

버전 2의 경우 이 파라미터는 파라미터 aurora_binlog_use_large_read_buffer가 1로 설정된 경우에만 작동합니다.

이진 로그 복제 최대 수율 메커니즘 사용 설정

다음과 같이 이진 로그 복제 최대 수율 최적화를 시작할 수 있습니다. 이렇게 하면 binlog 원본 인스턴스에서 트랜잭션에 대한 지연 시간이 최소화됩니다. 그러나 더 높은 복제 지연이 발생할 수 있습니다.

Aurora MySQL 클러스터에 대해 최대 수율 binlog 최적화를 설정하려면
  1. 다음 파라미터 설정을 사용해 DB 클러스터 파라미터 그룹을 생성 또는 편집합니다.

    • aurora_binlog_use_large_read_buffer: ON 또는 1의 값으로 켭니다.

    • aurora_binlog_replication_max_yield_seconds: 0보다 큰 값을 입력합니다.

  2. DB 클러스터 파라미터 그룹을 binlog 소스로 작동하는 Aurora MySQL 클러스터와 연결합니다. 이 작업을 수행하려면 파라미터 그룹 작업의 절차를 따르십시오.

  3. 파라미터 변경 사항이 적용되는지 확인합니다. 이렇게 하기 위해 binlog 원본 인스턴스에서 다음 쿼리를 실행하십시오.

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    다음과 유사하게 출력되어야 합니다.

    +---------------------------------------+-----------------------------------------------+ | @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds | +---------------------------------------+-----------------------------------------------+ | 1 | 45 | +---------------------------------------+-----------------------------------------------+

이진 로그 복제 최대 수율 최적화 해제

다음과 같이 이진 로그 복제 최대 수율 최적화를 해제할 수 있습니다. 이렇게 하면 복제 지연이 최소화됩니다. 그러나 binlog 원본 인스턴스의 트랜잭션에 대한 지연 시간이 더 길어질 수 있습니다.

Aurora MySQL 클러스터에 대한 최대 수율 최적화를 해제하는 방법
  1. Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 aurora_binlog_replication_max_yield_seconds가 0으로 설정되어 있는지 확인합니다. 파라미터 그룹을 사용한 구성 파라미터 설정에 대한 자세한 내용은 파라미터 그룹 작업 단원을 참조하십시오.

  2. 파라미터 변경 사항이 적용되는지 확인합니다. 이렇게 하기 위해 binlog 원본 인스턴스에서 다음 쿼리를 실행하십시오.

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    다음과 유사하게 출력되어야 합니다.

    +-----------------------------------------------+ | @@aurora_binlog_replication_max_yield_seconds | +-----------------------------------------------+ | 0 | +-----------------------------------------------+

대량 읽기 버퍼 해제

다음과 같이 전체 대량 읽기 버퍼 기능을 해제할 수 있습니다.

Aurora MySQL 클러스터에 대한 큰 이진 로그 읽기 버퍼를 해제하려면
  1. aurora_binlog_use_large_read_bufferOFF 또는 0으로 재설정합니다.

    Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 aurora_binlog_use_large_read_buffer가 0으로 설정되어 있는지 확인합니다. 파라미터 그룹을 사용한 구성 파라미터 설정에 대한 자세한 내용은 파라미터 그룹 작업 단원을 참조하십시오.

  2. binlog 원본 인스턴스에서 다음 쿼리를 실행합니다.

    SELECT @@ aurora_binlog_use_large_read_buffer;

    다음과 유사하게 출력되어야 합니다.

    +---------------------------------------+ | @@aurora_binlog_use_large_read_buffer | +---------------------------------------+ | 0 | +---------------------------------------+

향상된 binlog 설정

향상된 binlog는 binlog를 켜서 발생하는 컴퓨팅 성능 오버헤드를 줄여 주는데, 이 오버헤드는 경우에 따라 최대 50% 까지 증가할 수 있습니다. 향상된 binlog를 사용하면 이러한 오버헤드를 약 13%로 줄일 수 있습니다. 오버헤드를 줄이기 위해 향상된 binlog는 바이너리 로그와 트랜잭션 로그를 스토리지에 병렬식으로 기록하여 트랜잭션 커밋 시 기록되는 데이터를 최소화합니다.

또한 향상된 binlog를 사용하면 커뮤니티 MySQL binlog에 비해 다시 시작 및 장애 조치 후 데이터베이스 복구 시간이 최대 99% 향상됩니다. 향상된 binlog는 기존 binlog 기반 워크로드와 호환되며 커뮤니티 MySQL binlog와 상호 작용하는 것과 동일한 방식으로 상호 작용합니다.

향상된 binlog는 Aurora MySQL 버전 3.03.1 이상에서 사용할 수 있습니다.

향상된 binlog 파라미터 구성

향상된 binlog 파라미터를 켜거나 끄면 커뮤니티 MySQL binlog와 향상된 binlog 간에 전환할 수 있습니다. 기존 binlog 소비자는 binlog 파일 시퀀스의 공백 없이 binlog 파일을 계속 읽고 사용할 수 있습니다.

향상된 binlog 켜기
파라미터 기본값 설명
binlog_format binlog_format 파라미터를 원하는 바이너리 로깅 형식으로 설정하여 향상된 binlog를 켭니다. binlog_format parameter가 OFF로 설정되어 있지 않은지 확인하세요. 자세한 내용은 Aurora MySQL 이진 로깅 구성을 참조하세요.
aurora_enhanced_binlog 0 Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 이 파라미터를 1로 설정합니다. 이 파라미터의 값을 변경할 때 DBClusterParameterGroupStatus 값이 pending-reboot로 표시되면 라이터 인스턴스를 재부팅해야 합니다.
binlog_backup 1 향상된 binlog를 켜려면 이 파라미터를 끄세요. 이렇게 하려면 이 파라미터의 값을 0으로 설정합니다.
binlog_replication_globaldb 1 향상된 binlog를 켜려면 이 파라미터를 끄세요. 이렇게 하려면 이 파라미터의 값을 0으로 설정합니다.
중요

향상된 binlog를 사용하는 경우에만 binlog_backupbinlog_replication_globaldb 파라미터를 끌 수 있습니다.

향상된 binlog 끄기
파라미터 설명
aurora_enhanced_binlog Aurora MySQL 클러스터와 연결된 DB 클러스터 파라미터 그룹에서 이 파라미터를 0로 설정합니다. 이 파라미터의 값을 변경할 때 DBClusterParameterGroupStatus 값이 pending-reboot로 표시되면 라이터 인스턴스를 재부팅해야 합니다.
binlog_backup 향상된 binlog를 끄려면 이 파라미터를 켜세요. 이렇게 하려면 이 파라미터의 값을 1으로 설정합니다.
binlog_replication_globaldb 향상된 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가 켜지면 기본값 134217728268435456으로 자동 조정됩니다.

  • 커뮤니티 MySQL binlog와 달리 향상된 binlog가 켜져 있을 때는 binlog_checksum이 동적 파라미터로 작동하지 않습니다. 이 파라미터에 대한 변경 사항을 적용하려면 ApplyMethodimmediate인 경우에도 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 파라미터 구성 단원을 참조하십시오.

예 향상된 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)
예 향상된 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를 끈 후에 작성한 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 파라미터 구성 단원을 참조하십시오.

예 향상된 binlog가 켜져 있을 때 Global Database 장애 조치 작업이 수행됩니다.

이전 프라이머리 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)
예 향상된 binlog가 꺼져 있을 때 Global Database 장애 조치 작업이 수행됩니다.

소스 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를 끈 후 작성된 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

  • 데이터베이스에서 손상된 테이블을 삭제하거나 이름을 바꿀 수 없습니다. 이 테이블을 삭제하려면 AWS Support에 문의하세요.

  • 향상된 binlog가 켜지면 binlog I/O 캐시가 비활성화됩니다. 자세한 내용은 이진 로그 복제 최적화하기 단원을 참조하십시오.

    참고

    향상된 binlog는 binlog I/O 캐시와 유사한 읽기 성능 향상 및 더 나은 쓰기 성능 개선을 제공합니다.

  • 역추적 기능은 지원되지 않습니다. 다음과 같은 조건에서는 향상된 binlog를 DB 클러스터에서 켤 수 없습니다.

    • 현재 역추적 기능이 활성화된 DB 클러스터.

    • 이전에 역추적 기능이 활성화되었지만 비활성화되지 않은 DB 클러스터

    • 역추적 기능이 활성화된 소스 DB 클러스터 또는 스냅샷에서 복원된 DB 클러스터.