복제란?

네트워크로 연결된 여러 장비에 동일한 데이터 복사본을 유지한다는 의미다.
복제에서 모든 어려움은 복제된 데이터의 변경 처리에 있으며, 이것을 single leader, multi leader, leaderless알고리즘으로 처리할 수 있다.

복제시 주요 고려 포인트

동기식 복제 vs 비동기식 복제
잘못된 복제본을 어떻게 처리할 것인가?

데이터 복제가 필요한 이유?

지리적으로 사용자와 가깝게 데이터를 유지해 지연 시간을 줄인다.
시스템의 일부에 장애가 발생해도 지속적으로 동작할 수 있게 해 가용성을 높인다.
읽기 질의를 제공ㅇ하는 장비의 수를 확장해 읽기 처리량을 늘린다.

복제: 각 장비에 전체 데이터셋의 복사본을 보유할 수 있을 때
파티셔닝(샤딩): 단일 장비에는 너무 큰 데이터셋을 대상으로 할 때

모든 복제 서버에 모든 데이터가 있다는 사실을 어떻게 보장할 것인가?

데이터베이스의 모든 쓰기는 몯느 복제 서버에서 처리되어야 한다. 그렇지 않으면 복제 서버는 더 이상 동일한 데이터를 유지할 수 없다.
=> leader-based replication = active-passive = master-slave 구조가 필요한 이유이다.

리더가 팔로워 복제 방식

복제 서버 중 하나를 leader = master = primary로 지정한다.
클라이언트가 데이터베이스에 쓰기를 할 때 클라이언트 -> 리더로 요청을 보낸다.
리더는 먼저 로컬 저장소에 새로운 데이터를 기록한다.
리더가 로컬 저장소에 새로운 데이터를 기록할 때마다 데이터 변경을 replication log나 change stream의 일부로 follower = read replica = slave = seconary = hot standby 에게 전송한다.
각 팔로워가 리더로부터 로그를 받으면 리더가 처리한 것과 동일한 순서로 모든 쓰기를 적용해 그에 맞게 데이터베이스의 로컬 복사본을 갱신한다.

클라이언트가 데이터베이스로부터 읽기를 할 때는 리더 또는 임의 팔로워에게 질의할 수 있다.
하지만 쓰기는 리더에게만 허용된다. 팔로워는 클라이언트 관점에서는 읽기 전용이다.
복제 모드는 PostgresQL, MySQL, Oracle Data Guard 같은ㄷ 데이터베이스에 내장된 기능이고, MongoDB같은 일부 비관계형 데이터베이스에서도 사용한다.
리더 기반 복제는 카프카와 RabbitMQ의 고가용성 큐 같은 분산 메세지 브로커에도 사용된다.

동기식으로 복제할 것인가? 비동기식으로 복제할 것인가?

동기식:

팔로워가 쓰기를 수신했는지 확인해줄때까지 리더가 기다린다.
확인이 끝나면 사용자에게 성공을 보고하고 다른 클라이언트에게 해당 쓰기를 보여준다.

비동기식:

리더는 메세지를 전송하지만 팔로워의 응답을 기다리지는 않는다.

동기식

장점: 팔로워가 리더와 일관성 있게 최신 데이터 복사본을 가지는 것을 보장한다.
갑자기 리더가 작동하지 ㅇ낳아도 데이터는 팔로워에서 계속 사용할 수 있음을 확신할 수 있다.

단점: 어떤 문제로 인해 동기 팔로워가 응답하지 않는다면 쓰기가 처리될 수 없다.
리더는 모든 쓰기를 block하고 동기 복제 서버가 다시 사용할 수 있을 때까지 기다려야 한다.

모든 팔로워가 동기식인 상황은 비현실적이다. 임의의한 노드 장애는 전체 시스템을 멈추게 할 수 있다.

현실적으로, 동기식 복제를 사용하려면 보통 팔로워 하나는 동기식으로 하고 그 밖에는 비동기식으로 하는 것이다.
동기식 팔로워가 사용할 수 없게 되면 비동기식 팔로워 중 하나가 동기식이 된다.
적어도 두 노드에(리더, 동기팔로워) 최신 데이터 복사본이 있다는 것을 보장하게 된다. 이것이 반동기식semi-synchronous다.

비동기식

보통 리더 기반 복제는 완전히 비동기식으로 구성한다.
장점: 모든 팔로워가 잘못되더라도 리더가 쓰기 처리를 계속 할 수 있다.
단점: 리더가 잘못되고 복구할 수 없으면 팔로워에게 아직 복제되지 않은 모든 쓰기는 유실되는데, 이것은 쓰기가 클라이언트에게 확인된 경우에도 지속성을 보장하지 않는다.

특히 많은 팔로워가 있거나 지리적으로 분산된 경우 비동기식 복제를 한다.

새로운 팔로워를 설정해서 복제 서버 늘릴 때

새로운 팔로워가 리더의 데이터 복제본을 정확히 가지고 있는지 보장하려면?

한 노드에서 다른 노드로 복사하는 것은 충분하지 않다. 데이터는 유동적이기 때문에, 복사 결과가 유효하지 않을 수 있다.
데이터를 lock 잡아서 디스크 파일을 일관성있게 쓸 수 있긴 하지만 가용성이 저하된다.

팔로워 설정을 중단시간 없이 하는 방법

데이터베이스를 lock잡지 않고 리더의 스냅샷을 일정 시점에 가져온다. 대부분의 db는 이런 기능이 있다.
스냅샷을 새로운 팔로워 노드에 복사한다.
팔로워는 리더에 연결해 스냅샷 이후 발생한 모든 데이터 변경을 요청한다. 스냅샷이 리더의 복제 로그의 정확한 위치와 연관되어야 한다. (log sequence number, binlog coordinate등으로 부른다)
팔로워가 스냅샷 이후 데이터 변경의 미처리분(backlog)를 모두 처리햇을 때 따라잡았다고 볼 수 있고, 이때부터 리더의 데이터 변화를 이어서 처리할 수 있다.

노드를 중단하고 처리해야 한다면?

계획된 유지보수로 인한 중단 등을 염두해두고 어떻게 고가용성을 달성할 수 있을 것인가를 탐구한다.

DB복제란?

<데이터 중심 애플리케이션 설계를 읽고>