Amazon RDS for MySQL의 Active/Active 복제를 위한 Group Replication 플러그인 소개

이 글은 AWS Database Delivery Blog에 게시된 Introducing Group Replication plugin for active/active replication on Amazon RDS for MySQL by Mershad Irani and Vijay Karumajji 을 한국어 번역 및 편집하였습니다.

Amazon Relational Database Service (Amazon RDS) for MySQL 은 이제 Active/Active (활성/활성) 복제를 위한 Group Replication 플러그인을 지원합니다. 이 플러그인을 사용하여 RDS for MySQL 데이터베이스 인스턴스 간에 Active/Active 복제를 설정하여 애플리케이션에 지속적인 가용성을 제공할 수 있습니다. Active/Active 클러스터의 두 개 이상의 데이터베이스 인스턴스에 쓰기를 수행함으로써 가용성을 극대화하고 쓰기 대기 시간을 감소시킬 수 있습니다. Group Replication 플러그인을 사용하여 최대 9개의 Amazon RDS for MySQL 인스턴스 간에 Active/Active 복제를 구성할 수 있습니다. Group Replication 플러그인은 Amazon RDS for MySQL 8.0.35 및 높은 버전에서 사용할 수 있습니다.

이 글에서는 MySQL Group Replication, 사용 사례, 구성, 응용 프로그램 수준 고려 사항, 그리고 현대적인 데이터베이스 관리에서의 중요성에 대해 논의합니다.

Group Replication 소개

MySQL Group Replication 플러그인은 Paxos 분산 알고리즘의 구현을 기반으로 한 커뮤니티 플러그인으로, 최대 아홉 개의 데이터베이스 (DB) 인스턴스를 Active/Active 설정으로 구성할 수 있습니다. 어떤 트랜잭션이든 전체 트랜잭션 시퀀스에서 주어진 트랜잭션의 순서에 대한 합의가 ‘그룹’의 대다수의 DB 인스턴스에서 이뤄져야만 커밋됩니다.

RDS for MySQL 인스턴스에 Group Replication 플러그인을 사용하여 설정된 Active/Active 클러스터는 Multi-Primary 모드 에서 그룹 복제를 사용합니다. Multi-Primary 모드에서 클러스터의 일부인 모든 인스턴스는 클러스터에 가입할 때 읽기-쓰기 모드로 설정됩니다. Multi-Primary 모드는 내장 충돌 감지/처리 및 일관성 보장이 포함된 거의 동기화된 복제를 제공합니다. 인스턴스에 Group Replication을 구성했지만 클러스터에 성공적으로 참여할 수 없는 경우, 해당 인스턴스는 자동으로 읽기 전용 모드로 설정됩니다. 자세한 내용은 MySQL 사용자 가이드의 Group Replication 을 참조하십시오.

다음 이미지는 Group Replication 아키텍처를 설명합니다:

그룹 복제 플러그인을 사용한 Active/Active 복제 사용 사례

이 섹션에서는 Active/Active 복제의 일반적인 사용 사례에 대해 논의합니다.

지속적인 가용성 – 현대의 빠르게 변화하는 경쟁적인 비즈니스 환경에서 조직은 중요한 응용 프로그램 및 서비스에 대한 중단 없는 액세스를 보장하기 위해 데이터베이스 및 데이터 시스템에 의존합니다. Group Replication 플러그인을 사용하여 Active/Active 복제를 설정하면 기업은 여러 데이터베이스 인스턴스 간에 데이터 일관성과 높은 가용성을 유지할 수 있습니다. 여러 데이터베이스 인스턴스에 걸쳐 Active/Active 복제를 구성하고 읽기 및 쓰기 작업을 분산함으로써 기업은 하드웨어 오류, 네트워크 연결 문제 또는 계획된 유지 관리 이벤트가 발생하는 경우 하나 이상의 DB 인스턴스에서 데이터에 계속 액세스할 수 있도록 보장할 수 있습니다. 이러한 클러스터 토폴로지는 내결함성을 향상시킬 뿐만 아니라 Active/Active 인스턴스 간에 작업 부하를 균일하게 분산시키는 로드 밸런싱 기능도 제공합니다. 그룹 내의 한 인스턴스를 사용할 수 없게 되면 커넥터, 로드 밸런서, 라우터 또는 미들웨어를 사용하여 연결된 클라이언트를 Active/Active 클러스터의 사용 가능한 다른 DB 인스턴스로 리디렉션해야 합니다. 결과적으로 기업은 지속적인 가용성을 달성하고 다운타임을 최소화하여 최종 사용자에게 원활한 사용자 경험을 제공할 수 있습니다.

