Aurora Multi-AZ와 MySQL 복제 HA의 차이

데이터베이스를 여러 가용 영역에 배치했다고 해서 같은 고가용성(HA) 구조가 되는 것은 아니다. 장애 후에도 데이터가 남는지, 그 데이터를 처리할 서버가 준비되어 있는지, 애플리케이션이 새 서버에 연결할 수 있는지는 서로 다른 문제다. Aurora의 스토리지 복제와 MySQL의 binlog 복제를 같은 것으로 이해하면 reader 지연을 데이터 손실로 오해하거나, 반대로 복제본이 있다는 이유만으로 안전한 자동 승격이 가능하다고 판단하기 쉽다.

이 글은 단일 리전 Aurora MySQL 클러스터와 Community MySQL의 비동기·반동기 복제로 구성한 HA를 비교한다. Group Replication은 별도의 합의·멤버십 구조를 갖는 대안으로 구분한다. SQL 예제는 MySQL 8.0 폐기용 단일 서버에서 실행한 진단과 가정 입력의 집합 판정이다. 실제 Aurora 장애, AZ 단절, 복제 승격 또는 애플리케이션 RTO를 측정한 결과가 아니다.

1. Multi-AZ라는 이름보다 배포 유형을 먼저 확인한다

운영 문서의 첫 줄에는 제품명과 배포 유형을 명시해야 한다. 다음 세 가지는 이름이 비슷하지만 데이터 경로와 대기 인스턴스의 역할이 다르다.

• Aurora DB 클러스터: writer와 Aurora Replica가 하나의 논리적 클러스터 볼륨을 사용한다. 스토리지는 인스턴스 배치와 별개로 여러 AZ에 복제된다. 다른 AZ의 reader를 두어야 해당 AZ에서 실행 중인 승격 후보를 확보할 수 있다.
• RDS for MySQL Multi-AZ DB instance 배포: 다른 AZ의 동기식 standby를 유지한다. 이 standby는 일반 읽기 트래픽을 처리하는 read replica가 아니다.
• RDS for MySQL Multi-AZ DB cluster 배포: 서로 다른 AZ에 writer와 읽기 가능한 두 reader를 두는 반동기식 구조다. Aurora 클러스터와 동일한 제품이나 스토리지 구조로 취급하지 않는다.

자체 운영 MySQL을 서로 다른 AZ에 두는 것은 이 중 어느 관리형 상품도 자동으로 구성하지 않는다. binlog 복제를 연결한 뒤에도 장애 감지, 승격 권한, 이전 writer 차단, 접속 경로 변경과 복귀 절차를 별도로 마련해야 한다.

2. Aurora는 데이터의 생존과 실행 인스턴스의 생존을 분리한다

2.1 클러스터 볼륨의 복제는 reader 수와 독립적이다

Aurora의 클러스터 볼륨은 한 리전의 세 AZ에 데이터 사본을 분산한다. AWS 문서는 writer의 데이터를 여섯 스토리지 노드에 동기적으로 복제한다고 설명한다. 여기서 여섯 사본은 여섯 MySQL 서버가 SQL을 실행한다는 뜻이 아니다. 계산 계층과 스토리지 계층이 분리되어 있으며, writer와 reader는 같은 논리적 볼륨을 사용한다.

따라서 reader를 추가하는 목적은 독립적인 전체 데이터 파일 사본을 하나 더 운영하는 것이 아니라, 읽기 처리 자원과 이미 준비된 승격 후보를 확보하는 데 있다. reader가 없어도 스토리지 다중 AZ 복제는 존재한다. 그러나 writer가 중단되면 쿼리를 처리할 인스턴스를 복구하거나 새로 준비해야 하므로 스토리지 내구성이 곧 계산 계층의 즉시 가용성은 아니다.

스토리지 장애 허용 범위 역시 단일 리전 안의 설계다. 리전 전체 장애까지 다루려면 Aurora Global Database 등 별도 지역 간 복구 설계가 필요하며, 그 복제·전환 조건을 단일 리전 Multi-AZ와 구별해야 한다.

2.2 공유 볼륨이어도 reader의 가시성은 지연될 수 있다

