공부, 기록

개요라이브 운영 중 Vacuum 으로 인한 DB CPU 상승을 확인하여 Vacuum에 대해 세부 내용을 파악하고 대책을 마련하고자함 문제 상황서비스에서 CPU가 증가하며 비교적 증가 시간이 유지되는 상황 확인. READ,WRITE IOPSCPUPerformance InsightsLog 확인 내용AUTO VACUUM은 3가지 동작 방식이 있다. 1. 일반 AUTOVACUUM 로그 : automatic vacuum table of2. TXID 관리를 위한 AUTOVACUUM 로그 : automatic vacuum to prevent wraparound table of 3. Eager Mode로 동작하는 AUTO VACUUM 로그 : automatic aggressive vacuum tab..

운영 중 PostgreSQL 14버전에서 유니크 인덱스에서 NULL 의 중복 입력이 가능한 것을 확인하였습니다. CREATE UNIQUE INDEX UNIQUE_INDEX ON TABLEA (COLA, COLB)위와 같은 인덱스가 생성되어 있는 상태에서아래 데이터가 여러건 조회가 발생합니다. SELECT COUNT(*) FROM TABLEA  WHERE COLA = '' AND COLB IS NULL; CREATE UNIQUE INDEX UNIQUE_INDEX_01 ON TABLEA (COLA, COLB) WHERE COLB IS NOT NULL;CREATE UNIQUE INDEX UNIQUE_INDEX_02 ON TABLEA  (COLA) WHERE COLB IS NULL;유니크 인덱스 2개를 통하여 ..

개요postgresql 파티션 테이블 기능 테스트를 진행하였습니다.postgresql 파티션 테이블 용어 확인 및 정리파티션 테이블 -> 파티션으로 구성된 테이블 (The partitioned table itself is a “virtual” table having no storage of its own)파티션 -> 파티션 테이블의 하위 데이터 저장되는 영역 (Instead, the storage belongs to partitions)특징선언적 파티셔닝과 상속을 통한 파티셔닝 기법 2가지가 존재합니다.일반적으로 선언적 파티셔닝은 다른 DBMS와 비슷한 파티셔닝 장단점을 가지고 있다고 생각이 듭니다.다만 POSTGRESQL 에서 파티셔닝을 사용하였을 때 추가적인 장점은 VACUUM 관련입니다.Partit..

PostgreSQL의 LOCK에 대한 개념을 알고 싶어서 작성. wait와 lock을 확인하기 위한 방법성능 개선 도우미를 확인한다 (Aurora)pg_stat_activity : 프로세스 수준의 다양한 정보를 제공하는 시스템 뷰https://www.postgresql.org/docs/16/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEWpg_locks : 데이터베이스 서버 내 현재 활동 중인 프로세스가 소유 및 대기 중인 Lock 정보를 제공하는 시스템 뷰https://www.postgresql.org/docs/16/view-pg-locks.htmlpg_locks와 pg_stat_activity를 통해 현재 Lock을 소유한 프로세스(Holder)와 대기..

1. 채번 증가 개발팀에서 UPSERT 를 위해 주로 사용하는 INSERT ON CONFLICT DO UPDATE 구문에서 UPDATE 이후 SEQ가 증가하는 상황에 대해 확인하였습니다.시퀀스 객체는 INSERT가 발생하여 채번이 된 이후 INSERT 구문이 롤백이 되더라도 채번 자체를 취소하지 않습니다.이는 MySQL의 Auto increment 에서도 동일하게 발생하는데 INSERT ON DUPLICATE 로 UPDATE를 진행한 이후 다음 INSERT는 마지막 시퀀스에서 UPDATE가 일어난 만큼 점프한 값으로 입력이 됩니다.postgreSQL도 동일한 현상이 발생하였고 약간의 차이점은 postgreSQL의 경우 HEAP 테이블로 입력 순으로 정렬이 되는데 UPDATE가 DELETE, INSERT로..

개요운영 작업 간 테이블 컬럼 추가, 컬럼 타입 변경, 인덱스 작업이 필요하여 영향도 확인 테스트 내용테이블은 2.1G / 680 만건 db.r6g.xlarge 인스턴스 타입해당 컬럼은 인덱스 O, VARCHAR(255) 상태테스트 아래와 같이 진행컬럼 타입 변경 (varchar(255) → varchar(1000), varchar(100) → text, text → varchar(1000), varchar(1000) → varchar(255) 4개 케이스 경우 테스트)인덱스 삭제컬럼 삭제 신규 컬럼 추가온라인 인덱스 생성 테스트 스크립트 및 결과LOCK 조회 쿼리 SELECT t.relname, l.locktype, page, virtualtransaction,..

개발팀에서 IN 구문이 아닌 ANY 구문 사용을 요청을 하였습니다코드 레벨에서 IN 을 사용하면 코드가 무너지는( ? ) 원인이 있었습니다 --개발팀 코멘트IN 일때trace_id in (%s)%s 에 들어갈 조건들을 쭉 string으로 풀어해치는 로직 추가ANY 일 때trace_id = ANY($1)원래 DB 호출할 때 넘기는 parameter 그대로 사용 가능 IN과 ANY가 동일한 실행계획으로 풀리는 것으로 보이는데 성능도 동일할지 약간의 테스트를 진행해보았습니다. 테스트 테이블create table minjae_test (col1 bigserial primary key, col2 int, col3 varchar(10)); 조회 실행 계획ANY EXPLAINIndex Scan using minjae..

서비스를 모니터링 하는 중 Aurora PostgreSQL 성능 개선 도우미에 DBLoad 가 증가하고 지연 값으로는 IO:XactSync 가 잡히며 해당하는 쿼리는 COMMIT 만 찍히는 상황이 발생하여 이를 케이스 오픈을 진행해가면서 상세하게 확인하고자 하였습니다.  먼저 해당 지표는 Aurora 문서에서 다음과 같이 설명되어있습니다.IO:XactSync 이벤트는 데이터베이스가 Aurora 스토리지 하위 시스템이 일반 트랜잭션의 커밋을 승인하거나 준비된 트랜잭션(Prepared Transcation)의 커밋 또는 롤백을 확인할 때까지 대기 중일 때 발생합니다. 준비된 트랜잭션은 PostgreSQL의 2단계 커밋 지원의 일부입니다. 해당 지표가 발생하는 원인은 다음과 같습니다.Onpremise 환경의 ..

개요서비스 관련 쿼리를 개선하면서 MySQL에만 사용되는 기능인 index for group by를 적용하게 되어 작성합니다.사용되는 쿼리와 테이블은 다음과 같은 형식입니다테이블CREATE TABLE `tableA` ( `id` int NOT NULL AUTO_INCREMENT, `strDepth1Category` varchar(100) COLLATE utf8mb4_general_ci DEFAULT NULL, `strDepth2Category` varchar(100) COLLATE utf8mb4_general_ci DEFAULT NULL, `strDepth3Category` varchar(100) COLLATE utf8mb4_general_ci DEFAULT NULL, `strServiceNam..

#!/bin/bash# Writer와 Reader 정보를 저장할 전역 배열declare -a writer_instancesdeclare -a reader_instances# 모든 클러스터 정보 요약 출력summarize_clusters_info() { local clusters=("${@}") # Writer와 Reader 배열 초기화 writer_instances=() reader_instances=() for cluster in "${clusters[@]}"; do # 클러스터 내 모든 인스턴스 정보 가져오기 local instances instances=$(aws rds describe-db-clusters \ --..