Pod 재시작이 같은 AOF 오류를 반복했습니다

8월 28일 Valkey 복제본이 incremental AOF를 읽지 못하고 재시작하는 문제를 확인했습니다. Valkey의 multi-part AOF는 base 파일, incremental 파일, manifest로 구성됩니다. 한 파일의 손상과 전체 데이터 디렉터리 손실을 같은 문제로 취급하면 복구 범위가 커집니다.

로그에서 실패하는 파일과 offset을 확인하고 valkey-check-aof로 손상을 점검했습니다. 먼저 현재 primary와 정상 복제본, Sentinel quorum을 확인한 뒤 문제가 있는 대상이 복제본인지 다시 대조했습니다.

검사 전에 원본 파일을 보존합니다

아래는 중지된 복제본에서 확보한 작업용 사본을 검사하는 예제입니다. example.incr.aof는 가상의 파일명이며 운영 경로가 아닙니다.

SHELL
cp -p ./example.incr.aof ./example.incr.aof.before-repair
sha256sum ./example.incr.aof ./example.incr.aof.before-repair
valkey-check-aof ./example.incr.aof

--fix가 없는 호출은 손상 검사이며 수리 실행이 아닙니다. 검사 결과와 로그의 offset을 비교해 같은 파일을 조사하는지 확인합니다. 파일을 읽는 Valkey 프로세스가 계속 쓰는 상태에서 복사하거나 수리하지 않습니다.

실제 복구에서는 보존한 원본과 검사 결과를 확인한 뒤 승인된 복제본의 손상된 tail을 정리하고 다시 동기화했습니다. primary의 AOF를 같은 방식으로 자동 수정하는 절차는 만들지 않았습니다. AOF manifest나 base RDB까지 손상된 경우에도 동일한 tail 복구가 통한다고 가정하지 않습니다.

Sentinel과 복제 상태가 완료 조건입니다

SHELL
valkey-cli INFO replication
valkey-cli -p 26379 SENTINEL ckquorum example-primary

이 명령은 예제용 로컬 접속이며 인증과 연결 옵션은 환경에서 별도로 준비합니다. 첫 조회로 role, master_link_status와 동기화 상태를 확인하고, 두 번째 조회로 해당 primary 그룹의 failover quorum을 확인합니다. 읽기 결과를 실제 복구 대상과 대조해야 하므로 건강한 다른 인스턴스의 결과만 보고 완료하지 않습니다.

복구 후에는 대상 복제본의 primary 연결, 동기화 진행 종료, 다른 복제본과 Sentinel 상태를 확인했습니다. Ready가 된 것과 데이터 복제가 정상인 것은 별도 검사입니다. 이번 파일 손상이 생긴 근본 원인은 확인되지 않은 부분을 남겼습니다.

검사와 수리 옵션의 의미는 Valkey persistence 문서를 참고합니다.