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 클러스터에서 안팎으로의 binlog 복제를 사용할 수 없습니다. 구체적으로는 Aurora Serverless v1 및 멀티 마스터 클러스터에 binlog 복제를 사용할 수 없습니다. SHOW MASTER STATUSSHOW SLAVE STATUS 문이 출력을 반환하지 않을 경우 사용 중인 클러스터가 binlog 복제를 지원하는 클러스터인지 확인하세요.

다른 AWS 리전의 RDS for MySQL DB 인스턴스 또는 Aurora MySQL DB 클러스터를 사용하여 복제할 수도 있습니다. AWS 리전 간 복제를 수행할 경우 DB 클러스터와 DB 인스턴스에 공개 액세스가 가능한지 확인합니다. Aurora MySQL DB 클러스터는 VPC의 퍼블릭 서브넷에 포함되어야 합니다.

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

Aurora MySQL 2.04 이상에서는 Aurora MySQL과 외부 원본 또는 복제를 위해 전역 트랜잭션 식별자(GTID)를 사용하는 대상 간에 복제 작업을 할 수 있습니다. Aurora MySQL DB 클러스터에 있는 GTID 관련 파라미터에 외부 데이터베이스의 GTID 상태와 호환되는 설정이 있어야 합니다. 이 작업을 수행하는 방법은 Aurora MySQL용 GTID 기반 복제 사용 단원을 참조하십시오.

주의

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

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

Aurora MySQL을 사용한 MySQL 복제 설정 단계는 다음과 같으며, 이 주제의 뒷부분에 자세히 설명되어 있습니다.

1. 복제 소스에 대한 이진 로깅 활성화

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

3. 복제 소스의 스냅샷 만들기

4. 복제본 대상으로 스냅샷 로드

5. 복제본 대상에 대해 복제 활성화

6. 복제본 모니터링

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

MySQL로 Aurora 복제를 설정하려면 다음 단계를 수행합니다.

1. 복제 소스에 대한 이진 로깅 활성화

다음 데이터베이스 엔진의 복제 소스에 대한 이진 로깅을 활성화하는 방법의 지침을 확인하십시오.

데이터베이스 엔진 지침

Aurora

Aurora MySQL DB 클러스터에 대한 이진 로깅을 활성화하려면

binlog_format 파라미터를 ROW, STATEMENT, MIXED로 설정합니다. 특정 binlog 형식이 필요하지 않는 한 MIXED로 설정하는 것이 좋습니다. binlog_format 파라미터는 기본 클러스터 파라미터 그룹에 속하는 클러스터 수준 파라미터입니다. binlog_format 파라미터를 OFF에서 다른 값으로 변경하는 경우, Aurora DB 클러스터를 재부팅해야 변경 사항이 적용됩니다.

자세한 내용은 Amazon Aurora DB 클러스터와 DB 인스턴스 파라미터DB 파라미터 그룹 및 DB 클러스터 파라미터 그룹 작업 단원을 참조하십시오.

RDS for MySQL

Amazon RDS DB 인스턴스에 대한 이진 로깅을 활성화하려면

Amazon RDS DB 인스턴스에 대한 이진 로깅을 직접 활성화할 수는 없지만, 다음 중 하나를 수행하여 활성화할 수 있습니다.

  • DB 인스턴스의 자동 백업을 활성화합니다. DB 인스턴스를 생성할 때 자동 백업을 활성화하거나 기존 DB 인스턴스를 수정하여 백업을 활성화할 수 있습니다. 자세한 내용은 Amazon RDS 사용 설명서DB 인스턴스 생성 단원을 참조하십시오.

  • DB 인스턴스의 읽기 전용 복제본을 생성합니다. 자세한 내용은 Amazon RDS 사용 설명서읽기 전용 복제본 작업을 참조하십시오.

MySQL(외부)

암호화된 복제 설정

Aurora MySQL 버전 5.6을 사용하여 데이터를 안전하게 복제하려면 암호화된 복제를 사용하십시오.