Follow-the-sun 모델 – Group Replication을 사용한 Active/Active 복제는 종종 애플리케이션에 대한 ‘태양을 따라가는’ 모델을 구현하는 데 사용됩니다. Group Replication 플러그인은 데이터 복제 일관성 과 모든 Active/Active 클러스터의 DB 인스턴스에 일관된 복사본이 사용 가능하도록 하는 흐름 제어 메커니즘을 갖추고 있습니다. 애플리케이션은 현재 시간이 낮인 위치로 active 기본 인스턴스를 동적으로 이동시킬 수 있어 피크 기간 동안의 쓰기 성능을 최적화할 수 있습니다. 더 나아가 나머지 DB 인스턴스 간에 읽기를 로드 밸런싱하여 읽기 지연 시간을 최적화할 수 있습니다.

그룹 복제 플러그인을 사용하는 Active/Active 클러스터에 대한 모범 사례 및 주요 고려 사항

이 섹션에서는 Group Replication 플러그인을 사용한 Active/Active 클러스터에 대한 모범 사례에 대해 논의합니다.

DB 인스턴스의 수 – 워크로드 및 고가용성 요구 사항을 기반으로 Active/Active 클러스터의 DB 인스턴스 수를 선택하십시오. 홀수 개의 DB 인스턴스를 권장하며 네트워크 파티션이 발생한 경우에도 대다수를 확립할 수 있도록합니다. 예를 들어 5개 노드로 구성 된 Active/Active 클러스터에서 네트워크 파티션을 통해 노드가 각각 3개와 2개의 그룹으로 나뉜 경우 여전히 대다수 쿼럼을 확립할 수 있으므로, 쓰기는 3개 노드 그룹으로 계속할 수 있습니다. 그러나 6개 노드 클러스터에 대해서 클러스터가 각 3개의 노드로 네트워크 파티션이 나뉜 경우 쿼럼을 확립할 수 없습니다.

읽기/쓰기 분할 – Active/Active 클러스터에서 응용 프로그램 성능을 최적화하려면 클러스터의 DB 인스턴스 간에 읽기 및 쓰기를 분할할 수 있습니다. 애플리케이션의 트랜잭션 패턴을 평가하고 읽기 요청을 가까운 DB 인스턴스로 라우팅하여 지연 시간을 줄입니다. 이 접근 방식을 사용하면 처리량이 향상되고 대기 시간이 단축됩니다. 지속적인 모니터링과 조정을 통해 응용 프로그램은 변화하는 워크로드 패턴에 적응하고 효과적으로 로드를 분산할 수 있습니다.

연결 풀링 – 데이터베이스 연결을 효율적으로 관리하고 모든 요청에 대해 새 연결을 설정하는 오버헤드를 줄이기 위해 연결 풀링을 구현합니다.

오류 처리 – 애플리케이션은 Active/Active 복제 작업 시 강력한 오류 처리를 구현해야 합니다. 네트워크 문제 또는 일시적인 중단으로 인해 연결 오류 또는 트랜잭션 실패가 발생할 수 있습니다. 애플리케이션 계층에서 재시도 논리와 지수 백오프를 구현하면 일시적인 오류를 원활하게 처리할 수 있습니다. 교착 상태와 같은 분산 동시성 문제의 경우 애플리케이션 코드에서 재시도를 자동화하세요. 지연으로 인한 인증 실패와 같은 오류를 적극적으로 모니터링하고 조사를 위해 경고합니다. 재조인 시도 중 로그에서 경고 수준 (Warning level) 의 오류를 감시하세요. 다재다능한 오류 처리는 애플리케이션의 지속적인 가용성을 유지하고 심각한 오류를 사전에 발견하는 데 도움이 됩니다.

