[MySQL] AWS와 Azure간 데이터베이스 Primary/Secondary 구성

 

AWS Database 장애 시 Azure Database로 전환

 

기존 운영 환경이 AWS에 구축된 상태에서, 장애 발생 시 Azure Database로 전환이 가능한지 검증하기 위해 인프라를 구성하고 테스트를 진행했습니다.

 

 

제한 사항

Multi-Replication

 

Chain-Replication

 

AWS와 Azure 간 데이터베이스 장애 복구 환경을 구축할 때, Primary/Secondary 복제에서는 Chain-Replication을 사용할 수 없으며, Multi-Replication 방식만 지원됩니다. 

 

 

복제 방법

• 바이너리 로그(binlog) 파일 위치
• GTID 기반 복제

이 글에서는 주로 바이너리 로그 복제에 대해 다룹니다. 필요에 따라 gtid_mode 설정을 활성화하여 GTID 기반 복제로 전환할 수 있습니다.

기본적인 동기화 유형은 단방향 비동기 복제입니다. 그 외에도 동기 복제(synchronous replication)와 반동기 복제(semi-synchronous replication) 옵션이 존재합니다.

GTID란?
Global Transaction IDentifiers의 약어로, MySQL과 MariaDB에서 트랜잭션을 고유하게 식별하기 위한 ID 입니다.각 트랜잭션이 실행될 때마다 GTID가 자동으로 생성되며, 이를 활용하여 마스터-슬레이브(Primary-Secondary) 복제 환경에서 일관성을 유지하고 장애 복구를 용이하게 합니다.

 

 

사전 요구 사항

• AWS와 Azure 클라우드 가 상호 간 네트워크로 연결되어 있어야 합니다.
• 호환성을 위해 원본 데이터베이스와 대상 데이터베이스 서버가 동일한 MySQL 버전(5.7)에 있어야 합니다.
• Timezone을 상호 일치시켜야 합니다. 해당 테스트 에서는 Aisa/Seoul로 일치시켰습니다.
• 원본 및 대상 데이터베이스의 문자 집합이 동일한지 확인합니다.
• 각 테이블에 Primary Key가 있어야 합니다.(테이블에 Primary Key가 없으면 복제 프로세스가 느려질 수 있습니다.)
• 모든 테이블에서 InnoDB를 사용하는지 확인합니다. (Azure MySQL은 InnoDB 스토리지 엔진만 지원합니다.)
• 원본 및 대상 데이터베이스 간 3306 포트로 통신이 허용되어 있어야 합니다.
• GTID_mode를 일치시킵니다. 해당 테스트에서는 원본 DB의 경우 GTID_mode가 OFF되어 있습니다.

TimeZone 확인

binlog format 확인

DB 엔진 확인

 

GTID_mode 확인

 

 

binlog 확인

AWS RDS for MySQL에서 Binary Log(binlog)가 활성화되었는지 확인합니다.

아래 프로시저를 호출하여 Binary Log Retention 설정을 확인하면, binlog가 Azure MySQL 서버로 복제될 때까지 로그가 유지되는지 여부를 검증할 수 있습니다.

binlog retention 확인

 

binlog retention hours가 null 값으로 되어있는 경우 다음 프로시저를 통해 로그 보존 시간 변경이 그낭합니다.

* 정의된 보존 기간에 따라 원본 서버에 Binary Log를 저장할 충분한 디스크 공간 확보가 필요합니다.

 

Azure는 Portal 내 서버 매개 변수 메뉴에서 변경이 가능합니다.

 

 

AWS RDS for MySQL 데이터 덤프 캡처

원본 AWS RDS for MySQL 서버에서 데이터 덤프를 캡처하는 2가지 방법이 존재합니다. 

1. 원본 서버에서 직접 데이터 덤프 캡처

2. 읽기 복제본에서 데이터 덤프 캡처

 

원본 서버에서 직접 데이터 덤프 캡처

트랜잭션으로 일관된 데이터 덤프를 얻으려면 몇 분 동안 애플리케이션에서 쓰기를 중지해야 합니다. 데이터 덤프를 캡처할 때 쓰기가 처리되지 않도록 ‘read_only’ 매개 변수를 일시적으로 1로 설정 합니다.(Downtime 발생)

AWS Prameter Group에서 변수 설정 변경

 

원본 서버에서 쓰기를 중지한 후, ‘show master status;’ 명령을 실행하여 이진로그 파일 이름 및 Position을 수집합니다.(중요)

덤프 캡처 시 이진 로그 파일명과 Position이 변경 될 경우 복제 시 에러가 발생합니다.

 

AWS RDS for MySQL에서 ‘mysqldump’를 실행합니다.

mysqldump –h <hostname> -u <username> -p --databases <database name> --order-by-primary --set-gtid-purged=OFF --compress > awsdummy.sql

 