Aurora Replica의 변경 반영은 비동기적이다. 같은 클러스터 볼륨을 사용하더라도 reader가 변경을 처리하고 읽기에 반영하는 시점, 캐시 상태, 트랜잭션의 Read View는 writer와 같지 않을 수 있다. 저장 계층에 데이터가 보존되었다는 사실과 임의의 reader SELECT에서 그 데이터가 보인다는 사실은 별개다.

이 때문에 두 가지 반대 해석을 모두 피해야 한다.

• reader에서 방금 쓴 행이 보이지 않는다고 곧바로 스토리지 복제 실패로 판단하지 않는다.
• 공유 스토리지라는 이유로 모든 reader가 커밋 직후 같은 결과를 반환한다고 가정하지 않는다.

쓰기 직후 확인이 중요한 업무는 writer 읽기, 명시적인 일관성 정책, 짧은 트랜잭션 경계 등을 함께 설계한다. Aurora 내부 reader의 상태를 일반 binlog 채널의 GTID나 Seconds_Behind_Source만으로 설명할 수는 없다.

flowchart TB
  subgraph A["Aurora 단일 리전 클러스터"]
    AW["writer 계산 인스턴스"] --> AS["공유 논리 볼륨 · 세 AZ의 스토리지 사본"]
    AR["다른 AZ의 reader · 승격 후보"] --> AS
    AW -. "비동기 변경 반영 · 읽기 가시성 지연 가능" .-> AR
    AC["관리형 장애 감지 · 역할 전환"] --> AR
  end
  subgraph M["일반 MySQL 복제 기반 HA"]
    MW["source · InnoDB와 binlog"] --> MR["replica receiver · relay log"]
    MR --> MA["applier · replica의 독립 InnoDB 데이터"]
    MA --> MC["후보 검증 · 이전 writer 차단 · 승격"]
    MC --> ME["Proxy · DNS 등 접속 경로 전환"]
  end

그림의 Aurora reader 연결은 공유 볼륨 사용을 나타내며 독립적인 업무 쓰기 권한을 뜻하지 않는다. MySQL 쪽에서는 수신과 적용, 승격이 서로 다른 단계라는 점이 핵심이다.

3. MySQL 복제 HA는 독립 데이터 사본의 진행도를 관리한다

3.1 비동기 복제의 커밋 성공은 replica 도착 확인이 아니다

일반적인 MySQL 복제에서 source는 변경을 binlog에 기록하고, replica의 receiver는 이를 받아 relay log에 저장한다. applier는 이벤트를 실행하여 replica의 InnoDB 데이터에 반영한다. 두 서버는 독립된 데이터 파일과 버퍼 풀을 갖는다.

비동기 복제에서는 source가 성공을 반환할 때 replica가 해당 변경을 수신했는지 기다리지 않는다. source만 보유한 커밋이 있는 상태에서 source와 그 저장장치를 사용할 수 없게 되면, replica 승격으로 잃는 변경이 생길 수 있다. 반면 이벤트가 이미 relay log에 도착했지만 적용만 늦은 경우에는, 잔여 적용을 기다려 손실 없이 전환할 여지가 있다. 두 상황을 단순한 ‘복제 지연’ 하나로 묶으면 안 된다.

innodb_flush_log_at_trx_commit과 sync_binlog는 source의 로컬 내구성을 해석하는 데 중요하다. 하지만 두 값이 내구성 위주로 설정되어 있어도 원격 replica 도착을 보장하지는 않는다. 로컬 디스크 보존과 장애 후 승격 대상의 데이터 보존은 별도의 조건이다.

3.2 반동기 ACK는 수신·기록 증거이며 적용 완료 증거가 아니다

반동기 복제는 설정된 수의 replica가 이벤트를 수신하여 relay log에 기록하고 디스크에 flush했다는 ACK를 기다린다. ACK를 보낸 replica에서 해당 트랜잭션의 SQL 적용과 커밋까지 끝났다는 뜻은 아니다. source의 대기 지점 설정도 확인해야 한다.

운영자는 다음 조건을 함께 관리해야 한다.

1. 반동기가 양쪽에서 활성화되어 있고, 현재 실제로 동작하는지 확인한다. 설정값 ON과 현재 동작 상태는 같지 않을 수 있다.
2. ACK 대기 시간 초과로 비동기 모드로 전환되는 구간을 관측한다. 반동기를 설치했다는 사실만으로 모든 커밋에 원격 보존 증거가 있다고 판단하지 않는다.
3. 승격 후보가 필요한 트랜잭션을 보유하고 있는지 확인한다. ACK를 하지 않은 임의의 replica를 선택하면 보호 의도를 깨뜨릴 수 있다.
4. 수신된 변경의 적용 완료와 오류 유무를 확인하고, 이전 source가 독립적으로 쓰기를 계속하지 못하게 차단한다.