현재 외부 MySQL 데이터베이스로 암호화된 복제는 ​Aurora MySQL 버전 5.6에만 지원됩니다.

참고

암호화된 복제를 사용할 필요가 없다면 이 단계를 건너 뛸 수 있습니다.

다음은 암호화된 복제를 사용하기 위한 사전 조건입니다.

  • 외부 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 인증서 및 키 생성을 참조하십시오.

    인증 기관(CA) 인증서, 클라이언트 키, 클라이언트 인증서가 필요합니다.

  2. SSL을 사용하여 마스터 사용자로 Aurora MySQL DB 클러스터에 연결하십시오.

    SSL을 이용한 Aurora MySQL DB 클러스터 연결에 대한 자세한 정보는 Aurora MySQL DB 클러스터에서 SSL/TLS 사용를 참조하십시오.

  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_materialAurora MySQL DB 클러스터에서 SSL/TLS 사용 단원을 참조하십시오.

    참고

    프로시저를 실행한 후 파일에 암호를 저장합니다. 이 파일을 나중에 삭제하려면 mysql_rds_remove_binlog_ssl_material 저장 프로시저를 실행할 수 있습니다.

외부 MySQL 데이터베이스에 대한 이진 로깅을 활성화하려면

  1. 명령 셸에서 mysql 서비스를 중지합니다.

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

    sudo vi /etc/my.cnf

    log_binserver_id 옵션을 [mysqld] 섹션에 추가합니다. log_bin 옵션은 이진 로그 파일에 대한 파일 이름 식별자를 제공합니다. server_id 옵션은 소스-복제본 관계에서 서버의 고유 식별자를 제공합니다.

    암호화된 복제가 필요 없다면, binlogs를 활성화 시키고 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 master configuration 섹션을 참조하세요.

  3. mysql 서비스를 시작합니다.

    sudo service mysqld start

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

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

다음 데이터베이스 엔진의 이진 로그를 보관하는 방법에 대한 지침을 확인하십시오.

데이터베이스 엔진 지침

Aurora

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 retention hours' 구성 파라미터와 함께 DB 클러스터에 binlog 파일을 보관할 시간(최대 2160시간(90일))을 지정합니다. 다음 예에서는 binlog 파일의 보관 기간을 6일로 설정합니다.

CALL mysql.rds_set_configuration('binlog retention hours', 144);

복제를 시작한 후 복제본에 대해 SHOW SLAVE STATUS 명령을 실행하고 Seconds behind master 필드를 선택하여 변경 사항이 복제본에 적용되었는지 확인할 수 있습니다. Seconds behind master 필드가 0이면 복제본 지연이 없습니다. 복제 지연이 없는 경우 binlog retention hours 구성 파라미터를 더 짧은 기간으로 설정하여 binlog 파일을 보관할 기간을 줄입니다.

이 설정을 지정하지 않으면 Aurora MySQL의 기본값은 24(1일)입니다.

'binlog retention hours' 값을 2160보다 높게 지정하면 Aurora MySQL은(는) 2160의 값을 사용합니다.

RDS for MySQL

Amazon RDS DB 인스턴스에 이진 로그를 보관하려면

이전 단원에서 설명한 Aurora MySQL DB 클러스터와 같은 방법으로 이진 로그 보관 시간을 설정하여 Amazon RDS DB 인스턴스에 binlog 파일을 보관할 수 있습니다.

DB 인스턴스에 대한 읽기 전용 복제본을 생성하여 Amazon RDS DB 인스턴스에 binlog 파일을 보관할 수도 있습니다. 이 읽기 전용 복제본은 임시 복제본이며 binlog 파일 보관의 목적으로만 사용됩니다. 읽기 전용 복제본이 생성된 후 읽기 전용 복제본에 대한 mysql_rds_stop_replication 프로시저를 호출합니다(mysql.rds_stop_replication 프로시저는 MySQL 버전 5.5, 5.6 이상 및 5.7 이상에서만 사용할 수 있음). 복제가 중지된 동안 Amazon RDS에서는 복제 소스에서 binlog 파일을 삭제하지 않습니다. 영구 복제본을 사용하여 복제를 설정한 후 복제 소스와 영구 복제본 사이의 복제 지연(Seconds behind master 필드)이 0에 도달한 경우 읽기 전용 복제본을 삭제할 수 있습니다.

