MySQL 8.0에서 추가된 모든 기능 – 복제

1. 다중 소스 복제(Multi Source Replication)에서 채널별 필터 설정

[원본제공링크 1]

다중 소스 복제는 하나의 복제본(replica)이 여러 소스(master)로부터 데이터를 복제하는 구조입니다. MySQL 8.0부터는 각 복제 채널에 대해 개별적인 필터를 설정할 수 있어, 특정 소스에서만 필요한 데이터만을 복제하도록 구성할 수 있습니다. 이는 동일한 데이터베이스나 테이블이 여러 소스에 존재할 때, 복제본이 특정 소스에서만 해당 데이터를 복제하도록 제어할 수 있게 합니다.

2. 바이너리 로그를 통한 원자적 DDL 복구

[원본제공링크 1]

MySQL 8.0에서는 원자적 DDL(데이터 정의 언어) 기능이 도입되어, DDL 작업 시 데이터 사전, 스토리지 엔진, 바이너리 로그에 대한 변경을 하나의 원자적 작업으로 처리합니다. 이는 서버가 중단되더라도 DDL 작업이 완전히 적용되거나 전혀 적용되지 않도록 보장합니다. 복구 시에는 바이너리 로그를 활용하여 이러한 원자성을 유지하며, 일관된 데이터베이스 상태를 복원합니다.

3. Write-set 기반 트랜잭션 의존성 추적

[원본제공링크 1 2]

MySQL 8.0에서는 트랜잭션 간의 의존성을 추적하기 위해 쓰기 집합(Write Set) 기반의 메커니즘을 도입했습니다. 이를 통해 복제본(replica)에서 병렬로 적용할 수 있는 트랜잭션을 식별하여, 복제 성능을 향상시킵니다. 쓰기 집합 기반 트랜잭션 의존성 추적은 각 트랜잭션이 데이터베이스에서 수정하는 행(row)의 집합을 분석하여, 서로 독립적인 트랜잭션을 병렬로 처리할 수 있도록 하는 기술입니다. 이 메커니즘은 복제본에서 병렬 복제의 효율성을 높여, 복제 지연(slave lag)을 줄이고 전체 시스템의 성능을 개선합니다.

4. 수신 스레드와 적용 스레드 간 경합 감소

[원본제공링크 1]

MySQL 8.0에서는 복제본의 수신 스레드(I/O 스레드)와 적용 스레드(SQL 스레드) 간의 경합을 줄이기 위해 동기화 메커니즘이 개선되었습니다. MySQL의 복제본은 소스 서버로부터 데이터를 수신하는 I/O 스레드와, 수신된 데이터를 적용하는 SQL 스레드로 구성됩니다. 이전 버전에서는 두 스레드가 릴레이 로그에 접근할 때 잠금을 사용하여 경합이 발생하였고, 이는 복제 성능 저하의 원인이 되었습니다. MySQL 8.0에서는 이러한 경합을 줄이기 위해 동기화 메커니즘이 개선되어, 두 스레드가 릴레이 로그에 대한 잠금 없이 병렬로 작업할 수 있게 되었습니다.

5. 트랜잭션 내 임시 테이블에 대한 GTID 지원

[원본제공링크 1]

MySQL 8.0.13부터는 GTID(Global Transaction Identifier) 모드에서 트랜잭션 내부에서 임시 테이블을 생성하거나 삭제할 수 있습니다. GTID는 각 트랜잭션에 고유한 식별자를 부여하여 복제의 일관성을 유지하는 기능입니다. 이전에는 GTID 모드에서 트랜잭션 내부에서 임시 테이블을 생성(CREATE TEMPORARY TABLE)하거나 삭제(DROP TEMPORARY TABLE)하는 것이 제한되었습니다. 그러나 MySQL 8.0.13부터는 바이너리 로그 포맷을 ROW 또는 MIXED로 설정하면 이러한 제한이 해제되어, 트랜잭션 내부에서도 임시 테이블을 자유롭게 사용할 수 있게 되었습니다.

6. 부분 JSON 업데이트 복제

