개요read view로 인하여 purge가 막히고 조회가 지연될 수 있다는 사실은 알고 있으나 그 부분에 대하여 명확하게 이해하고 있다고 생각되지 않아서 해당 부분의 개념을 습득하고자 하였습니다.read view 가 어떻게 만들어지고, purge 가 그것을 기준으로 어디까지 정리하며, HLL 이 커졌을 때 어떤 쿼리가 실제로 영향을 받는지를 한 흐름으로 정리합니다. 대상 버전은 MySQL 8.0 / Aurora MySQL 3 입니다.다루는 것제외한 것read view 항목 · 생성 시점 · 가시성 판정DB_ROLL_PTR 비트 구조 · undo 물리 경로purge 경계(m_low_limit_no)와 HLL 증감undo 물리 생애 · 롤백버전 체인 vs delete-mark 비용 구분Aurora 공유 스토..

개요MYSQL 클러스터에서 Writer 인덱스 생성 중 Reader 조회가 지연되었습니다.AWS 답변은 "인덱스 생성 redo 가 Reader 버퍼풀에 영향을 주었다" 였으나, 재현 테스트, 당시 모니터링 지표 등을 확인하였을 떄 원인은 Writer purge 정지 와 LOB 의 MVCC 특성 이었습니다.1. 사례테이블역할tableA유니크 인덱스 생성 대상 (약 65분 소요)tableB큰 JSON 컬럼을 ON Duplicate key update 로 재작성 — 조회가 지연된 테이블tableCReader 버퍼풀을 최대 점유하던 테이블시각WriterHLLReader07:10tableA 인덱스 생성 시작증가 시작tableB 조회 지연 시작07:10~08:10DDL 진행, tableB ON Duplicate k..

개요 : 평소 AWS 리소스를 운영 중 Latency 지표에 대한 궁금증이 많았습니다. 디스크 I/O 1건당 평균 소요시간이라는 해당 지표는 Write처리량이 높을 때는 낮은 Latency를 점검 같은 사용량이 낮을 때는 높은 Latency 지표를 보일 때가 있었는데요. 디스크 성능 수준을 보는 해당 지표라면 처리량에 따른 Latency 수준은 같아야 하지 않나? 라는 생각이 항상 따라다녔습니다. 해당 사례에서 AWS 엔지니어분과의 질의를 통해 지표에 대한 이해를 좀 더 높일 수 있었습니다.배경 : DocumentDB 이관 배치 중 INSERT 지연판별 근거 : WriteLatency 감소 + DiskQueueDepth 급증현상이관 배치 구간의 지표가 직관과 반대 방향으로 움직였습니다.지표작업 전작업 중..

개요 : 약 20GB 규모 컬렉션의 $out 이 약 45분 소요된 원인을 확인하고, 대량 쓰기 작업의 배치 설계 기준을 정리하고자 합니다.현상컬렉션을 백업하기 위해 $out 과 mongoexport 를 수행하였으나 1시간이 넘어 중단하였습니다.항목값대상DocumentDB 5.0인스턴스db.r8g.xlarge (버퍼 캐시 약 21.3 GiB)$out 소요 시간라이브 서버 예측 : 약 1시간 30분 테스트 서버 : 2,687초 (약 45분)컬렉션 물리 크기약 25,423 MiB (3,254,153 페이지)확인 내용A. 컬렉션 사이즈가 성능에 영향을 주는지--> 영향을 줍니다. 약 15 GiB 까지 평탄하다가 버퍼 사이즈와 유사한 20 GiB 부터 성능이 급격히 감소대상 크기페이지소요ms/page소스 히트율2..

