<Reowns>rlaeowns
Admin

클러스터 간 복제 구성된 aurora mysql 업그레이드

Reowns · 41 days ago

곧 회사에서 사용중인 aurora mysql 3.4.x 버전의 패치를 진행합니다. 타겟 버전은 aws의 권고대로 3.10.4로 정해졌습니다. 현재 8.4 호환 버전까지 출시된 상황이나 aws 측에서도 추가 검증이 필요하다고 본 것 같습니다.

오늘은 aurora mysql 클러스터간 복제 구성된 인스턴스들의 복제를 깨뜨리지 않고 서비스 무중단 패치하기 위해 했던 고민과 테스트 과정을 적어보려 합니다. 패치 순서는 Source, Replica 순으로 진행했으며 Source 부분부터 보겠습니다. 현재 아래 그림 처럼 복제가 진행 중입니다.

(S): Source, (R): Replica

+--------+   binlog   +--------+
|   s    |----------->|   R    |
+--------+            +--------+

Source에 블루 그린 배포를 생성하면 이렇게 될거고

+--------+   binlog   +--------+
| S(blue)|----------->|   R    |
+--------+            +--------+
    |
    | binlog
    ↓
+---------+
| S(Green)|
+---------+

switch 이후에는 아래 처럼 Green이었던 애가 다시 Replica를 봐야하는데, 이 과정이 모두 매끄럽게 진행이 가능한지를 봐야합니다. 그림에서 S(blue)는 blue_old이고, S(Green)은 blue_new입니다.

+--------+        +--------+
| S(blue)|---X--->|   R    |
+--------+      ┌>+--------+
    |          / 
    X         /
    ↓        / binlog
+---------+ /
| S(Green)|/
+---------+

[테스트]

  1. 먼저 클러스터 2개를 생성하고 복제 구성을 했습니다.
/**************** Replica ************************/
-- 1. 클러스터 파라미터 수정 
replicate-do-table : replica_test.test_table

/**************** Source *************************/
-- 2. replication 계정 생성, 
CREATE USER 'repl'@'%' IDENTIFIED BY '비번';

-- 3. replication 계정 권한 부여
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SHOW GRANTS FOR 'repl'@'%';

-- 4. test db 생성 (Master)
CREATE DATABASE IF NOT EXISTS replica_test;

-- 5. binlog file, pos 확인
SHOW MASTER STATUS;

-- 6. test table 생성
USE replica_test;

CREATE TABLE test_table (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL,
    value INT NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
);

/**************** Replica ************************/
-- 7. test db 생성 (Slave)
CREATE DATABASE IF NOT EXISTS replica_test;

-- 8. replication source 등록
CALL mysql.rds_set_external_source(
  'source_host',
  3306,
  'repl',
  'repl#12',
  'mysql-bin.000001',  -- binlog 파일명
  157,                 -- position
  0                    -- ssl 여부
);

-- 9. replication 시작
CALL mysql.rds_start_replication;
  1. ai를 활용해 10초 간격으로 insert 하면서 소스, 리플리카 건수 비교 프로그램을 생성했습니다.
1) 이 테이블 10초 간격으로 insert 하는 프로그램 만들어주고 기동 방법 알려주셈
2) 여기서 특정 인스턴스랑 건수 비교해서 출력하는 로직도 좀 알려주라
3) 두개 섞어
  1. 블루그린 생성 후 (S/Blue) -> [ (S/Green), (R) ] 양방향 복제를 확인 후 블루그린을 전환합니다.
  2. 블루그린 전환 후에는 (S/New_Blue) -> (R) 연결해주고 데이터를 확인합니다.
    (switch 후 이벤트 메시지가 발생하는데 여기에서 전환 후 New_Blue의 binlog file, offset 정보를 얻을 수 있습니다. https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-switching.html)
-- 10. 재등록
CALL mysql.rds_stop_replication;

CALL mysql.rds_set_external_source(
  'source_host',
  3306,
  'repl',
  'repl#12',
  'mysql-bin.000001',  -- binlog 파일명
  157,                 -- position
  0                    -- ssl 여부
);

CALL mysql.rds_start_replication;

1~4 까지 과정을 성공적으로 진행해 Source 클러스터를 무중단 업그레이드 완료했습니다. 이후에는 Replica 인스턴스를 업그레이드 할 차례입니다. Aurora 블루그린 배포 가이드에 "블루 DB 인스턴스는 외부 binlog 복제본이 될 수 없습니다." 라고 명시 돼 있습니다. 패치 방법이 몇 가지로 나뉩니다.

  • replica는 인플레이스로 업그레이드
  • 복제를 끊고 replica를 블루그린 업그레이드 후 다시 연결
  • 테스트 4번의 과정을 replica 블루그린 업그레이드 후 진행

첫 번째가 가장 간단하지만 다운 타임이 발생합니다. 다행히 저희 Replica DB 연관 서비스는 주로 내부 대시보드 용도로 사용돼 일과 시간 외 다운 타임이 허용될 수 있을 것 같습니다. 그럼 아래 시나리오대로 업그레이드를 진행하면 됩니다. 시나리오에는 테스트 진행했던 Source 인스턴스 업그레이드 과정도 포함 돼 있습니다.

[ Replica를 인플레이스로 업그레이드 ]

(S): Source, (R): Replica
1. (S) 블루그린 생성
2. (S), (R) [블루 → 그린, 슬레이브] 둘 다 복제가 되는지 확인 
3. (S) Switchover
4. (S) Event에서 binlog 좌표 획득
5. (R) 블루의 모든 binlog 적용 완료 대기
6. (R) rds_stop_replication, Source 해제
7. (R) 새 Writer로 Source 설정
8. (R) rds_start_replication
9. (R) 인플레이스 업그레이드 (3.04 → 3.10)
10. (R) 정상 동작 확인

만약 리플리카도 무중단 업그레이드가 필요하다면 저는 세 번째 방법(테스트 4번의 과정을 replica 블루그린 배포 후 진행)을 사용할 것 같습니다. 후반부 절차가 약간 바뀝니다.

[ Replica를 블루그린으로 업그레이드 ]

(S): Source, (R): Replica
1. (S) 블루그린 생성
2. (S), (R) [블루 → 그린, 슬레이브] 둘 다 복제가 되는지 확인 
3. (S) Switchover
4. (S) Event에서 binlog 좌표 획득
5. (R) 블루의 모든 binlog 적용 완료 대기
6. (R) rds_stop_replication, Source 해제
7. (R) 블루그린 업그레이드 (3.04 → 3.10)
8. (R) 새 Writer로 Source 설정
9. (R) rds_start_replication
10. (R)정상 동작 확인

오로라 mysql에서 db레벨 복제를 사용한다면 업그레이드 시 이렇게 번거로운 절차가 따라옵니다. 만약 제가 프로그램을 다시 설계할 수 있다면 db레벨 복제를 사용하지 않고 aws에서 제공하는 복제 기능을 이용해 볼 것 같습니다. 그래도 이번 테스트를 통해 실제 패치 전 몇 번의 연습을 해볼 수 있어 좋은 기회였고, 클라우드 서비스를 이용해 이렇게 편하게 무중단 패치를 진행할 수 있어 다행이라 생각했습니다.

← Back