[원본제공링크 1]

이전의 MySQL 버전에서는 JSON 문서의 일부를 수정하더라도 전체 문서를 바이너리 로그에 기록하고 복제본으로 전송했습니다. 이로 인해 큰 JSON 문서의 작은 변경에도 많은 리소스가 소모되었습니다. MySQL 8.0.3부터는 binlog_row_value_options 변수를 PARTIAL_JSON으로 설정하면, JSON 문서의 부분 업데이트 시 변경된 부분만을 바이너리 로그에 기록하고 복제합니다. 이를 통해 디스크 사용량과 네트워크 트래픽을 줄이고, 복제 성능을 향상시킬 수 있습니다.

7. 바이너리 로그에 확장된 테이블 메타데이터

[원본제공링크 1 2]

바이너리 로그는 데이터 변경 이벤트를 기록하여 복제와 복구에 활용됩니다. MySQL 8.0.1부터는 테이블의 확장된 메타데이터가 바이너리 로그에 포함되어, 복제본(replica)에서 데이터 타입 변환과 같은 작업을 더 정확하게 수행할 수 있습니다.

8. RESET MASTER TO ‘x’

[원본제공링크 1]

MySQL 8.0에서 RESET MASTER TO 'x' 명령어는 바이너리 로그 파일의 인덱스를 ‘x’로 초기화합니다. 이는 새로운 복제 설정 시 바이너리 로그 파일의 번호를 원하는 값으로 시작할 수 있게 해줍니다. RESET MASTER 명령어는 현재 서버의 모든 바이너리 로그 파일을 삭제하고, 새로운 빈 바이너리 로그 파일을 생성합니다. TO 'x' 옵션을 사용하면, 새로운 바이너리 로그 파일의 인덱스를 ‘x’로 설정할 수 있습니다. 예를 들어, RESET MASTER TO 1234;를 실행하면 새로운 바이너리 로그 파일이 source-bin.001234로 시작합니다.

9. GTID_EXECUTED가 비어 있지 않을 때 GTID_PURGED 설정 가능

[원본제공링크 1]

MySQL 8.0부터는 GTID_EXECUTED가 비어 있지 않더라도 GTID_PURGED를 설정할 수 있습니다. 이는 복제 환경에서 GTID 관리의 유연성을 높여, 특정 GTID 세트를 추가하거나 기존 세트로 교체할 수 있게 합니다. GTID(Global Transaction Identifier)는 각 트랜잭션에 고유한 식별자를 부여하여 복제의 일관성을 유지하는 데 사용됩니다. GTID_EXECUTED는 서버에서 실행된 모든 GTID의 집합을 나타내며, GTID_PURGED는 바이너리 로그에서 제거된 GTID의 집합을 나타냅니다. 이전 버전에서는 GTID_EXECUTED가 비어 있어야만 GTID_PURGED를 설정할 수 있었지만, MySQL 8.0부터는 이러한 제한이 제거되었습니다.

10. 초 단위로 설정 가능한 바이너리 로그 만료 시간

[원본제공링크 1]

바이너리 로그는 데이터 변경 이벤트를 기록하여 복제 및 복구에 활용됩니다. 이전에는 expire_logs_days 변수를 사용하여 일 단위로 로그의 보관 기간을 설정했으나, MySQL 8.0부터는 binlog_expire_logs_seconds 변수를 도입하여 초 단위로 설정할 수 있게 되었습니다. 이를 통해 로그 보관 기간을 보다 세밀하게 관리할 수 있습니다.

11. 디스크가 가득 찬 상황에서도 복제 모니터링이 중단되지 않음

[원본제공링크 1]

이전 버전의 MySQL에서는 디스크 공간이 부족할 때 복제 스레드가 멈추고, 이로 인해 복제 상태를 확인하거나 스레드를 종료하는 명령어들이 응답하지 않는 문제가 있었습니다. MySQL 8.0.2부터는 이러한 상황에서도 복제 모니터링 명령어(SHOW SLAVE STATUS 등)와 관리 명령어(KILL 등)가 즉시 응답하도록 개선되었습니다. 이를 통해 디스크 공간 부족 시에도 복제 상태를 신속하게 파악하고, 필요한 조치를 취할 수 있습니다.

