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

이번 포스팅은 nginx가 구성되어 있는 개발/상용에서는 잘 되던 인증이 nginx가 없는 로컬에서는 왜 안 되었는지 원인을 정리하고 기록하는 포스팅이다...인증은 볼때마다 새롭다...ㅎㅎ OAuth2 인증은 주로 클라이언트 애플리케이션이 리소스 소유자(사용자)의 승인을 받아 리소스 서버의 데이터에 접근할 수 있도록 허가를 요청하는 프로세스이다.  Authorization Request: 클라이언트가 인증 서버에 권한 부여 요청을 보냄.User Authentication: 사용자가 인증을 통해 권한을 승인함.Authorization Code Issuance: 인증 서버가 클라이언트에게 Authorization Code를 발급함.Token Exchange: 클라이언트가 Authorization Code를 ..

에러 메시지Got fatal error 1236 from master when reading data from binary log: 'Could not open log file'.. 발생 원인01번이 primary, 02번이 secondary 구조로 복제를 하고 있는 상황을 가정하자.이 상황에서 01번에 장애가 발생하면, HA 솔루션에 의해 02번으로 Primary가 넘어가게 된다. 02번은 01번으로 복제 연결이 되어 있는 상황이었고, 01번은 다시 재기동을 하고 있다.01번은 재기동을 하면서 신규 binlog 파일을 열어서 binlog를 이어서 작성한다.하지만 02번은 이 상황을 모르고 복제해 오던 로그의 다음 포지션을 바라보고 있어서 위의 에러가 발생한 것이다. 해결 방법은 신규 binlog 파일의..

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 구문이 바로 실행되었다. #기타 확인해 볼 것: 메타데이터 락 확..