minkukjo
commented
1 year ago 복제 데이터 포맷
- 바이너리 로그에 이벤트가 어떤 포맷으로 기록되는지도 설정할 수 있다고 한다.
Statement 기반 바이너리 로그 포맷
- 최초의 바이너리 로그 포맷
- SQL문 자체를 바이너리 로그에 기록하는 방식.
- 사람이 읽을 수 있어서 가독성이 좋다.
- 단점은 비확정적으로 처리될 수 있는 쿼리의 경우 데이터가 달라질 수 있다.
- 락을 걸거나, UUID 처럼 랜덤한 함수를 실행시키는 경우나, 사용자 정의 함수 또는 스토어드 프로시저를 사용하는 경우가 그 예에 해당한다.
Row 기반 바이너리 로그 포맷
- ROW 데이터 자체가 바이너리 로그에 기록되므로 어떤 이벤트건 더 적은 락을 점유하여 처리된다.
- 단점은 변경된 데이터가 그대로 바이너리 로그에 기록되므로 쿼리 하나가 많은 데이터를 변경한 경우 그 변경 데이터가 전부 기록되므로 바이너리 로그 파일의 크기가 매우 커질 수 있다.
Mixed 포맷
- Statement + Row 기반 바이너리 로그 포맷을 섞어서 쓸 수 있는 형태
- 기본적으로는 Statement를 쓰고, 필요 시 자동으로 Row 포맷으로 전환해 기록한다.
- 복제될 시 안전하지 못한 쿼리의 경우 ( 위에서 언급한 함수나 스토어드 프로시저를 사용한 쿼리 )는 알아서 Row로 바꿔준다.
Row 포맷 용량 최적화
- Row 기반을 꺼리는 가장 큰 이유는 바이너리 로그파일의 용량이 너무 커질 수 있는 위험도가 있기 때문이다.
- Row 기반을 사용할 때 바이너리 로그 파일의 용량을 줄일 수 있는 두 가지 방법이 있다.
바이너리 로그 Row 이미지
binlog_row_image시스템 변수에서 어떤 레코드의 컬럼 값을 바이너리 로그에 기록할지를 결정하는 옵션이다.- full, minial, noblob 총 세가지이다.
- full은 전부 다 기록한다는 거고, minimal은 꼭 필요한 컬럼만 바이너리 로그에 기록한다. noblob은 blob이나 text에서 변경이 발생하지 않은 경우 바이너리 로그 파일에 기록하지 않는다.
바이너리 로그 트랜잭션 압축
- Row 기반에서 트랜잭션으로 변경된 데이터만 압축해서 바이너리 로그에 기록할 수 있는 기능.
- zstd 압축 알고리즘을 사용해 압축하여 바이너리 로그에 기록하고 이후 레플리카에서 읽어갈 때 압축을 풀어서 사용한다.
- 압축을 적용하면 바이너리 로그 파일의 크기가 절반가까이 줄어드는 벤치마크를 볼 수 있다.
- 물론 압축을 사용하면 소요시간이 길어지게 된다.
복제 동기화 방식
- MySQL에서 소스 서버와 레플리카 서버 간에는 두 가지 복제 방싱르 사용한다.
- 하나는 비동기 복제요, 다른 하나는 반동기 복제이다.
비동기 복제
- 비동기방식은 소스 서버가 자신과 복제 연결된 레플리카 서버의 변경 이벤트가 정상적으로 잘 전달되었는지 확인하지 않는 방식이다.
- 다만 트랜잭션 누락이 발생할 시 수동으로 처리해주어야하는 단점이 존재한다.
- 하지만 성능도 빠르고, 레플리카 서버를 여러 대 연결한다 해도 소스 서버에서 큰 성능 저하가 없으므로 레플리카 서버를 증설해서 트래픽을 분산하는 용도로 제격이다.
반동기 복제
- 소스 서버는 레플리카 서버가 소스 서버로부터 받아온 변경 이벤트를 릴레이 로그에 기록한 뒤 응답을 보내면 그 때 트랜잭션을 완전히 커밋시키고 클라이언트에 결과를 반영한다.
- 레플리카 서버에 장애가 생기면 소스 서버에도 영향을 받을 수 있다.
- 여기서 반동기라는 용어를 쓴 이유는, 레플리카 서버에
전송을 완료했다는 의미이지 복제가지 제대로 잘 됐는지는 알 수 없다. - 그래서 일정 부분만 동기화를 보장해준다 하여 반동기라 표현한다.
- 개인적으로는 비동기 복제보다는 반동기 복제가 조금 더 안전해 보인다.
복제 토폴로지
- 복제 토폴로지는 소스 서버가 여러 개일 경우 복제를 위해 사용하는 데이터 복제 방식이다.
싱글 레플리카 복제 구성
- 소스서버 하나에 레플리카 서버 하나만 연결된 구성이다.
- 주로 어드민에 적합한데, 왜냐하면 레플리카 서버의 복제가 지연되더라도 쿼리가 큰 영향을 미치지 않기 때문이다.
멀티 레플리카 복제 구성
- 하나의 소스에 2개 이상의 레플리카 서버를 연결한 경우
- 레플리카 서버로 읽기 요청이 들어오는 경우 레플리카 서버는 소스 서버만큼 중요해진다.
- 따라서 백업용 레플리카 서버를 하나 더 두는 것이 좋다.
체인 복제 구성
- 멀티 레플리카 복제 구성에 레플리카 서버가 너무 많아 소스 서버의 악영향이 미칠 경우 1:M:M 구조의 체인 복제 구성을 고려해볼 수 있다.
- MySQL 복제에서 소스 서버는 레플리카 서버가 요청할 때 마다 바이너리 로그를 읽어서 전달해야한다.
- 만약 하나의 소스 서버에 연결된 레플리카 수가 많으면 바이너리 로그를 읽고 전달하는 것이 소스서버에게 부담이 될 수 있다.
- 체인 복제는 소스 서버에 연결된 레플리카 서버에 다시 레플리카 서버가 연결되는 경우, 그 레플리카 서버를 소스 서버로 승격시키고 해당 레플리카(소스 서버2) 서버가 자신에게 달려있는 레플리카에게 바이너리 로그를 전달하는 방식이다.
- 일종의 다단계(?) 같은 방식이다.
- 주로 MySQL 서버를 업그레이드 하거나 장비를 일괄 교체 해야할 때도 이 방식을 많이 사용한다고 한다.
듀얼 소스 복제구성
- 두 개의 MySQL 서버가 서로 소스 서버이자 레플리카 서버로 구성된 형태이다.
- ACTIVE-PASSIVE 도는 ACTIVE-ACTIVE 형태로 구성할 수 있다.
- ACTIVE-PASSIVE는 하나의 소스 서버에만 쓰기 작업이 수행되는 형태인데, 이게 마치 싱글 레플리카 복제와 비슷해보이지만, 다른 예비 서버인 소스 서버가 바로 쓰기 작업이 가능한 상태이므로 쓰기 작업이 수행되는 도중 서버에서 문제가 발생해도 별도의 설정 변경 없이 실전 투입이 가능하다는 점에서 차이가 있다.
- ACTIVE-ACTIVE의 경우 두 서버 모두에 쓰기를 수행하는 형태로, 서로 다른 지역에 MySQL 서버를 두고 각 지역에서 발생하는 쓰기 요청은 해당 지역에 위치만 MySQL로 수행하게 하면 클라이언트에서 조금 더 빠르게 처리가 가능하다.
- 다만 서로의 트랜잭션이 전달 완료되어 적용되기 전 까지 두 서버는 서로 일관되지 않은 데이터를 가질 수 있음에 유의하자.
- AutoIncrement도 문제가 될 수 있는데, 이 경우 increment_offset 시스템 변수와 auto_increment_increment 시스템 변수를 적절히 사용하자.
멀티 소스 복제 구성
- 여러 소스 서버가 하나의 레플리카 서버를 갖는 경우
- 데이터를 통합하는 경우나 백업을 위한 목적으로 이러한 구성을 갖는다.
멀티 소스 복제 동작
- 소스 서버와 레플리카 사이에는 채널이라고 부르는 복제 채널이 존재한다.
- 이 복제 채널에 어느 소스서버와의 복제 연결인지를 구별할 수 있는 채널 이름이 존재한다.
복제 고급 설정
- 복제에 사용할 수 있는 추가적인 설정들
지연된 복제
- 복제는 최대한 빠르게 동기화하여 소스 서버와 레플리카 서버 간의 데이터를 동일한 상태로 만드는 것에 그 목적이 있다.
- 동기화 지연이 없을 수록 레프리카 서버를 이용한 장애 복구는 용이해진다.
- 그러나 의도적으로 복제를 지연시켜야하는 경우도 존재한다.
- 이 옵션은 그런 상황을 위해 존재하는 옵션이다.
멀티 스레드 복제
- 소스 서버로부터 복제된 트랜잭션들을 하나의 스레드가 아닌 여러 개의 스레드로 처리할 수 있게 하는 기능이다.
- Relay 로그에서 쓰레드가 해당 작업을 읽어온 뒤 N개의 큐에 던지고 각각의 워커 쓰레드들이 해당 큐에서 작업을 뽑아내서 처리하는 방식이다.
데이터베이스 기반 멀티 스레드 복제
- MySQL 내의 데이터베이스 단위로 병렬 처리를 수행하는 형태이다.
- 여러 데이터베이스가 존재한다면 좋은 성능을 발휘하지만, 데이터베이스가 하나면 사실상 의미없다.
LOGICAL CLOCK 기반 멀티스레드 복제
- 앞선 방식에서 데이터베이스가 하나인 경우 멀티 스레드의 이점을 누리지 못했다.
- LOGICAL CLOCK 기반 복제 방식은 소스 서버로부터 넘어온 전체 트랜잭션들을 데이터베이스에 종속적이지 않고 멀티스레드로 처리할 수 있게 해주는 방식이다.
- LOGICAL CLOCK의 동작 방식은 소스 서버에서 트랜잭션들이 바이너리 로그에 기록될 때 각 트랜잭션 별로 논리적인 순번을 부여하여 레플리카 서버에서 트랜잭션 순번 값을 바탕으로 정해진 기준에 따라 병렬로 실행할 수 있게 해주는 기능이다.
바이너리 로그 그룹 커밋
- 여러 트랜잭션에 대해 커밋을 동시에 진행할 수 있게 해주는 기능.
- 각 트랜잭션들은 단계 별로 대기 큐에 등록된다.
- Flush 단계 : 대기 큐에 등록된 각 트랜잭션들을 순차적으로 바이너리 로그에 기록
- Sync 단계 : 앞서 기록된 바이너리 로그 내용들을 디스크와 동기화하는 fsync() 시스템 콜이 수행.
- Commit 단계 : 대기 큐에 등록된 트랜잭션들에 대해 스토리지 엔진 커밋을 수행.
Commit-parent 기반 LOGICAL CLOCK 방식
- 동일 시점에 커밋된 트랜잭션들을 레플리카 서버에서 병렬로 실행될 수 있게 해주는 기능.
- 커밋 시점이 같은 트랜잭션들은 잠금 경합 등과 같이 서로 충돌하는 부분이 없는 트랜잭션이므로 병렬로 실행 가능.
잠금 기반 LOGICAL CLOCK 방식
- 트랜잭션 순번 값이 동일하지 않더라도 커밋 시점이 겹치면 레플리카 서버에서 병렬로 처리 가능.
- 여기에 착안해 커밋 처리 시점이 겹치는 트랜잭션들을 병렬로 처리하는 방식이다.
WriteSet 기반 LOGICAL CLOCK
- 트랜잭션이 변경한 데이터를 기준으로 병렬 처리 가능 여부를 결정하는 방식.
- 만약 두 트랜잭션이 서로 다른 데이터를 변경한다면, WriteSet은 두 트랜잭션을 병렬로 실행할 수 있다.
- 즉 동일한 데이터를 변경하지 않는 건을 제외하고는 모두 병렬로 수행될 수 있다.
멀티스레드 복제와 복제 포지션 정보
- 멀티스레드 복제에서 각 워커 스레드들이 실행한 바이너리 로그 이벤트 포지션 정보는 worker-relay-log.info라는 파일들에 각 스레드 별로 저장이 된다.
- 워커 스레드들은 이벤트를 수행할 때 마다 해당 데이터를 갱신한다.
크래시 세이프 복제
- MySQL이 복제 중 비정상 종료되어 재구동 되더라도 복제가 원활하게 진행될 수 있게 여러 설정들을 제공한다.
- 이러한 문제 없이 제공되는 복제를
Crash Safe Replication이라 부른다.
서버 장애와 복제 실패
- 5.6 버전 이후부터 처리 중인 포지션 내용을 TABLE로 저장하게 되는데, 이 경우 InnoDB 엔진을 사용하기 때문에 SQL 스레드가 트랜잭션 적용과 포지션 정보 업데이트를 한 트랜잭션 내에서 수행하므로 원자적으로 처리가 가능해진다.
- 그러나 그렇다 하더라도 릴레이 로그 파일에 이벤트를 쓰는 작업과 포지션 정보를 업데이트 하는 작업이 SQL 스레드 처럼 원자적으로 처리가 불가능해 여전히 불일치 문제의 가능성이 존재한다.
- 이 불일치 문제는 relay_log_recovery 옵션이 도입되면서 해결됐는데, 재구동 시 I/O 스레드의 포지션을 SQL 스레드가 마지막으로 실행한 포지션으로 초기화하는 옵션이다.
필터링된 복제
- MySQL 복제에서는 소스 서버의 특정 이벤트만 레플리카 서버에 적용할 수 있게 하는 필터링 기능을 제공한다.
- 소스, 레플리카 둘 다 사용가능하다.
- 특정 DB에 대한 이벤트만 바이너리 로그에 기록되게 하거나 기록되지 않게 하는 설정도 가능하다.
Edwin222
DaehunGwak
진도
일시
2022.09.04.(일) 21:00