MySQL Replication 설명
MySQL Replication이란?
MySQL Replication이란 단어의 뜻 그대로 복제입니다. 즉, 물리적으로 다른 서버의 저장 공간” 안에 동일한 데이터를 복사하는 기술입니다.
MySQL복제라는 말과 같이, 디스크를 독립적으로 분리하여 데이터를 유지합니다.
엄격하게 다시 말하자면, “MySQL Replication은 데이터를 이중화”하는 개념입니다.
MySQL은 오직 단일 마스터에서만 데이터 변경 작업을 수행할 수 있고,
그렇기 때문에 MySQL에서는 쓰기 부하 분산은 불가능하지만, 읽기 부하 분산은 가능합니다. 그리고 특정 노드 디스크 장애가 전체 데이터 유실로 이어지지 않습니다. 데이터가 “복제”되기 때문 입니다.
Master, Slave 간Data 복제 방법
MySQL Replication은 로그 기반으로 비동기적으로 데이터를 복제합니다. 마스터에서는 데이터 변경 작업이 수행되면 Binary Log라는 곳에 이력을 기록을 하는데, Statement, Row 그리고 Mixed 등 세 가지 방식이 있습니다.
Statement-based Type
MySQL 3.23 이후로 도입된 방식
실행된 SQL을 그대로 Binary Log에 기록
Binary Log 사이즈는 작으나, SQL 에 따라 결과가 달라질 수 있음
(Time Function, UUID, User Defined Function)
Row-based Type
MySQL 5.1부터 도입된 방식
변경된 행을 BASE64로 Encoding하여 Binary Log에 기록
특정 SQL이 변경하는 행 수가 많은 경우 Binary Log 사이즈가 비약적으로 커질 수 있음
Mixed Type (Statement + Row)
기본적으로 Statement-Based Type으로 기록되나, 경우에 따라 Row-base Type으로 Binary Log에 기록
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
• 단순 Insert/Update/Delete에서는 Binary Log를 Row based로 설정 시 Statement Based 보다 Master/Slave 간 데이터 시간 차가 20~30% 적게 발생함
• Semi-synchronous Replication 테스트에도 Row based 성능이 Statement Based보다 20~30% 나은 결과를 보임
• Grouping SQL 에서는 Row based가 서버 간 시간 차가 거의 발생하지 않음
보기에는 Row Based 퍼포먼스가 뛰어난 것을 보실 수 있습니다.
특히나 Master 서버에 집계성 SQL이 Insert..Select 또는 Create table as Select 형태로 구성되는 로직이 많다면 더욱 유리합니다.
하지만!!
Row Based Binary Log는 5.1 버전부터 도입된 방식으로 아직까지도 여기저기 버그가 있습니다.
특히나 PK 가 없는 대용량 테이블을 대량으로 수정하게 되면, Slave서버에서는 해당 시점에서 멈추는 현상이 발생합니다.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
저희 권고하며 가장 많이 쓰는 방식은 Mixed Type 방식 입니다. SKT에서도 Mixed Type 으로 Replication 동기화를 표준화 하고 있습니다.
그렇다면 복제는 어떤 방식으로 이뤄질까요? 아래 그림으로 설명 드리겠습니다.
• Master에서 데이터 변경이 일어나면 자신의 데이터베이스에 반영합니다.
• Master에서 변경된 이력을 Binary Log에 기록 후 관련 이벤트를 전달합니다.
3. Slave IO_THREAD에서 Master 이벤트를 감지하고,
Master Binary Log 자신의 Relay Log라는 곳에 기록을 합니다.
4. Slave SQL_THREAD는 Relay Log를 읽고 자신의 데이터베이스에 기록을 합니다.
기억해야할 사항은 마스터에서는 여러 세션에서 데이터 변경 처리가 가능하지만(멀티스레딩), 슬레이브에서는 오직 하나 SQL Thread에서만 데이터 변경 처리가 가능한 점입니다. 그렇기 때문에 마스터에 데이터 변경 트래픽이 과도하게 몰리게 되면 마스터/슬레이브 간 데이터 동기화 시간이 크게 벌어질 수도 있습니다.
'Database > MySQL & MariaDB' 카테고리의 다른 글
[MySQL/MariaDB] Replication의 작동원리 (0) | 2020.11.06 |
---|---|
[MySQL/MaraiDB] Full 백업 / 테이블 백업 및 복구 (0) | 2020.09.24 |
[MySQL/MariaDB] Maria DB IO 및 swap 점유 튜닝 포인트 (0) | 2020.09.11 |
[MySQL/MariaDB] Replication 상태 확인 (0) | 2020.09.11 |
[MySQL/MariaDB] MySQL/MariaDB 기본 명령어 (0) | 2020.09.11 |