팔로워가 죽어 재시작 되면 연결이 끊어진 동안 발생한 데이터 변경을 모두 요청, 즉 따라잡기 복구를 통해 쉽게 복구될 수 있다고 한다.
그런데, 팔로워가 죽어있던 시간이 길고, 그 동안 리더에 쓰기 작업이 많이 발생했다면 팔로워를 복구하는데 시간이 오래 걸릴 것이다(Replication lag). 이런 경우, 팔로워가 오랫동안 죽어있을 것이고 그 동안 남은 노드들이 트래픽을 받아 연쇄적으로 장애가 날 확률이 있다고 생각된다. 이럴 때는 어떻게 해결할까?
GPT 답변:
주기적인 백업: 데이터베이스 리더나 다른 인프라에서 주기적으로 전체 백업(full backup) 또는 증분 백업(incremental backup)을 수행합니다. 이 백업은 별도의 스토리지에 보관됩니다.
팔로워의 문제 발생: 만약 팔로워에 문제가 발생하여 데이터 동기화에 너무 오랜 시간이 걸린다고 판단될 경우, 이 백업을 활용할 수 있습니다.
백업 복원: 팔로워에서 최신 백업을 복원합니다. 이렇게 되면 팔로워는 백업 시점의 데이터 상태가 됩니다.
변경 로그 적용: 백업 이후의 변경사항을 로그(예: 바이너리 로그나 월 로그)를 통해 팔로워에 적용하여, 팔로워를 리더의 최신 상태로 동기화시킵니다.
이 방식은 주로 팔로워에 심각한 문제나 데이터 손상이 발생했을 때 사용됩니다. 백업 및 복원 전략은 데이터베이스 관리 작업 중 하나로, 데이터 유실의 위험을 최소화하기 위해 주기적으로 백업을 수행하고, 필요할 때 빠르게 복원할 수 있는 방안을 마련해두는 것이 중요합니다.
팔로워가 죽어 재시작 되면 연결이 끊어진 동안 발생한 데이터 변경을 모두 요청, 즉 따라잡기 복구를 통해 쉽게 복구될 수 있다고 한다.
그런데, 팔로워가 죽어있던 시간이 길고, 그 동안 리더에 쓰기 작업이 많이 발생했다면 팔로워를 복구하는데 시간이 오래 걸릴 것이다(Replication lag). 이런 경우, 팔로워가 오랫동안 죽어있을 것이고 그 동안 남은 노드들이 트래픽을 받아 연쇄적으로 장애가 날 확률이 있다고 생각된다. 이럴 때는 어떻게 해결할까?
GPT 답변: