반응형
개인적으로 MySQL 5.6 출시에 가장 크게 기대했던 부분은 병렬 복제 기능(MTS, Multi Threaded Slave)이었다.
하지만 이 기능은 특정 상황에서만 적용이 가능한 단점이 있어서, 보편적으로 활용을 하지는 못했었다.
5.6 버전의 병렬 복제 기능은 schema 단위로 개별적인 복제 처리를 하다보니, schema 단위의 트랜잭션 정합성을 맞출 수 없다는 구조적인 문제가 있었으며, schema 개수가 많지 않거나 schema 간 쓰기 부하가 균일하지 않으면 병렬 처리의 장점을 활용할 수가 없기 때문이다.
※ 5.6 버전의 병렬 복제 관련해서 작성했던 포스트
https://blog.naver.com/seuis398/70186283219
하지만 지난 2015년 10월말 출시된 MySQL 5.7 버전에서는 기존 병렬 복제의 단점을 개선한 LOGICAL_CLOCK 방식의 병렬 복제를 지원한다.
LOGICAL_CLOCK 방식을 사용하는 경우, 동일 schema 내의 변경도 병렬 처리가 가능하며, 쓰기 부하가 균일하지 않아도 병렬 처리의 장점을 활용할 수 있다.
병렬 복제 구조 자체는 동일하지만, Coordinator 역할을 하는 SQL Thread가 worker thread에 작업을 할당하는 방식이 단순히 "작업 대상 스키마"를 기준으로 하던 것에서 "Master의 Binlog Group Commit 단위"로 동시 수행 가능 여부를 판단하는 것으로 변경되었다.
▷ IO Thread : master db의 변경 내용을 받아와서 relay log에 저장
▷ SQL Thread : relay log의 내용을 읽어서 worker thread에 할당
ㄴ DATABASE 방식 (5.6 지원, Default) : relay log 이벤트의 적용 대상 schema 기준으로 개별 worker thread에게 할당
ㄴ LOGICAL_CLOCK 방식 (5.7 지원) : master에서의 prepare commit timestamp 기준으로 relay log 이벤트들을 worker thread에게 할당
▷ Worker Thread : SQL Thread가 전달한 변경 내용을 slave db에 반영
5.6 버전에서 병렬 복제를 적용했던 것과 유사하게, slave-parallel-type, slave_parallel_workers 설정을 변경하고 복제를 재시작하면 된다.
| set global slave-parallel-type = LOGICAL_CLOCK or DATABASE ; set global slave_parallel_workers = worker thread 개수 ; stop slave ; start slave ; |
LOGICAL_CLOCK 방식의 효과가 얼마나 될지 간단하게 기존 DATABASE 방식과 성능 비교를 해보았다.
테스트 장비가 스펙이 조금 떨어지는 장비라 조금 아쉽긴 하지만, LOGICAL_CLOCK 방식의 효과는 충분히 확인할 수 있었다.
(6 core CPU, RAM 12G, Sas Disk 15K RPM 2EA , raid 1+0)
● 테스트 Case#1
master db에서 단순 insert 쿼리를 16개 thread에서 수행 (schema 1개)
slave 1 : slave-parallel-type = LOGICAL_CLOCK , slave_parallel_workers = 16
slave 2 : slave-parallel-type = DATABASE , slave_parallel_workers = 16
slave 3 : slave_parallel_workers = 0 (기존 single thread 방식)
위와 같은 환경에서는 DATABASE 방식에서 병렬 처리 효과를 기대하기 힘들다.
worker thread를 16개 만들어도 결국 변경이 발생하는 schema에 할당된 1개 worker thread만 일을 할 수 있기 때문이다.
반면, LOGICAL CLOCK 방식에서는 병렬 처리가 가능하므로, master와 근접한 수준의 처리가 가능한 것을 확인할 수 있다.
● 테스트 Case#2
master db에서 단순 insert 쿼리를 16개 thread에서 수행 (schema 4개)
slave 1 : slave-parallel-type = LOGICAL_CLOCK , slave_parallel_workers = 16
slave 2 : slave-parallel-type = DATABASE , slave_parallel_workers = 16
slave 3 : slave_parallel_workers = 0 (기존 single thread 방식)
schema가 4개로 늘어나면서 DATABASE 방식에서도 어느 정도의 병렬 처리 효과는 얻을 수 있었지만, 여전히 master와의 격차를 줄이기 어렵다.
반면, LOGICAL_CLOCK 방식에서는 1번 테스트와 동일하게, master와 근접한 수준의 처리가 가능한 것을 확인할 수 있다.
쓰기 부하가 많은 MySQL 환경에서는 복제 지연을 관리하는 것도 중요한 관리 포인트이다.
특히, Fusion IO 등 비교적 높은 사양의 HW를 구축을 한 경우에는 Slave가 Master의 처리량을 커버할 수 없어 더 문제가 될 수 있다.
MySQL 5.7을 도입한다면, 이런 고민을 조금 덜 할 수 있을 것으로 보인다.
출처 : https://m.blog.naver.com/PostView.naver?blogId=seuis398&logNo=220589886414&proxyReferer=https:%2F%2Fwww.google.com%2F
반응형