반동기는 원격 데이터 보존 가능성을 강화하는 기능이지 장애 감지기, 선출기 또는 접속 라우터가 아니다. Group Replication도 별도로 살펴봐야 한다. Group Replication의 멤버 합의·트랜잭션 인증을 일반 반동기 ACK나 Aurora 스토리지 복제와 같은 것으로 설명하지 않는다.

4. 장애 전환에서 달라지는 운영 책임

Aurora: 관리형 역할 전환과 애플리케이션 복구를 나눈다

다른 AZ의 Aurora Replica가 있으면 관리형 장애 전환의 후보로 사용할 수 있다. 승격 우선순위와 인스턴스 크기, 장애 시 처리량을 함께 검토한다. reader가 평소의 읽기 부하만 감당하도록 작게 구성되어 있다면, 승격 성공 후에도 쓰기 지연과 연결 폭증으로 업무가 정상화되지 않을 수 있다.

reader가 없거나 writer와 모든 reader가 같은 AZ에 있다면, 해당 AZ 전체 장애에 대응할 준비된 다른 AZ의 후보가 없다. 스토리지는 다중 AZ라는 설명만 보고 이 배치를 HA 완료로 승인해서는 안 된다.

cluster endpoint는 현재 writer를 가리키지만, 기존 TCP 연결과 진행 중 트랜잭션을 새 writer로 이동시키지는 않는다. 애플리케이션은 실패 연결을 버리고 새 연결을 얻어야 한다. DNS 캐시와 연결 풀의 검증 정책도 영향을 준다. AWS 문서의 일반적인 전환 시간 설명을 자신의 서비스 RTO 보장으로 사용하지 말고, 업무 성공률과 지연이 회복되는 시점을 측정해야 한다.

MySQL: 후보 판정과 fencing을 승격 이전 조건으로 둔다

자체 복제 HA의 핵심 위험은 잘못된 장애 판정으로 두 writer를 만드는 것이다. 감지기가 source에 연결하지 못해도 source는 다른 애플리케이션에서 쓰기를 받고 있을 수 있다. 네트워크 단절과 프로세스 종료를 동일하게 판단하지 않는다.

안전한 전환은 대체로 다음 순서로 설계한다.

1. 장애 범위와 자동화 실행 주체를 확정하고 중복 승격 시도를 방지한다.
2. 이전 writer의 쓰기를 차단한다. 네트워크 격리나 전원 차단 등 장애 상황에서도 효력이 있는 fencing 수단과 확인 증거가 필요하다.
3. 후보의 수신·적용 경계, applier 오류, 고유한 추가 GTID, 복제 필터와 데이터 정합성을 확인한다.
4. 정책상 허용되는 손실 범위와 적용 대기를 판단한 뒤 후보를 writer로 전환한다.
5. 접속 경로를 바꾸고 실제 업무 계정의 읽기·쓰기를 검증한다. 이전 서버는 정합성을 확인하거나 재구축하기 전까지 writer로 복귀시키지 않는다.

read_only나 super_read_only를 확인하는 것은 유용하지만, 접근 불가능한 이전 writer의 상태를 바꿨다는 증거가 될 수 없다. Proxy에서 경로를 뺀 것만으로 우회 연결까지 차단되었다고 가정하지도 않는다.

두 구조에 공통인 불명확한 커밋 결과

클라이언트가 COMMIT을 보낸 뒤 연결이 끊기면 서버에서 커밋이 끝났는지 응답만 유실되었는지 바로 알 수 없을 수 있다. Aurora의 관리형 승격이나 MySQL의 무손실 승격이 이 애플리케이션 문제를 자동 해결하지는 않는다. 주문·결제 등은 요청 식별자와 고유 제약, 처리 결과 재조회, 멱등 재시도를 설계해야 한다. 무조건 같은 INSERT를 반복하는 방식은 HA가 정상이어도 업무 중복을 만든다.

5. SQL로 확인할 수 있는 것과 확인할 수 없는 것

