개발자가 되고 싶은 준개발자

MySQL 8.0.25버전에서 Prepared statement가 index 못 타는 버그를 발견하여 버전 업그레이드를 하게 되었다. Prepared Statement란? Prepared Statement란 파라미터를 미리 채우지 않고, 공란으로 둔 후에 값을 따로 덧붙여서 쿼리하는 방식이다. mysql> PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse'; mysql> SET @a = 3; mysql> SET @b = 4; mysql> EXECUTE stmt1 USING @a, @b; +------------+ | hypotenuse | +------------+ | 5 | +------------+ mysql> DEALLOCATE ..

인덱스가 있어도 복제 방식으로 인해 unique key가 필요한 경우가 있다. 특히 binlog 기반으로 복제하는 MySQL의 경우 대량의 데이터 변경을 한 쿼리에서 할 경우 복제 지연이 발생할 수 있다. 예를 들면, ROW-BASED 복제 환경에서 unique key나 primary key가 없는 테이블에 Primary에서 100만건 데이터를 삭제한다고 가정해보자. (ROW-BASED 복제는 binary log를 쿼리 기준으로 기록하는 것이 아니라 쿼리에서 변경된 데이터 row 기준으로 기록하는 것을 말한다.) Primary에서는 1회의 index/table full scan으로 처리되지만, row-based 복제에서는 binary log가 쿼리 단위가 아닌 변경된 데이터 기준으로 쌓이게 된다. 따라서..

MySQL DB를 3대 HA 구성으로 사용하고 있다. (Primary 1대와 Replica 2대로 구성되어 있다. Write은 Primary에서만 일어난다.) DB 작업을 하다가 Primary에서 1~2 시간 내로 끝나던 Delete 쿼리가 Replica에서는 수십시간이 지나도 쿼리가 완료되지 않고 Replication Lag만 계속 늘어나는 현상을 발견하여 이에 대해 정리해 보고자 한다. 내 상식으로는 Primary에서 걸린 시간만큼 Replica에서도 같은 쿼리를 적용할 것 같았다. 그런데 이 경우에는 Primary보다 Replica에서 쿼리를 수행하는 데 훨씬 더 시간이 오래 걸렸다. Primary에서 날린 쿼리는 50GB 정도 되는 테이블에 날짜 기반으로 검색하여 데이터를 삭제하는 쿼리(delet..

# 문제 여유 메모리가 있음에도 불구하고 swap이 사용되는 현상이 발생했다. 먼저 메모리와 swap 상태를 확인해 보았다. free -h 메모리는 125기가 중에 71기가만 사용 중인데 벌써 swap 을 사용하고 있다. numactl -H NUMA 구성을 살펴보면 노드 2개로 구성되어 있다. vi /etc/my.cnf 버퍼 풀은 63기가로 잡혀있다. 문제는 NUMA 노드당 메모리가 약 63GB 잡혀있는데, 버퍼 풀이 이미 63GB를 사용해서 다른 프로세스가 NODE 0에 작업을 할당받으면 메모리를 사용할 수 없어 NODE 1에 여유 메모리가 있음에도 swap을 사용하게 된다. ps -ef | grep mysql numastat -p 39697 mysql 프로세스의 PID로 프로세스에서 NUMA NODE..

DB를 운영하다 보면 서비스 담당 팀의 변경이나 담당 회사의 변경, 서버 노후화로 인한 서버 교체 등의 다양한 이유로 데이터베이스 이관을 하게 된다. 데이터베이스 이관 시에는 다양한 이해관계자들이 함께 협의를 하는 경우가 많다. 이관 전에 DB를 운영하는 사람, 서비스를 담당하는 PM, 이관 후 운영할 사람, 개발자 등이 함께 진행 방향을 논의하게 된다. 논의에 앞서 DBA 입장에서 먼저 확인해 보면 좋은 것들이 있다. 1. 이관할 데이터의 양 먼저 이관할 데이터의 양은 최대한 줄이는 것이 좋다. 대부분의 서비스에서는 로그성으로 쌓기만 하고 데이터 변경은 하지 않는 테이블이 있고, 주로 이런 테이블들의 용량이 크다. 이런 테이블들은 서비스 이관 시에 바로 필요한 데이터가 아닐 수 있기에 이관 우선순위가 ..

사전에 테이블 락이 있는지 아래 쿼리를 통해 확인하고 쿼리를 수행해도 쿼리가 다른 트랜잭션에 밀려 실행이 안 되는 현상이 있었다. #테이블 락 확인 SHOW OPEN TABLE WHERE In_use > 0; 이럴 경우 오래 실행되고 있는 트랜잭션이 있는지, 메타데이터 락이 있는지 추가로 확인해보면 도움이 될 수 있다. #트랜잭션 확인 select * from information_schma.innodb_trx \G 보면 3월 1일부터 실행되었던 트랜잭션이 있다. kill 166941076(스레드 id)로 해당 스레드를 죽인다. 위 트랜잭션은 show processlist의 상단에서도 확인할 수 있었다. 죽이고 나니 원래 실행하려던 DDL 구문이 바로 실행되었다. #기타 확인해 볼 것: 메타데이터 락 확..

#디스크 접근 방식 Sequential Access mySQL은 디스크에 저장된 데이터에 접근할 때 페이지 단위로 접근한다. 페이지는 데이터를 검색하는 최소 단위이다. 물리적으로 인접한 페이지를 순차적으로 읽는 방식으로 보통 테이블 풀 스캔에 사용된다. 데이터를 찾고자 이동하는 디스크 헤더의 움직임을 최소화하여 작업 시간과 리소스 점유 비용을 줄일 수 있다. Randon Access 물리적으로 떨어진 페이지들에 임의로 접근하는 방식으로 페이지가 위치한 물리적인 위치를 고려하지 않고 접근한다. 디스크 헤더가 정해진 순서 없이 이동하므로 디스크의 물리적인 움직임이 많아 오래 걸린다. # 오브젝트 스캔 유형 테이블 풀 스캔 인덱스를 거치지 않고 테이블을 처음부터 끝까지 훑어보는 스캔 방식이다. 테이블 풀 스캔..