binlog 적용 시간 불일치로 인한 장애

• 해당 페이지 에서는 백업 및 복구 적용 시간 불일치로 인하여 발생했던 종료예정 서비스 장애에 대해서 필자가 지원한 이력을 다룬다.
  
  
  • 필자팀이 관리 했던 서비스 중에 종료예정이 되어서 AO 에 서비스 종료 업무를 이관했던 서비스가 있었다. 이 서비스 종료를 할 때 필자 회사내의 관리 서버 VM 에서
    해당 서비스를 관리를 할 타 신규 계열사 (그룹 본사에서 분사) 관리 서버에 DB 를 이관해야 하는 업무가 있었다.
    
    
  • 이 DB 이관을 담당 할 회사는 외부사였는데 외부사가 운영중인 서비스를 장기 점검시간을 가진 후에 수행 한 작업은 아래와 같았다.
    우선 사내에서 적용되는 mysql 서비스 백업 정책은 아래와 같이 매주 목요일 오전 5시에 Full Backup 을, 매일 오전 5시에는 Incremental Backup 을 수행 한다.
    (incremental 은 binlog 혹은 xtrabackup incremental 수행)
    

• • 이 때, 외부사가 이관할 데이터를 준비할때 목요일 오전 5시에 받은 full data 만 준비를 해놓은 상태였다.
    
    

• • 해당 서비스 점검 시작시간은 오전 10시였기에 오전 10시에 DB를 내렸는데 이 때, 오전 5시 ~ 10시에 발생한 데이터 변경 이력을 5시에 받은 full backup 파일에 적용을 못했기에
    5시간의 데이터 간격이 발생했고, 이 상황에서 이관된 서버에서 오후 4시에 DB 를 올렸을 때, 오전 시간대에 서비스를 사용한 고객들에게 VOC 를 받아서 AO측에서 이에 대한 해결 방법 지원을 요청 했었다.

•  
  • 이에 대해서 해결 방법을 생각해보게 되었고 아래와 같은 상황에서 내릴 수 있는 결론은 아래와 같았다.
    
    
    • 해당 서비스를 오후 4시에 오픈했는데 VOC 문의가 오게 되어서 AO에서 4시 10분에 서비스를 내리고 다시 점검을 개시함
    • 10분간의 데이터 변경이력은 AO 및 개발단에서 소스코드 확인을 통해 데이터 변경에 대한 추적 및 변경 적용 가능
    • 오전 10시 ~ 오후 4시 사이에는 데이터 변경이력이 하나도 없었음
    • 위의 상황 에서는 기존서버에 존재하는 오전10시에 내린 DB data 영역을 다시 Full Backup 적용 후, AO 에서 해당 시점에 data에 10분간 변경이력을 적용하는 방법이 최적

• • 위의 결론을 통하여 오전 10시 시점 data 영역을 xtrabackup 으로 다시 full backup 수행 후, AO 측에 전달하고, 10분간의 변경이력을 재적용해서 서비스 복구 지원을 했었다.
    
    
• 해당 사례는 기술적으로 DB 내부적인 오류가 있는 사항은 아니었으나 다른 서버 mig 및 실 복구 시, 복구 시점을 고려하는 것이 얼마나 중요한지를 알려주는 사례였다.