Amazon Relational Database Service
사용 설명서 (API 버전 2014-10-31)

MariaDB 읽기 전용 복제본 작업

이 단원에는 Amazon RDS MariaDB의 읽기 전용 복제본 작업에 대한 자세한 정보가 포함되어 있습니다. 읽기 전용 복제본에 대한 일반적인 정보와 사용 지침은 MariaDB, MySQL 및 PostgreSQL DB 인스턴스의 읽기 전용 복제본 작업 단원을 참조하십시오.

MariaDB를 사용한 읽기 전용 복제본 구성

MariaDB DB 인스턴스를 복제 원본으로 사용하려면 백업 보존 기간을 0이 아닌 다른 값으로 설정하여 원본 DB 인스턴스의 자동 백업을 활성화해야 합니다. 이러한 요건은 다른 읽기 전용 복제본의 원본 DB 인스턴스인 읽기 전용 복제본에도 똑같이 적용됩니다.

DB 인스턴스 하나에서 최대 5개까지 읽기 전용 복제본을 생성할 수 있습니다. 효과적인 복제를 위해서는 읽기 전용 복제본도 각각 원본 DB 인스턴스와 동일한 용량의 컴퓨팅 파워와 스토리지 리소스를 가져야 합니다. 원본 DB 인스턴스를 확장하면 읽기 전용 복제본도 확장해야 합니다.

읽기 전용 복제본이 모든 버전의 MariaDB 기반인 경우에는 읽기 전용 복제본을 다른 읽기 전용 복제본의 원본 DB 인스턴스로 지정할 수 있습니다. 예를 들어 MyDBInstance에서 ReadReplica1을 생성한 후 다시 ReadReplica1에서 ReadReplica2를 생성할 수 있습니다. MyDBInstance의 업데이트는 ReadReplica1에도 복제되며, 다시 한 번 ReadReplica1에서 ReadReplica2로 복제됩니다. 하지만 복제 체인에 포함될 수 있는 인스턴스는 최대 4개로 제한됩니다. 예를 들어 MySourceDBInstance에서 ReadReplica1을 생성한 후 다시 ReadReplica1에서 ReadReplica2를 생성하고, ReadReplica2에서 ReadReplica3을 생성할 수 있지만 ReadReplica3에서 ReadReplica4를 생성할 수는 없습니다.

MariaDB 읽기 전용 복제본을 다른 읽기 전용 복제본으로 복제할 수 있도록 승격한 경우 이 읽기 전용 복제본은 활성화 상태를 유지합니다. MyDBInstance1이 MyDBInstance2로, 그리고 MyDBInstance2가 다시 MyDBInstance3으로 복제된다고 예를 들어보겠습니다. 이때 MyDBInstance2를 승격하는 경우 MyDBInstance1에서 MyDBInstance2로는 더 이상 복제가 이루어지지 않습니다. 하지만 MyDBInstance2는 여전히 MyDBInstance3으로 복제됩니다.

Amazon RDS MariaDB 읽기 전용 복제본에서 자동 백업을 활성화하려면 먼저 읽기 전용 복제본을 생성한 다음 자동 백업이 활성화되도록 읽기 전용 복제본을 변경해야 합니다.

읽기 전용 복제본이 원본 인스턴스의 한계치인 5개를 벗어나지 않는 경우에 한해 다수의 읽기 전용 복제본을 동시에 실행하거나, 동일한 원본 DB 인스턴스를 참조하는 작업은 생성 또는 삭제할 수도 있습니다.

MariaDB를 사용한 읽기 전용 복제본 업데이트

읽기 전용 복제본은 읽기 쿼리를 지원하도록 설계되었지만 때때로 업데이트가 필요할 수 있습니다. 예를 들어 특정 유형의 쿼리가 복제본에 액세스하는 속도를 높이기 위해 인덱스를 추가해야 할 경우가 있습니다. 업데이트를 활성화하려면 읽기 전용 복제본의 DB 파라미터 그룹에서 read_only 파라미터를 0으로 설정합니다.

MariaDB를 사용한 다중 AZ 읽기 전용 복제본 배포

읽기 전용 복제본은 단일 AZ 또는 다중 AZ DB 인스턴스 배포를 통해서도 생성할 수 있습니다. 다중 AZ 배포는 중요 데이터의 내구성과 가용성을 개선하는 데 효과적이지만 읽기 전용 쿼리를 실행하는 데 보조로 사용할 수는 없습니다. 그 대신 읽기 전용 쿼리 부하를 줄일 목적으로 트래픽이 많은 다중 AZ DB 인스턴스에서 읽기 전용 복제본을 생성할 수 있습니다. 다중 AZ 배포의 원본 인스턴스가 보조 인스턴스로 장애 조치된 경우에는 연결된 모든 읽기 전용 복제본이 자동으로 전환되어 보조(이제는 기본) 인스턴스를 복제 원본으로 사용합니다. 자세한 내용은 Amazon RDS를 위한 고가용성(다중 AZ) 단원을 참조하십시오.

