쓰기 뒤 읽기 복제본에서 본인 변경을 보장하려고 로그 위치를 전달합니다. 어떤 위치를 비교하고 장애 때 어떻게 처리하나요?

사용자가 성공한 쓰기의 최소 반영 위치를 다음 읽기의 조건으로 전달하면 해당 위치를 적용한 복제본에서만 읽게 할 수 있습니다. 단순히 저장 후 몇 초 원본에 고정하는 것보다 명시적인 조건이지만 엔진별 로그 위치와 failover 의미를 알아야 합니다.

동작 원리와 전제

쓰기 응답의 토큰이 실제 커밋을 나타내는 위치인지 확인하고 읽기 replica의 수신 위치가 아니라 적용 위치와 비교합니다. 네트워크로 로그를 받았어도 replay가 끝나지 않으면 최신 값이 아닙니다. 다른 클러스터·세대의 위치 숫자를 직접 비교하지 않습니다.

선택과 실패 처리

조건을 만족하지 못하면 deadline 안에서 대기하거나 원본으로 우회합니다. 모든 읽기를 원본으로 보내는 장애 fallback은 포화를 만들 수 있어 중요 기능과 예산을 나눕니다. 원본 장애로 성공 쓰기를 잃을 수 있는 구성에서는 토큰이 영원히 충족되지 않을 수 있어 불확정 결과와 복구 정책을 둡니다.

구체적인 사례와 검증

replica의 로그 수신 위치는 120인데 적용 위치가 110이고 사용자가 요구한 위치가 115라면 그 replica는 아직 조건을 만족하지 못합니다. 네트워크가 빠른 것과 읽기 상태가 최신인 것을 구분하는 예입니다. 여러 replica를 번갈아 쓰는 세션에는 이미 본 최소 버전을 유지하면 값 역행을 줄일 수 있습니다. 토큰을 브라우저가 보냈다는 이유로 무제한 대기를 허용하지 않고 형식·세대·범위와 deadline을 검사합니다. failover 후 같은 숫자가 다른 로그 계통을 뜻할 수 있어 제품이 제공하는 epoch·timeline·GTID 의미를 따릅니다. 강한 보존과 세션 관찰은 별개로 명시하겠습니다.

사용자가 다른 기기·세션으로 이동하거나 토큰이 만료되는 경로를 시험합니다. 토큰을 변조해 큰 위치를 요구하며 무한 대기시키지 못하도록 검증·상한을 둡니다. 본인 쓰기 관찰과 모든 사용자에 대한 전역 선형화는 다른 보장입니다.