트랜잭션 크기 – group_replication_transaction_size_limit 매개변수를 설정하기 전에 애플리케이션의 트랜잭션 크기 분포 및 패턴을 측정합니다. 이 제한은 복제 지연을 줄이는 데 도움이 될 수 있는 트랜잭션 크기를 제어합니다. 이 매개변수의 기본값은 150,000,000 bytes 입니다. 이 제한에 맞는 작은 트랜잭션을 생성하는 OLTP 애플리케이션은 대기 시간 급증을 방지할 수 있습니다. 그러나 대규모 배치를 수정하거나 삽입하는 워크로드에는 더 큰 트랜잭션이 필요할 수 있습니다. 제한을 너무 낮게 설정하거나 기본값으로 두면 중요한 애플리케이션 트랜잭션이 예기치 않게 실패할 수 있습니다. 동시에 한도가 너무 높으면 복제본의 트랜잭션 백로그 및 메모리 부족 문제가 발생할 수 있습니다. 선택한 인스턴스 클래스에 사용 가능한 메모리가 충분하지 않은 경우 이 변수를 늘리는 대신 데이터 수정 사항을 더 작은 배치로 일괄 처리하는 것이 좋습니다. 이 제한은 Active/Active 클러스터의 모든 DB 인스턴스에 걸쳐 일관되게 구성되어야 합니다. 애플리케이션의 성능과 복제 처리량을 최적화하려면 이 매개변수를 사전에 조정하는 것이 중요합니다.

계단식 외래 키 제약 조건 – 그룹 복제를 사용하는 Active/Active 클러스터에서는 데이터 불일치를 방지하기 위해 group_replication_enforce_update_everywhere_checks 매개변수가 기본적으로 ON으로 설정됩니다.

이 변수의 값이 ON으로 설정되면 애플리케이션이 계단식 외래 키 제약 조건이 있는 테이블에서 DML을 수행하지 못할 수 있다는 점에 유의하는 것이 중요합니다. 이 매개변수를 비활성화하면 데이터 수정에 더 많은 유연성이 허용되지만 제대로 관리되지 않으면 데이터 불일치가 발생할 수도 있습니다. Active/Active 클러스터에서 계단식 외래 키 제약 조건 사용을 고려할 때 애플리케이션 내에서 데이터 무결성과 일관성을 유지하기 위해 적절한 예방 조치를 취해야 합니다. 이 파라미터를 OFF로 설정할 계획이라면 애플리케이션 내에서 충돌 관리를 수행하는 것이 좋습니다. 예를 들어 여러 DB 인스턴스의 동일한 테이블에 대해 트랜잭션을 실행하지 않는 것이 좋습니다. 복잡한 데이터 관계가 있는 Active/Active 클러스터를 관리하려면 다양한 구성 및 매개변수 설정에서 애플리케이션의 동작을 테스트하고 이해하는 것이 필수적입니다.

오류 감지 매개변수 – 애플리케이션에 대한 오류 허용 범위를 정의하기 위해 조정해야 하는 세 가지 오류 감지 매개변수가 있습니다.

a) Group_replication_member_expel_timeout: 그룹 복제 플러그인을 사용하는 Active/Active 클러스터의 인스턴스는 일시적인 네트워크 문제에 직면하거나 리소스 병목 현상으로 인해 응답하지 않아 클러스터의 DB 인스턴스가 클러스터의 다른 DB 인스턴스와의 통신이 일시적으로 끊어질 수 있습니다. 클러스터가 응답하지 않는 DB 인스턴스를 식별하는 데 몇 초 정도 걸릴 수 있습니다. 인스턴스 식별이 되면 ‘suspicion (의심)‘ 상태의 DB 인스턴스가 확인됩니다. 의심스러운 DB 인스턴스는 기본적으로 5초 후에 그룹 복제에서 추방됩니다. group_replication_member_expel_timeout 매개변수를 수정하여 추방 제한 시간을 구성할 수 있습니다. group_replication_member_expel_timeout 을 늘리면 응답하지 않는 DB 인스턴스가 ‘그룹’ 에서 추방되기 전에 복구할 수 있는 기회를 허용합니다. 더 긴 시간 초과를 선택하면 짧은 네트워크 중단이나 일시적인 응답 없음을 경험하는 DB 인스턴스에 도움이 될 수 있습니다. 그러나 이 제한 시간을 매우 큰 값으로 늘리면 나머지 정상 DB 인스턴스 내에 과반수 쿼럼이 설정된 경우에도 쓰기를 차단할 수 있는 실패한 DB 인스턴스 감지가 지연될 수 있습니다.