MySQL(외부)

외부 MySQL 데이터베이스에 이진 로그를 보관하려면

외부 MySQL 데이터베이스의 binlog 파일은 Amazon RDS에서 관리하지 않으므로 삭제할 때까지 보관됩니다.

복제를 시작한 후 복제본에 대해 SHOW SLAVE STATUS 명령을 실행하고 Seconds behind master 필드를 선택하여 변경 사항이 복제본에 적용되었는지 확인할 수 있습니다. Seconds behind master 필드가 0이면 복제본 지연이 없습니다. 복제 지연이 없는 경우 이전 binlog 파일을 삭제할 수 있습니다.

3. 복제 소스의 스냅샷 만들기

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

다음 데이터베이스 엔진의 복제 소스의 스냅샷을 생성하는 방법에 대한 지침을 확인하십시오.

데이터베이스 엔진 지침

Aurora

Aurora MySQL DB 클러스터의 스냅샷을 만들려면

  1. Amazon Aurora DB 클러스터의 DB 클러스터 스냅샷을 생성합니다. 자세한 내용은 DB 클러스터 스냅샷 생성 섹션을 참조하세요.

  2. 방금 만든 DB 클러스터 스냅샷에서 복원하여 새 Aurora DB 클러스터를 생성합니다. 복원된 DB 클러스터의 DB 파라미터 그룹을 원래 DB 클러스터와 동일하게 유지해야 합니다. 이렇게 해야 DB 클러스터 사본에 이진수 로깅이 활성화됩니다. 자세한 내용은 DB cluster 스냅샷에서 복원 섹션을 참조하세요.

  3. 콘솔에서 Databases(데이터베이스)를 선택하고 복원된 Aurora DB 클러스터의 기본 인스턴스(writer)를 선택하여 세부 정보를 표시합니다. [Recent Events]로 스크롤합니다. binlog 파일 이름과 위치를 포함한 이벤트 메시지가 표시됩니다. 이벤트 메시지의 형식은 다음과 같습니다.

    Binlog position from crash recovery is binlog-file-name binlog-position

    복제 시작 위치에 해당하는 binlog 파일 이름 및 위치 값을 저장합니다.

    AWS CLI에서 describe-events 명령을 호출하여 binlog 파일 이름 및 위치를 얻을 수도 있습니다. 다음은 describe-events 명령과 명령 출력의 예입니다.

    PROMPT> 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 파일 위치를 확인하여 binlog 파일 이름과 위치를 가져올 수도 있습니다.

  4. 복제본 대상이 다른 AWS 계정이 소유한 Aurora DB 클러스터이거나, 외부 MySQL 데이터베이스이거나, RDS for MySQL DB 인스턴스인 경우 Amazon Aurora DB 클러스터 스냅샷에서 데이터를 로드할 수 없습니다. 대신 MySQL 클라이언트를 사용하여 DB 클러스터에 연결하고 mysqldump 명령을 실행하여 Amazon Aurora DB 클러스터의 덤프를 생성할 수 있습니다. 생성한 Amazon Aurora DB 클러스터 사본에 대해 mysqldump 명령을 실행해야 합니다. 다음은 예제입니다.

    PROMPT> mysqldump --databases <database_name> --single-transaction --order-by-primary -r backup.sql -u <local_user> -p
  5. 새로 생성된 Aurora DB 클러스터에서 데이터 덤프 생성을 마치고 나면 해당 DB 클러스터는 더 이상 필요하지 않으므로 삭제합니다.

RDS for MySQL