12. 바이너리 로그에 트랜잭션 바이트 길이 메타데이터 포함

[원본제공링크 1]

MySQL 8.0.2부터 바이너리 로그에 각 트랜잭션의 바이트 길이 메타데이터가 포함됩니다. 바이너리 로그는 MySQL에서 데이터 변경 이벤트를 기록하여 복제 및 복구에 활용됩니다. MySQL 8.0.2부터는 각 트랜잭션의 바이트 길이 정보가 바이너리 로그에 메타데이터로 포함되어, 로그를 파싱할 때 트랜잭션의 시작과 끝을 쉽게 식별할 수 있으며, 복제 및 데이터 변경 캡처(CDC) 작업의 효율성이 향상됩니다.

13. 바이너리 로그의 각 트랜잭션에 대한 서버 버전 정보

[원본제공링크 1 2 3]

바이너리 로그는 MySQL에서 데이터 변경 이벤트를 기록하여 복제 및 복구에 활용됩니다. MySQL 8.0.14부터는 각 트랜잭션에 대해 두 가지 서버 버전 정보가 바이너리 로그에 포함됩니다:
1. original_server_version: 트랜잭션이 처음 커밋된 서버의 MySQL 버전.
2. immediate_server_version: 트랜잭션이 복제되어 직전에 적용된 서버의 MySQL 버전.
이러한 정보는 복제 환경에서 서버 간의 버전 차이로 인한 호환성 문제를 진단하고 해결하는 데 유용합니다.

14. 다중 스레드 복제본에서 START SLAVE UNTIL 명령어 지원

[원본제공링크 1]

START REPLICA UNTIL 명령어는 복제본이 특정 지점까지 복제를 진행한 후 자동으로 멈추도록 설정합니다. MySQL 8.0부터는 다중 스레드 복제본에서도 이 명령어를 사용할 수 있으며, 이는 복제본의 동기화 및 관리에 유용합니다.

15. 마이크로초 단위 지연 복제 지원

[원본제공링크 1]

지연 복제는 복제본(replica)이 원본 서버(source)보다 일정 시간 뒤에 트랜잭션을 적용하도록 설정하는 기능입니다. 이는 원본 서버에서 발생한 실수나 오류로부터 복제본을 보호하거나, 특정 시점의 데이터 상태를 유지하는 데 유용합니다. MySQL 8.0에서는 CHANGE REPLICATION SOURCE TO SOURCE_DELAY = N 명령어를 사용하여 지연 시간을 설정하며, 여기서 N은 지연 시간(초 단위)을 나타냅니다.
(원본 타이틀이 마이크로초에 대한 이야기인데, 딜레이는 초 단위로만 설정 가능합니다. 링크되어있는 레퍼런스 매뉴얼 내용 참고해보면, 딜레이가 모니터링 되기로는 마이크로초 단위로 모니터링 된다는 취지인 것 같습니다. )

16. binlog-row-event-max-size 시스템 변수

[원본제공링크 1]

MySQL의 바이너리 로그는 데이터 변경 이벤트를 기록하여 복제 및 복구에 활용됩니다. 행 기반 복제를 사용할 때, 여러 행의 변경 사항을 하나의 이벤트로 그룹화하여 바이너리 로그에 기록합니다. binlog_row_event_max_size 변수는 이러한 행 기반 이벤트의 최대 크기를 지정하며, 가능한 경우 이 크기를 초과하지 않도록 이벤트를 그룹화합니다. 그러나 단일 행의 변경이 이 크기를 초과하는 경우, 해당 이벤트는 설정된 크기를 넘을 수 있습니다.

17. PFS(Performance Schema)를 통한 복제 적용기 지연 및 큐 모니터링

[원본제공링크 1 2 3]

