[AWS] Aurora mySQL 3.0 업그레이드 - Cluster간 binlog replication (스냅샷 복원 및 Aurora clone 복제) , Blue-Green Deployment(블루-그린 배포) 작업 스크립트

업그레이드 전 사전 확인사항

MySQL 8.0과 MySQL 5.7 변경 사항 중 개발자들이 숙지해야 할 변경 사항을 사전에 확인하여 공지한다.

딱히 존재하지 않아 보인다. 기능 테스트를 통해 프로시저 및 jdbc를 통한 DB 동작 호환성 정도만 보면 될것 같다.

중요한 확인사항

아래는 AWS 공식 문서에서 가져옴.

• Character set 변경 : UTF8 → UTF8MB4 (utf8mb4_0900_ai_ci)
• 예약 키워드 추가 : RANGE
• 쿼리 캐시 제거
• 구문 에러
• 뷰, 루틴, 트리거 및 이벤트에는 SQL_CACHE, SQL_NO_CACHE, QUERY_CACHE와 같이 더 이상 사용되지 않는 SQL 구문이 없어야 합니다.
• FTS 인덱스가 없는 테이블에는 FTS_DOC_ID 열이 없어야 합니다.
• InnoDB 데이터 사전과 실제 테이블 정의 간에 열 정의 불일치가 없어야 합니다.
• lower_case_table_names 파라미터를 1로 설정하는 경우 모든 데이터베이스 및 테이블 이름은 소문자여야 합니다.
• 이벤트 및 트리거에는 누락되었거나 빈 definer 또는 잘못된 생성 컨텍스트가 없어야 합니다.
• 데이터베이스의 모든 트리거 이름은 고유해야 합니다.
• Aurora MySQL 버전 3에서는 DDL 복구 및 빠른 DDL이 지원되지 않습니다. 데이터베이스에는 이러한 기능과 관련된 아티팩트가 없어야 합니다.
• REDUNDANT 또는 COMPACT 행 형식의 테이블은 767바이트보다 큰 인덱스를 가질 수 없습니다.
• tiny 텍스트 열에 정의된 인덱스의 접두사 길이는 255바이트를 초과할 수 없습니다. utf8mb4 문자 집합의 경우 지원되는 접두사 길이가 63자로 제한됩니다.
• MySQL 5.7에서는 innodb_large_prefix 파라미터를 사용하여 더 큰 접두사 길이를 허용했습니다. 이 파라미터는 MySQL 8.0에서 더 이상 사용되지 않습니다.
• mysql.host 테이블에 InnoDB 메타데이터 불일치가 없어야 합니다.
• 시스템 테이블에 열 데이터 유형 불일치가 없어야 합니다.
• prepared 상태의 XA 트랜잭션이 없어야 합니다.
• 뷰의 열 이름은 64자를 초과할 수 없습니다.
• 저장 프로시저의 특수 문자 불일치가 없어야 합니다.
• 테이블에 데이터 파일 경로 불일치가 없어야 합니다.

Amazon RDS 블루/그린 배포

• 가장 바람직한 방법으로 신규 클러스터 생성으로 서버 교체가 가능하다는 장점이 있음 (단점이 될 수 있음)
• Route 53 도메인을 통해 일정 기간 동안 읽기 트래픽 일부를 그린환경에서 실행되도록 유도한다면 성능 테스트 및 문제 예방에 효과적임
• Aurora MySQL v3 → v2 replication 가능 유무 확인 필수

작업 스크립트

1. binlog [source] 켜져 있는지 확인하기

# binlog 확인
show global variables like 'log_bin';

show variables like '%binlog_format%';

# 활성화 : Cluster parameter binlog_format을 ROW로 변경 후 인스턴스 재기동 진행

# 확인 명령어
SHOW BINARY LOGS;
SHOW MASTER LOGS;
SHOW MASTER STATUS;

# binlog 보관 기간 확인
CALL mysql.rds_show_configuration;

# binlog 보관 기간 설정 (3일)
CALL mysql.rds_set_configuration('binlog retention hours', 72);

2. 블루/그린 배포 만들기

1. AWS Console → Amazon RDS → 클러스터 선택 → 작업 → 블루/그린 배포 생성
2. 그린 데이터베이스의 엔진 버전을 선택

3. replication 확인 [source, replica]( 확인하는 이유 : 구성하면 자동으로 복제 계정 생성하고 복제 진행된다.)

# 복제용 임시 사용자 확인 (rdsrepladmin)
source, replica > select user, host from mysql.user where user = 'rdsrepladmin'

# 복제 확인
replica > SHOW REPLICA STATUS;

4.  블루/그린 배포 전환(전환하면 자동으로 복제 계정 삭제하고 복제 해제된다.)

• green 클러스터 선택 → 작업 → 전환

5.복구(롤백) 환경 구성 [source, replica]

• 신규로 승격된 인스턴스에서 기존 인스턴스로 복제 구성, 기존 인스턴스를 replica로 명명

binlog로 수동으로 replication 다시 재연결하는 이유: 데이터 동기화를 위해, 롤백용으로 만들기 위해서

# 전환 작업 시 애플리케이션을 중단하지 않았으므로 binlog 위치 탐색
# binlog 확인
source > show binary logs;

# 전환된 지점의 binlog 파일의 이벤트 확인 (Server_id가 변경된 지점)
source > show binlog events in 'mysql-bin-changelog.000001' LIMIT 37,8;

# 복제용 임시 사용자 생성
source > CREATE USER 'repl_user'@'%' IDENTIFIED BY 'password';

