Busy한 MySQL 서버에서 Deadlock Troubleshooting

관리자가 관리해야 하는 서버에는 많은 deadlock이 있습니다. 특히 비즈니스 기능적으로 중요한 몇 개의 테이블에서 자주 발생합니다. 데드락이 생기는 쿼리는 복잡하고, 많은 경우에 큰 데이터를 읽습니다. 대부분 오래 진행되는 트랜잭션에서 데드락이 발생할 수 있고, 짧은 쿼리에서 하나의 row에서 발생하기도 합니다.

많은 트랜잭션 시스템에서 데드락은 일상 생활입니다. 어플리케이션은 반드시 데드락을 다룰 수 있어야 합니다. 그 밖에도, 유저 트리거와 유저가 시도하는 것들을 포기해야 하더라도 작업이 종료될 필요가 있습니다. 종종 실패하기도 하고, 성공 할 때까지 재 시도를 하기도 합니다. 

이 교착 상태 프로세스에 소요되는 시간에 따라, 그 낭비 작업의 엄청난 금액을 나타낼 수 있습니다. 여러번 재시작을 하려면 두 시간 걸리는 프로세스 시스템에 많은 부하가 옵니다. 차례로 추가되는 로드로 인해 더 교착 상태가 발생합니다. 이 교착 상태는 악순환 될 수 있어서, 방지하는 것이 중요합니다.

교착 상태를 피하는 것은 당신이 그것을 관찰 할 때 훨씬 쉽습니다.  MySQL에서 이러한 어려운 점이 어렵습니다.해당 정보는 SHOW ENGINE INNODB STATUS 에서 볼 수 있기 때문입니다. PT-Deadlock-logger 가 이러한 상황에 도움이 됩니다. 아직 모든 정보를 파악하는 데에는 사용하기 힘들지만 많은 정보를 알 수 있습니다.

1. Creating work/scratch tables. 

많은 장기 실행 프로세스는 읽기 전용 모드에서 특정 테이블과 참조하고 다른 테이블을 갱신하지만,  교착상태는 그들이 읽는 테이블에서의 쓰기 작업 때문에 발생한다. 

row들의 복사본을 스크래치 테이블에 생성하는 프로세스를 시작하기 위해 read-only 테이블이 필요하다. 그리고나서 트랜잭션을 커밋하면 이런 lock 종속성 문제를 완화할 수 있다.

2. Moving work into the application. 

INSERT .. SELECT 구문을 SELECT 다음에 INSERT로 구문 변경을 해서 구문 기반 복제에도 역시 효율을 가져왔습니다.

3. Retry, but not right away. 

일부 프로세스는 즉시 데드락 구문을 재 시도하도록 되어있었습니다. 성공할 가능성이 없습니다. 재 시도하기 전에 잠시 대기하고, 잠금을 해제 할 수있는 시간을 주는 것이 좋습니다.

BY LEE JI EUN