Delayed Replication을 이용해 유실된 데이터 빠르게 복구하기

티몬 개발팀이 MySQL의 Delayed Replication으로 데이터 유실에 대비하는 방법을 정리한 글이다. 2017년 2월 GitLab.com이 실수로 5시간 분량 데이터를 잃은 사고를 계기로, 물리 장애가 아니라 사람과 코드의 실수로 생긴 유실을 어떻게 빠르게 되돌릴지 다룬다. 복제에 지연 시간을 의도적으로 걸어두면 그 시간만큼 대응 여유가 생긴다는 것이 요지다.

핵심 포인트

자료 유실 요인은 실수, 천재지변, 정전·하드웨어 고장, 하드디스크 에러, 침입자 다섯 가지로 나뉜다
물리적 장애는 RAID·Replication·백업·스냅샷으로 회피할 수 있지만 그 밖의 장애는 원본을 덮어써서 복구가 어렵다
조건절 실수, 소스의 사이드 이펙트로 인한 의도치 않은 쿼리, DDL 실수가 대표적인 유실 상황이다
복제는 기본적으로 실시간이지만 옵션으로 지연을 걸 수 있고, 글에서는 3,600초를 준다
마스터에서 조건절 없는 UPDATE가 나가도 지연된 슬레이브에는 이전 데이터가 남아 있어 그 시간 안에 대처하면 복구된다
백업이 없는 경우는 대개 못 해서가 아니라 안 해서였다는 것이 글의 결론이다

상세 정리

사고 배경: GitLab은 2017년 2월 1일 공지로 5시간 분량 데이터 유실을 공개했고 이 글은 그 사고를 출발점으로 삼는다
자료 제공: 해당 사고는 원문 공지와 번역본 링크를 함께 걸어 경위를 직접 확인할 수 있게 했다
문제 정의: 서비스 품질을 논할 때 안정성이 빠지지 않으며, 안정적이지 않은 서비스는 그만큼 신뢰도가 떨어진다
대응 순서: 장애를 예방하는 것이 가장 좋은 방법이고 지연 복제는 이미 터진 뒤를 위한 그다음 수단이다
물리와 논리의 차이: 물리 장애는 대응책이 정형화돼 있으나 그 밖의 장애는 발생 패턴이 다양하고 원본 데이터 위에 덮어써서 되돌릴 지점을 잡기 어렵다
현실적 선택: 이런 경우 Replication의 Delayed 기능으로 미리 준비해두는 것이 가장 현실적이라고 본다
준비물: Replication으로 묶인 MySQL 마스터와 슬레이브 쌍이 필요하다
기본 동작: 옵션을 주지 않으면 마스터 입력이 슬레이브에 최대한 실시간으로 반영된다
지연 설정: 복제 지연을 3,600초로 걸어 한 시간 분량의 대응 여유를 만든다
검증 절차: 원천 데이터를 넣고, 지연을 건 뒤, 마스터에서 조건절을 빠뜨린 UPDATE를 실행하고, 슬레이브를 조회해 이전 값이 남아 있는지 확인하는 순서로 확인한다
복구 창: 유효한 것은 설정한 지연 시간 안뿐이라 사고 감지가 늦으면 슬레이브까지 같은 변경이 반영된다
옵션 상세: 지연 복제의 세부 설정은 MySQL 공식 문서 링크로 넘긴다
인식 전환: 백업이 잘된 서비스에서 장애가 드문 것이 아니라 인지하지 못했을 뿐이라는 관점을 덧붙인다
마무리 주장: 조직화된 백업 체계도 좋지만 지금 당장 mysqldump 한 줄을 실행하는 것이 실제로 도움이 된다고 정리한다