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

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..