Amazon RDS DB 인스턴스의 스냅샷을 만들려면

  1. Amazon RDS DB 인스턴스의 읽기 전용 복제본을 생성합니다. 자세한 내용은 Amazon Relational Database Service 사용 설명서읽기 전용 복제본 생성 단원을 참조하십시오.

  2. 읽기 전용 복제본에 연결하고 mysql_rds_stop_replication 프로시저를 실행하여 복제를 중지합니다.

  3. 읽기 전용 복제본이 중지됨 상태인 동안 읽기 전용 복제본에 연결하고 SHOW SLAVE STATUS 명령을 실행합니다. Relay_Master_Log_File 필드에서 현재 이진 로그 파일 이름을 검색하고 Exec_Master_Log_Pos 필드에서 로그 파일 위치를 검색합니다. 복제를 시작할 때에 대비하여 해당 값을 저장합니다.

  4. 읽기 전용 복제본을 중지됨 상태로 유지하면서 읽기 전용 복제본의 DB 스냅샷을 생성합니다. 자세한 내용은 Amazon Relational Database Service 사용 설명서DB 스냅샷 생성 단원을 참조하십시오.

  5. 읽기 전용 복제본을 삭제합니다.

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

Aurora MySQL DB 클러스터로 스냅샷을 로드하려면

  • 복제 소스의 스냅샷이 DB 클러스터 스냅샷인 경우 DB 클러스터 스냅샷에서 복원하여 새 Aurora MySQL DB 클러스터를 복제본 대상으로 생성할 수 있습니다. 자세한 내용은 DB cluster 스냅샷에서 복원 섹션을 참조하세요.

  • 복제 소스의 스냅샷이 DB 스냅샷인 경우 DB 스냅샷의 데이터를 새 Aurora MySQL DB 클러스터로 마이그레이션할 수 있습니다. 자세한 내용은 Amazon Aurora DB 클러스터로 데이터 마이그레이션 섹션을 참조하세요.

  • 복제 소스의 스냅샷이 mysqldump 명령의 출력인 경우 다음 단계를 따릅니다.

    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. 복제본 대상에 대해 복제 활성화

복제를 활성화하기 전에 Aurora MySQL DB 클러스터 또는 RDS for MySQL DB 인스턴스 복제본 대상의 스냅샷을 수동으로 생성하는 것이 좋습니다. 문제가 발생하여 DB 클러스터 또는 DB 인스턴스 복제본 대상을 통해 복제를 다시 설정해야 하는 경우, 데이터를 복제본 대상으로 다시 가져오는 대신 이 스냅샷에서 DB 클러스터 또는 DB 인스턴스를 복원할 수 있습니다.

또한 복제에만 사용되는 사용자 ID를 생성할 수도 있습니다. 다음은 예제입니다.

mysql> CREATE USER 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';

사용자에게 REPLICATION CLIENTREPLICATION SLAVE 권한이 필요합니다. 해당 사용자에게 이 권한을 부여합니다.

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';

암호화된 복제를 사용해야 한다면, 복제 사용자에게 SSL 연결이 반드시 필요합니다. 예를 들어, 다음 문 중 하나를 사용하여 사용자 계정 repl_user에서 SSL을 연결합니다.

GRANT USAGE ON *.* TO 'repl_user'@'<domain_name>' REQUIRE SSL;
참고

REQUIRE SSL이 포함되어 있지 않다면, 복제 연결이 자동으로 암호화되지 않은 연결로 돌아갈 수 있습니다.

다음 데이터베이스 엔진의 복제를 활성화하는 방법에 대한 지침을 확인하십시오.

데이터베이스 엔진 지침

Aurora

