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

MySQL 8.0.18 부터는 EXPLAIN ANALYZE로 쿼리를 분석할 수 있다. EXPLAIN ANALYZE가 기존 MySQL 8.0 부터 제공되던 EXPLAIN FORMAT=TREE 와 다른 점은 실행 계획(estimated cost) 뿐만 아니라 실제 실행했을 때 비용도 같이 보여준다는 점이다. EXPLAIN ANAYLYZE를 사용해 보기 위해 인덱스를 필요로 하는 쿼리에 대해 IGNORE INDEX와 USE INDEX 힌트를 사용해 인덱스를 사용하지 않을 때와 사용할 때 실행 계획을 비교해 봤다. 먼저 수행된 단계가 가장 안 쪽으로 indent되어 표시된다. 따라서 먼저 수행된 table scan부터 보면 된다. Table Scan 단계) 실행 계획 cost: 574010 rows:549000..

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. 이관할 데이터의 양 먼저 이관할 데이터의 양은 최대한 줄이는 것이 좋다. 대부분의 서비스에서는 로그성으로 쌓기만 하고 데이터 변경은 하지 않는 테이블이 있고, 주로 이런 테이블들의 용량이 크다. 이런 테이블들은 서비스 이관 시에 바로 필요한 데이터가 아닐 수 있기에 이관 우선순위가 ..

복제는 정상적으로 되고 있는 상황이나 아래처럼 3번 DB의 master가 Unknown으로 뜨는 현상이 생겼다. 03번 복제 성정의 master_host가 ip가 아닌 호스트명으로 되어 있었다. MMM은 내부적으로 ip를 호스트명으로 치환하므로 ip를 master_host로 입력해주어야 한다. DB에서 change master to ~로 master_host를 ip로 수정해 주면 된다.

사전에 테이블 락이 있는지 아래 쿼리를 통해 확인하고 쿼리를 수행해도 쿼리가 다른 트랜잭션에 밀려 실행이 안 되는 현상이 있었다. #테이블 락 확인 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 물리적으로 떨어진 페이지들에 임의로 접근하는 방식으로 페이지가 위치한 물리적인 위치를 고려하지 않고 접근한다. 디스크 헤더가 정해진 순서 없이 이동하므로 디스크의 물리적인 움직임이 많아 오래 걸린다. # 오브젝트 스캔 유형 테이블 풀 스캔 인덱스를 거치지 않고 테이블을 처음부터 끝까지 훑어보는 스캔 방식이다. 테이블 풀 스캔..

#가격 mysql은 community와 enterprise 버전이 있고, community 버전은 무료이다. 이에 비해 오라클은 가격이 비싸고 무료 버전이 없다. # 스토리지 오라클 DB는 통합된 스토리지 하나를 공유하여 사용하나 MySQL은 물리적인 DB 서버마다 독립적으로 스토리지를 할당하여 구성한다. 따라서 오라클은 공유 스토리지를 사용하므로 어느 DB 서버에 접속하여 SQL문을 수행하더라도 같은 결과를 출력한다. MySQL에서도 복제 구성을 통해 DB 여러 대가 같은 데이터를 갖도록 구성할 수 있다. 단 이 경우에는 대부분 master-slave 구조로 구축을 하기 때문에 쓰기 작업은 한 서버에서만 발생하고, 나머지 서버에서는 읽기 작업만 하는 구조를 갖는다. master-slave 구조로 구축할..