AWS Aurora 5.7에서 MySQL 5.7로 복제 실패기

1. Intro

  • AWS RDS 5.7 지원 중단. 일부는 버전 업 / 일부는 버전 고정 후 IDC 이동
  • 어떻게 안정적으로 옮길 수 있을까
    • 대부분의 레퍼런스들은 클라우드 벤더로 들고오는 예시 (IDC > AWS)
    • 벤더사를 탈피하는 예시는 거의 없다 (AWS > IDC)
  • 근데 시키면 해야지
    • dump & restore 방식은 정지가 불가결
    • 실시간 / 최종적 동기화되는 replication으로 구성할 수 없을까
  • RDS는 Managed 서비스, 안정적인 서비스 제공은 가능하나 디테일을 제어할 수 있는 수단이 거의없다
  • 증분 백업 & 리스토어 개념으로 접근> 실패
  • 실시간 데이터 누적분 전환 필요 > DMS를 사용한 CDC로 해결


2. 실패) Aurora 5.7와 MySQL replication

둘다 동일한 MySQL 5.7 기반이므로 최초에는 단순히 두개 클러스터간 binlog replication을 설정하면 될것이라고 생각하였다.

Ref) https://hoing.io/archives/2638

그러나.. Aurora 5.7과 설치형 MySQL 5.7간의 binlog replication은 원활히 수행되지 않는다.

3. Aurora 5.7은 MySQL 5.7인가 8.0인가

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.2124.html

Aurora MySQL 2.12 버전은 MySQL 5.7.44까지 호환됩니다. 

동일한 버전의 Database 서버이므로 두 서버간 이진로그 기반 복제를 설정하면 원활하게 동기화 및 데이터 이전이 진행될 것이라고 생각했다. 그러나, 실제로 동기화가 진행되지는 못하였다.

Aurora RDS 내부 동작은 8.0 의심

그 이유는 RDS 복제를 설정했을때 일련의 오류와 함께 원활히 연동되었지 않았기 때문이다. 처음에는 구성 설정의 누락 및 오류를 의심하였으나, 각 에러의 원인을 살펴보면 Aurora MySQL version2는 MySQL5.7이 아닌 8을 기반으로 만들어지지않았나 하는 의문이 든다.


RDS main cluster든, 스냅샷으로 생성한 RDS replica cluster든 아래와 같은 에러들이 발생하였다.

Error ‘Character set ‘#255’ 

Error 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query, ~

두 서버간 default collation이 달라서 발생하였고, MySQL 8.0->5.7 으로의 리플리케이션이 불가능 하다. 하위버전에서 상위버전으로의 연동은 가능하겠으나, 상위버전에서 하위버전으로의 연동은 지원하지 않는것과 유사한느낌인가.. 싶기도하고

  • https://kimdubi.github.io/mysql/mysql8to57_collation/
  • https://stackoverflow.com/questions/70751902/error-character-set-255-in-mysql-replication

collation_server > utf8mb4_0900_ai_ci

MySQL에서 collation_server 변수는 서버의 기본 정렬방식(collation)을 정의하는 역할을 한다. MySQL 5.7에서는 default로 latin1_swedish_ci 의 값을 갖고, MySQL 8.0에서는 utf8mb4_0900_ai_ci 의 값을 갖는다.

컨테이너로 MySQL 5.7, MySQL 8.0 각각 실행

  • MySQL5.7 docker compose
services:
  mysql57:
    image: mysql:5.7
    container_name: mysql57
    ports:
      - "5700:3306"
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: testdb57
      MYSQL_USER: user57
      MYSQL_PASSWORD: password57
    volumes:
      - mysql57_data:/var/lib/mysql
    restart: unless-stopped
volumes:
  mysql57_data:

  • MySQL 8.0 docker compose
services:
  mysql80:
    image: mysql:8.0
    container_name: mysql80
    ports:
      - "8000:3306"
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: testdb80
      MYSQL_USER: user80
      MYSQL_PASSWORD: password80
    command: --default-authentication-plugin=mysql_native_password --ssl=0
    volumes:
      - mysql80_data:/var/lib/mysql
    restart: unless-stopped
volumes:
  mysql80_data:

5.7 환경에서는 utf8mb4_0900_ai_ci 값이 없어서 조회 및 설정이 불가능하다.

# mysql 사용 환경 설정
export MYSQL_PWD=root

# 각 MySQL 서버의 character_set, collation 값 조회
mysql -uroot -h 127.0.0.1 -e "SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';" -P5700

mysql -uroot -h 127.0.0.1 -e "SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';" -P8000

# 5.7에서, 지원하는 collation_server의 값에 utf8mb4_0900_ai_ci 는 없음
mysql -uroot -h 127.0.0.1 -e "SHOW COLLATION WHERE Charset = 'utf8mb4';" -P5700