b) Group_Replication_AutoRejoin_Tries: 인스턴스가 Active/Active 클러스터에서 추방되면 DB 인스턴스는 기본적으로 최대 3번 ‘그룹’에 재가입을 시도합니다. 그룹에 참여하기 위한 연속 재시도 사이에는 5분 간격이 있습니다. 내결함성에 따라 group_replication_autorejoin_tries 매개변수를 조정하여 재시도 횟수를 늘리거나 줄일 수 있습니다. 정의된 횟수만큼 시도한 후에도 DB 인스턴스가 그룹에 조인하지 못하면 그룹 복제를 수동으로 다시 시작해야 합니다.

클러스터의 DB 인스턴스에 간헐적인 연결 문제가 발생하는 경우, 더 많은 자동 재조인 기회를 제공하고 수동 개입을 제한하려는 경우 이 파라미터를 늘리는 것이 좋습니다. 재조인 시도를 제한하거나 수동 개입이 필요한 DB 인스턴스 식별을 신속하게 처리하려면 이 값을 줄이십시오.

자동 재조인 시도 도중과 그 사이에 DB 인스턴스는 읽기 전용 모드로 유지되고 쓰기를 허용하지 않으므로 시간이 지남에 따라 오래된 읽기가 발생할 가능성이 높아집니다. 애플리케이션이 일정 기간 동안 오래된 읽기 가능성을 허용할 수 없는 경우 group_replication_autorejoin_tries 를 0으로 구성합니다.

c) Group_Replication_Unreachable_Majority_Timeout: 경우에 따라 네트워크 파티션이 DB 인스턴스를 더 작은 그룹으로 격리하여 클러스터를 나눌 수 있습니다. 예를 들어, 7개의 인스턴스가 있는 Active/Active 클러스터에는 쿼럼에 대해 응답하려면 최소 4개의 인스턴스가 필요합니다. 네트워크 파티션이 클러스터를 인스턴스 4개와 인스턴스 3개의 그룹으로 나누는 경우 인스턴스가 3개인 파티션은 쿼럼을 달성할 수 없습니다. group_replication_unreachable_majority_timeout은 네트워크 파티션이 발생하고 대다수에 연결할 수 없는 DB 인스턴스가 그룹을 떠나기 전에 대기하는 시간(초)을 정의합니다. 이 변수는 기본적으로 0으로 설정됩니다. 이는 소수가 그룹을 떠나기까지 영원히 기다리는 것을 의미합니다. 애플리케이션이 이러한 조건에 직면하는 것을 방지하려면 매개변수를 0보다 큰 적절한 값으로 설정할 수 있습니다. 정의된 제한 시간에 도달하면 소수에 대해 보류 중인 모든 트랜잭션이 롤백되고 소수 파티션의 DB 인스턴스가 ERROR 상태가 됩니다. 여기에서 애플리케이션은 필요에 따라 오류 처리를 수행할 수 있습니다.

흐름 제어 – 그룹 복제 플러그인을 사용하면 대부분의 그룹 인스턴스(n/2 + 1, 여기서 n은 클러스터의 인스턴스 수)가 발생한 모든 트랜잭션의 순서에 동의한 후에만 트랜잭션이 커밋된 것으로 간주됩니다. 이는 그룹이 적당한 수의 트랜잭션을 처리할 때 잘 작동합니다. 트랜잭션 수가 많은 경우 클러스터의 느린 DB 인스턴스가 뒤처질 수 있습니다. 이로 인해 느린 인스턴스에서 읽을 때 오래된 데이터가 반환될 수 있습니다. 이 문제를 해결하기 위해 그룹 복제에는 인증할 트랜잭션과 적용할 트랜잭션 측면에서 DB 인스턴스가 누적할 수 있는 백로그 양에 제한을 두는 흐름 제어 메커니즘이 있습니다. group_replication_flow_control_applier_threshold 및 group_replication_flow_control_certifier_threshold 매개변수(기본적으로 25,000개 트랜잭션)를 사용하여 트랜잭션 크기, 최고치, 전체 처리량 요구 사항을 포함한 애플리케이션의 워크로드 패턴을 기반으로 허용 가능한 복제 성능 및 지연을 정의할 수 있습니다. 이러한 제한이 초과될 때마다, 그리고 계속해서 초과되는 동안 흐름 제어 메커니즘은 클러스터 내에서 가장 느린 DB 인스턴스의 용량과 일치하도록 모든 쓰기 DB 인스턴스의 처리량을 제한합니다.