개요 : maxTimeMS 를 지정하였음에도 쿼리가 중단되지 않는 원인을 확인하고 정리하고자 합니다.현상maxTimeMS 를 5,000ms 로 지정한 aggregate 쿼리가 약 15초 동안 수행되고도 중단되지 않는 것을 확인하였습니다.항목값대상db.collection지정한 maxTimeMS5,000 ms실제 수행 시간(millis)14,974 ms (약 15초)planSummaryCOLLSCANnreturned38 건수집된 profile 로그입니다. [실측]{ "ns": "db.collection", "command": { "aggregate": "collection", "pipeline": [ { "$match": { "collection.col1": { "$exists": t..

개요 : Performance Insights 의 DocumentLock 대기 이벤트가 증가한 원인을 확인하고 정리하고자 합니다. 현상특정 클러스터에서 UTC 2026-04-04 17:30:28 경 profile 로그상 INSERT 쿼리가 평소 대비 지연되는 것을 확인하였습니다.같은 시점 Performance Insights 에서 DocumentLock 대기 이벤트로 INSERT 가 증가하는 것을 확인하였습니다.공식 문서에는 DocumentLock 이 "동일한 문서에 대한 동시 쓰기 횟수가 많으면 발생" 한다고만 기술되어 있습니다.그런데 해당 시점의 INSERT 는 증분 _id 를 사용하였으므로 동일 문서에 대한 동시 쓰기로 보기 어려웠습니다.다만 인덱스로 사용하는 필드에 대하여 동일한 값의 INSERT..

개요Aurora PostgreSQL 의 메이저버전 업그레이드를 진행하면서 확인하였던 내용을 정리하였습니다.대상은 논리복제를 사용하고 있는 클러스터, 미사용하고 있는 클러스터로 나누어져 있으며논리복제를 사용하는 경우 AWS의 블루그린 배포를 사용하지 못하여 자체적으로 처리하였으며논리복제를 사용하지 않는 경우 AWS의 블루그린 배포를 사용하여 진행하였습니다.작업 절차는 논리복제를 사용하는 자체 구성에 대하여 작성하였으며 하단에 블루그린 배포를 사용하는 경우의 차이점, 유의사항을 추가하였습니다.Aurora PostgreSQL 14.6 → 16.8목적 EOS 로 인한 메이저버전 업그레이드방식 Aurora Clone 기반 자체 논리 복제 구성 아래 내용은 QA 서버를 대상으로 진행하였습니다.대상 구성대상 DB 1..

개요 : Aurora 비용 관리 측면에서 데이터 유지보수에 대한 개발팀과의 논의 중 클러스터의 스토리지 사용량은 DELETE 로는 사용량이 줄지 않고 DROP 으로만 줄어드는 것에 대하여 좀 더 깊은 이해를 가지고 싶어 DBMS별 DELETE와 DROP의 처리 방식이나 차이에 대하여 알아두고자 합니다 처음 가졌던 추측은SQL SERVER에서 경험했던 것 처럼 DELETE 로 처리되면 논리적인 크기만 확보되고 SHRINK 등의 작업 없이는 물리적인 크기는 확보되지 않는 것이 아닐까. DROP은 파일 단위를 삭제 (Innodb의 경우 옵션에 따라 다르지만)하여 바로 회수가 되는 것 아닐까였습니다 DELETE 동작 방식. MySQL InnoDBDELETE 는 행을 즉시 제거하지 않고 delete-marked ..

개요기본적으로 대소문자 구분을 하는 PostgreSQL에서 대소문자 구분 없이 데이터를 조회할 방법이 있을지에 대한 검토입니다. DB 생성 옵션Aurora PostgreSQL은 파라미터로 Collate를 지정할 수 없습니다.다만 생성할 때 CLI를 사용하면 지정이 가능합니다.create-db-cluster[--availability-zones ][--backup-retention-period ][--character-set-name ][--database-name ]다만 지정 가능한 값은 C, en_US.UTF-8 로 CI, CS 의 옵션이 없어서 대소문자 구분과는 큰 관련이 없습니다대소문자 구분 없애는 방법 리스트 방법인덱스 사용Like 구문1LOWER() / UPPER() 함수함수형 인덱스 필요가능2..

개요 : Aggressive Vacuum의 영향도를 줄이기 위해 Vacuum Freeze 배치를 설정했던 과정을 정리합니다.Aurora PostgreSQL 대형 테이블 Aggressive Vacuum 운영 전략수백 GB 이상의 대형 테이블에서 Transaction ID Wraparound를 방지하면서서비스 영향을 최소화하는 VACUUM FREEZE 배치 운영 방법을 정리합니다.테이블 사이즈가 증가할 수록 Tuple 수는 증가하게될 때 Vacuum 트리거를 조정하여 상대적으로 Vaccuum이 자주 동작하게 하면 일반 Lazy Vacuum의 영향도는 일정하더라도 Eager 방식의 Vacuum의 영향도는 해소가 되지 않습니다.AutoVacuum의 autovacuum_freeze_max_age 기준에 도달하면 ..

개요 : Aurora 환경에서만 익숙해져있어서 Onpremise 환경의 특징도 알아두고자 베이스한 내용을 공부하고자 함[PostgreSQL On-Premise] Phase 1 — 설치 및 파일시스템 구조Aurora와의 핵심 차이Aurora 관리 영역On-Premise에서 직접 해야 할 것initdb 자동 실행initdb 직접 실행, --data-checksums 설정파일 구조 비가시화$PGDATA 구조 이해 및 직접 관리Parameter Grouppostgresql.conf + pg_hba.conf 직접 관리프로세스 추상화각 프로세스 역할 이해, OOM 대응OS 튜닝 AWS 담당vm.swappiness, HugePages 등 직접 설정1-1. initdb — 클러스터 초기화initdb -D /var/li..

개요 : Aurora PostgreSQL 표준화를 진행하면서 확인하였던 파라미터에 대한 정리입니다.Aurora PostgreSQL 파라미터 표준값 정리 — OLTP 환경 기준Aurora PostgreSQL을 운영하면서 파라미터 표준값을 정립하는 과정에서 확인한 내용들을 정리합니다.환경 기준: 4 vCPU / 32GB (r6g.xlarge), OLTP, max_connections 36001. Aurora 파라미터의 특수성Aurora 파라미터를 다룰 때 두 가지 개념을 구분해야 합니다.Aurora 기본값이 자동 계산되는 파라미터: 수정은 가능하지만 Aurora가 인스턴스 메모리/vCPU 기반으로 최적값을 자동 계산합니다. 기본값이 대부분의 경우 적절하며, 변경 시 의도치 않은 성능 저하가 생길 수 있어 주..

TABLEA에 인덱스 생성 작업을 시작하였습니다.작업 시작 직후부터 Replica에서 인덱스 생성과 관계없는 TABLEB의 조회 쿼리에서 지연이 발생하기 시작했고, 인덱스 생성이 완료된 08:10 이후 자연스럽게 해소되었습니다.Primary: TABLEA 인덱스 생성 시작 (07:00) │ ▼Replica: TABLEB 조회 쿼리 지연 발생 │ ▼Primary: 인덱스 생성 완료 (08:10) │ ▼Replica: 지연 해소, 지표 정상화 확인 내용지표변화의미innodb_buffer_pool_reads증가Buffer Pool miss → Storage에서 직접 readinnodb_pages_read증가물리 I/O 발생innodb_buffer_pool_read_request..

개요QA 환경의 MYSQL에서 OOM 에러가 발생하여 원인 확인 및 조치에 대하여 확인하였던 내용입니다.QA 환경의 장비는 T4G.Large를 사용하여 8GIB의 메모리를 사용할 수 있습니다.메모리 사용량 관련 지표Freeable Memory (OS 전체 영역에 대한 가용 메모리, buffer pool에 할당된 메모리는 제외하고 산출됨)SwapUsage 메모리 SWAP 지표 Performance Schema 관련 확인 내용Summary 테이블 중 by_account와 by_host 테이블이 대부분을 차지하고 있음-- Performance Schema 전체 메모리 사용량SELECT SUBSTRING_INDEX(EVENT_NAME, '/', 2) AS category,ROUND(SUM(CURRENT_NUM..

DocumentDB를 운영하던 중 특정 시간쯤에 입력 쿼리들에 대하여 대량의 지연이 발생한 후 해소되는 현상이 발생하였습니다.이 글은 해당 이슈에 대한 원인을 파악하기 위해 확인하였던 내용들과 거기서 알게된 내용들에 대해 정리하고자 합니다. 1. 현상서비스 오픈 이후 얼마 되지 않은 시점부터 특정 시간대에 평소 30MS 이하의 처리 속도를 보이던 입력과 유니크 인덱스를 바탕으로한 단일 업데이트 쿼리가 300~400MS 까지 증가한 후 감소하는 현상을 발견하였습니다.해당 컬렉션은 _id 컬럼의 인덱스와 uuid 값을 가진 데이터의 유니크 인덱스를 가지고 있었고 데이터 사이즈는 수억건으로 꽤 큰 편이었습니다. 2. 확인 내용여러 지표들에 대해 확인하였으며 해당 과정에서 알게된 내용입니다.확인 지표A. Wr..

VACUUM에는 Analyze, Freeze, Verbose 처럼 Truncate 라는 옵션이 있습니다.Trunacte는 일반적으로 데이터를 삭제하는 작업처럼 느껴지는데요 Vacuum에서는 어떤 역할을 하는지 정리하고자 합니다. Vacuum Truncate는 일반적으로 Default 옵션으로 별도 지정이 없을 경우 동작합니다(Auto Vacuum도 동일합니다).이 동작은 Table의 끝에 있는 페이지가 비어있을 경우 해당 공간을 O.S에 반환하는 동작을 합니다.TRUNCATESpecifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the trun..

개요팀 정책으로 표준화된 AWS DBMS에 대하여 작성한 Terraform 코드를 Jenkins 를 통하여 파라미터를 입력 받아 비교적 편하게 DB를 생성하는 작업을 하고자 하였습니다.내부적으로 Gitlab을 소스코드 저장소로 사용하고 있었기 때문에 Jenkins와 Gitlab을 연동하는 작업이 필요하였습니다.GitLab 연동Jenkins 관리 → Credentials → System → Global credentials 에서 우측 상단의 Add Credentials 선택합니다. GitLab Access TokenUsername : GitLab IDPassword : Access Token GitLab Api Token 생성API token : Git Access TokenGitLab connection..

BTREE 복합 인덱스에서 컬럼이 2개이고 선행 컬럼이 범위 검색으로 사용될 경우 후행 컬럼은 인덱스 조회에서 사용되지 못하는데 이 상황에서 I/O를 최대한 줄이기 위해 DBMS는 Index Condition Pushdown 과 같은 기능을 제공합니다. MySQLIndex Condition Pushdown(ICP) 기능을 사용할 수 있습니다.이는 실행계획에서 확인할 수 있으며INDEX = COLA, COLB Query = SELECT * FROM TABLEA WHERE COLA BETWEEN X AND Y AND COLB = Z의 상황에서 아래와 같이 동작합니다.MySQL (ICP)ICP 기능이 없을 때MySQL서버는 스토리지 엔진에 쿼리에 데이터 조회를 요청합니다.그 후 스토리지 엔진은 인덱스의 ..

PostgreSQL의 테이블 DROP은 트랜잭션 내에서 처리가 가능한 즉 롤백이 가능한 특징을 가지고 있습니다.이러한 방식은 Lazy 처리 방식으로 인하여 가능합니다. DDL이 사용되면 처리는 트랜잭션 내에서 여러 메타데이터를 삭제한 뒤 COMMIT이 되면 Pending List에 DROP할 파일을 추가하고 이후 물리 파일을 삭제하는 과정을 거칩니다. AuroraPostgreSQL은 Aurora의 특징으로 인해 동적으로 물리 파일 크기를 조정합니다.AuroraPostgreSQL을 운영 및 테스트하던 중 용량이 큰 TABLE을 DROP할 때 CPU가 증가하던 상황을 확인하여 Onpremise의 PostgreSQL과는 다른 구성으로 인한 영향이 어떠한지 확인을 진행해보았습니다.아래는 각 작업에 대한 정보와 ..

Aurora와 Onpremise 의 PostgreSQL과 MySQL의 크래쉬 상황에서 복원 (롤포워드) 방식에 대해 알아보고자 합니다.Onpremise에서는 사실 WAL, UndoLog, RedoLog 등을 사용하여 복원하는 것이 일반적이라서 크게 특이사항이 없었는데 Aurora는 클러스터 볼륨, 컴퓨팅 영역 분리의 특징, 로그를 전달하는 방식의 데이터 저장 처리 등 다른 부분이 있기 때문에이를 비교하고 이해하여 종합적인 이해도를 높이고자 하였습니다. On-Premise MySQL (InnoDB)Redo Log, Undo Log, Doublewrite Buffer 의 3가지 요소로 DB를 정상화 시킵니다.먼저 서버는 체크 포인트의 마지막 지점을 파악하고 이 지점부터 RedoLog 파일과 DoubleWr..