Replication

RDB에서의 Replication은 데이터베이스 시스템에서 원본 데이터를 복사하여 별도의 데이터베이스로 관리하는 중요한 개념이다. 이를 통해 데이터 손실을 대비한 복구 전략을 마련할 수 있으며, 시스템 성능을 확장하는 데에도 사용된다.

Replication에서 원본 데이터베이스를 마스터(Master), 복제된 데이터베이스를 슬레이브(Slave)라고 부른다. 데이터 복제 시 성능을 위해 비동기 방식이 주로 사용되는데, 이는 마스터가 슬레이브에 데이터가 완전히 저장될 때까지 기다리지 않고 다음 작업을 처리하기 때문이다. 반면, 동기 방식은 슬레이브에 데이터가 저장될 때까지 마스터가 대기해야 하므로 성능에 불리하여 잘 사용되지 않는다.

만약 마스터 DB가 다운되면, 슬레이브 중 하나를 마스터로 승격하여 운영을 지속함으로써 가용성을 확보한다. 또한, 웹 애플리케이션에서는 쓰기 작업은 마스터, 읽기 작업은 슬레이브에서 처리하도록 하여 부하를 분산하고 성능을 확장할 수 있다.

Redis 지원 기능

• 1.Replication
  a. master-replicas: 원본인 master와 복제본인 replica의 관계
  b. command stream: 명령 stream을 master에서 replica로 전달하여 데이터 쓰기 뿐아니라 ttl 설정도 동일하게 동작한다.
  c. resync: master-replica의 network가 끊어지더라도 재동기화를 진행한다.

• 2.Sentinel:
  a. monitoring: Sentinel은 주기적으로 마스터와 슬레이브 노드의 상태를 모니터링한다.
  b. automatic failover: 장애가 확정되면, Sentinel은 슬레이브 노드 중 하나를 새 마스터로 자동으로 승격(failover)한다.

• 3.Cluster:
  a. multiple master: 여러 개의 마스터 서버를 동시에 운영하여 성능을 높이고 데이터를 저장할 때, Hash 알고리즘을 사용하여 어떤 마스터에 저장할지를 결정한다. 또한 각 마스터 서버에는 복제 서버(슬레이브)가 있어, 마스터 서버에 문제가 생기면 복제 서버가 대신 역할을 맡아 시스템이 계속 작동한다.

Docker-compose master-slave 아키텍쳐 구축

version: '3.8'
networks:
  replica:
    driver: bridge
services:
  redis:
    container_name: redis
    image: redis:6.2
    ports:
      - 6379:6379
    networks:
      - replica
    restart: always

  replica:
    container_name: replica
    image: redis:6.2
    ports:
      - 6378:6379
    networks:
      - replica
    volumes:
      - ./conf:/usr/local/etc/redis
    command: redis-server /usr/local/etc/redis/redis.conf --replicaof redis 6379
    restart: no

  replica2:
    container_name: replica2 
    image: redis:6.2
    ports:
      - 6377:6379
    networks:
      - replica
    volumes:
      - ./conf:/usr/local/etc/redis
    command: redis-server /usr/local/etc/redis/redis.conf --replicaof redis 6379
    restart: no

master와 2개의 replica 컨테이너를 준비하고 실행하였다.

마스터 노드에서 info 명령어로 상태를 확인해 보면, 2개의 레플리카 컨테이너와의 연결 상태, IP 주소, 포트 번호, 오프셋(offset)을 확인할 수 있다. Replication은 연결이 끊어졌다가 다시 연결되었을 때, 끊긴 부분부터 동기화를 재개할 수 있다. 이는 ID와 오프셋을 기반으로 동작하기 때문이다. 마스터가 데이터를 어디까지 전송했는지 하나하나 식별하기 때문에, 각 Replica가 어디까지 동기화되었는지를 알 수 있다.


master-slave 컨테이너 동기화 확인

key1부터 key5까지 키에 값을 할당한 후, 각 레플리카 컨테이너에서 keys * 명령어로 확인해 보았다. 동일한 키와 값이 레플리카에도 저장된 것을 확인할 수 있었다. 또한, 마스터 노드에서 unlink key1로 key1을 삭제한 후, Replica 컨테이너에서도 해당 키를 찾을 수 없었다.

마스터 노드의 info를 다시 확인해 보니, 모든 컨테이너의 오프셋이 2887로 동일하여 동기화가 제대로 이루어졌음을 알 수 있었다.

참고: 레플리카(slave) 노드에서는 쓰기 작업이 불가능하며(Read-only), 읽기 작업만 가능하다.