group_replication_flow_control_mode 를 DISABLED로 설정하여 흐름 제어를 비활성화할 수 있습니다. 흐름 제어를 비활성화하면 성능이 향상될 수 있지만 프로세스의 메모리 공간도 늘어나 메모리 부족 상태가 발생할 수 있습니다. 따라서 워크로드 트래픽 패턴이 이를 지원할 수 없고 인스턴스에 사용 가능한 FreeableMemory 가 충분하지 않은 한 흐름 제어를 비활성화하는 것은 권장되지 않습니다.

또한 적절한 지연 수준에서 제한이 발생하도록 애플리케이션 처리량 요구 사항을 처리하기 위해 replica parallel workers 를 구성할 수도 있습니다. 워크로드 프로필이 변경됨에 따라 복제 지연 지표를 지속적으로 모니터링하고 설정을 재조정합니다. 매개변수 값의 최적 조합은 지연을 관리하는 동시에 애플리케이션의 분산 토폴로지 전체에서 성능을 최대화합니다.

트랜잭션 일관성 – 그룹 복제를 사용하여 Active/Active 클러스터에 대한 네 가지 일관성 수준 EVENTUAL, BEFORE, AFTER 및 BEFORE_AND_AFTER 중 하나를 선택할 수 있습니다. 기본 일관성 수준은 EVENTUAL입니다. RDS 데이터베이스 파라미터 그룹 을 사용하거나 세션 수준에서 트랜잭션 일관성을 구성할 수 있습니다. 각 일관성 수준에 대해 자세히 알아보려면 MySQL 사용자 가이드 를 참조하세요.

일관성 수준이 더 강력해지면 애플리케이션은 클러스터 내의 DB 인스턴스 간에 변경 사항이 전파될 때까지 기다리는 데 더 많은 시간을 소비합니다. 애플리케이션 및 성능 요구 사항을 기반으로 일관성 모델을 신중하게 평가하고 선택해야 합니다.

VPC 피어링 – Active/Active 클러스터의 DB 인스턴스가 서로 다른 VPC에 있는 경우 DB 인스턴스가 프라이빗 IP를 통해 연결할 수 있도록 VPC 간에 VPC 피어링을 구성하는 것이 좋습니다.

모니터링 및 경고 – DB 인스턴스가 응답하지 않거나 클러스터에서 추방된 시기를 감지하고 이에 따라 트래픽을 다시 라우팅할 수 있도록 애플리케이션이 복제 상태를 지속적으로 모니터링하는 것이 좋습니다. 다음 Performance_schema 테이블을 사용하여 Active/Active 클러스터의 상태를 모니터링할 수 있습니다.

performance_schema.replication_group_members: 클러스터에 포함된 각 DB 인스턴스의 상태를 제공합니다.

performance_schema.replication_group_member_stats: 인증과 관련된 클러스터 수준 정보와 클러스터 내 각 DB 인스턴스가 수신하고 발생하는 트랜잭션에 대한 통계를 제공합니다.

performance_schema.replication_connection_status: 원본 DB 인스턴스에 대한 복제본의 연결을 처리하는 복제 I/O 스레드의 현재 상태를 제공합니다.

그룹 복제 플러그인을 사용하여 MySQL용 RDS 인스턴스로 Active/Active 클러스터 설정

Active/Active 클러스터를 처음부터 생성하거나 기존 Amazon RDS for MySQL 인스턴스를 Active/Active 클러스터 설정으로 마이그레이션하여 생성할 수 있습니다. 단일 AZ나 다중 AZ 인스턴스 또는 둘의 조합에 걸쳐 Active/Active 복제를 설정할 수 있습니다.

Active/Active 클러스터 생성

Active/Active 클러스터를 처음부터 생성하려면 MySQL용 RDS DB 인스턴스를 새로 생성해야 하며 여기에 데이터가 기록되어서는 안 됩니다. DB 인스턴스에 이미 데이터가 포함되어 있는 경우 다음 섹션에 설명된 대로 인스턴스를 Active/Active 클러스터로 마이그레이션하여 그룹 복제를 구성해야 합니다.

다음 예에서는 처음부터 3개 노드 Active/Active 클러스터를 설정했습니다. Active/Active 클러스터를 처음부터 생성하려면 다음을 수행합니다.