아래 진단은 권한이 있는 계정에서 실행한다. 테스트 서버는 binlog와 복제 채널이 활성화되지 않은 단일 MySQL 서버다. 출력의 log_bin=0과 빈 채널 목록은 이 검증 환경의 상태이지 운영 권장 구성이나 HA 정상 판정이 아니다.

5.1 로컬 내구성과 쓰기 역할의 단서

SELECT VERSION() AS mysql_version,
       @@GLOBAL.log_bin AS log_bin,
       @@GLOBAL.gtid_mode AS gtid_mode,
       @@GLOBAL.innodb_flush_log_at_trx_commit AS redo_flush,
       @@GLOBAL.sync_binlog AS binlog_sync,
       @@GLOBAL.read_only AS read_only,
       @@GLOBAL.super_read_only AS super_read_only;

실행 결과(MySQL 8.0.x):

mysql> SELECT VERSION() AS mysql_version,
    ->        @@GLOBAL.log_bin AS log_bin,
    ->        @@GLOBAL.gtid_mode AS gtid_mode,
    ->        @@GLOBAL.innodb_flush_log_at_trx_commit AS redo_flush,
    ->        @@GLOBAL.sync_binlog AS binlog_sync,
    ->        @@GLOBAL.read_only AS read_only,
    ->        @@GLOBAL.super_read_only AS super_read_only;

+---------------+---------+-----------+------------+-------------+-----------+-----------------+
| mysql_version | log_bin | gtid_mode | redo_flush | binlog_sync | read_only | super_read_only |
+---------------+---------+-----------+------------+-------------+-----------+-----------------+
| 8.0.46        |       0 | OFF       |          1 |           1 |         0 |               0 |
+---------------+---------+-----------+------------+-------------+-----------+-----------------+
1 row in set (0.00 sec)

일반 MySQL에서는 binlog 활성화, GTID 사용 정책, 로컬 로그 동기화, 복제본의 쓰기 제한을 함께 본다. 이 조회에는 원격 ACK나 fencing 성공 증거가 없다. Aurora의 내부 HA 역시 일반 MySQL의 log_bin 활성 여부만으로 판정할 수 없다. 외부 binlog 복제를 위한 설정과 클러스터 내부 복제는 구별한다.

5.2 binlog 채널의 수신과 적용 오류를 따로 관측한다

SELECT CHANNEL_NAME, SERVICE_STATE, LAST_ERROR_NUMBER
FROM performance_schema.replication_connection_status
ORDER BY CHANNEL_NAME;

SELECT CHANNEL_NAME, WORKER_ID, SERVICE_STATE, LAST_ERROR_NUMBER
FROM performance_schema.replication_applier_status_by_worker
ORDER BY CHANNEL_NAME, WORKER_ID
LIMIT 10;

실행 결과(MySQL 8.0.x):

mysql> SELECT CHANNEL_NAME, SERVICE_STATE, LAST_ERROR_NUMBER
    -> FROM performance_schema.replication_connection_status
    -> ORDER BY CHANNEL_NAME;

Empty set (0.00 sec)

mysql> SELECT CHANNEL_NAME, WORKER_ID, SERVICE_STATE, LAST_ERROR_NUMBER
    -> FROM performance_schema.replication_applier_status_by_worker
    -> ORDER BY CHANNEL_NAME, WORKER_ID
    -> LIMIT 10;

Empty set (0.01 sec)

단일 서버의 Empty set은 ‘수신·적용 지연이 0’이 아니라 이 환경에서 관측할 복제 채널과 worker가 없다는 뜻이다. 실제 복제 서버에서는 예상 채널이 존재하는지부터 확인한다. SERVICE_STATE=ON과 오류 번호 0은 유용하지만 최신 트랜잭션까지 적용했다는 충분조건이 아니다. 수신한 GTID 집합, 실행한 GTID 집합, 기준 writer의 경계와 오류 메시지를 함께 확보해야 한다. worker가 많은 환경에서는 예제의 LIMIT 10을 그대로 사용해 나머지 오류를 놓치지 않도록 범위를 조정한다.

이 Performance Schema 조회 결과를 Aurora 내부 reader의 상태 표로 해석하지 않는다. Aurora에서는 관리형 이벤트, 인스턴스 역할·AZ, reader 지연과 애플리케이션 관측을 함께 사용한다. Aurora에서 외부 binlog 채널을 별도로 운영한다면 그 채널의 관측과 내부 HA 관측을 구분한다.

