Aws Aurora 다수 DB 커넥션 끊어졌을때

Aurora 특정 노드에서 DB 커넥션이 다수 끊겼는데, 다수의 Replication Lag이 확인이 된 사례가 있었습니다.

 

1. Replica Lag이란?

Replica lag이란? 원본 클러스터의 데이터를 읽기 전용 DB 인스턴스로 복제해 올때의 지연 시간을 의미합니다. 

 

ReplicaLag

복제본 지연(밀리초)

원본 DB 인스턴스를 기준으로 읽기 전용 복제본 DB 인스턴스의 지연 시간. MySQL, MariaDB, Oracle, PostgreSQL 및 SQL Server 읽기 전용 복제본에 적용됩니다.

초

 

2. 문제 시점 당시의 Cloudwatch metric

그림1. 문제 시점 당시의 DB 커넥션

그림2. ReplicaLag

그림3. ReplicaLag

3. 문제점 분석

 

DB 커넥션의 Drop은 커넥션 타임아웃에 의한 것일 수 있기 때문에 application/DB-error logs를 확인하고 조치되어야 합니다.

 

당시 Disk I/O와 분당 부하량 평균이 다음과 같았습니다.

 

Disk I/O
----------------------------------------------------------
Write IO/s          : 8648.53(+1265.66)
Write Throughput  : 71935200(+6140176)
Disk Queue Depth  : 12(-5)

Load Average Minute
--------------------------------------------
One    Minute : 8.43(+2.51) vCPUs

 

해당 내용으로 미루어 볼 때, 쓰기로 인한 부하가 spike로 치솟게 되었고, reader 인스턴스가 이를 따라잡지 못해서 replica lag으로 이어졌다고 볼 수 있었습니다.

 

급작스런 쓰기 활동에 대한 surge가 기존에 쓰기 활동이 많은 프로덕션의 클러스터에 있어서 부하를 야기할 수 있습니다. surge에 의한 stress를 받아 reader node가 뒤쳐질 수 있기 때문입니다.

 

즉, 트랜잭션 기간 내내 영향을 받는 모든 행에서 발생한 모든 변경 사항을 추적해야 합니다. 
장기 실행 트랜잭션이 완료되면 퍼지 스레드 작업의 스파이크가 시작됩니다.
장기간 실행되는 트랜잭션을 통해 생성되는 백로그의 양으로 인해 갑작스런 삭제로 인해 Aurora Replica가 지연될 수 있습니다. Aurora MySQL에는 메트릭 롤백 세그먼트 기록 목록 길이가 포함됩니다. CloudWatch에서 이 메트릭을 사용하여 아래와 같이 제거를 확인할 수 있습니다.

 

4. 해결책

 

1. 클러스터내의 모든 인스턴스가 같은 스펙을 갖도록 변경합니다.

2. 만약 이후에 wirter에 replica lag이 발생한다면, 다음의 쿼리를 통해서 확인할 수 있습니다.

a. 

SHOW FULL PROCESSLIST;

: SHOW PROCESSLIST 명령은 MySQL 인스턴스에서 현재 실행 중인 스레드를 보여 줍니다. 
같은 명령 집합이 실행 중이지만 완료되지 않는 경우가 있습니다. 이 경우 이후 명령문은 첫 번째 명령 집합이 완료될 때까지 기다려야 합니다. 
왜냐하면 InnoDB 행 수준 잠금이 동일한 행을 업데이트하고 있을 수 있기 때문입니다.

b. 

SHOW ENGINE INNODB STATUS;

SHOW Engine InnoDB 상태 쿼리는 표준 InnoDB 모니터에서 InnoDB 스토리지 엔진의 상태에 대한 정보를 제공합니다.

c.  

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

INNODB_TRX table은 read-only 트랜잭션이 아닌 현존하는 모든 InnoDB 트랜잭션의 정보를 제공합니다.

d.  

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

INNODB_LOCKS table은 InnoDB 트랜잭션이 요청했지만, 요청에 대한 응답을 받지 못한 정보를
보여줍니다. 

e. 다음의 쿼리는 대기중인 트랜잭션과 어떤 트랜잭션이 대기 트랜잭션을 막고 있는지 확인할 수 있습니다.

SELECT
  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query
FROM      information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b
  ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r
  ON r.trx_id = w.requesting_trx_id;

또한, troubleshoot을 위해서 애플리케이션단에서 slow-query logs를 확인하여 예상치 못한 오래 돌고 있는 쿼리를 찾아서 최적화 해야합니다.

관련 링크 : https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/