LiteFS 복제 위치 추적하기
LiteFS에서 생성된 각 데이터베이스는 복제 로그(replication log) 안에서 자신의 위치(position)를 유지해요. 이 위치는 단조 증가하는 트랜잭션 ID(TXID)와 데이터베이스 내용의 롤링 체크섬(rolling checksum)으로 구성돼요. 이 문서에서는 위치를 확인하는 방법과 일관성 처리에 TXID를 활용하는 방법을 설명해 드릴게요.
출처: 문서
본문
LiteFS에서 생성된 각 데이터베이스는 복제 로그 안에서 자신의 위치(position)를 유지해요. 이 위치는 단조 증가하는 트랜잭션 ID(TXID)와 데이터베이스 내용의 롤링 체크섬의 조합으로 이루어져 있어요.
데이터베이스 파일 옆에 있는 -pos 접미사가 붙은 파일을 읽으면 어떤 데이터베이스든 그 위치를 볼 수 있어요. 예를 들어 db라는 이름의 데이터베이스가 있다면 db-pos라는 파일에서 읽을 수 있어요:
$ cat /path/to/mnt/db-pos
00000000002df417/ce552e44f23fbbdd
TXID는 16자리 16진수로 인코딩된 uint64로 표현돼요. 체크섬도 16자리 16진수로 인코딩된 uint64로 표현돼요. 이 둘은 슬래시로 연결되며 끝에 줄바꿈이 추가돼요.
LiteFS 이벤트 스트림을 사용해 복제 위치 업데이트를 실시간으로 받을 수도 있어요.
TXID로 일관성 처리하기
클라이언트는 서로 다른 노드에 대한 요청 사이에서 데이터베이스 상태가 일관되도록 보장하고 싶다면 TXID를 사용할 수 있어요. 예를 들어 프라이머리(primary)에 대한 쓰기는 TXID 100에서 발생할 수 있어요. 이후 레플리카(replica)에 대한 요청이 수행되면, 클라이언트는 TXID를 애플리케이션에 전달하고 트랜잭션 ID 100에 도달하거나 초과할 때까지 기다리게 할 수 있어요.
시간 지연으로 일관성 처리하기
또 다른 접근 방식은 쓰기가 발생한 후 몇 초 동안 클라이언트의 후속 읽기를 프라이머리로 리다이렉트하는 것이에요. 이 시간이면 대개 쓰기의 변경 사항이 레플리카가 다시 클라이언트에게 읽기 요청을 제공하기 전에 복사되는 데 충분해요. 다만 복제가 지정된 시간 안에 반드시 일어난다고 보장되지 않으므로, 위치 파일의 TXID로 확인하는 방법보다 일관성 보장이 약해요.