1.그룹 복제 파라미터가 구성된 DB 파라미터 그룹을 생성합니다. 자세한 내용은 DB 파라미터 그룹 생성을 참조하세요. 3개 DB 인스턴스 모두에 대해 동일한 파라미터 그룹을 사용하거나 Active/Active 클러스터의 각 인스턴스에 대해 별도의 파라미터 그룹을 생성할 수 있습니다. 각 인스턴스에 대해 별도의 매개변수 그룹을 사용하는 경우 그룹 복제 구성 매개변수가 각 매개변수 그룹에서 동일한지 확인하십시오. 그렇지 않으면 그룹 복제가 시작되지 않습니다. 데모를 쉽게 하기 위해 Active/Active 클러스터의 3개 인스턴스 모두에 대해 단일 파라미터 그룹을 사용하겠습니다.

2.다음 매개변수를 사용하여 매개변수 그룹을 구성합니다.

3.생성된 파라미터 그룹을 사용하여 3개의 새 인스턴스를 생성합니다. 자세한 내용은 RDS MySQL DB 인스턴스 생성 을 참조하십시오. 1단계에서 생성된 파라미터 그룹이 데이터베이스 생성 시 인스턴스와 연결되어 있는지 확인하세요. 각 MySQL용 Amazon RDS 인스턴스는 MySQL 8.0.35 이상을 실행해야 합니다.

4.인스턴스가 사용 가능 상태가 되면 각 인스턴스에 접속하여 ‘그룹 이름’이 구성되었는지 확인합니다. 자세한 내용은 MySQL DB 인스턴스 생성 및 연결 을 참조하세요.

mysql> show variables like ‘group_replication_group_name’;
+------------------------------+--------------------------------------+
| Variable_name | Value |
+------------------------------+--------------------------------------+
| group_replication_group_name | 11111111-2222-3333-4444-555555555555 |
+------------------------------+--------------------------------------+
1 row in set (0.00 sec)

5.Active/Active 클러스터의 일부가 될 인스턴스를 나열하려면 group_replication_group_seeds 매개변수를 구성하십시오. 이 매개변수를 쉼표로 구분된 3개 인스턴스의 끝점으로 설정합니다. 다음 스크린샷은 예제의 매개변수 값을 보여줍니다.

6.인스턴스에 연결하고 다음 쿼리를 실행하여 매개변수 변경 사항이 전파되었는지 확인합니다.

mysql> show variables like '%seeds%';
+-------------------------------+---------------------------------------------
| Variable_name | Value |
+-------------------------------+---------------------------------------------
| group_replication_group_seeds | mysql80-gr7-n1.abcdefghijkl.us-west-2.rds.amazonaws.com:3306,mysql80-gr7-n2.abcdefghijkl.us-west-2.rds.amazonaws.com:3306,mysql80-gr7-n3.abcdefghijkl.us-west-2.rds.amazonaws.com |
+-------------------------------+--------------------------------------------+
1 row in set (0.00 sec)

7.바이너리 로그 보존을 구성하고 그룹 복제 사용자 및 그룹 복제 복구 채널을 생성합니다. Active/Active 클러스터의 3개 인스턴스 모두에서 다음 문을 실행합니다.

# Configure binary log retention.
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binary log

# Create the group replication user.
call
mysql.rds_group_replication_create_user('group_replication_user_password');
call

# Create the Group replication Recovery Channel
mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');

8.클러스터의 DB 인스턴스 중 하나에서 다음 저장 프로시저를 실행하여 클러스터를 부트스트랩합니다.

call mysql.rds_group_replication_start(1);

이 문은 클러스터의 한 DB 인스턴스에서 그룹 복제를 시작합니다. 저장 프로시저 rds_group_replication_start 에 대한 매개변수 값 1은 클러스터를 부트스트래핑하고 있음을 지정합니다.

9.클러스터의 다른 DB 인스턴스에서 그룹 복제를 시작하려면 파라미터 값을 0으로 설정하여 rds_group_replication_start를 실행합니다.

call mysql.rds_group_replication_start(0);