MySQL의 Performance Schema는 서버의 성능 및 상태를 모니터링하는 도구로, 복제 관련 정보를 제공하는 여러 테이블을 포함합니다. 특히, 복제 적용기의 지연 및 큐 상태를 모니터링하는 데 유용한 테이블들이 있습니다.

예시:

-- 각 워커 스레드의 상태
SELECT * FROM performance_schema.replication_applier_status_by_worker; 

-- 코디네이터 스레드의 상태
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;

-- 복제 적용기의 전체적인 상태
SELECT * FROM performance_schema.replication_applier_status;

18. PFS: 백업을 위한 일관된 로그 위치 읽기

[원본제공링크 1]

백업 시 데이터의 일관성을 유지하려면 데이터 파일과 함께 해당 시점의 로그 위치를 정확히 파악해야 합니다. MySQL 8.0.11부터 도입된 performance_schema.log_status 테이블은 이러한 정보를 제공합니다. 이 테이블을 조회하면 서버는 짧은 시간 동안 “프리즈” 상태가 되어 GTID, 현재 바이너리 로그 파일명 및 위치, 각 복제 채널의 릴레이 로그 파일명 및 위치, InnoDB의 LSN(Log Sequence Number) 등을 일관된 상태로 수집합니다. 이를 통해 백업 도구는 해당 시점의 정확한 로그 위치를 파악하여 복제 및 복구 시 데이터 일관성을 유지할 수 있습니다.

19. PFS: 행 기반 복제 적용기 스레드 진행 상태

[원본제공링크 1]

MySQL의 행 기반 복제(Row-Based Replication)는 데이터 변경을 행 단위로 기록하여 복제하는 방식입니다. 이 과정에서 적용기 스레드(applier thread)는 원본 서버의 변경 사항을 복제본에 적용합니다. Performance Schema는 이러한 적용기 스레드의 진행 상황을 모니터링할 수 있는 다양한 테이블을 제공합니다.

20. PFS: 복제 적용기 재시도에 대한 카운터

[원본제공링크 1]

복제 환경에서 적용기 스레드는 원본 서버의 트랜잭션을 복제본에 적용합니다. MySQL의 Performance Schema는 복제 적용기(applier) 스레드의 트랜잭션 재시도 횟수를 모니터링할 수 있는 기능을 제공합니다. 이를 통해 복제 지연의 원인을 파악하고, 복제 성능을 최적화하는 데 도움이 됩니다. 일시적인 오류나 충돌로 인해 트랜잭션 적용이 실패할 경우, 설정된 횟수만큼 재시도를 수행합니다. 이러한 재시도는 복제 지연의 원인이 될 수 있으므로, 모니터링이 중요합니다.

예시:

-- 해당 채널에서 발생한 총 트랜잭션 재시도 횟수를 확인
SELECT CHANNEL_NAME, COUNT_TRANSACTIONS_RETRIES
FROM performance_schema.replication_applier_status;

--  마지막으로 적용된 트랜잭션의 재시도 횟수를 확인
SELECT WORKER_ID, LAST_APPLIED_TRANSACTION_RETRIES_COUNT
FROM performance_schema.replication_applier_status_by_worker;

21. 바이너리 로그 마스터 키 온라인 회전 지원

[원본제공링크 1]

MySQL 8.0.16부터 ALTER INSTANCE ROTATE BINLOG MASTER KEY 명령어를 통해 서버를 중단하지 않고 바이너리 로그 마스터 키를 교체할 수 있습니다. 이 명령어는 새로운 마스터 키를 생성하고, 기존의 바이너리 로그와 릴레이 로그 파일의 암호화 키를 업데이트하며, 사용되지 않는 이전 키를 키링에서 제거합니다.

22. 바이너리 로그에 파티션 메타데이터 포함

[원본제공링크 1]

MySQL에서 파티션 테이블은 데이터를 여러 파티션으로 분할하여 저장함으로써 대용량 데이터 처리 시 성능을 향상시킵니다. 바이너리 로그는 데이터 변경 사항을 기록하여 복제 및 복구에 활용되는데, 파티션 테이블의 경우 변경된 데이터가 어느 파티션에 속하는지의 정보도 함께 기록됩니다.