Aurora MySQL DB 클러스터에서 복제를 활성화하려면

  1. DB 클러스터 스냅샷에서 DB 클러스터 복제본 대상을 생성한 경우 DB 클러스터 복제본 대상에 연결하고 SHOW MASTER STATUS 명령을 실행합니다. File 필드에서 현재 이진 로그 파일 이름을 검색하고 Position 필드에서 로그 파일 위치를 검색합니다.

    DB 스냅샷에서 DB 클러스터 복제본 대상을 생성한 경우 복제 시작 위치에 해당하는 binlog 파일 및 binlog 위치가 필요합니다. 복제 소스의 스냅샷을 생성할 때 SHOW SLAVE STATUS 명령에서 이 값을 검색했습니다.

  2. DB 클러스터에 연결하고 mysql_rds_set_external_master 프로시저와 mysql_rds_start_replication 프로시저를 실행하여 이전 단계의 이진수 로그 파일 이름과 위치를 사용하여 복제 소스로 복제를 시작합니다. 다음은 예제입니다.

    CALL mysql.rds_set_external_master ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); CALL mysql.rds_start_replication;

RDS for MySQL

Amazon RDS DB 인스턴스에서 복제를 활성화하려면

  1. DB 스냅샷에서 DB 인스턴스 복제본 대상을 생성한 경우 복제 시작 위치에 해당하는 binlog 파일 및 binlog 위치가 필요합니다. 복제 소스의 스냅샷을 생성할 때 SHOW SLAVE STATUS 명령에서 이 값을 검색했습니다.

  2. DB 인스턴스에 연결하고 mysql_rds_set_external_master 프로시저와 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;

MySQL(외부)

외부 MySQL 데이터베이스에서 복제를 활성화하려면

  1. 복제 시작 위치에 해당하는 binlog 파일 및 binlog 위치를 검색합니다. 복제 소스의 스냅샷을 생성할 때 SHOW SLAVE STATUS 명령에서 이 값을 검색했습니다. 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 TOSTART SLAVE를 실행하여 이전 단계의 이진수 로그 파일 이름과 위치를 사용하여 복제 소스로 복제를 시작합니다.

    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; START SLAVE;

6. 복제본 모니터링

Aurora MySQL DB 클러스터를 사용하여 MySQL 복제를 설정한 경우 복제본 대상인 Aurora MySQL DB 클러스터에 대한 장애 조치 이벤트를 모니터링해야 합니다. 장애 조치가 발생할 경우에는 복제본 대상인 DB 클러스터가 다른 네트워크 주소를 가진 새 호스트에서 다시 생성될 수도 있습니다. 장애 조치 이벤트를 모니터링하는 자세한 방법은 Amazon RDS 이벤트 알림 서비스 사용 단원을 참조하십시오.

또한 복제본 대상에 연결하고 SHOW SLAVE STATUS 명령을 실행하여 복제본 대상이 복제 소스보다 얼마나 지연되었는지 모니터링할 수 있습니다. 명령 출력의 Seconds Behind Master 필드는 복제본 대상이 소스보다 얼마나 지연되었는지 알려줍니다.

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

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

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

2. 복제 소스에 대한 이진 로깅 비활성화

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

다음 데이터베이스 엔진의 이진 로그 복제를 중지하는 방법에 대한 지침을 확인하십시오.

데이터베이스 엔진 지침

Aurora

Aurora MySQL DB 클러스터 복제본 대상에 대한 이진 로그 복제를 중지하는 방법

복제본 대상인 Aurora DB 클러스터에 연결하고, mysql_rds_stop_replication 프로시저를 호출합니다. mysql.rds_stop_replication 프로시저는 MySQL 5.5 이상, 5.6 이상, 5.7 이상 버전에서만 사용할 수 있습니다.

RDS for MySQL

Amazon RDS DB 인스턴스에 대한 이진 로그 복제를 중지하는 방법

복제본 대상인 RDS DB 클러스터에 연결하고, mysql_rds_stop_replication 프로시저를 호출합니다. mysql.rds_stop_replication 프로시저는 MySQL 5.5 이상, 5.6 이상, 5.7 이상 버전에서만 사용할 수 있습니다.

MySQL(외부)

