개요 : 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..