10.다음 쿼리를 실행하여 3개의 DB 인스턴스 모두에서 그룹 복제가 실행되고 있는지 확인합니다. 클러스터의 모든 DB 인스턴스에 대해 멤버 상태가 온라인인지 확인합니다.

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+
|CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+
|group_replication_applier | d8f5281c-744c-11ee-9783-06fb8f36ecdb | ip-172-xx-x-xxx | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
|group_replication_applier | d9ced226-744c-11ee-9257-06a0f6d23da7 | ip-172-xx-x-xxx | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
|group_replication_applier | e7f6c424-744c-11ee-836f-0619032f4835 | ip-172-xx-x-xxx | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
+---------------------------+--------------------------------------+
3 rows in set (0.00 sec)

11.인스턴스에 데이터를 삽입하고 Active/Active 클러스터의 나머지 인스턴스에 복제되는지 확인합니다.

기존 RDS 인스턴스를 Active/Active 클러스터로 마이그레이션

기존 인스턴스를 Active/Active 클러스터로 마이그레이션하는 것은 새 DB 인스턴스를 생성하는 대신 기존 RDS for MySQL 인스턴스의 특정 시점 복원 (PITR)을 수행해야 한다는 점을 제외하면 처음부터 Active/Active 클러스터를 생성하는 것과 유사합니다. .

사전 작업

DB 인스턴스와 연결된 파라미터 그룹이 다른 RDS 인스턴스와 공유되지 않는지 확인하십시오. 공유 매개변수 그룹으로 인해 Active/Active 클러스터에 속하지 않는 다른 인스턴스에서 잘못된 구성이 발생할 수 있습니다. 공유되는 경우 인스턴스를 별도의 파라미터 그룹에 다시 연결하세요. 이 예에서는 쉽게 시연할 수 있도록 새 매개변수 그룹을 생성 합니다. MySQL용 Amazon RDS 인스턴스는 MySQL 8.0.35 이상을 실행해야 합니다.

1.그룹 복제 파라미터가 구성된 DB 파라미터 그룹을 생성합니다. 자세한 내용은 DB 파라미터 그룹 생성을 참조하세요. 3개 DB 인스턴스 모두에 대해 동일한 파라미터 그룹을 사용하거나 Active/Active 클러스터의 각 인스턴스에 대해 별도의 파라미터 그룹을 생성할 수 있습니다. 각 인스턴스에 대해 별도의 매개변수 그룹을 사용하는 경우 그룹 복제 구성 매개변수가 각 매개변수 그룹에서 동일한지 확인하십시오. 그렇지 않으면 그룹 복제가 시작되지 않습니다. 쉽게 설명하기 위해 Active/Active 클러스터의 3개 인스턴스 모두에 대해 단일 매개변수 그룹을 사용하겠습니다.

2.다음 매개변수를 사용하여 매개변수 그룹을 구성합니다.

3.1단계에서 생성한 매개변수 그룹과 연결 하여 인스턴스를 수정합니다. 자세한 내용은 DB 파라미터 그룹을 DB 인스턴스와 연결을 참조하십시오.

4.새 파라미터 그룹 변경 사항이 적용되도록 인스턴스를 재부팅합니다. 자세한 내용은 DB 인스턴스 재부팅 을 참조하세요.

5.현재 인스턴스의 스냅샷을 만듭니다. 자세한 내용은 DB 스냅샷 생성을 참조하세요.

6.스냅샷이 완료되면 현재 인스턴스를 최신 시점으로 PITR(특정 시점 복원)을 수행하여 클러스터의 나머지 2개 DB 인스턴스를 생성합니다. 자세한 내용은 DB 인스턴스를 지정된 시간으로 복원 을 참조하세요. 클러스터에 두 개의 추가 DB 인스턴스가 필요하므로 PITR 작업을 두 번 수행해야 합니다. PITR 인스턴스 생성 시 새로 생성된 매개변수 그룹을 연결하는 것을 잊지 마세요.

7.group_replication_group_seeds 매개변수를 3개 인스턴스의 엔드포인트로 설정합니다. 다음 스크린샷은 예제의 매개변수 값을 보여줍니다.

8.인스턴스에 연결하고 다음 쿼리를 실행하여 매개변수 변경 사항이 전파되었는지 확인합니다.

