MySQL의 timeout 설정 sleep 세션 client-mysql 서버와 연결 후 다음 query 수행까지 대기중인 상태의 세션 sleep 세션이 너무 많고 정리가 안되는 경우 connection full 로 인해 신규 세션 접속이 불가능해지고 session 별 할당 되는 메모리로 인해 memory 부족 현상 발생할 수 있음 timeout 관련 설정 connect_timeout : MySQL 서버 접속시에 접속실패를 메시지를 보내기까지 대기하는 시간 delayed_insert_timeout : insert시 delay될 경우 대기하는 시간 innodb_lock_wait_timeout : innodb에 transaction 처리중 lock이 걸렸을 시 롤백 될때까지 대기하는 시간으로 innodb는 자..

MySQL online으로 일반테이블 파티셔닝 전환하기 기존 일반테이블을 파티셔닝 테이블로 변환할 때 pt-osc 를 활용하여 온라인 작업으로 할 수 없을까 검색하던 중 카카오에서는 아래의 내용처럼 pt-osc를 수정하여 사용한다는 것을 알게 되었습니다 http://small-dbtalk.blogspot.com/2014/04/pt-online-schema-change-modified-pt.html 간단하게 요약하자면 MySQL에서 하나의 ALTER 문으로 처리하지 못하는 DDL작업들을 pt-osc에서도 처리하지 못했는데요. 대표적으로 일반테이블을 파티션테이블로 전환하는 경우 PK 구성 변경과 파티셔닝 커맨드를 하나의 ALTER문으로 표현할 수 없기 때문에 pt-osc를 활용할 수 없습니다. 이런 점을 개..

MySQL 특정 테이블만 시점복구 하기 얼마 전 서비스 로직 이슈로 특정 데이터들이 CASCADE 삭제되어 데이터가 유실되는 일이 발생했습니다. 영향 받은 테이블들은 전체 테이블들 중 두개였고 전체 서비스를 장애 시점 이전으로 롤백시킬 수는 없는 상황이었기 때문에 해당 테이블들만 복구를 진행했습니다. 대상 테이블들은 특히 또 FOREIGN KEY constraint 가 걸려있어서 여러모로 생각해줘야 하는 부분들이 많았습니다. 먼저 복구 시나리오는 아래와 같습니다. * 복구 시점 찾기 * 최신 백업본 로드 (10/30일 새벽 백업본) * 10/30일 새벽 백업본 + 장애 시점 전 까지의 binary log 적용 ( 대상 테이블 관련 DML만 추출해서 적용하기 ) * 장애유발쿼리 제거하고 그 이후부터 현재까..

MySQL INSERT INTO ON DUPLICATE KEY UPDATE 로 인한 LOCK 이슈 MySQL의 편리한 기능 중 INSERT INTO ~ ON DUPLICATE KEY UPDATE 구문이 있습니다. unique key, primary key 로 unique 제약조건이 걸려 있는 상황에서 중복된 데이터가 들어오면 DUPLICATE KEY UPDATE 구문으로 update 를 수행하는 구문인데요. ORACLE 이나 기타 DB에서는 REPLCAE 에 해당하는 구문입니다. 참 편리한 기능이지만 DML이 많이 발생하는 상황에서 동일한 ROW 에 UPDATE 를 시도하는 세션이 많이 쌓이는 경우 LOCK 과 함께 CPU가 급증하는 현상을 만날 수 있는 주의해야할 쿼리이기도 합니다. 장애 상황 문제 쿼..

Subquery Tuning 서브쿼리 동작 방식 filter 서브쿼리의 결과 건수가 몇건이건 상관 없이 전체 쿼리의 결과는 최대 메인쿼리 결과만큼나옴 메인 쿼리 수행 결과 만큼 서브쿼리를 실행함, 쿼리 순서는 메인쿼리 -> 서브쿼리 고정 메인 쿼리 실행 결과 건 수 + 서브쿼리로 input 되는 값 에 따라 경우의 수 나뉠 수 있음 메인 쿼리 실행 결과 건 수 많음 + input 되는 값이 unique 한 경우 메인 쿼리 실행 결과 건 수 적음 + input 되는 값이 unique 한 경우 메인 쿼리 실행 결과 건 수 많음 + input 되는 값이 unique 하지 않고 중복되는 값이 많음 2>3>1 순으로 성능 나올 것 Filter 동작 방식은 메인쿼리의 실행 결과 건수가 많고 (조인 시도 횟수 증가)..

index타던 쿼리가 full scan할 때(range_optimizer_max_mem_size) Index 잘 타던 쿼리가 fullscan을 하면서 CPU가 100% 를 치는 이슈가 발생했습니다. range_optimizer_max_mem_size 라는 생소한 파라미터를 설정하여 이슈 해결한 사례를 공유합니다. 이슈 상황 DB server에서 갑자기 CPU가 100%를 치는 상황이 발생 원인은 아래 Slow query 가 수행되면서 발생한것으로 추측 SELECT * FROM tb_test tb1 LEFT OUTER JOIN tb_test2 AS tb2 ON tb1.name = tb2.name WHERE tb1.status = 'active' AND tb1.resource_id in (1,2 ........