Last Updated on 10월 6, 2023 by Jade(정현호)
안녕하세요
이번글은 Amazon RDS for MySQL에서의 Multi-AZ DB Cluster(다중 AZ DB 클러스터)에 대해서 확인해보도록 하겠습니다.
Contents
Multi-AZ DB Cluster
Amazon RDS의 Multi-AZ DB Cluster(다중 AZ DB 클러스터) 는 기존에 Multi-AZ 인스턴스와 달리 접속하여 읽기 가능한(사용이 가능한) standby(대기) DB 인스턴스 2개가 있는 Amazon RDS의 반동기식(Semi-synchronous) 고가용성 배포 모드입니다.
Multi-AZ DB Cluster(다중 AZ DB 클러스터)에는 동일 AWS 리전에 3개 개별 가용 영역(AZ- Availability Zones) 에 라이터 DB 인스턴스 1개와 리더 DB 인스턴스 2개가 있습니다. Multi-AZ DB Cluster(다중 AZ DB 클러스터)는 Multi-AZ 인스턴스(다중 AZ DB 인스턴스) 배포에 비해 고가용성, 읽기 워크로드 용량 증가, 쓰기 지연 시간 감소 기능을 제공합니다.
Multi-AZ DB Cluster는 라이터와 리더 클러스터 접속 주소(End Point URL)을 지원합니다.
Note
Multi-AZ DB Cluster는 Aurora DB 클러스터와 동일하지 않습니다. Aurora DB 클러스터에 대한 자세한 내용은 Amazon Aurora 사용 설명서를 참조하세요.
Multi-AZ DB Cluster 개요 및 차이점
Multi-AZ DB Cluster에서는 DB엔진의 네이티브한 복제 기능을 사용하여 라이터 DB 인스턴스의 데이터를 2개의 리더 DB 인스턴스로 복제를 하며, 라이터 DB 인스턴스가 변경되면 각 리더 DB 인스턴스로 변경점이 전송됩니다.
Multi-AZ DB Cluster(다중 AZ DB 클러스터)는 라이터 DB 인스턴스에서 변경 사항을 커밋하려면 하나 이상의 리더 DB 인스턴스의 승인을 받아야 하는 Semi-synchronous replication(반동기식 복제)를 사용합니다.
리더 DB 인스턴스는 자동 장애 조치(automatic failover) 대상 역할을 하며 또한 읽기 트래픽 처리 기능을 제공하여 애플리케이션 읽기 처리량을 늘립니다. 라이터 DB 인스턴스에 중단이 발생하면 RDS는 리더 DB 인스턴스 중 하나로 장애 조치(failover)를 수행합니다. RDS는 어떤 리더 DB 인스턴스에 가장 최근 변경 기록이 가지고 있는지를 기준으로 이 작업(장애 조치)을 수행합니다.
다음 다이어그램은 Multi-AZ DB Cluster(다중 AZ DB 클러스터)를 보여줍니다.
일반적으로 Multi-AZ DB Cluster(다중 AZ DB 클러스터)는 Multi-AZ instance(다중 AZ 인스턴스)에 비해 쓰기 대기 시간이 짧습니다. 또한 설명한 것처럼 읽기 전용 워크로드를 리더 DB 인스턴스에서 실행되도록 기능이 제공됩니다.
DB 엔진 네이티브 복제 기술을 사용함으로 RDS for MySQL에서 특히 복제 오류를 방지하기 위해서 모든 테이블에 프라이머리 키(PK) 설정하는 것이 권장됩니다.
다음 다이어그램은 Multi-AZ DB Instance(다중 AZ DB 인스턴스)를 보여줍니다.
Multi-AZ Instance도 Amazon RDS의 고가용성 및 장애 조치 기능 지원을 제공합니다.
Multi-AZ Instance 옵션을 지정하여 RDS 생성시 자동으로 서로 다른 가용 영역(AZ- Availability Zones)에 동기식(Synchronous) 대기(Standby) 복제본(Replica)을 프로비저닝합니다.
프라이머리(Primary) DB 인스턴스 전체를 대기(Standby) 복제본으로 동기화 방식으로 복제가 수행되며, 데이터베이스 백업은 대기(Standby) 복제본 인스턴스에서 수행하여 Primary DB 인스턴스 서버의 부하를 최소화합니다.
Multi-AZ DB Cluster는 DB엔진의 네이티브 복제 방식을 사용하는데 반해, Multi-AZ Instance는 MySQL 기준으로 스토리지(디스크) 복제 기술인 DRBD을 이용하여 예비 복제본과 동기화를 합니다.(DB엔진에 따라서 복제 구현 방식이 일부 차이가 있음)
그래서 Multi-AZ Instance의 예비 DB 인스턴스는 평상시에는 사용이 불가하고 자동 장애 조치(Fail-Over)나 사용자 Take-Over를 수행하여 고가용성을 주 목적으로 사용합니다. 물론 백업의 경우 Standby DB 인스턴스에서 수행함에 따라 Primary DB 인스턴스의 부하를 줄이는데 도움이 됩니다.
Multi-AZ Instance에 대한 보다 자세한 내용은 아래 이전 포스팅을 참조하시면 됩니다.
Multi-AZ DB Cluster 제한
Multi-AZ DB Cluster(다중 AZ 클러스터)는 Multi-AZ Instance(다중 AZ 인스턴스)에 비해서 상대적으로 더 많은 제한사항이 존재합니다.
-
다중 AZ DB 클러스터는 프로비저닝된 IOPS 스토리지만 지원합니다.
-
단일 AZ DB 인스턴스 배포 또는 다중 AZ DB 인스턴스 배포를 다중 AZ DB 클러스터로 변경할 수 없습니다. 대신에 단일 AZ DB 인스턴스 배포 또는 다중 AZ DB 인스턴스 배포의 스냅샷을 다중 AZ DB 클러스터로 복원할 수는 있습니다.
-
단일 AZ DB 인스턴스 배포 또는 다중 AZ DB 인스턴스 배포를 다중 AZ DB 클러스터 배포로 변경할 수 없습니다. 대신에 다중 AZ DB 클러스터 배포의 스냅샷을 단일 AZ DB 인스턴스 배포 또는 다중 AZ DB 인스턴스 배포로 복원할 수는 있습니다.
-
다중 AZ DB 클러스터는 모든 수정이 DB 클러스터 수준에서 수행되므로 DB 인스턴스 수준에서 수정을 지원하지 않습니다.
-
다중 AZ DB 클러스터는 GTID 방식으로 복제가 구성되어 있습니다. 그렇기 때문에 RDS for MySQL 다중 AZ DB 클러스터는 소스에 GTID가 활성화된 경우에만 외부 MySQL 소스에서 복제를 지원합니다. 자세한 내용은 mysql.rds_set_external_master_with_auto_position 섹션을 참조하세요. 그러므로 위치 기반 binlog 복제는 지원되지 않습니다.
-
다중 AZ DB 클러스터는 다음 기능을 지원하지 않습니다.
-
Amazon RDS 프록시
-
IPv6 연결 지원(듀얼 스택 모드)
-
교차 리전 자동 백업
-
Amazon S3 버킷으로 다중 AZ DB 클러스터 스냅샷 데이터 내보내기
-
IAM DB 인증
-
Kerberos 인증
-
포트 수정
또는 다중 AZ DB 클러스터를 특정 시점으로 복원하고 다른 포트 지정 가능
-
옵션 그룹 수
-
삭제된 클러스터의 시점 복구(PITR)
-
예약 DB 인스턴스
-
Amazon S3 버킷에서 다중 AZ DB 클러스터 스냅샷 복원
-
할당된 최대 스토리지를 설정하여 스토리지 자동 크기 조정
또는 수동으로 스토리지 크기 조정 가능
-
DB 클러스터 중지 및 시작
-
다중 AZ DB 클러스터의 스냅샷 복사
-
암호화되지 않은 다중 AZ DB 클러스터 암호화
-
-
MySQL용 다중 AZ DB 클러스터용 RDS는 외부 대상 데이터베이스로의 복제를 지원하지 않습니다.
-
RDS for MySQL 다중 AZ DB 클러스터는 다음 시스템 저장 프로시저만 지원합니다.
그러므로 Standalone RDS for MySQL 또는 Multi-AZ Instance(다중 AZ 인스턴스)에 비해 다중 AZ DB 클러스터에서 지원하는 저장 프로시저 수가 적습니다.-
mysql.rds_rotate_general_log -
mysql.rds_rotate_slow_log -
mysql.rds_show_configuration -
mysql.rds_set_external_master_with_auto_position
RDS for MySQL Multi-AZ DB 클러스터는 다른 저장 프로시저를 지원하지 않습니다. 이러한 프로시저 사용에 대한 자세한 내용은 RDS for MySQL 저장 프로시저 참조 섹션을 참조하세요.
-
-
PostgreSQL 다중 AZ DB 클러스터용 RDS는
aws_s3,pg_transport,pglogical과 같은 PostgreSQL 확장을 지원하지 않습니다. -
PostgreSQL 다중 AZ DB 클러스터용 RDS는 아웃바운드 네트워크 액세스에 사용자 지정 DNS 서버 사용을 지원하지 않습니다.
Multi-AZ 클러스터 생성 및 변경 과 관리
RDS for MySQL 생성시 Multi-AZ DB 클러스터로 생성은 다음과 같이 옵션을 선택하여 생성합니다.
하단에 "Show versions that support the Multi-AZ DB cluster" 를 활성화하여 Multi-AZ DB Cluster 사용 가능한 DB 버전 리스트만 확인할 수 있습니다. 포스팅에서는 8.0.34 로 선택하였습니다.
Availability and durability에서 "Multi-AZ DB Cluster" 을 선택합니다.
제한사항에 기술된 내용과 같이 Multi-AZ DB Cluster는 Provisioned IOPS SSD(io1)만 사용할 수 있습니다.
생성이 완료되면 다음과 같이 3개 가용영역에 나눠서 라이터 DB 인스턴스1개, 리더 DB인스턴스 2개가 생성된 것을 확인할 수 있습니다.
Multi-AZ DB Cluster는 라이터, 리더 클러스터 DB 접속 엔드포인트를 제공합니다. 클러스터에서 Endpoint 주소를 확인할 수 있습니다.
제한사항 내용과 같이 DB인스턴스 레벨에서의 수정은 불가 합니다.
클러스터 레벨에서 수정이 가능합니다. 클러스터 레벨에서의 수정이 가능하다는 의미는 일반적인 RDS for MySQL과 차이점이 있음을 의미합니다.
그 중에서 대표적으로 인스턴스별로 DB 파라미터 그룹을 설정이 불가하며 클러스터에서 1개의 클러스터 파라미터 그룹을 같이 사용합니다.
그래서 Multi-AZ DB Cluster 는 파라미터 그룹도 Type이 "DB Cluster Parameter Group" 으로 사용합니다.
DB인스턴스 레벨에서의 Actions도 제한되며, 다음 이미지에서 확인되는 기능만 사용 가능합니다.
Multi-AZ Instance는 Primary(마스터) DB 인스턴스를 재시작 할 때 장애조치 재시작 기능을 사용할 수 있으나 Multi-AZ DB Cluster에서의 Primary(마스터) DB 인스턴스 재시작(Reboot)은 단어 그대로 DB인스턴스만 재시작 됩니다.
그러므로 Primary(Writer,마스터) DB 인스턴스를 재시작하게 되면 재시작 완료까지 DB 쓰기 작업이 불가하게 됩니다.
클러스터의 Actions 메뉴에는 Failover 메뉴가 있고 해당 메뉴를 통해서 사용자 정의 장애조치를 수행할 수 있습니다.
Failover가 완료되면 다음과 같이 라이터 인스턴스가 변경된 것을 확인할 수 있습니다.
장애 조치가 완료되는 데 걸리는 시간은 라이터 DB 인스턴스를 사용할 수 없게 된 데이터베이스 활동 및 기타 조건에 따라 달라집니다.
장애 조치에 소요되는 시간은 일반적으로 35초 아래입니다.
장애 조치는 두 리더 DB 인스턴스에 모두 장애가 발생한 라이터의 처리되지 않은 트랜잭션이 적용되면 완료됩니다. 장애 조치가 완료되면 RDS 콘솔에 새 가용 영역이 반영되는 데 시간이 더 걸릴 수 있습니다.
AWS Aurora Cluster에서는 인스턴스별로 티어 순위(장애조치시 우선순위)를 설정하여 사용자가 원하는 특정 인스턴스가 Writer 인스턴스가 될 수 있도록, 또는 어떤 인스턴스는 Writer 인스턴스가 될 순위를 낮추는 등으로 설정할 수 있습니다.
AWS Aurora MySQL 에 대해서는 아래 포스팅을 참조하시면 됩니다.
RDS for MySQL의 Multi-AZ DB Cluster는 DB 인스턴스별로 "Modify(수정)" 기능을 지원하지 않으며 그에 따라 인스턴스별로 장애 조치에 관련한 우선 순위 지정 관련한 기능을 지원하지 않습니다.
라이터 DB 인스턴스에서 장애가 발생하게 되면 AWS RDS는 어느 리더 DB 인스턴스가 장애 조치 대상이 되는지를 선택하며, AWS RDS는 어느 리더 DB 인스턴스의 가장 최근 변경 기록을 기준으로 라이터 DB 인스턴스 선정 및 라이터 인스턴스로 승격을 수행합니다.
바이너리 로그는 기본적으로 모두 활성화되어 있는 상태로 리더 DB 인스턴스에서도 활성화되어 있습니다.
mysql> \s
--------------
<... 중략 ...>
Server version: 8.0.34 Source distribution
Protocol version: 10
Connection: rds-test-01.cluster-ro-.... <!!----
Server characterset: utf8mb4
Db characterset: utf8mb4
Client characterset: utf8mb4
Conn. characterset: utf8mb4
TCP port: 3306
Binary data as: Hexadecimal
Uptime: 1 hour 13 min 27 sec
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin-changelog.000016
Position: 197
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 0db9d28f-6270-11ee-a03c-0a5d94085604:1-14
DNS 이름 조회를 위한 JVM TTL 설정
AWS Aurora Cluster과 동일하게 Cluster Endpoint를 사용함에 따라서 DNS 레코드값에 대해서 캐시를 하는 개발언어나 드라이버에서는 캐시 라이프 타입을 기본값보다 작게 설정이 필요 합니다.
DNS 주소 캐시값 보유 시간이 매우 길다면 장애발생시 새로운 라이터/리더 인스턴스로 접속에 문제가 발생하게 됩니다.
Java JVM은 DNS 이름 조회를 캐시합니다. JVM은 호스트 이름을 IP 주소로 확인하는 경우 유지 시간(TTL)이라고 하는 지정된 기간 동안 IP 주소를 캐싱합니다.
DNS TTL 값을 60초 이하(많이 작은 값으로) 로 하여 JVM을 구성하는 것이 좋습니다.
JVM의 TTL을 수정하려면 networkaddress.cache.ttl 속성 값을 설정합니다. 필요에 따라 다음 방법 중 하나를 사용합니다.
- JVM을 사용하는 모든 애플리케이션에 대해 전역적으로 속성 값을 설정
networkaddress.cache.ttl 파일에서 $JAVA_HOME/jre/lib/security/java.security을 설정
- networkaddress.cache.ttl=60
- 애플리케이션에만 로컬로 속성을 설정
네트워크 연결이 설정되기 전에 애플리케이션의 초기화 코드에서 networkaddress.cache.ttl을 설정- java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
이번 글은 여기에서 마무리하도록 하겠습니다.
긴 글 읽어주셔서 감사합니다.
Reference
Reference URL
• aws.amazon.com/multi-az-db-clusters-concepts
• aws.amazon.com/Concepts.MultiAZSingleStandby
관련된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
