Last Updated on 7월 3, 2023 by Jade(정현호)
안녕하세요
이번 포스팅에서는 Amazon RDS for MySQL 에서 Multi-thread Replication 과 Replication-Filter 관련해서 확인 해보려고 합니다.
아래 포스팅에서 이어지는 글 입니다.
Multi-thread Replication
MySQL 5.6 에서 부터 추가된 기능된 병렬 복제 기능(Multi-Threaded Replication)을 RDS for MySQL 에서도 사용할 수 있습니다.
포스팅에서는 RDS for MySQL 8.0.27 버전을 사용하였고, GTID 기능을 RDS for MySQL 8.0.26(8.x 버전대에서는) 부터 지원함으로 GTID 도 같이 사용하도록 하겠습니다.
• 관련 포스팅
MySQL바이너리 그룹 커밋 과 Multi-Threaded Replication 은 기능이 연관되어 있으므로 2개 내용을 모두 확인 하시는 편이 도움이 됩니다. 관련된 내용은 아래 포스팅을 참조하시면 됩니다.
파라미터 그룹 은 아래와 같이 변경 하고 진행 하도록 하겠습니다.
- gtid-mode=1(ON)
- enforce_gtid_consistency=1(ON)
- slave_parallel_type=LOGICAL_CLOCK
- slave_parallel_workers=4
- slave_preserve_commit_order=1
참고로 GTID 모드 설정은 파라미터 그룹에서 2개가 있으며 아래의 이미지 처럼 수정이 가능한 gtid-mode 파마미터를 수정을 하면 됩니다.
slave_parallel_workers 는 복제 상황에 따라서 적절한 값을 설정하여 사용하시면 됩니다.
slave_preserve_commit_order 시스템 변수은 레플리카 서버에서 실행되는 이벤트들이 마스터 서버(소스 서버)에서 커밋된 순서와 동일한 순서로 커밋할 것인지를 제어하는 시스템 변수로 설정이 1(ON) 로 활성화 되어 있다면 워커 스레드들에서 여러 이벤트들이 동시에 처리되어도 릴레이 로그에서에 기록된 순서대로 커밋되어 릴레이 로그에서 실행된 트랜잭션 시퀀스이 간격이 생기는 것을 방지합니다.
이 시스템 변수는 Multit Treaded 이 활성화되지 않은 Replica 에는 영향을 미치지 않습니다.
Primary 인스턴스와 Replica 인스턴스가 각각의 파라미터 그룹을 사용할 경우 MTS 설정과 관련된 파라미터 3개는 Replica 인스턴스에서 사용하는 파라미터 그룹에 설정을 해야 합니다.
( slave_parallel_type, slave_parallel_workers, slave_preserve_commit_order)
slave_preserve_commit_order=1 을 사용하려면 Replica 인스턴스에서 --log-bin 및 --log-slave-updates를 활성화해야 합니다. 그리고 slave_parallel_type 은 LOGICAL_CLOCK 으로 설정되어야 합니다.
RDS for MySQL 과 Aurora MySQL 에서 log_slave_updates 파라미터의 기본 값은 1(ON) 이며, 변경이 불가한 파라미터 입니다.
파라미터 그룹 설정 및 읽기 전용 복제본 생성이 완료 된 후 먼저 Replica 인스턴스에 접속하여 show replica(slave) status\G 를 조회하면 아래와 같이 Auto_Position=1 로 GTID 모드로 복제가 되고 있는 것을 확인 할 수 있습니다.
Source_SSL_Crlpath:
Retrieved_Gtid_Set: fa9a55d0-8aa2-11ec-9545-0a9d00b777e8:1-7
Executed_Gtid_Set: fa9a55d0-8aa2-11ec-9545-0a9d00b777e8:1-7
Auto_Position: 1
Replicate_Rewrite_DB:
[참고] GTID_MODE 지원은 RDS for MySQL 8.0.26 이상 부터 가능 합니다.
각 복제 스레드에서 몇 개의 트랜잭션을 실행하는지 등을 확인 하기 위해서는 Performance_schema 를 참조하시면 됩니다.
먼저 performance_schema의 replication_applier_status_by_worker 를 통해 아래와 같이 설정한 WORKER 수나 정보를 확인 학인 할 수 있습니다.
mysql> select * from
performance_schema.replication_applier_status_by_worker\G
*************************** 1. row ***************************
CHANNEL_NAME:
WORKER_ID: 1
*************************** 2. row ***************************
CHANNEL_NAME:
WORKER_ID: 2
*************************** 3. row ***************************
CHANNEL_NAME:
WORKER_ID: 3
*************************** 4. row ***************************
CHANNEL_NAME:
WORKER_ID: 4
< 내용 중략 >
performance_schema 의 events_transactions_summary_by_thread_by_event_name 는 performance_schema 에서 지표 활성화가 필요 합니다.
performance_schema.setup_instruments 를 통해서 활성화 하거나 RDS의 Performance Insights(한글: 성능 개선 도우미) 를 사용중이라면 활성화가 됨으로 별도로 작업 하실것은 없습니다.
[참고1] Performance Insights 는 모든 RDS 클래스 에서 지원되는 것은 아니면 보통 작은 규모인 micro, small 에서는 지원되지 않습니다.
[참고2] RDS 가 아닌 MySQL 엔진에서의 slave_parallel_type 와 slave_parallel_workers 시스템 변수의 변화가 있으며, MySQL 서버 8.0.26 버전 부터 replica_parallel_type 과 replica_parallel_workers 으로 이름이 변경되었습니다.
8.0.27에서는 replica_parallel_type의 기본값이 DATABASE 에서 LOGICAL_CLOCK 으로 변경되었으며, replica_parallel_workers 기본값도 4로 변경되었습니다.
8.0.29 버전부터 replica_parallel_type is deprecated 가 되고 LOGICAL_CLOCK은 이후에 독점적으로 사용된다 라고 하며 해당 부분은 8.0.29 버전이 릴리즈 되고 추가로 확인을 해보긴 해야할것 같습니다.
Replication-Filter
RDS for MySQL 이 Aurora for MySQL 에 비해 장점이라고 한다면 이번에 확인 할 Replication-Filter 와 같이 MySQL 자체의 고유의 기능을 그래도 Aurora 에 비해서 조금 더 많이 사용을 할 수 있다는 점일 것 같습니다.
상황에 따라서 보편적으로 Database(Schema) 단위로 복제 필터를 하거나 테이블 단위로 필터를 사용할 경우가 있으실 것 입니다.
RDS for MySQL 에는 이미 table 단위로 Replication Filter 가 설정된 상태 이긴 합니다.
mysql> show replica status\G
*************************** 1. row ***************************
Replica_IO_State:
Source_Host:
Source_User: rdsrepladmin
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin-changelog.000741
Read_Source_Log_Pos: 573
Relay_Log_File: relaylog.000018
Relay_Log_Pos: 4
Relay_Source_Log_File: mysql-bin-changelog.000741
Replica_IO_Running: No
Replica_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table: innodb_memcache.cache_policies,innodb_memcache.config_options,mysql.plugin,mysql.rds_configuration,mysql.rds_history,mysql.rds_monitor,mysql.rds_replication_status,mysql.rds_sysinfo
Replicate_Wild_Do_Table:
복제 필터 제한 사항
RDS for MySQL 에 대한 복제 필터에 다음과 같은 제한 사항이 적용됩니다.
-
각 복제 필터링 파라미터에는 2,000자 제한이 있습니다.
-
복제 필터에서는 쉼표가 지원되지 않습니다.
-
이진 로그 필터링에 대해서는 MySQL
--binlog-do-db및--binlog-ignore-db옵션이 지원되지 않습니다. -
복제 필터링은 XA 트랜잭션을 지원하지 않습니다.
자세한 내용은 MySQL 설명서에서 XA 트랜잭션에 대한 제한 사항을 참조하세요.
-
복제 필터링은 RDS for MySQL 버전 8.0.17 이상의 8.0 버전 및 버전 5.7.26 이상의 5.7 버전에 대해 지원됩니다.
-
RDS for MySQL 버전 5.6에 대해서는 복제 필터링이 지원되지 않습니다.
위와 같은 제약사항이 아니라면 보통의 경우에는 필터 적용이 가능 합니다.
Source 와 Replica 인스턴스가 같은 파라미터 그룹을 사용하고 있다면 해당 파라미터 그룹에 설정을, 인스턴스 별로 각각 사용 중이라면 Replica 인스턴스에서 사용중인 파라미터 그룹에서 아래와 같이 설정을 진행하시면 됩니다.
파라미터를 설정 하기 위해서 먼저 Replica 인스턴스에서 사용중인 파라미터 그룹을 선택 합니다.
파라미터 그룹에서 ignore 로 검색하면 아래와 같이 3개의 파라미터가 검색되며 수정 가능하고, 적용 유형은 dynamic 인 것을 확인 할 수 있습니다. 오른쪽 상단의 "파라미터 편집" 버튼을 클릭 합니다
설정 할 파라미터에 복제를 하지 않은 대상(DB 또는 Table) 을 입력 한 후 우측 상단에 "변경 사항 저장" 을 클릭하여 저장을 합니다.
또는 변경 사항 미리 보기를 선택하여 변경되는 파라미터 내용을 적용 전에 확인 할 수도 있습니다.
파라미터가 적용이 시작되면 아래와 같이 인스턴스의 상태는 "수정 중" 으로 변경 되게 됩니다
인스턴스가 자동으로 재기동 되지는 않습니다.
변경이 완료 되면 상태는 "사용 가능" 으로 다시 표기가 변경 되며, 로그 및 이벤트 에서는 아래 와 같이 이벤트 내용을 확인 할 수 있습니다.
필터 설정이 완료 된 후 Replica 인스턴스에서 복제 상태를 조회하면 아래와 같이 filter 가 적용 된 것 을 확인 할 수 있습니다.
mysql> show replica status\G
*************************** 1. row ***************************
Replica_IO_State:
Source_Host:
Source_User: rdsrepladmin
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin-changelog.000741
Read_Source_Log_Pos: 573
Relay_Log_File: relaylog.000040
Relay_Log_Pos: 4
Relay_Source_Log_File: mysql-bin-changelog.000741
Replica_IO_Running: No
Replica_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB: tdb <---!!!!
Replicate_Do_Table:
위와 같이 ignore_db 가 적용 되었다면 마스터 서버에서의 변경 내영이 반영이 되지 않게 됩니다.
-- Master mysql> select * from tb_test; +------+ | id | +------+ | 1 | +------+ -- Slave mysql> select * from tb_test; +------+ | id | +------+ | 1 | +------+ -- Master mysql> insert into tb_test values(2); Query OK, 1 row affected (0.01 sec) mysql> select * from tb_test; +------+ | id | +------+ | 1 | | 2 | +------+ -- Slave mysql> select * from tb_test; +------+ | id | +------+ | 1 | +------+다
다만 Replica 측에서 복제에 대해서 ignore 설정이기 때문에 Replica 의 Relaylog 를 확인하면 Source 에서의 변경 내용이 Relaylog 에도 기록 되고 있음을 확인할 수 있습니다. ignore 설정에 의해서 Replica 에서 반영만 하지 않을 뿐 입니다.
작업 이나 임시성의 데이터베이스를 생성후 ignore_db 로 지정하여 사용하는 방법을 생각 해볼 수 있습니다.
ctas 등으로 임시적으로 데이터를 만들어서 보거나 DML 을 위한 임시 중간 테이블 등으로 임시성 또는 작업용 database 를 생성 후 ignore_db 로 지정하여 사용하는 방법이 보통적이라고 할수 있겠습니다.
복제가 불필요한 테이블이 업무적으로 확인된 다면 해당 테이블에 대해서 ignore_table 설정 진행할 수도 있습니다.
다만 설치형 MySQL 이나 RDS 나 모두 주의할 점은 ignore_db 가 설정된 db 에서 작업시 복제가 되어야할 오퍼레이션도 복제가 안될수 있다는 점 입니다.
ignore_db 로 설정된 db에서 임시성 insert나 ctas 등으로 작업 후에 데이터베이스(스키마) 변경 없이 ignore_db에서 계속 작업을 하면 Replica 인스턴스로 복제가 되어야 할 정상적인 오퍼레이션인 계정 생성이나 권한 생성 , 테이블의 생성이나 데이터 변경 등도 Replica 인스턴스로 복제가 되지 않게 됩니다.
그래서 복제가 되어야하는 작업일 경우에는 명시적으로 다른 db로 이동하여 작업해야 함을 상기 해야 합니다.
mysql> use tdb; <-- ignore_db 로 설정된 DB < ... 임시성 작업 ...> -- DB 변경 mysql> use seller; mysql> create table ... mysql> create user... mysql> grant ... mysql> insert ....
* create database 구문은 ignore 와 상관없이 복제가 됩니다.
[참고] RDS의 Read Replica 에서는 read_write 가 가능 합니다.
가령 ignore_db 로 지정된 데이터베이스 설정하기 전에 테이블이 있었을 경우 Read Replica 에 있는 테이블을 삭제 하기 위해서 Read Replica 에서 drop table 을 수행하게 되면 read-only 이기 때문에 명령어 수행이 불가능 하게 됩니다.
그렇다고 Master 인스턴스에서 drop table 구문을 수행하여도 ignore_db 라서 명령어가 복제 수행되지 않습니다.
이럴 경우 ignore_db 설정을 해제하고 master 에서 명령을 수행하여 replica 인스턴스에서 복제가 되어서 처리할 수도 있겠으며 아래와 같이 read_only 를 =off(0) 으로 설정 변경하고 Read Replica 에서 직접 명령어를 수행하는 것도 한가지 방법이 될 수 있습니다.
* Read Replica에서 read_only = off 로 설정 되었을 경우 Read Replica 에서 수행되는(임의이건 실수이건) DML이나 DDL 수행에 매우 주의가 필요합니다.(문제가 발생하여 리플리케이션이 중지가 될수 있음)
이번 포스팅은 여기까지 정리하도록 하겠으며 추가적인 내용은 향후 업데이트 하도록 하겠습니다.
Reference
Reference Link
• aws.amazon.com/USER_MySQL.Replication.ReadReplicas
• aws.amazon.com/amazon-rds-for-mysql-part-2
• blog.naver.com/lyh1620
• percona.com/mysql-5-7-parallel-replication
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