5.3 수신 완료와 적용 완료는 다른 판정이다

다음은 가정한 GTID 집합을 비교하는 교육용 예제다. aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100을 조사 시점에 확보한 기준 이력으로 놓는다. 실제 복제나 장애를 발생시키지 않으며 서버의 GTID 실행 이력을 변경하지도 않는다.

SET @reference_set = 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100';

WITH candidates AS (
    SELECT 'not_received' AS candidate,
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-98' AS received_set,
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-98' AS executed_set
    UNION ALL
    SELECT 'pending_apply',
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100',
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-98'
    UNION ALL
    SELECT 'covered',
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100',
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100'
    UNION ALL
    SELECT 'extra_execution',
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100',
           'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100,bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb:1'
)
SELECT candidate,
       GTID_SUBSET(@reference_set, received_set) AS received_covers,
       GTID_SUBSET(@reference_set, executed_set) AS applied_covers,
       (GTID_SUBTRACT(executed_set, @reference_set) <> '') AS has_extra
FROM candidates
ORDER BY candidate;

실행 결과(MySQL 8.0.x):

긴 CTE 입력 부분만 줄인 실행 기록이다. 결과의 모든 행과 열은 그대로 표시했다.

mysql> SET @reference_set = 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-100';
Query OK, 0 rows affected (0.00 sec)

mysql> WITH candidates AS (...) SELECT ... FROM candidates ORDER BY candidate;
+-----------------+-----------------+----------------+-----------+
| candidate       | received_covers | applied_covers | has_extra |
+-----------------+-----------------+----------------+-----------+
| covered         |               1 |              1 |         0 |
| extra_execution |               1 |              1 |         1 |
| not_received    |               0 |              0 |         0 |
| pending_apply   |               1 |              0 |         0 |
+-----------------+-----------------+----------------+-----------+
4 rows in set (0.00 sec)

• not_received: 기준 이력이 수신 집합에도 없다. source가 사라졌을 때 다른 보존 경로가 있는지 확인해야 한다.
• pending_apply: 기준 이력은 수신했지만 적용하지 못했다. 적용 오류·잠금·처리량 문제와 대기 가능 시간을 조사한다.
• covered: 가정한 기준 이력을 수신·실행 집합이 포함한다. 이것만으로 실제 승격을 승인하지는 않는다.
• extra_execution: 기준을 모두 포함하더라도 추가 실행 이력이 있다. 해당 이력이 합법적인 다른 source의 이력인지, replica에서 발생한 업무 쓰기인지 조사해야 한다.

실전에서는 ‘수신했다’의 근거를 해당 채널의 수신 집합과 이미 실행된 관련 이력 등을 바탕으로 구성해야 한다. 채널 재설정 이후의 수신 집합 하나를 서버 전체의 보존 이력으로 취급하지 않는다. 또한 source에서 수집한 기준이 오래되었다면 위 판정은 그 이후 커밋을 다루지 못한다. source 접근이 끊겨 최종 경계를 확보하지 못한 상황에서 완전한 RPO 0을 이 SQL만으로 증명할 수 없다.

GTID는 실행 이력의 식별자이지 데이터 내용의 checksum이 아니다. 복제 필터, 빈 GTID 스킵, 별도 변경으로 같은 GTID 범위와 다른 데이터가 공존할 수 있다. 승격 결정에는 업무 핵심 행과 제약, 복제 정책의 검증이 추가로 필요하다.

6. 장애 시나리오별로 설계의 빈틈을 찾는다

writer 프로세스만 중단된 경우: Aurora는 상황에 따라 같은 인스턴스 재시작 또는 reader 승격으로 복구한다. 일반 MySQL은 source 재시작과 replica 승격 중 어느 쪽이 안전하고 빠른지 정책을 정해야 한다. 단순 연결 실패 한 번으로 즉시 승격하면 불필요한 전환과 이력 분기를 만들 수 있다.

writer AZ 전체가 단절된 경우: Aurora에서는 다른 AZ의 준비된 reader와 그 처리 용량을 확인한다. 일반 MySQL에서는 다른 AZ의 후보뿐 아니라 감지기·승격 제어기·Proxy가 같은 장애에 함께 사라지는지도 확인한다. DB 두 대의 분산 배치만으로 제어 경로의 단일 장애점이 사라지지 않는다.

