기술 · 실용 가이드
Redis가 ‘MISCONF…디스크에 저장할 수 없음’이라고 하나요? 쓰기 복구 전에 RDB 실패 경계를 증명하세요
stop-writes-on-bgsave-error를 끄는 것은 복구 증명이 아닙니다. 오류, RDB 경로, 서버 로그, 파일시스템, INFO persistence를 수집하고 측정된 원인 하나를 고친 뒤 BGSAVE, snapshot, 대표 쓰기를 검증하세요.
Redis는 RDB background save가 실패하고 write-stop 정책이 켜져 있으면 MISCONF를 반환합니다. 메시지는 쓰기가 차단된 이유를 보여 주지만 capacity, inode, read-only mount, permission, child creation 중 무엇인지는 확정하지 않습니다.
정책을 바꾸기 전에 증거를 보존하세요. live Redis와 RDB directory를 확인하고 client error, server log, INFO persistence를 연결한 뒤 측정된 경계 하나를 복구하고 새 snapshot과 representative write를 증명합니다.
오류를 보존하고 실제 RDB target 확인
client error, timestamp, endpoint, 해당 log를 저장하고 같은 instance에서 INFO server, INFO persistence, CONFIG GET dir/dbfilename/stop-writes-on-bgsave-error를 읽으세요.
directory가 temporary file과 rename의 filesystem을 결정합니다. container에서는 같은 namespace 또는 runtime metadata로 mount를 확인하세요.
첫 실패 경계 분류
ENOSPC는 directory의 blocks와 df -i, permission은 path chain·owner·mode·security label·effective user, EROFS는 active mount options를 확인합니다.
background child failure는 memory, overcommit, cgroup, process limit 증거를 보존합니다. 다른 경계의 해결책을 대신 쓰지 마세요.
측정된 원인만 최소 변경
증명된 filesystem, inode, ownership, writable mount 또는 child resource boundary에 reversible change 하나를 적용하고 전후 값을 남깁니다.
arbitrary dir 이동, chmod 777, key 삭제, 증상만 없애는 restart는 피하세요. persistence, backup, restart behavior를 함께 확인합니다.
정책 복구 전 RDB exit test
충돌하는 persistence 작업이 없을 때 BGSAVE를 실행하고 완료 후 INFO persistence에서 rdb_last_bgsave_status:ok, 새 save time, unexpected job 부재를 확인하세요.
successful log, INFO, RDB timestamp/size, expected owner, backup/replica monitoring을 대조하고 불일치하면 incident를 계속 엽니다.
쓰기를 의도적으로 복구하고 기록
emergency 중 guard를 껐다면 persistence proof 이후 intended value로 되돌리고 CONFIG GET으로 확인합니다. approved namespace에서 test key를 write/read/cleanup하세요.
error, cause, directory, mount, measurements, BGSAVE, INFO, RDB, policy, app check를 기록하고 증명할 수 없으면 escalate하세요.
