DB Replication 개념 (feat. MySQL)

DB Replication?

운영중인 대규모 애플리케이션 환경에서는 데이터의 지속적인 가용성과 신뢰성이 매우 중요하기 때문에 원본 서버와 복제 서버 간의 데이터 동기화는 필수이다.

바이너리 로그를 저장하는 방식은?

Replication은Source 서버에서 발생하는 모든 데이터 변경 사항을 Replica 서버로 복제해서 두 서버 간의 데이터 일관성을 유지하는 메커니즘이다. 이러한 과정은 주로 바이너리로그를 기반으로 이루어진다.

바이너리 로그는 Source서버에서 실행된 모든 데이터 변경 쿼리를 기록하는 역할을 한다. MySQL에서는 바이너리를 저장하는 방식으로 Row, Statement, Mixed의 세가지 방식을 제공하며, 각 방식은 고유한 장단점을 가지고 있다.

Row

row 방식은 데이터베이스의 각 행별로 변경된 내용을 정확히 기록한다. 행별로 기록하기때문에 데이터 일관성을 매우 높게 유지할 수 있다. 벗 그렇기 때문에 저장공간에 부담이 크다.

Statement

데이터 변경을 일으킨 SQL 문 자체를 바이너리로그에 기록한다. 상대적으로 용량이 작기때문에 저장공간 절약에 유리하다. 하지만 비확정적 SQL쿼리가 실행될 경우 동일한 쿼리가 Source와 Replica서버에서 다른 결과를 초래할 수 있어 데이터 불일치 문제가 발생할 수 있다. (SELECT NOW() 와 같이 실행 시점에 데이터가 결정되는 함수 등등)

Mixed

Mixed는 상황에 따라 row기반과 statement기반을 혼합하여 로그를 기록한다. 비확정적 sql이 아닌경우 statement, 비확정적 sql이 실행될 경우 row방식을 사용한다.

복제과정

Source 서버에서 데이터 변경 쿼리가 실행되고, 선택된 로그 저장 방식에 따라 바이너리록에 기록된 후 Replica 서버의 IO 스래드가 바이너리로그를 읽어와 Replica서버의 Relay log로 전송한다. Relay log는 Replica서버에서 Source 서버의 바이너리로그를 저장하는 임시 저장소 역할을 한다.

이곳에 저장된 Replica서버의 SQL스레드가 실제 데이터베이스에 변경사항을 적용한다. 이 과정은 매우 효율적으로 설계되어 일반적으로 100밀리초 이내에 데이터가 동기화된다.

결론

• 로그 크기 절약이 중요한 경우: Statement
• 정확성이 중요한 경우 (트리거, 비결정적 함수 사용 등): Row
• 대부분의 환경에서는 Mixed 모드가 가장 합리적 선택