mysql> show variables like '%seeds%';
+-------------------------------+----------------------------------+
| Variable_name | Value |
+-------------------------------+----------------------------------+
| group_replication_group_seeds | mysql80-gr7-n1.abcdefghijkl.us-west-2.rds.amazonaws.com:3306,mysql80-gr7-n2.abcdefghijkl.us-west-2.rds.amazonaws.com:3306,mysql80-gr7-n3.abcdefghijkl.us-west-2.rds.amazonaws.com |
+-------------------------------+----------------------------------+
1 row in set (0.00 sec)

9.바이너리 로그 보존 주기를 구성하고 그룹 복제 사용자 및 그룹 복제 복구 채널을 생성합니다. Active/Active 클러스터의 3개 인스턴스 모두에서 다음 문을 실행합니다.

# Configure binary log retention.
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binary log

# Create the group replication user.
call
mysql.rds_group_replication_create_user('group_replication_user_password');
call

# Create the Group replication Recovery Channel
mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');

10.클러스터의 DB 인스턴스 중 하나에서 다음 저장 프로시저를 실행하여 클러스터를 부트스트랩합니다.

call mysql.rds_group_replication_start(1);

이 문은 클러스터의 DB 인스턴스 1개에서 그룹 복제를 시작합니다. 저장 프로시저 rds_group_replication_start에 대한 매개변수 값 1은 클러스터를 부트스트래핑하고 있음을 지정합니다.

11.클러스터의 다른 DB 인스턴스에서 그룹 복제를 시작하려면 파라미터 값을 0으로 설정하여 rds_group_replication_start 를 실행합니다.

call mysql.rds_group_replication_start(0);

12.다음 쿼리를 실행하여 3개의 DB 인스턴스 모두에서 그룹 복제가 실행되고 있는지 확인합니다. 각 DB 인스턴스의 멤버 상태가 온라인인지 확인합니다.

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+
|CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+
|group_replication_applier | d8f5281c-744c-11ee-9783-06fb8f36ecdb | ip-172-xx-x-xxx | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
|group_replication_applier | d9ced226-744c-11ee-9257-06a0f6d23da7 | ip-172-xx-x-xxx | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
|group_replication_applier | e7f6c424-744c-11ee-836f-0619032f4835 | ip-172-xx-x-xxx | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
+---------------------------+--------------------------------------+
3 rows in set (0.00 sec)

13.인스턴스에 데이터를 삽입하고 Active/Active 클러스터의 나머지 인스턴스에 복제되고 있는지 확인합니다.

환경 정리 하기

테스트 설정을 정리할 준비가 되면 다음 단계에 따라 Active/Active 클러스터를 독립형 DB 인스턴스로 변환하는 것이 좋습니다.

1.저장 프로시저를 사용하여 그룹 복제를 중지 합니다. rds_group_replication_stop()을 호출합니다.

2.사용자 지정 파라미터 그룹의 group_replication_group_seeds 파라미터에서 DB 인스턴스를 삭제합니다.

3.파라미터 그룹에서는 Active/Active 클러스터에서 제거하려는 파라미터 group_replication_group_seeds에서 DB 인스턴스를 삭제합니다.

4.DB 인스턴스와 연결된 파라미터 group_replication_group_name, rds.group_replication_enabled 및 group_replication_group_seeds를 삭제합니다.

5.업데이트된 파라미터 설정을 적용하려면 DB 인스턴스를 재부팅하세요.

자세한 내용은 MySQL용 RDS 사용자 가이드 를 참조하세요.

결론

Amazon RDS for MySQL에 그룹 복제 플러그인이 도입되면서 애플리케이션은 Active/Active 구성에서 최대 9개의 DB 인스턴스에 걸쳐 지속적인 가용성을 구현하고 쓰기 지연 시간을 최적화할 수 있습니다. 그룹 복제 플러그인은 Active/Active 클러스터의 모든 DB 인스턴스에서 데이터 일관성을 유지하여 중요한 데이터를 안정적으로 유지하고 액세스할 수 있도록 보장합니다.

애플리케이션의 워크로드 패턴을 고려하여 그룹 복제 플러그인을 사용하여 Active/Active 복제를 구현하는 것이 사용 사례에 적합한 선택인지 검토하세요. 여러 구성 옵션 간을 전환하고, 성능을 모니터링하고, 필요에 따라 데이터베이스 인프라를 확장하여 애플리케이션의 성능과 안정성을 최적화하고 사용자에게 원활한 경험을 제공하세요.

질문이나 의견이 있으면 댓글을 부탁드립니다.