# 권한 지정
source > GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
source > flush privileges;

# replication 구성
replica > CALL mysql.rds_set_external_source ('rds.amazonaws.com', 3306, 'repl_user', '비밀번호', 'mysql-bin-changelog.000001', 123, 0);

# 복제 시작
replica > CALL mysql.rds_start_replication;

# 복제 확인
replica > SHOW REPLICA STATUS;

 

참고 : https://aws.amazon.com/ko/blogs/tech/amazon-rds-mysql-blue-green-after-restoring/

Amazon RDS MySQL 블루/그린 배포환경에서 전환 작업 이후 복구 환경 구성을 위한 동기화 기법 | Amazon

Cluster간 binlog replication (스냅샷 복원 및 Aurora clone 복제)

• rollback 간편함
• aurora v2와 v3 버전간 replication 유무 확인 필수

작업 스크립트

1. binlog [source]

• # 원본 클러스터 파라미터에 binlog 켜져있는지 확인
  show global variables like 'log_bin';
  
  # 참조 - 타입 확인
  show variables like '%binlog_format%';
  
  # 확인 명령어
  SHOW BINARY LOGS;
  # 또는
  SHOW MASTER LOGS;
  
  # 또, 아래 명령으로 바이너리 로그 파일에 대한 상태 정보를 확인할 수 있다. 로그위치 확인 가능
  SHOW MASTER STATUS;
  
  # binlog 보관 기간 확인
  CALL mysql.rds_show_configuration;
  
  # binlog 보관 기간 설정 (3일)
  CALL mysql.rds_set_configuration('binlog retention hours', 72);

2. Cluster 복제 [replica]

# 클론을 활용한 클러스터 생성
  - AWS Management Console을 사용하여 Aurora DB 클러스터를 복제하는 방법
    - RDS 콘솔 → 데이터베이스 → 클러스터 선택 → 작업 → **복제본 생성 선택**
    - 설정, 연결성 및 클러스터 복제본에 대한 기타 옵션을 구성할 수 있는 복제본 생성 페이지가 열린다.
    - Aurora DB 클러스터에 부여할 이름을 입력
    - 인스턴스 크기 선택
    - 사용가능이면 복제본을 사용할 준비가 된 것

 
# 스냅샷을 통한 클러스터 생성 (사용안함)
  - write instance 선택 → 작업 메뉴 → 스냅샷 생성 선택
  - 생성된 스냅샷을 선택후 클러스터 생성 (스냅샷 복원을 선택), vpc선택, 파라미터그룹 선택
  - 복원된 인스턴스의 로그& 이벤트 정보에서 binlog 파일명과 포지션 정보를 확인

 

•  

3. replication 구성 [source, replica]

•  
• # 복제용 임시 사용자 생성 source > CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password'; # 권한 지정 source > GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; source > flush privileges; # 2버전 복제 설정 replica > CALL mysql.rds_set_external_master ('rds.amazonaws.com', 3306, 'repl_user', '비밀번호', 'mysql-bin-changelog.000676', 213123132, 0); # 3버전일 경우, 복제 설정 replica > CALL mysql.rds_set_external_source ('rds.amazonaws.com', 3306, 'repl_user', '비밀번호', 'mysql-bin-changelog.000676', 213123132, 0); # 복제 시작 replica > CALL mysql.rds_start_replication;

여기서 매우 중요한 사항.. 확인 또 확인해야한다

binlog는 반드시 복제 시점의 binlog와 position으로 적용해야한다.

복제시점에 aws 접속해서 최근이벤트에서 binlog position을 찾는다.

그 positon을 replication 연결해야된다 아니면 뒤에 나오는 binlog position과 겹쳐서

replication이 실패하게 된다.

아래는 실패 했을때 예시이다

mysql> SHOW SLAVE STATUS\G

Slave_IO_Running: Connecting

Slave_SQL_Running: Yes

error connecting to master 'repl_user@rds.amazonaws.com:3306' - retry-time: 60  retries: 1

 

실패시 Last_IO_Error

error connecting to master 'repl_user@rds.amazonaws.com:3306' - retry-time: 60  retries: 1

메시지가 나오면서 실패 .....

이러면 다시 못 돌린다. stop slave, reset slave해도 소용이 없음

지우고 다시 replication 거는 수밖에없다

그래서 처음부터 꼼꼼하게 잘하는게 중요하다. 

4. replication 확인 [replica]

SHOW SLAVE STATUS; # 2버전
SHOW REPLICA STATUS; # 3버전

•  

5. 업그레이드 진행 및 버전 체크 [replica]

• DB클러스터 선택 > 수정 클릭 > 엔진선택 > 파라미터 그룹을 사전에 미리 생성한 파라미터 그룹으로 변경 > 즉시 적용 선택

# aurora 버전확인
select @@aurora_version;

# DBMS 버전 확인
show variables like '%version';

•  

6. replication 확인 [replica]

SHOW SLAVE STATUS; # 2버전
SHOW REPLICA STATUS; # 3버전

 

 

# 참조

복제 중지
CALL mysql.rds_stop_replication;

복제 정보 삭제
CALL mysql.rds_reset_external_source;

 

Inplace Upgrade

• 추천하지 않는다.
• 스냅샷 생성 뒤, 사용하는 시스템 그대로 업그레이드 시키는 방법
• 중요하지 않은 시스템일 경우

업그레이드 실패시 트러블슈팅

Upgrading the major version of an Amazon Aurora MySQL DB cluster - Amazon Aurora

Upgrading the major version of an Amazon Aurora MySQL DB cluster - Amazon Aurora