https://team-edo.github.io/tags/%EC%9E%A5%EC%95%A0-%EB%B3%B5%EA%B5%AC/Recent content in 장애 복구 on 얼쑤 · Team EdoHugoko-krMon, 09 Nov 2026 00:00:00 +0000https://team-edo.github.io/posts/2026/11/mysql-replication-write-policy/Mon, 09 Nov 2026 00:00:00 +0000https://team-edo.github.io/posts/2026/11/mysql-replication-write-policy/<p>운영 DB의 시간당 백업을 대기 서버로 보내고 있었다. 최근 24시간의 수신 기록에서 대기 서버가 가진 최신 스냅샷의 나이는 최대 <strong>1시간 29초</strong>였다. 그때 원본 서버를 잃었다면 스냅샷 이후에 저장한 기록은 백업에서 복구할 수 없었다. 전송이 밀리면 이 구간은 더 길어질 수 있다.</p> <p>대기 서버에 MySQL 복제본을 두면 백업 사이의 변경도 따라갈 수 있다. 그러자 다른 질문이 생겼다. <strong>두 서버 사이 연결만 끊겼을 때, 아직 정상인 원본은 계속 저장을 받아야 할까?</strong></p>https://team-edo.github.io/posts/2026/11/two-host-availability/Mon, 09 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/two-host-availability/<p>운영 서버 한 대가 꺼졌다고 가정해 보겠습니다. 두 번째 서버에서 앱이 떠 있어도 사용자가 쓰던 주소가 그 서버로 향하고, 앱이 기존 데이터를 읽고 새 데이터를 저장할 수 있어야 서비스가 돌아옵니다. 얼쑤에서는 서버 두 대를 유지하고 추가 유료 인프라를 전제하지 않는 조건으로 Docker Compose를 확장하는 안과 가벼운 Kubernetes 배포판인 K3s를 쓰는 안을 비교했습니다. 비교 기준은 각 도구가 앱 실행, 접속, 쓰기 복구 중 어디까지 맡을 수 있는가였습니다.</p>