읽기 복제본에서 데이터 덤프 캡처

 

원본 서버에서 쓰기를 중지할 수 없거나 원본 서버에서 데이터를 덤프 시 성능이 허용되지 않는 수준인 경우 다음과 같이 복제본 서버에서 덤프를 캡처할 수 있습니다.

원본 서버와 동일한 구성으로 AWS RDS for MySQL 읽기 복제본을 생성합니다. AWS RDS for MySQL 읽기 복제본이 원본 AWS RDS for MySQL 서버를 따라잡도록 합니다.  읽기 복제본에서 복제본 지연 시간이 0에 도달하면 저장 프로시저 ‘call mysql.rds_stop_replication;’ 를 호출하여 복제를 중지합니다.

 

복제 중지 후 ‘show slave status’ 명령을 실행하여 Relay_Master_Log_File 필드의 현재 Binary Log 파일 이름과 Position 위치를 수집합니다. 

AWS RDS for MySQL 읽기 복제본에서 ‘mysqldump’ 명령어를 실행합니다.

mysqldump –h <hostname> -u <username> -p --databases <database name> --order-by-primary --set-gtid-purged=OFF --single-transaction --compress > awsreaddummy.sql

 

 

AWS RDS for MySQL 데이터 덤프를 Azure MySQL로 복원

AWS RDS for MySQL에서 캡처한 데이터 덤프를 아래 명령어를 사용하여 Azure MySQL로 복원합니다.

mysql –h <hostname> -u <username> -p < <Dumpfile>.sql

 

AWS RDS for MySQL 내 복제에 사용할 사용자를 생성하고 권한을 부여합니다.

 

 

AWS RDS for MySQL 와 Azure MySQL Primary/Secondary 연결

AWS RDS for MySQL 원본 서버와 Azure MySQL 대상 서버를 연결하려면 대상 Azure MySQL 서버에 로그인 합니다. 아래 명령을 실행하여 AWS RDS for MySQL 서버를 원본 서버로 설정합니다.

아래 명령에서 '<master_bin_log_file>',master_bin_log_position,’ 에는 원본 서버에서 전체 덤프 캡처 시에 수집한 Binary 로그 파일 명과 Position을 기입합니다.

mysql.az_replication_change_master('source_server','replication_user_name','replication_user_password',3306,'<master_bin_log_file>',master_bin_log_position,'<master_ssl_ca>');

 

복제본 서버에서 복제 상태를 확인하려면 다음 명령을 실행합니다.

Slave_IO_Running, Slave_SQL_Running 매개 변수 상태가 모두 ‘예’이면 복제가 시작되어 실행 중인 상태
Seconds_Behind_Master 매개 변수 값이 0이면 대상이 원본 서버의 모든 업데이트 처리를 완료 한 것

 

 

복제 중단을 통해 장애 상황 시 복구 테스트

장애 상황 복구 테스트를 진행하기 위해 AWS 클라우드가 전체적으로 장애 상황이 발생했다고 가정하고 AWS와 Azure 간 데이터베이스 복제를 중단해보겠습니다. 중단 후 Azure Secondary MySQL read_only 옵션을 OFF 시키면 이 때부터 Primary로서 동작할 수 있습니다.

 

AWS Route53을 통해 기존 AWS RDS for MySQL로 접근하던 트래픽을 Azure를 바라보도록 함으로써 Azure 데이터베이스를 사용하여 AWS가 복구되는 동안 Primary의 역할을 할 수 있도록 합니다.

 

단, 복제가 중지된 시간 동안 Azure DB에 변경분이 발생하게 되면 복제가 재시작될 때 데이터 정합성 에러 발생합니다.

이를 해결하기 위해서는 본문에서 설명한 바와 같이 AWS to Azure 복제 과정을 반대로 다시 진행해주어야 합니다.

 

 

AWS Aurora MySQL DB의 경우 Binlog 활성화

AWS Aurora MySQL DB의 경우 기본적으로 Binary 로그가 Disable, Binary 로그 복제를 위해서는 파라미터 그룹에서 변수 변경이 필요합니다.

AWS Aurora MySQL DB

 

파라미터 그룹에서 binlog_format을 Row로 변경하면 Binary 로깅이 ON으로 변경됩니다.(재부팅에 따른 다운타임 발생)

 

 

 

참고 링크

입력 데이터 복제를 사용하여 Amazon RDS for MySQL를 Azure Database for MySQL로 마이그레이션

데이터 인 복제를 사용하여 MySQL용 Amazon RDS 마이그레이션 - Azure Database for MySQL - Flexible Server

Multi-Cloud MySQL Replication from AWS to Azure in Real-Time

Multi-Cloud MySQL Replication from AWS to Azure in Real-Time

Amazon Aurora MySQL 클러스터에 대한 바이너리 로깅 활성화