reader 또는 replica만 느려진 경우: Aurora에서는 읽기 지연과 승격 후 성능을, 일반 MySQL에서는 수신 지연과 적용 지연을 구분한다. ‘가장 빨리 응답하는 서버’와 ‘가장 필요한 이력을 많이 보존한 후보’는 같지 않을 수 있다.

업무 DELETE가 잘못 커밋된 경우: 두 구조 모두 정상적인 변경으로 전파될 수 있다. 복제와 HA는 과거의 올바른 상태를 보존하는 백업이 아니다. PITR, 백업 보존, 복구 승인과 데이터 재조정 절차가 따로 있어야 한다.

리전 전체가 영향을 받은 경우: 단일 리전 Multi-AZ와 같은 리전 안의 MySQL 복제는 범위를 벗어난다. 별도 리전 데이터 보존, 승격 정책, 트래픽 전환 및 복귀를 설계한다. 지역 간 복제를 추가했다는 사실만으로 지역 내와 같은 손실·복구 시간 조건이 성립하지 않는다.

7. 도입 결정과 운영 인수 체크리스트

관리형 구조의 가치는 운영 책임이 사라지는 것이 아니라, 스토리지 복구와 인스턴스 역할 전환의 상당 부분을 서비스에 맡길 수 있다는 데 있다. 자체 MySQL HA는 복제 토폴로지와 인프라 선택의 자유가 크지만, 그만큼 실패 판정과 데이터 경계에 대한 책임이 운영팀에 남는다. 비교 시 인스턴스 비용뿐 아니라 리허설, 야간 대응, 업그레이드, 복구 자동화 유지보수 비용까지 포함한다.

• Aurora, RDS Multi-AZ DB instance, RDS Multi-AZ DB cluster, 자체 MySQL 중 정확한 배포 유형을 기록했다.
• 데이터 사본의 AZ와 실행 인스턴스의 AZ를 따로 확인했다.
• writer AZ 장애 뒤에도 사용할 승격 후보와 충분한 처리 용량이 있다.
• 비동기·반동기의 커밋 보존 조건, 반동기 시간 초과 시 정책과 알림을 정의했다.
• 자체 HA에서는 이전 writer 차단을 확인한 뒤 승격하도록 절차를 구성했다.
• GTID 기준 시점, 수신·적용 경계, 추가 이력과 데이터 검증을 구분했다.
• endpoint 전환 뒤 DNS 캐시, 연결 풀, 업무 계정과 트랜잭션 재시도를 시험했다.
• COMMIT 결과 불명확 상황에 대해 멱등 키와 처리 결과 조회를 제공한다.
• RTO는 DB 역할 변경 완료가 아니라 업무 성공률·지연 회복까지 측정한다.
• 잘못된 정상 쓰기와 리전 장애를 위한 백업·PITR·별도 DR 계획이 있다.

8. 정리

Aurora Multi-AZ의 핵심은 여러 AZ에 보존되는 스토리지와 승격 가능한 계산 인스턴스의 분리다. MySQL 복제 HA의 핵심은 독립 데이터 사본 사이에서 필요한 변경의 수신·적용 경계를 확인하고 안전하게 쓰기 권한을 이전하는 것이다. 두 구조 모두 애플리케이션 연결 복구와 업무 중복 방지까지 완성해야 서비스의 HA가 된다.

설계 검토에서는 ‘복제본이 몇 대인가’보다 ‘어떤 장애 뒤에 어떤 커밋이 남고, 누가 쓰기 권한을 가지며, 업무가 언제 다시 성공하는가’를 먼저 묻는다. 이 기준은 이후의 승격 후보 선정, 연결 풀 복구, 지역 간 재해복구 절차를 평가할 때도 그대로 사용할 수 있다.

참고 자료

2026-11-07에 확인한 공식 문서다. 제품 설명과 로컬 SQL 검증의 범위를 구분하여 적용한다.

• AWS — Aurora 고가용성 및 장애 전환
• AWS — Aurora 스토리지와 안정성
• AWS — Aurora 복제와 공유 클러스터 볼륨
• AWS — RDS Multi-AZ DB instance 배포
• AWS — RDS Multi-AZ DB cluster 배포
• MySQL 8.4 — 반동기 복제의 ACK와 시간 초과 동작