읽기 전용 복제본을 Multi-AZ DB 인스턴스를 생성할 수 있습니다. Amazon RDS는 복제본에 대한 장애 조치 지원을 위해 다른 가용 영역에 복제본의 대기를 생성합니다. 읽기 전용 복제본을 다중 AZ DB 인스턴스로 생성하는 작업은 원본 데이터베이스가 다중 AZ DB 인스턴스인지 여부와는 독립적입니다.

MariaDB 읽기 전용 복제본 모니터링

MariaDB 읽기 전용 복제본의 경우 Amazon RDS ReplicaLag 지표를 보면서 Amazon CloudWatch의 복제 지연을 모니터링할 수 있습니다. ReplicaLag 지표는 SHOW SLAVE STATUS 명령의 Seconds_Behind_Master 필드의 값을 보고합니다.

이렇게 MariaDB에서 복제 지연이 발생하는 공통 원인은 다음과 같습니다.

  • 네트워크 중단.

  • 읽기 전용 복제본 관련 인덱스를 할당하여 테이블에 쓰기 작업 중일 때. 읽기 전용 복제본에서 read_only 파라미터가 0으로 설정되어 있지 않으면 복제가 중단될 수 있습니다.

  • MyISAM과 같은 비트랜잭션 스토리지 엔진 사용. 복제는 MariaDB 10.2 이상의 InnoDB 스토리지 엔진 및 MariaDB 10.1 이전 XtraDB 스토리지 엔진에 대해서만 지원됩니다.

ReplicaLag 지표가 0에 도달하면 복제본이 원본 DB 인스턴스를 따라잡은 것입니다. ReplicaLag 지표가 -1을 반환하는 경우 복제가 현재 활성이 아닙니다. ReplicaLag = -1은 Seconds_Behind_Master = NULL​과 동등합니다.

MariaDB 읽기 전용 복제본을 사용한 복제 시작 및 중지

Amazon RDS DB 인스턴스에서는 시스템에 저장된 프로시저인 mysql.rds_stop_replication과(와) mysql.rds_start_replication을 호출하여 복제 프로세스를 종료하거나 재시작할 수 있습니다. 대용량 인덱스를 생성하는 등 오랜 시간이 걸리는 작업에서 두 Amazon RDS 인스턴스를 서로 복제할 때도 이런 방법이 가능합니다. 또한 데이터베이스를 가져오거나 내보낼 때도 복제를 종료하거나 시작할 필요가 있습니다. 자세한 내용은 가동 중지 시간을 단축하여 Amazon RDS MySQL MariaDB DB 인스턴스로 데이터 가져오기복제를 사용하여 MySQL DB 인스턴스에서 데이터 내보내기 단원을 참조하십시오.

수동으로, 혹은 복제 오류로 인해 연속하여 30일 이상 복제가 중단된 경우에는 Amazon RDS가 마스터 DB 인스턴스와 모든 읽기 전용 복제본 사이의 복제를 종료합니다. 이렇게 하는 이유는 마스터 DB 인스턴스에 대한 스토리지 요건 증가와 장애 조치의 장기화를 방지하기 위해서입니다. 이후에도 읽기 전용 복제본 DB 인스턴스는 여전히 사용할 수 있습니다. 하지만 읽기 전용 복제본에서 필요한 이진 로그가 복제 종료와 함께 마스터 DB 인스턴스에서 삭제되어 복제를 재개할 수 없습니다. 마스터 DB 인스턴스에서 복제를 재개하려면 새로운 읽기 전용 복제본을 생성해야 합니다.

MariaDB를 사용한 읽기 전용 복제본 삭제

읽기 전용 복제본을 삭제할 때는 DB 인스턴스를 삭제할 때와 똑같은 메커니즘으로 명시적이어야 합니다. 원본 DB 인스턴스만 삭제하고 복제본을 삭제하지 않으면 각 복제본은 독립 실행형 DB 인스턴스로 승격됩니다.

MariaDB 읽기 전용 복제본의 문제 해결

MariaDB의 복제본 기술은 비동기적입니다. 간혹 원본 DB 인스턴스에서 BinLogDiskUsage가 증가하면 읽기 전용 복제본의 ReplicaLag가 예상되는 이유도 비동기식이기 때문입니다. 예를 들어 원본 DB 인스턴스에 대해 대량의 쓰기 작업이 동시에 발생할 수 있습니다. 반대로 읽기 전용 복제본에 대한 쓰기 작업은 단일 I/O 스레드를 사용하기 때문에 연이어 차례로 발생합니다. 이로 인해 원본 인스턴스와 읽기 전용 복제본 사이에 지연 시간이 있기 마련입니다. 읽기 전용 복제본에 대한 자세한 내용은 MariaDB 설명서에서 Replication Overview 단원을 참조하십시오.