23. 바이너리 로그 캐시 암호화 지원

[원본제공링크 1]

MySQL 8.0.14부터 바이너리 로그와 릴레이 로그 파일의 암호화를 지원합니다. 그러나 바이너리 로그 캐시의 메모리 버퍼는 암호화되지 않으며, MySQL 8.0.17부터는 이 캐시가 디스크의 임시 파일로 기록될 때 AES-CTR 모드로 암호화됩니다.

24. mysqlbinlog의 프로토콜 압축 지원

[원본제공링크 1]

MySQL 8.0.17부터 mysqlbinlog 유틸리티는 --compress 또는 -C 옵션을 통해 서버와의 통신 시 프로토콜 압축을 지원합니다. 이를 통해 바이너리 로그를 원격 서버에서 읽을 때 네트워크 대역폭을 절약하고 전송 속도를 향상시킬 수 있습니다.

25. 권한 검사를 통한 복제 지원

[원본제공링크 1 2]

기본적으로 MySQL 복제는 소스 서버에서 이미 승인된 트랜잭션을 복제본에서 적용할 때 추가적인 권한 검사를 수행하지 않습니다. 그러나 보안 강화를 위해 복제본에서 트랜잭션을 적용하기 전에 지정된 사용자 계정의 권한을 확인하도록 설정할 수 있습니다. 이를 위해 MySQL 8.0.18부터 복제 시 권한 검사를 수행하는 PRIVILEGE_CHECKS_USER 기능이 도입되었습니다. 이를 통해 복제 적용기(applier)가 각 트랜잭션을 적용하기 전에 지정된 사용자 계정의 권한을 확인하여, 복제 채널의 보안을 강화할 수 있습니다.

26. CHANGE MASTER … REQUIRE_ROW_FORMAT 옵션 추가

[원본제공링크 1]

MySQL 복제는 바이너리 로그의 이벤트를 기반으로 이루어지며, 이 이벤트는 주로 행 기반(row-based) 또는 문장 기반(statement-based) 형식으로 기록됩니다. 행 기반 복제는 각 행의 변경 사항을 기록하여 데이터 일관성을 높이고, 문장 기반 복제는 실행된 SQL 문장을 기록합니다. MySQL 8.0.19부터 CHANGE MASTER TO 명령어에 REQUIRE_ROW_FORMAT 옵션이 추가되었습니다. 이 옵션을 활성화하면 복제 채널이 행 기반(row-based) 이벤트만 수락하도록 설정되어, 복제 시 보안과 일관성을 강화할 수 있습니다.

27. 새 slave_preserve_commit_order 옵션

[원본제공링크 1]

MySQL의 병렬 복제 기능은 복제본에서 여러 스레드가 동시에 트랜잭션을 적용하여 복제 성능을 향상시킵니다. 그러나 이러한 병렬 처리로 인해 트랜잭션의 커밋 순서가 원본 서버와 달라질 수 있으며, 이는 데이터 일관성 문제를 야기할 수 있습니다. slave_preserve_commit_order 옵션은 이러한 문제를 해결하기 위해 도입되었으며, 복제본에서 트랜잭션의 커밋 순서를 원본 서버와 동일하게 유지하도록 보장합니다.

28. 바이너리 로그 압축

[원본제공링크 1]

MySQL 8.0.20부터 바이너리 로그 트랜잭션 압축 기능이 도입되었습니다. 이를 통해 트랜잭션 페이로드를 압축하여 저장 공간을 절약하고, 복제 시 네트워크 대역폭을 감소시켜 성능을 향상시킬 수 있습니다.

29. 복제본에서 기본 키 검사 활성화/비활성화

[원본제공링크 1]

MySQL 8.0.20부터 복제본에서 테이블의 기본 키 존재 여부를 검사하는 REQUIRE_TABLE_PRIMARY_KEY_CHECK 옵션이 도입되었습니다. 이를 통해 복제본에서 기본 키 검사를 활성화하거나 비활성화하여 데이터 무결성을 관리할 수 있습니다.