이전 복구 대상 이름을 그대로 사용하지 않습니다

9월 14일 Valkey 복제본 복구를 다시 수행했습니다. 8월에 조사했던 AOF 문제와 비슷한 증상이더라도 현재 primary와 replica 역할은 달라질 수 있습니다. 먼저 INFO replication과 Sentinel 정보를 읽고, 현재 primary가 정상이며 다른 복제본이 남아 있는지 확인했습니다.

반복 복구에서 보완한 부분은 완료 조건입니다. Pod가 Ready라는 사실만 확인하면 primary 연결이 끊겨 있거나 full sync가 진행 중인 복제본을 정상으로 기록할 수 있습니다.

복제본 연결과 동기화 종료를 함께 검사합니다

아래는 접속 옵션이 준비된 작업 환경에서 실행하는 예제입니다. 로컬 접속은 설명용이며 실제 접속 대상은 작업 전에 확인해야 합니다.

SHELL
set -euo pipefail
info=$(valkey-cli --raw INFO replication | tr -d '\r')
value() {
  awk -F: -v wanted="$1" '$1 == wanted { print $2 }' <<<"$info"
}

[[ "$(value role)" == "slave" ]]
[[ "$(value master_link_status)" == "up" ]]
[[ "$(value master_sync_in_progress)" == "0" ]]
printf '%s\n' 'replica link is up and initial sync is complete'

Valkey의 INFO 출력에는 복제본 역할이 slave로 표시됩니다. 이 검사는 조회한 인스턴스가 복제본이고 primary와 연결되었으며 초기 동기화가 끝났는지 확인합니다. 특정 key의 최신 데이터나 전체 데이터 일치까지 입증하는 코드는 아닙니다.

운영 완료 검사에서는 primary가 보고하는 연결 복제본 수와 Sentinel quorum도 확인합니다. 예제의 출력 세 항목만으로 failover 안전성을 확정하지 않습니다.

같은 손상이어도 다시 원본을 보존합니다

AOF 수리 전에는 대상 프로세스를 멈추고 원본 파일을 보존합니다. 이전 복구의 사본을 이번 복구의 백업으로 취급하지 않습니다. 이번 파일의 checksum과 valkey-check-aof 결과를 남기고, 손상 범위에 따라 수리 가능 여부를 판단합니다.

복구 후에는 연결 상태, 동기화 종료, 정상 복제본 수, Sentinel 상태를 각각 확인했습니다. 스토리지 오류인지 비정상 종료로 생긴 문제인지는 추가 근거가 필요하므로 손상 원인을 추정으로 확정하지 않았습니다.

반복 절차를 실행 가능한 조건으로 남깁니다

런북에는 조사 명령뿐 아니라 중단 조건과 완료 조건을 함께 둡니다. 역할이 replica가 아니거나 quorum을 확인할 수 없으면 복구를 진행하지 않고, 동기화가 끝나지 않으면 완료로 보고하지 않습니다. 같은 사건이 반복될 때도 현재 상태를 다시 읽는 기준을 유지합니다.