원본 DB 인스턴스와 뒤이어 일어나는 읽기 전용 복제본의 업데이트 간 지연 시간을 줄일 수 있는 방법이 몇 가지 있으며, 다음과 같습니다.

  • 읽기 전용 복제본의 크기를 조정하여 원본 DB 인스턴스에 버금가는 스토리지 크기와 DB 인스턴스 클래스를 할당합니다.

  • 원본 DB 인스턴스와 읽기 전용 복제본에 사용되는 DB 파라미터 그룹의 파라미터 설정이 서로 호환되는지 확인합니다. 자세한 정보와 예는 이번 섹션 후반의 max_allowed_packet 파라미터 관련 설명을 참조하십시오.

Amazon RDS는 읽기 전용 복제본의 복제 상태를 모니터링하고, 어떤 이유로든 복제가 중지되는 경우 읽기 전용 복제본 인스턴스의 Replication State 필드를 Error로 업데이트합니다. 읽기 전용 복제본에 대한 DML 쿼리가 원본 DB 인스턴스의 업데이트와 충돌하는 경우가 한 예가 될 수 있습니다.

MariaDB 엔진에서 발생하는 관련 오류에 대한 세부 정보는 Replication Error 필드에서 다시 확인할 수 있습니다. RDS-EVENT-0045, RDS-EVENT-0046RDS-EVENT-0047을 포함하여 읽기 전용 복제본의 상태를 표시하는 이벤트도 생성됩니다. 이벤트와 이벤트 구독에 대한 자세한 내용은 Amazon RDS 이벤트 알림 서비스 사용 단원을 참조하십시오. MariaDB 오류 메시지가 반환되는 경우 MariaDB 오류 메시지 문서에 설명되어 있는 오류를 검토하십시오.

복제 오류의 원인이 되는 공통적인 문제를 하나 꼽으라고 하면 읽기 전용 복제본의 max_allowed_packet 파라미터 값이 원본 DB 인스턴스의 max_allowed_packet 파라미터 값보다 작을 때입니다. max_allowed_packet 파라미터는 DB 파라미터 그룹에서 사용자가 직접 설정할 수 있는 파라미터로서 데이터베이스에서 실행할 수 있는 DML 코드의 최대 크기를 지정하는 데 사용됩니다. 경우에 따라 원본 DB 인스턴스와 연결된 DB 파라미터 그룹에서 max_allowed_packet 파라미터 값이 원본의 읽기 전용 복제본과 연결된 DB 파라미터 그룹에서 max_allowed_packet 파라미터 값보다 작습니다. 이러한 경우에는 복제 프로세스에서 오류(패킷이 'max_allowed_packet' 바이트보다 큼)가 발생하여 복제가 중단될 수도 있습니다. 원본 및 읽기 전용 복제본이 같은 max_allowed_packet 파라미터 값을 가진 DB 파라미터 그룹을 사용하도록 하여 이 오류를 수정할 수 있습니다.

이밖에 복제 오류의 원인이 되는 공통적인 상황은 다음과 같습니다.

  • 읽기 전용 복제본의 테이블에 쓰기 작업을 실행하는 경우. 읽기 전용 복제본에서 인덱스를 만들 때는 read_only 파라미터를 0으로 설정해야 합니다. 읽기 전용 복제본의 테이블에 데이터를 쓰면 복제가 중단될 수 있습니다.

  • MyISAM 같은 비트랜잭션 스토리지 엔진을 사용할 때. 읽기 전용 복제본에는 트랜잭션 스토리지 엔진이 필요합니다. 복제는 MariaDB 10.2 이상의 InnoDB 스토리지 엔진 및 MariaDB 10.1 이전 XtraDB 스토리지 엔진에 대해서만 지원됩니다.

  • SYSDATE()와 같이 안전하지 않은 비결정적 쿼리를 사용하는 경우. 자세한 내용은 Determination of Safe and Unsafe Statements in Binary Logging을 참조하십시오.

오류를 건너뛰어도 안전하다고 판단될 경우에는 현재 복제 오류 넘어가기 섹션에 설명한 단계를 따르십시오. 그 밖에 읽기 전용 복제본을 삭제하고 엔드포인트가 이전 읽기 전용 복제본의 엔드포인트와 동일하게 유지되도록 같은 DB 인스턴스 식별자를 사용하여 인스턴스를 생성할 수도 있습니다. 복제 오류가 해결되면 Replication Statereplicating으로 변경됩니다.

MariaDB DB 인스턴스에서는 경우에 따라 읽기 전용 복제본을 보조 인스턴스로 전환하지 못할 수도 있습니다. 이는 일부 binlog 이벤트가 오류로 인해 플러시되지 않기 때문입니다. 이때는 수동으로 읽기 전용 복제본을 삭제한 후 다시 생성해야 합니다. 다음 동적 변수 값을 설정하여 발생하는 이러한 가능성을 줄일 수 있습니다: sync_binlog=1, innodb_flush_log_at_trx_commit=1innodb_support_xa=1. 단, 이 설정은 성능 감소의 원인이 될 수도 있으므로 변경 사항을 프로덕션 환경에 적용하기 전에 그 효과를 테스트하는 것이 좋습니다.