MariaDB Replication Overview - 마리아 DB 이중화 개요

1. Overview

Replication(이중화, 복제)은 하나 이상의 서버(primary)에서 다른 서버(replica)들로 미러링 하는 것을 말합니다.

복제의 원천 소스가 되는 서버를 Primary 라고 하며 복제 대상이 되는 서버를 Replica 라고 합니다.

복제시 테이블이나 데이터베이스 단위로 복제한 데이터를 제어할 수 있습니다.

mariaDB에서 기본적인 복제 방법은 binary log를 사용하여 row level 복제를 하는 것입니다.

binary log는 데이터베이스에 발생하는 모든 DML을 기록합니다.

MariaDB의 Binary Log는 데이터베이스 서버에서 발생하는 모든 작업을 이진 형태로 로그로 남기는 기능입니다. 이 로그는 마스터-슬레이브 복제와 같은 고급 데이터베이스 기능을 지원하는 데 중요합니다.

Binary Log는 크게 두 가지 종류의 이벤트로 구성됩니다. 첫 번째는 스키마 이벤트(Schema Event)이며, 데이터베이스의 스키마 변경 작업(DDL)을 기록합니다. 두 번째는 데이터 이벤트(Data Event)이며, 데이터 변경 작업(DML)을 기록합니다. 예를 들어 INSERT, UPDATE, DELETE 쿼리문이 이 이벤트에 해당됩니다.

Binary Log는 복제를 위해 주로 사용되지만, 데이터베이스 백업과 복구 등 다양한 용도로 활용될 수 있습니다. 또한, 로그 분석 도구를 사용하여 더 나은 성능을 제공하는 쿼리를 개발할 수도 있습니다.

Binary Log는 데이터베이스의 성능에 일부 영향을 미칠 수 있기 때문에, 이 기능을 사용하는 경우 로깅 레벨을 적절하게 설정하고 로그 로테이션 등의 관리를 철저하게 수행해야 합니다.

복제를 위해서 이 binary log를 읽어서 relay log를 생성합니다.

MariaDB의 Relay Log는 마스터-슬레이브 복제에서 사용되는 로그입니다. 마스터 서버에서 생성된 Binary Log를 슬레이브 서버에서 읽어들이고 적용하는 과정에서 Relay Log가 사용됩니다. 마스터-슬레이브 복제에서, 마스터 서버에서 변경된 데이터는 Binary Log에 기록됩니다. 그리고 이러한 변경 내역은 슬레이브 서버에서 Relay Log로 복제됩니다. Relay Log는 마스터 서버의 Binary Log와 동일한 이벤트를 포함하며, 마스터 서버의 Binary Log와 유사한 이진 형식으로 작성됩니다. Slave I/O Thread는 마스터 서버의 Binary Log를 읽어 Relay Log로 저장합니다. 이어서 Slave SQL Thread는 Relay Log에서 이벤트를 읽어들이고 슬레이브 데이터베이스에 적용합니다. 이 과정에서 Relay Log는 마스터-슬레이브 복제의 신뢰성을 보장하는 중요한 역할을 합니다. Relay Log는 슬레이브 서버에서 생성되므로, 마스터 서버와 다른 서버에 위치할 수 있습니다. 또한 Relay Log는 중간에 발생하는 네트워크 문제 등의 이슈로 인해 중단된 복제 작업을 이어서 수행할 수 있는 기능도 제공합니다. Relay Log는 마스터-슬레이브 복제의 안정성을 높이는 중요한 구성 요소입니다.

 

relay log는 복제 서버에서 생성되고 binary log와 동일한 포멧을 사용한며, 이를 통해 복제를 진행합니다. 복제가 완료되어 필요 없어진 로그는 삭제됩니다.

Replica 서버는 Primary 의 binary log에서 마지막으로 복제한 위치를 기록하여 유지합니다. 이를 통해서 연결이 끊어지거나 하는 등의 복제가 재시작 할 때 해당 위치에서부터 다시 시작합니다.

2. Replication Uses

Replication 다양한 시나리오에서 사용됩니다.

• 확장성(Scalability): 하나 이상의 복제본(Replica)을 가짐으로써 읽기를 여러 서버에 분산하여 Primary 서버에 대한 부하를 줄일 수 있습니다. 읽기(read) 작업이 많고 쓰기(write)작업이 적은 환경에서 모든 쓰기(write) 작업을 하나의 Primary 복제본을 가지고 다수의 읽기(read)를 처리하는 여러 복제본(Replica)으로 복제하는 것입니다.
• 데이터 분석(Data analysis): 데이터 분석은 Primary 서버에 너무 많은 부하(load)를 주어 서비스에 영향을 미칠 수 있습니다, 그러므로,복제본(Replica)에서 분석 작업을 처리하면 Primary 서버도 추가 부하의 영향을 받지 않고 처리할 수 있습니다.
• 백업 지원(Backup assistance): Database에서 백업을 일반적으로 lock 등의 추가 부하를 가져온다. 그러므로, 데이터를 복제본(Replica)으로 복제한 다음 데이터가 안정적인 상태에서 Primary 와 연결을 끊고 복제본(Replica) 서버에서 백업을 수행합니다.

이렇게 백업을 수행하면 Primary에 부하 없이 주기적으로 백업을 수행할 수 있습니다.​

• 데이터 분산(Distribution of data): Primary 서버에서 데이터 처리를 모두 하지 않고, 일부 데이터는 복제본(Replica) 서버에서 작업을 수행할 수 있습니다.

3. Common Replication Setups

Standard Replication

• 읽기 작업에 대한 확장성을 무한대로 가져올 수 있다.
• Primary 장애시 복제본을 Primary로 대체하여 고가용성을 제공할 수 있다.

​

Ring Replication

• 읽기/쓰기 작업에 대한 확장성을 제공한다.

• 데이터 충돌(conflict)에 대한 처리가 없다.

• application에서 데이터를 충돌나지 않게 분산해야한다.

• Primary가 하나라도 중단되면 전체 복제가 중단된다.

• 잘 사용하지 않는 구조로 보인다.

​

Star Replication

• 읽기/쓰기 작업에 대한 확장성을 제공한다.
• 데이터 충돌(conflict)에 대한 처리가 없다.
• application에서 데이터를 충돌나지 않게 분산해야한다.

​

Multi-Source Replication

• 다른 Primary로 부터 데이터를 받는 구조이다.
• 서로 다른 서비스를 제공하므로 병렬로 복제 가능하다.

​