Aurora MySQL replica lag 이슈 (복제 지연 이슈)

Aurora replica lag이란?

writer 인스턴스의 페이지 캐시와 비교한 Aurora replica의 페이지 캐시에 대한 지연 시간.

같은 스토리지를 활용하지만 각 reader computing instance간의 페이지 캐시에 업데이트 하기까지에는 짧지만 lag이 존재한다. 지연이 길어지는 경우 replica에 연결된 connection에서의 data가 sync되지 않아서 이슈가 발생할 수 있기 때문에 lag이 길어지는지 모니터링 할 필요가 있다.

 

replica lag 발생하는 경우

• 인스턴스가 동일한 사양인지 체크
  • reader node의 인스턴스 클래스 구성이 Writer보다 너무 작은 경우 변경 데이터의 볼륨이 너무 커서 리더가 캣이의 데이터를 무효화하고 따라잡 수 없게 됩니다.
• 여러 세션이 동시에 실행 줄일 때 리더 노드에서 지연이 발생할 수 있음. (복제에 사용 가능한 리소스가 부족하기 때문에 필요한 변경 사항을 적용하는 속도가 느려질 수 있습니다.
  • 이런 경우 CPUUtilization, DBConnections, NetworkReceiveThroughput, ActiveTransactions 지표들을 확인
• 이미 쓰기 작업이 많은 프로덕션 클러스터에서 갑자기 쓰기 작업이 급증하면 라이터 DB 인스턴스에 오버로드가 발생할 수 있습니다. 이러한 급증에 따른 처리 부담으로 인해 리더 노드에서 지연이 발생할 수 있습니다. DMLThroughput, DDLThroughput 및 Queries 지표의 급증을 보여주는 Amazon CloudWatch에서 이를 확인할 수 있습니다.
  • DMLThroughput, DDLThroughput 및 Queries 지표 확인
• RollbackSegmentHistoryListLength 가 길어질때. 트랜잭션 기간 동안 영향을 받는 모든 행에 발생한 모든 변경 사항을 추적해야 한다. 장기 실행 트랜잭션이 완된 후 스레드 purge활동이 증가. 장기 실행 트랜잭션을 통해 생성된 백로그의 볼륨으로 인해 발생하는 갑작스러운 제거 작업이 원인이 되어 Aurora 복제본이 지연될 수 있습니다.
• 일시적 네트워크 문제 해결
  • 드물지만 라이터 노드와 리더 노드 간에 또는 노드와 Aurora 스토리지 계층 간에 일시적인 네트워킹 통신 장애가 발생할 수 있습니다. 짧은 순간의 네트워킹 중단으로 인해 리더 노드가 지연되거나 다시 시작될 수 있습니다. 대량의 변경 데이터 또는 짧은 순간의 AZ 간 패킷 손실로 인한 네트워크 포화로 인해 Aurora Replica가 지연될 수 있습니다. 이 문제를 방지하려면 DB 인스턴스의 크기와 네트워킹 용량을 고려하는 것이 좋습니다.

중요: 버전 1.17.4부터 Aurora MySQL 1.x에는 다음과 같은 몇 가지 주목할 만한 기능이 있습니다.

• aurora_enable_replica_log_compression은 복제 페이로드를 압축하여 프라이머리와 Aurora 복제본 간의 네트워크 대역폭 사용률을 개선하는 클러스터 파라미터입니다. 이는 네트워크 포화 상태가 명확하게 나타날 때 유용합니다.
• aurora_enable_zdr은 열려 있는 연결을 유지하고 Aurora Replica를 다시 시작할 때 연결을 유지하는 데 활용할 수 있는 클러스터 파라미터입니다.
• aurora_enable_staggered_replica_restore는 Aurora 복제본이 시차가 있는 재시작 일정에 따라 클러스터 가용성을 높일 수 있는 클러스터 파라미터입니다.