최근 사용하고 있는 디비에서 쿼리락이 걸리는 이슈가 발생되었다.
어떤 쿼리 떄문에 다른 쿼리에 영향을 받고 있는지에 대한 확인을 하기 위해서는
아래의 쿼리를 통해서 확인이 가능하긴 하다.
# 차단 트랜잭션 확인
SELECT blocking_pid, blocking_query FROM sys.innodb_lock_waits;
# blocking_pid 로 문제가 된 THREAD_ID 를 확인
SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID = {blocking_pid};
# 쓰레드에 의해 실행된 마지막 쿼리의 락 확인을 위해 해당 쓰레드가 실행한 마지막 쿼리 확인
SELECT THREAD_ID, SQL_TEXT
FROM performance_schema.events_statements_history
WHERE THREAD_ID = {THREAD_ID} ORDER BY EVENT_ID;
하지만 문제가 될때마다 쿼리를 통해서 문제확인을 하려니 전체적인 흐름파악도 어렵고
얼마나 자주 이슈가 발생되었는지 확인도 불편한 문제가 있었는데 마침 참석했던 aws summit 에서 DATADOG 부스에 들렀다가 RDS 모니터링 기능중 락이 걸렸을때 어떤 쿼리 때문에 락이 걸렸는지 확인이 가능한 기능이 지원되고있다는 걸 알게되어 DATADOG 를 사용해보게되었다.
(이것은 신세계...)
RDS 디비는 mysql 8.0 을 사용하고 있기 때문에 다음의 문서를 참고하여 셋팅을 진행하였다.
https://docs.datadoghq.com/database_monitoring/setup_mysql/rds/?tab=mysql57
셋팅은 RDS 의 매트릭을 수집해야 하기 때문에 DB 를 사용하는 서버에 관련 설정을 하는것이 아니라
사용하려는 DB의 설정을 구성해야 하고 별도의 ec2 서버에 DATADOG 에이전트를 별도로 설치하여 연결해야 한다.
( 디비의 파라미터 수정 및 프로시저 생성 등.. )
비용은 모니터링하는 DB 하나당 $70 이기 때문에 여러개의 디비를 모니터링하려면 비용이 꽤 된다.
셋팅이 완료되고나면 바로 매트릭이 수집이 되는데 수집된 매트릭 정보는 APM -> Database monitoring 페이지에서 확인이 가능하다.
수집되는 쿼리 정보는 아래의 도움말을 참고하기 바란다.
https://docs.datadoghq.com/database_monitoring/query_samples/
https://docs.datadoghq.com/database_monitoring/query_metrics/
아래의 이미지처럼 해당 기능을 사용하면 락이 걸린 쿼리, 지연이 걸리거나 소요시간이 오래 걸리는 쿼리,
또는 인덱스를 타지 않거나 비용이 많이 책정된 쿼리를 한번에 볼수 있기 때문에 디비 튜닝에 많은 도움이 된다.
하지만 정작 DATADOG 를 사용하기로 한 목적인
락이 걸렸을때 어떤 쿼리가 문제가 되었는지에 대한 확인
을 할수가 없어 고객센터에 문의하였는데..
이럴수가...
mysql 은 아직 해당 기능이 미지원이라고....
Troubleshoot blocking queries with Datadog Database Monitoring
위의 블로그에서 해당 내용을 보긴 했는데 문서 하단에 Postgres 와 SQL Server 만 적용된다는걸 눈여겨 보지못하고 지나쳤건거다...ㅠ.,ㅜ
mysql 디비에 대한 blocking-query 지원은 Feature Request 는 있으나 아직 일정은 정해지지않았다고....
아쉽지만 해당기능은 mysql 이 지원되면 다시 써보는걸로....