외부 MySQL 데이터베이스에서 이진 로그 복제를 중지하는 방법

MySQL 데이터베이스에 연결하고 STOP REPLICATION 명령을 호출합니다.

2. 복제 소스에 대한 이진 로깅 비활성화

다음 데이터베이스 엔진의 복제 소스에 대한 이진 로깅을 비활성화하는 방법의 지침을 확인하십시오.

데이터베이스 엔진 지침

Aurora

Amazon Aurora DB 클러스터에 대한 이진 로깅을 비활성화하는 방법

  1. 복제 소스인 Aurora DB 클러스터에 연결하고, 이진 로그 보존 시간 프레임을 0으로 설정합니다. 이진 로그 보관 기간을 설정하려면, 다음 예제와 같이 mysql_rds_set_configuration 프로시저를 사용하여 'binlog retention hours' 구성 파라미터를 DB 클러스터에 binlog 파일을 보관할 시간(이 예제에서는 0)과 함께 지정합니다.

    CALL mysql.rds_set_configuration('binlog retention hours', 0);
  2. 복제 소스에서 binlog_format 파라미터를 OFF로 설정합니다. binlog_format 파라미터는 기본 클러스터 파라미터 그룹에 속하는 클러스터 수준 파라미터입니다.

    binlog_format 파라미터 값을 변경한 후에는 DB 클러스터를 재부팅해야만 변경 사항이 적용됩니다.

    자세한 내용은 Amazon Aurora DB 클러스터와 DB 인스턴스 파라미터DB 파라미터 그룹의 파라미터 수정 단원을 참조하십시오.

RDS for MySQL

Amazon RDS DB 인스턴스에 대한 이진 로깅을 비활성화하려면

Amazon RDS DB 인스턴스에 대한 이진 로깅을 직접 비활성화할 수는 없지만, 다음을 수행하여 비활성화할 수 있습니다.

  1. DB 인스턴스의 자동 백업을 비활성화합니다. 기존 DB 인스턴스를 수정하고 백업 보존 기간을 0으로 설정하여 자동 백업을 비활성화할 수 있습니다. 자세한 내용은 Amazon Relational Database Service 사용 설명서Amazon RDS DB 인스턴스 수정백업 작업을 참조하십시오.

  2. DB 인스턴스의 읽기 전용 복제본을 모두 삭제합니다. 자세한 정보는 Amazon Relational Database Service 사용 설명서에서 MariaDB, MySQL, PostgreSQL DB 인스턴스의 읽기 전용 복제본 사용을 참조하십시오.

MySQL(외부)

외부 MySQL 데이터베이스에 대한 이진 로깅을 비활성화하는 방법

MySQL 데이터베이스에 연결하고 STOP REPLICATION 명령을 호출합니다.

  1. 명령 셸에서 mysqld 서비스를 중지합니다.

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

    sudo vi /etc/my.cnf

    log_bin 섹션에서 server_id [mysqld]옵션을 삭제합니다.

    자세한 내용은 MySQL 설명서에서 Setting the replication master configuration 섹션을 참조하세요.

  3. mysql 서비스를 시작합니다.

    sudo service mysqld start

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를 유지 관리합니다. 이렇게 유지 관리해야 오류 발생 시 라이터 인스턴스를 복원할 수 있습니다.

중요

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

참고

Amazon Aurora MySQL DB 클러스터에서 복제를 시작하는 데 필요한 권한이 제한되고 Amazon RDS 마스터 사용자를 사용할 수 없습니다. 이 때문에 Amazon RDS mysql_rds_set_external_master mysql_rds_start_replication 절차를 사용하여 Amazon Aurora MySQL DB 클러스터와 MySQL DB 인스턴스 간 복제를 설정해야 합니다.