mysql -uroot -h 127.0.0.1 -e "SHOW COLLATION WHERE Charset = 'utf8mb4';" -P8000
  • 각 서버의 default collation_server variable 조회
  • 지정할 수 있는 collation 조회

default storage engine > InnoDB

두 버전의 DB 모두 Default Storage Engine 으로 InnoDB를 사용한다

따라서 실제로 새로 생성한 스키마등은 기본적으로 InnoDB 스토리지엔진으로 구성된다

그러나 클러스터 환경을 담당하는 시스템 테이블들(mysql등)중 일부는, MySQL 5.7에서는 MyISAM engine을 사용하며, MySQL 8.0에서는 InnoDB engine을 사용한다. 이는 변경이 불가능하다.

# 5.7에서, mysql 데이터베이스의 테이블들의 엔진 조회
mysql -uroot -h 127.0.0.1 -e "SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_SCHEMA = 'mysql';" -P5700

# 8.0에서, mysql 데이터베이스의 테이블들의 엔진 조회
mysql -uroot -h 127.0.0.1 -e "SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_SCHEMA = 'mysql';" -P8000
MySQL 5.7
MySQL 8.0
  • 백업 & 리스토어을 위한 mysqldump 사용 시, –all-databases 옵션을 사용하면 mysql, sys같은 모든 시스템 테이블까지 덤프된다.
  • 5.7 버전에서 일부 시스템 데이터베이스는 MyISAM Storage Engine사용, 8버전부터는 모두 InnoDB를 사용한다.
  • dump restore시 기본적으로 각 테이블에 대해 TABLE DROP 이후 CREATE TABLE 하는 과정을 거친다
  • 따라서 restore시 Storage Engine이 달라서 복원이 안되는 에러 발생
    • ERROR 1726 (HY000) at line 188528: Storage engine 'InnoDB' does not support system tables. [mysql.columns_priv]
  • 관련 레퍼런스를 알아보았을시에는, system table (information_schema mysql performance_schema sys tmp)을 제외하고 덤프하기 권장
    • https://stackoverflow.com/questions/60335202/mysql-error-1726-hy000-at-line-storage-engine-innodb-does-not-support
  • 5.7 버전에서 system table을 MyISAM에서 InnoDB로 변경하는것은 권장되지않음.

Warning

Do not convert MySQL system tables in the mysql database from MyISAM to InnoDB tables. This is an unsupported operation. If you do this, MySQL does not restart until you restore the old system tables from a backup or regenerate them by reinitializing the data directory (see Section 2.9.1, “Initializing the Data Directory”).

Converting an Existing Table, MySQL 5.7 docs

4. RDS for MySQL <> Aurora MySQL

RDS에서 MySQL cluster를 운영할 시 MySQL 그대로 사용하는 RDS for MySQL과 AWS에서 조금더 개선한 Aurora 두가지 선택지가 있다.

두 엔진 모두 mysql을 다루기에 동일할것이다라고 생각하였으나 설정 옵션등에서 다소 차이가 존재하였다. 어쩐지 문서에서 다루는 용어가 콘솔에서 안보이더라니..

  • 읽기 전용 복제본 > RDS for MySQL / 읽기 인스턴스 추가 > Aurora MySQL
  • RDS for MySQL stored procedure
    • https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-stored-proc-replicating.html
  • Aurora MySQL stored procedure reference
    • https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/mysql-stored-proc-replicating.html

5. Outro

Aurora RDS cluster에 직접 설치형 MySQL 인스턴스를 복제대상으로 추가하여 백업하는 방식은 Aurora 5.7에서 MySQL 5.7간의 직접 replication이 성공적으로 설정되지않아 실패하였다.

동기화를 제공하는 기능을 직접적으로 사용할 수 없다면, 목적을 이루기 위해 어떻게 이를 우회하여 or 비슷한 기능을 사용하여 구성할 수 있을까?

지금의 경우 목적은 하나의 Database cluster에서 다른 Database cluster로의 데이터 이전이 목적이였다. 이를 위해 직접적으로 binlog 기반 replication을 시도하였으나 원활히 사용할 수 없었다.

동기화를 어떻게 나누어서 생각할 수 있을까? 이미 기존에 쌓인 데이터와 추가로 쌓이는 변경분으로 나누어 생각할 수 있을것이다. 기존에 쌓인 데이터의 경우 dump & restore로 해결할 수 있고, 변경분의 경우 직접 replication이 되지않아 AWS DMS(Database Migration Service)를 사용해 source cluster에서의 변경 누적분을 감지한뒤 target cluster에 적용하는 방식으로 해결할 수 있었다. 이를 구성하는 과정은 다음글에서 검토하도록 하겠다.

Leave a Reply