https://gukin.dev/tags/deadlock/ Recent content in Deadlock on Gukin Han Hugo ko-kr Fri, 08 Aug 2025 00:00:00 +0000 https://gukin.dev/posts/innodb-lock-conflict-deadlock-analysis/ Fri, 08 Aug 2025 00:00:00 +0000 https://gukin.dev/posts/innodb-lock-conflict-deadlock-analysis/ <h2 id="요약">요약</h2> <ul> <li>MVVC는 트랜잭션 시작점을 기준으로 <strong>데이터 버저닝</strong>을 한다</li> <li>락 종류에 따라 <strong>충돌 상황을 테스트</strong> <ul> <li>공유락은 말그대로 트랜잭션끼리 공유할 수 있다</li> <li>베타락은 말그대로 하나의 트랜잭션만 가진다</li> <li>공유락을 가진 상태로 업데이트, 삭제 등을 하면 베타락을 획득하려는 시도를 한다</li> <li>락 획득 대기 사이클이 생기면 데드락이 발생한다</li> </ul> </li> <li><strong>데드락을 최소화</strong>하기 위한 락 설계 방법: <ul> <li>락을 잡는 순서를 트랜잭션 마다 동일하게 유지</li> <li>락 범위를 축소</li> <li>첫 쿼리 부터 for update로 가져오는 방법</li> </ul> </li> </ul> <h2 id="배경">배경</h2> <p>이번 주차는 낙관적 락과 비관적 락을 학습하게 되었다. 비관적 락은 흔히 느리지만 정합성이 중요할때 사용하며, 낙관적 락은 충돌 가능성이 낮을 때 상대적으로 빠른 상황을 요구할때 사용한다고 한다.</p> https://gukin.dev/posts/delete-insert-innodb-deadlock/ Mon, 21 Apr 2025 00:00:00 +0000 https://gukin.dev/posts/delete-insert-innodb-deadlock/ <h2 id="배경">배경</h2> <ul> <li>최근 우리 서비스는 Sentry를 통해 데드락 알람을 자주 받고 있다</li> <li>처음에는 중복 인덱스를 발견해서 제거하는 작업을 진행했다 <ul> <li>그럼에도 불구하고 동일한 로직에서 데드락이 발생하는 중이다</li> <li>조금은 빈도가 감소했을 수 있는데, 데드락 모니터링과 수집 및 통계화를 다른 회사에서는 어떻게 하는지 리서치가 필요해 보인다</li> </ul> </li> <li>아무튼 데드락을 분석해보니, 동일한 레코드의 DELETE-INSERT가 하나의 트랜잭션 내 수행되는 API에서 발생하였다</li> <li>명확한 원인을 파악하고 전략을 세우기 위해 분석을 시도하였다</li> </ul> <h2 id="innodb-deadlock-분석">InnoDB Deadlock 분석</h2> <h3 id="innodb-엔진-내부-상태를-확인하는-방법">InnoDB 엔진 내부 상태를 확인하는 방법</h3> <p>RDMBS 클라이언트에서 위 명령어를 입력:</p>