Notice
Recent Posts
Recent Comments
Link
반응형
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- Python
- Dynamic Programmin
- 삼성역량테스트
- mysql #numa #swap #memory
- 그거봤어?
- 알고리즘
- 독후감
- technical debt
- 규칙없음
- 동적 프로그래밍
- leetcode
- list of list
- 블린이
- No Rules Rules
- Envoy
- BFS
- 프로그래머스
- LongestPalindromicSubstring
- 리스트의 리스트
- 아마조니언
- 트리
- 파이썬
- 리트코드
- 와썹맨
- 삼성인 아마조니언 되다
- Unique Paths
- 기술적 채무
- 나는 아마존에서 미래를 다녔다
- 김태강
- minimum path sum
Archives
- Today
- Total
개발자가 되고 싶은 준개발자
[mysql] DDL 지연 현상 해결 방법 본문
사전에 테이블 락이 있는지 아래 쿼리를 통해 확인하고 쿼리를 수행해도 쿼리가 다른 트랜잭션에 밀려 실행이 안 되는 현상이 있었다.
#테이블 락 확인
SHOW OPEN TABLE WHERE In_use > 0;
이럴 경우 오래 실행되고 있는 트랜잭션이 있는지, 메타데이터 락이 있는지 추가로 확인해보면 도움이 될 수 있다.
#트랜잭션 확인
select * from information_schma.innodb_trx \G
보면 3월 1일부터 실행되었던 트랜잭션이 있다. kill 166941076(스레드 id)로 해당 스레드를 죽인다.
위 트랜잭션은 show processlist의 상단에서도 확인할 수 있었다.
죽이고 나니 원래 실행하려던 DDL 구문이 바로 실행되었다.
#기타 확인해 볼 것: 메타데이터 락 확인
select object_type, object_schema, object_name, lock_type, lock_status, thread_id, processlist_id, processlist_info
from performance_schema.metadata_locks
inner_join performance_schema.threads on thread_id = owner_thread_id
where processlist_id <> connection_id();
# innodb engine status
show engine innodb status \G
테이블 락이 있는지 확인한다.
'MySQL > mysql' 카테고리의 다른 글
[MySQL] PK, unique key 컬럼 선정 방법 (aka. 복제 지연 예방 방법) (0) | 2023.07.17 |
---|---|
[MySQL] Delete 쿼리 하나로 수십시간의 복제 지연 발생 원인 분석 (0) | 2023.05.04 |
[MySQL] swap 사용률 낮추기 위해 NUMA 정책 interleave로 바꾸기 (0) | 2023.02.23 |
MySQL 데이터베이스 이관 시 고려할 점 (0) | 2023.01.31 |
mysql 쿼리 튜닝 기본 (0) | 2022.12.14 |