외부 소스 인스턴스와 Amazon RDS의 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 인스턴스로 데이터 가져오기 절차를 사용하려고 할 수도 있습니다.

    Linux, macOS 또는 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 master or slave 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 절차를 사용하여 원본 MySQL 데이터베이스를 식별하십시오. 2단계에서 결정한 마스터 로그 파일 이름과 마스터 로그 위치를 사용합니다. 다음은 예제입니다.

    CALL mysql.rds_set_external_master ('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 설명서의 복제 구현 단원을 참조하십시오.

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.04.5~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.04.5부터 2.09.*까지 이러한 파라미터를 사용할 수 있습니다. Aurora MySQL 2.10.0 이상에서는 이러한 파라미터가 binlog I/O 캐시 최적화로 대체되므로 사용할 필요가 없습니다.

MySQL 5.6 호환 클러스터의 경우 Aurora MySQL 버전 1.17.6 이상에서 이러한 파라미터를 사용할 수 있습니다.

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

클러스터가 많은 수의 트랜잭션을 처리하는 동안 이진 로그 덤프 스레드가 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 MySQL 버전 2.04.5 이상에 대한 Binlog 최적화 파라미터
파라미터 기본값 유효한 값 설명
aurora_binlog_use_large_read_buffer 1 0, 1 복제 개선 기능을 켜기 위한 스위치. 1이면 이진 로그 덤프 스레드는 이진 로그 복제에 aurora_binlog_read_buffer_size를 사용합니다. 그렇지 않으면 기본 버퍼 크기 (8K) 가 사용됩니다.
aurora_binlog_read_buffer_size 5242880 8192-536870912 파라미터 aurora_binlog_use_large_read_buffer가 1로 설정된 경우 이진 로그 덤프 스레드가 사용하는 버퍼 크기를 읽습니다.
aurora_binlog_replication_max_yield_seconds 0 0-36000 2.04.5 - 2.04.8 사이의 Aurora MySQL 버전과 2.05 - 2.08.* 사이의 버전 (포함) 의 경우 허용되는 최대 값은 45입니다. 2.04.9 및 2.04.*의 이후 버전, 그리고 2.09 및 그 이후 버전에서 더 높은 값으로 조정할 수 있습니다. 이 파라미터는 파라미터 aurora_binlog_use_large_read_buffer가 1로 설정된 경우에만 작동합니다.
Aurora MySQL 버전 1.17.6 이상에 대한 Binlog 최적화 파라미터
파라미터 기본값 유효한 값 설명
aurora_binlog_use_large_read_buffer 0 0, 1 복제 개선 기능을 켜기 위한 스위치. 1이면 이진 로그 덤프 스레드가 이진 로그 복제에 aurora_binlog_read_buffer_size를 사용합니다. 그렇지 않으면 기본 버퍼 크기 (8KB) 가 사용됩니다.
aurora_binlog_read_buffer_size 5242880 8192-536870912 파라미터 aurora_binlog_use_large_read_buffer가 1로 설정된 경우 이진 로그 덤프 스레드가 사용하는 버퍼 크기를 읽습니다.
aurora_binlog_replication_max_yield_seconds 0 0-36000 이진 로그 덤프 스레드가 현재 binlog 파일 (전경 쿼리에 사용되는 파일) 을 복제본에 복제할 때 산출하는 최대 시간 (초) 입니다. 이 파라미터는 파라미터 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 클러스터와 연결합니다. 이 작업을 수행하려면 DB 파라미터 그룹 및 DB 클러스터 파라미터 그룹 작업의 절차를 따르십시오.

  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으로 설정되어 있는지 확인합니다. 파라미터 그룹을 사용한 구성 파라미터 설정에 대한 자세한 내용은 DB 파라미터 그룹 및 DB 클러스터 파라미터 그룹 작업 단원을 참조하십시오.

  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으로 설정되어 있는지 확인합니다. 파라미터 그룹을 사용한 구성 파라미터 설정에 대한 자세한 내용은 DB 파라미터 그룹 및 DB 클러스터 파라미터 그룹 작업 단원을 참조하십시오.

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

    SELECT @@ aurora_binlog_use_large_read_buffer;

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

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

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

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

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