내부 임시 테이블에서 사용하는 메모리 양을 표시하기 위해 aurora_temptable_ram_allocation 및 라는 두 가지 전역 상태 변수를 추가했습니다aurora_temptable_max_ram_allocation. 이러한 전역 상태 변수는 관찰성을 높이고 내부 임시 테이블 메모리 사용과 관련된 문제를 진단하는 데 도움이 됩니다.
PostgreSQL 의 HA (High Availability) 를 지원하는 Open Source
자동 장애를 감지하여 자동으로 Failover 지원 및 Replication 관리 등을 제공하여 서비스 중단을 최소화
maximum_lag_on_failover 기준에 따라 Failover 여부를 결정
PostgreSQL cluster를 쉽고 유연하게 구축을 지원하며, Python 기반
자체적으로 Leader 를 선출(promotion)하는데, 이때 Distributed Configuration Store(다양한 분산 설정 저장소-ZooKeeper, etcd, Consul, Kubernetes 등)를 활용하여 Cluster leader(primary) 를 선출
주로 Cluster status, Leader Info 등의 정보를 저장하는 용도이며, 모든 node가 해당 정보를 공유
RAFT 합의 알고리즘을 사용(대부분 election 관련한 것은 RAFT 알고리즘을 사용하는 듯 - MongoDB...)
PostgreSQL 인스턴스 startup / stop / restart 를 직접 관리하며, replication 생성을 위한 설정 변경 등도 자동으로 지원
Rest API를 제공하여 노드별 관리 및 상태 확인, 수동으로 장애조치(Manual Failover) 등을 지원
patronictl 명령어로 클러스터 상태 모니터링, switchover(수동 리더 전환), manual failover(강제 장애조치) 등 수행 가능
Cloud 환경 지원 (AWS, GCP, k8s)
설정 파일에 대해 실시간 적용
구성요소
역할
Patroni 인스턴스
각 서버(노드)에서 PostgreSQL 프로세스를 관리, 상태 체크, 리더 선출에 참여
분산 저장소(etcd 등)
클러스터 메타데이터, 리더 정보, 노드 상태 등 공유 역할
PostgreSQL 인스턴스
실질적인 데이터 저장 및 클라이언트 서비스 제공
Failover(장애조치) 동작 방식
상태 모니터링: 각 Patroni 인스턴스는 자신의 PostgreSQL과 외부 분산 저장소(etcd/Consul 등)을 통해 클러스터 전체 상태를 파악
각 Instance 에 존재하는 Patroni instance 들이 자신의 상태정보(정상 여부, LSN 동기화 등)를 주기적으로 etcd 에 등록
etcd 에 등록된 다른 노드들은, 이러한 정보들을 서로 계속 모니터링
Primary 장애 감지: Primary(PostgreSQL 리더) 인스턴스에 장애가 발생해 heartbeat/stats 갱신이 중지되면, 나머지 Replica Patroni 인스턴스들이 즉시 이를 감지.(Health check)
Primary(Leader) 선출(election): Patroni 인스턴스들이 협의하여 etcd 같은 분산 저장소를 통해 새로운 리더를 선출. 가장 최신의 WAL 로그를 가진 standby가 우선 승격 대상.
자동 승격(Promotion): 선출된 Replica는 자동으로 PostgreSQL primary로 승격(promote) 되고, 클러스터 상태가 분산 저장소에 반영
기존(Old) Primary restart : 장애가 복구된 이전 Primary는 자동으로 Replica로 강등(demote)되어 클러스터에 재합류(재동기화).
동적 재구성: 연결 관리(HAProxy, PgBouncer, 애플리케이션 등)는 REST API와 클러스터 메타 정보로 새로운 리더 정보를 즉시 인지.
DCS (분산 구성 저장소, Distributed Configuration Store) 역할
Cluster 상태 공유 및 Leader 선출
Cluster 내 모든 node(PostgreSQL + Patroni ) 의 DCS 에 접근하여 클러스터의 상태와 구성 정보를 저장하고 공유
Primary (Leader)의 경우 주기적으로 DCS에 자신의 상태(leader key, TTL 등)를 갱신하고, 다른 노드들이 이 정보를 지속적으로 체크하여, 혹시라도 갱신이 멈추면 key 를 만료시켜 Leader 선출 프로세스가 자동으로 시작
Node 상태 감지 및 Failover 지원
Patroni agent 가 자신의 상태 정보를 DCS 에 주기적으로 업데이트 하여 모든 노드가 서로의 상태를 감지할 수 있음
Split brain 방지
DCS 의 Leader lock 의 TTL 관리와 patroni 의 Self-fencing (자기 격리) 메커니즘을 통해, 네트워크 split 이나 시스템 장애시 여러 node 가 동시에 primary 로 오작동하는 문제를 예방
DCS와 connection 이 끊어지거나, Leader key 갱신이 실패하면, 해당 node 는 자신을 자동으로 replica 로 강등시켜 데이터 손실 및 충독을 예방
각종 관련된 확인 내용
#Patroni 클러스터 정보
root@QEMU-Virtual-Machine:/data# patronictl -c /etc/patroni1.yml list
+ Cluster: pg-cluster (7527206046275954701) ----+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+--------+----------------+---------+-----------+----+-----------+
| node1 | 127.0.0.1:5432 | Leader | running | 1 | |
| node2 | 127.0.0.1:5433 | Replica | streaming | 1 | 0 |
| node3 | 127.0.0.1:5434 | Replica | streaming | 1 | 0 |
+--------+----------------+---------+-----------+----+-----------+
# DCS(etcd) 정보
root@QEMU-Virtual-Machine:/data# etcdctl member list
2c5b13349b914f7c, started, etcd2, http://127.0.0.1:2480, http://127.0.0.1:2479, false
d6b6fc75feb1ea61, started, etcd3, http://127.0.0.1:2580, http://127.0.0.1:2579, false
e17d9e661baad1bc, started, etcd1, http://127.0.0.1:2380, http://127.0.0.1:2379, false
#Leader / member 정보
root@QEMU-Virtual-Machine:/data# etcdctl endpoint status --cluster
http://127.0.0.1:2479, 2c5b13349b914f7c, 3.6.2, 3.6.0, 78 kB, 78 kB, 0%, 0 B, false, false, 2, 292, 292, , , false
http://127.0.0.1:2579, d6b6fc75feb1ea61, 3.6.2, 3.6.0, 78 kB, 78 kB, 0%, 0 B, false, false, 2, 292, 292, , , false
http://127.0.0.1:2379, e17d9e661baad1bc, 3.6.2, 3.6.0, 78 kB, 78 kB, 0%, 0 B, true, false, 2, 292, 292, , , false
#/service/{Cluster name} 경로에 Cluster 상태 정보 및 구성 값을 저장되어 확인이 가능
# 아래 내용은 모든 내용을 출력 / 해당 정보들이 꾸준히 갱신
root@QEMU-Virtual-Machine:/data# etcdctl get / --prefix
/service/pg-cluster/config
{"ttl":30,"loop_wait":10,"retry_timeout":10,"maximum_lag_on_failover":1048576,"postgresql":{"use_pg_rewind":true,"parameters":{"wal_level":"replica","hot_standby":"on","max_wal_senders":10,"max_replication_slots":10,"wal_keep_size":"512MB"}}}
/service/pg-cluster/initialize
7527206046275954701
/service/pg-cluster/leader
node1
/service/pg-cluster/members/node1
{"conn_url":"postgres://127.0.0.1:5432/postgres","api_url":"http://127.0.0.1:8008/patroni","state":"running","role":"primary","version":"4.0.4","xlog_location":150995304,"timeline":1}
/service/pg-cluster/members/node2
{"conn_url":"postgres://127.0.0.1:5433/postgres","api_url":"http://127.0.0.1:8018/patroni","state":"running","role":"replica","version":"4.0.4","xlog_location":150995304,"replication_state":"streaming","timeline":1}
/service/pg-cluster/members/node3
{"conn_url":"postgres://127.0.0.1:5434/postgres","api_url":"http://127.0.0.1:8028/patroni","state":"running","role":"replica","version":"4.0.4","xlog_location":150995304,"replication_state":"streaming","timeline":1}
/service/pg-cluster/status
{"optime":150995304,"slots":{"node2":150995304,"node3":150995304,"node1":150995304},"retain_slots":["node1","node2","node3"]}
/service/pgtest/config
{"ttl":30,"loop_wait":10,"retry_timeout":10,"maximum_lag_on_failover":1048576,"postgresql":{"use_pg_rewind":true,"use_slots":true,"parameters":{"wal_level":"replica","hot_standby":"on","wal_keep_size":"64MB","max_wal_senders":10,"max_replication_slots":10}}}
/service/pgtest/initialize
7527193237175963385
/service/pgtest/status
{"optime":67438232,"slots":{"node2":33554680,"node3":33554680,"node1":67438232},"retain_slots":["node1","node2","node3"]}
# leader 정보만 확인 /service/{cluster name}/leader
root@QEMU-Virtual-Machine:/data# etcdctl get /service/pg-cluster/leader
/service/pg-cluster/leader
node1
# Patroni 가 사용하는 관련 모든 정보 /service/{cluster name}
root@QEMU-Virtual-Machine:/data# etcdctl get /service/pg-cluster --prefix
/service/pg-cluster/config
{"ttl":30,"loop_wait":10,"retry_timeout":10,"maximum_lag_on_failover":1048576,"postgresql":{"use_pg_rewind":true,"parameters":{"wal_level":"replica","hot_standby":"on","max_wal_senders":10,"max_replication_slots":10,"wal_keep_size":"512MB"}}}
/service/pg-cluster/initialize
7527206046275954701
/service/pg-cluster/leader
node1
/service/pg-cluster/members/node1
{"conn_url":"postgres://127.0.0.1:5432/postgres","api_url":"http://127.0.0.1:8008/patroni","state":"running","role":"primary","version":"4.0.4","xlog_location":150995304,"timeline":1}
/service/pg-cluster/members/node2
{"conn_url":"postgres://127.0.0.1:5433/postgres","api_url":"http://127.0.0.1:8018/patroni","state":"running","role":"replica","version":"4.0.4","xlog_location":150995304,"replication_state":"streaming","timeline":1}
/service/pg-cluster/members/node3
{"conn_url":"postgres://127.0.0.1:5434/postgres","api_url":"http://127.0.0.1:8028/patroni","state":"running","role":"replica","version":"4.0.4","xlog_location":150995304,"replication_state":"streaming","timeline":1}
/service/pg-cluster/status
{"optime":150995304,"slots":{"node2":150995304,"node3":150995304,"node1":150995304},"retain_slots":["node1","node2","node3"]}
+------------------------+
| etcd Cluster | <-- 클러스터 상태 관리(leader key, member key)
+-----------+------------+
^
|
Patroni REST API (상태 저장/전파, leader 선출 등)
+-----------+------------+
| Patroni | <-- 각 PostgreSQL 노드에 설치
+-----------+------------+
|
PostgreSQL 인스턴스 (primary, standby)
#by. perplexity
ETCD_VER=v3.6.2
# choose either URL
GOOGLE_URL=https://storage.googleapis.com/etcd
DOWNLOAD_URL=${GOOGLE_URL}
rm -f /tmp/etcd-${ETCD_VER}-linux-arm64.tar.gz
rm -rf /tmp/etcd-download-test && mkdir -p /tmp/etcd-download-test
curl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-arm64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-arm64.tar.gz
tar xzvf /tmp/etcd-${ETCD_VER}-linux-arm64.tar.gz -C /tmp/etcd-download-test --strip-components=1 --no-same-owner
rm -f /tmp/etcd-${ETCD_VER}-linux-arm64.tar.gz
/tmp/etcd-download-test/etcd --version
/tmp/etcd-download-test/etcdctl version
/tmp/etcd-download-test/etcdutl version
# start a local etcd server
# screen 으로 띄우자
sudo cp etcd etcdctl etcdutl /usr/local/bin/
screen -S etcd
etcd -- 실행
# 로그가 실행되면, Screen 에서 빠져나오자.
# write,read to etcd test
/tmp/etcd-download-test/etcdctl --endpoints=localhost:2379 put foo bar
/tmp/etcd-download-test/etcdctl --endpoints=localhost:2379 get foo
# test2
> etcdctl put mykey "this is awesome"
OK
> etcdctl get mykey
mykey
this is awesome
#etcd Cluster 상태 확인
etcdctl --endpoints=127.0.0.1:2379,127.0.0.1:2479,127.0.0.1:2579 endpoint status --write-out=table
#etcdctl 확인
etcdctl --endpoints=127.0.0.1:2379,127.0.0.1:2479,127.0.0.1:2579 endpoint health
127.0.0.1:2479 is healthy: successfully committed proposal: took = 5.062031ms
127.0.0.1:2379 is healthy: successfully committed proposal: took = 4.988364ms
127.0.0.1:2579 is healthy: successfully committed proposal: took = 5.038531ms
반드시 screen 으로 하는 것으로 하는 것을 추천 (가급적이면 서비스로 구성하여 로그들 확인)
# primary 로 정상적으로 로그가 발생하면 나머지 2,3 번 replica 들을 실행하는 것을 추천
root@QEMU-Virtual-Machine:/tmp/etcd-download-test# sudo -u postgres patroni /etc/patroni1.yml
root@QEMU-Virtual-Machine:/tmp/etcd-download-test# sudo -u postgres patroni /etc/patroni2.yml
root@QEMU-Virtual-Machine:/tmp/etcd-download-test# sudo -u postgres patroni /etc/patroni3.yml
#정상적으로 올라왔는지 확인하는 명령어
root@QEMU-Virtual-Machine:/data# patronictl -c /etc/patroni1.yml list
+ Cluster: pg-cluster (7527206046275954701) ----+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+--------+----------------+---------+-----------+----+-----------+
| node1 | 127.0.0.1:5432 | Leader | running | 1 | |
| node2 | 127.0.0.1:5433 | Replica | streaming | 1 | 0 |
| node3 | 127.0.0.1:5434 | Replica | streaming | 1 | 0 |
+--------+----------------+---------+-----------+----+-----------+
정상적으로 실행된 로그들
root@QEMU-Virtual-Machine:/etc/systemd/system# sudo -u postgres patroni /etc/patroni1.yml
2025-07-15 15:34:06,108 INFO: Selected new etcd server http://127.0.0.1:2579
2025-07-15 15:34:06,152 INFO: No PostgreSQL configuration items changed, nothing to reload.
2025-07-15 15:34:06,195 INFO: Lock owner: None; I am node1
2025-07-15 15:34:06,281 INFO: trying to bootstrap a new cluster
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".
Data page checksums are enabled.
creating directory /data/pg1 ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... Asia/Seoul
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
Success. You can now start the database server using:
/usr/lib/postgresql/17/bin/pg_ctl -D /data/pg1 -l logfile start
2025-07-15 15:34:06.872 KST [36610] LOG: starting PostgreSQL 17.5 (Ubuntu 17.5-0ubuntu0.25.04.1) on aarch64-unknown-linux-gnu, compiled by gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0, 64-bit
2025-07-15 15:34:06.872 KST [36610] LOG: listening on IPv4 address "127.0.0.1", port 5433
2025-07-15 15:34:06.873 KST [36610] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5433"
2025-07-15 15:34:06.876 KST [36613] LOG: database system was shut down at 2025-07-15 15:34:06 KST
2025-07-15 15:34:06,880 INFO: postmaster pid=36610
2025-07-15 15:34:06.880 KST [36610] LOG: database system is ready to accept connections
localhost:5433 - accepting connections
localhost:5433 - accepting connections
2025-07-15 15:34:06,895 INFO: establishing a new patroni heartbeat connection to postgres
2025-07-15 15:34:06,942 INFO: running post_bootstrap
2025-07-15 15:34:06,950 WARNING: Could not activate Linux watchdog device: Can't open watchdog device: [Errno 2] No such file or directory: '/dev/watchdog'
2025-07-15 15:34:07.096 KST [36611] LOG: checkpoint starting: force wait
2025-07-15 15:34:07,125 INFO: initialized a new cluster
2025-07-15 15:34:07.541 KST [36611] LOG: checkpoint complete: wrote 7 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.408 s, sync=0.008 s, total=0.445 s; sync files=6, longest=0.005 s, average=0.002 s; distance=8984 kB, estimate=8984 kB; lsn=0/2000080, redo lsn=0/2000028
2025-07-15 15:34:07.541 KST [36611] LOG: checkpoint starting: force wait
2025-07-15 15:34:07.545 KST [36611] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.005 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=8085 kB; lsn=0/2000150, redo lsn=0/20000F8
#Replica node log들
root@QEMU-Virtual-Machine:/tmp/etcd-download-test# sudo -u postgres patroni /etc/patroni3.yml
2025-07-15 16:53:53,208 INFO: Selected new etcd server http://127.0.0.1:2379
2025-07-15 16:53:53,253 INFO: No PostgreSQL configuration items changed, nothing to reload.
2025-07-15 16:53:53,296 INFO: Lock owner: node1; I am node3
2025-07-15 16:53:53,339 INFO: trying to bootstrap from leader 'node1'
2025-07-15 16:53:53,548 INFO: replica has been created using basebackup
2025-07-15 16:53:53,549 INFO: bootstrapped from leader 'node1'
2025-07-15 16:53:53,741 INFO: postmaster pid=39826
localhost:5434 - no response
2025-07-15 16:53:53.772 KST [39826] LOG: starting PostgreSQL 17.5 (Ubuntu 17.5-0ubuntu0.25.04.1) on aarch64-unknown-linux-gnu, compiled by gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0, 64-bit
2025-07-15 16:53:53.772 KST [39826] LOG: listening on IPv4 address "127.0.0.1", port 5434
2025-07-15 16:53:53.773 KST [39826] LOG: listening on Unix socket "/tmp/.s.PGSQL.5434"
2025-07-15 16:53:53.775 KST [39830] LOG: database system was interrupted; last known up at 2025-07-15 16:53:53 KST
2025-07-15 16:53:53.857 KST [39830] LOG: starting backup recovery with redo LSN 0/8000028, checkpoint LSN 0/8000080, on timeline ID 1
2025-07-15 16:53:53.858 KST [39830] LOG: entering standby mode
2025-07-15 16:53:53.860 KST [39830] LOG: redo starts at 0/8000028
2025-07-15 16:53:53.861 KST [39830] LOG: completed backup recovery with redo LSN 0/8000028 and end LSN 0/8000120
2025-07-15 16:53:53.861 KST [39830] LOG: consistent recovery state reached at 0/8000120
2025-07-15 16:53:53.861 KST [39826] LOG: database system is ready to accept read-only connections
2025-07-15 16:53:53.867 KST [39831] LOG: started streaming WAL from primary at 0/9000000 on timeline 1
localhost:5434 - accepting connections
localhost:5434 - accepting connections
2025-07-15 16:53:54,794 INFO: Lock owner: node1; I am node3
2025-07-15 16:53:54,794 INFO: establishing a new patroni heartbeat connection to postgres
2025-07-15 16:53:54,867 INFO: no action. I am (node3), a secondary, and following a leader (node1)
2025-07-15 16:53:59,529 INFO: no action. I am (node3), a secondary, and following a leader (node1)
2025-07-15 16:54:10,074 INFO: no action. I am (node3), a secondary, and following a leader (node1)
2025-07-15 16:54:20,030 INFO: no action. I am (node3), a secondary, and following a leader (node1)
2025-07-15 16:54:30,074 INFO: no action. I am (node3), a secondary, and following a leader (node1)
Patroni Trouble shooting
Patroni 구성하면서 발생한 문제들에 대해 정리
자료가 많지 않아, 구성 중에 설정값 누락도 많이 있었으며, 권한에 대한 이슈도 존재한 것을 작성
Case 1.
설정 중, etcd 설정 정보를 제대로 읽지 못하고, "v2" 에러가 발생 시, 설정값을 변경이 필요.
root@QEMU-Virtual-Machine:/etc/systemd/system# patroni /etc/patroni1.yml
2025-07-15 15:32:49,636 ERROR: Failed to get list of machines from http://127.0.0.1:2479/v2: EtcdException('Bad response : 404 page not found\n')
2025-07-15 15:32:49,637 ERROR: Failed to get list of machines from http://127.0.0.1:2379/v2: EtcdException('Bad response : 404 page not found\n')
2025-07-15 15:32:49,638 ERROR: Failed to get list of machines from http://127.0.0.1:2579/v2: EtcdException('Bad response : 404 page not found\n')
2025-07-15 15:32:49,638 INFO: waiting on etcd
2025-07-15 15:32:54,641 ERROR: Failed to get list of machines from http://127.0.0.1:2479/v2: EtcdException('Bad response : 404 page not found\n')
2025-07-15 15:32:54,645 ERROR: Failed to get list of machines from http://127.0.0.1:2379/v2: EtcdException('Bad response : 404 page not found\n')
2025-07-15 15:32:54,649 ERROR: Failed to get list of machines from http://127.0.0.1:2579/v2: EtcdException('Bad response : 404 page not found\n')
기존 가이드들 보면, 다음과 같이 `etcd` 라고 명칭하지만 이것을 `etcd3` 로 변경하면 해결
root@QEMU-Virtual-Machine:/data# cat /etc/patroni1.yml
scope: pg-cluster
name: node1
restapi:
listen: 0.0.0.0:8008
connect_address: 127.0.0.1:8008
etcd3: #<----- 일반 문서에는 etcd: 로 되어 있음
hosts: 127.0.0.1:2379,127.0.0.1:2479,127.0.0.1:2579
Case 2.
root 에서 patroni 실행 시 정상 실행이 안되는 경우
postgres 계정으로 전환하여 진행
실행 명령어 및 로그 내용
root@QEMU-Virtual-Machine:/tmp/etcd-download-test# patroni /etc/patroni3.yml
2025-07-15 01:57:32,711 INFO: Lock owner: None; I am node3
--> 계속 이러한 로그만 나오고 정상적으로 실행되는 어떠한 내용도 확인이 되지 않음
# 아래 처럼 postgres 계정으로 서비스 시작 진행
root@QEMU-Virtual-Machine:/tmp/etcd-download-test# sudo -u postgres patroni /etc/patroni3.yml
Case 3.
Patroni node 3번이 실행 도중 다음과 같은 에러가 발생하며 문제를 발생
2025-07-15 16:31:47,698 INFO: doing crash recovery in a single user mode
2025-07-15 16:31:47,713 ERROR: Error when reading postmaster.opts
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/patroni/postgresql/rewind.py", line 545, in read_postmaster_opts
with open(os.path.join(self._postgresql.data_dir, 'postmaster.opts')) as f:
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/data/pg3/postmaster.opts'
2025-07-15 16:31:47,719 ERROR: Crash recovery finished with code=1
2025-07-15 16:31:47,719 INFO: stdout=
2025-07-15 16:31:47,719 INFO: stderr=2025-07-15 16:31:47.718 KST [39181] FATAL: data directory "/data/pg3" has invalid permissions
2025-07-15 16:31:47.718 KST [39181] DETAIL: Permissions should be u=rwx (0700) or u=rwx,g=rx (0750).
log 상에서 다음과 같은 에러가 보인다면, 해당 secondary node 를 재 구축 진행
운영에서는 최신 백업으로 복구 후에 진행하는 것이 시간 단축에 도움
초기 과정에서는 해당 노드를 삭제하고 다시 구성하는 것이 빠르고, 깔끔한 방법
## Error log (replica node)
2025-07-15 16:50:13.401 KST [39717] FATAL: could not receive data from WAL stream: ERROR: requested starting point 0/6000000 is ahead of the WAL flush position of this server 0/5050660
## 이 오류 메시지는 PostgreSQL 스트리밍 복제가 시작될 때 레플리카 노드가 요청한 WAL 시점이 프라이머리 노드가 아직 생성하지 않은 LSN(Log Sequence Number)에 있다는 것을 의미(제대로 복제 데이터를 가져오지 못한 현상)
################################################################################
## 삭제 후 재구축
# 레플리카 노드에서 실행 (중요: primary가 정상 상태여야 함)
# patroni 를 강제 중지 또는
sudo systemctl stop patroni3 # 프로세스 정지
# 데이터 디렉토리 정리 (중요: 실수로 primary에서 하지 않도록 주의)
rm -rf /data/pg3/*
# 또는 수동으로 초기화된 basebackup
sudo -u postgres pg_basebackup -h <primary_ip> -D /data/pg3 -U replicator -P -R
# 퍼미션 재확인
chown -R postgres:postgres /data/pg3
chmod 700 /data/pg3
# Patroni 재시작
sudo systemctl start patroni 또는
root@QEMU-Virtual-Machine:/tmp/etcd-download-test# sudo -u postgres patroni /etc/patroni3.yml
vi /data/pg1/postgresql.conf
# config 파일 위치
data_directory = '/data/pg1/data'
hba_file = '/data/pg1/pg_hba.conf'
ident_file = '/data/pg1/pg_ident.conf'
#logging 및 기본 설정 정보 수정
logging_collector = on
log_directory = '/data/pg1/log'
log_filename = 'postgresql-%Y-%m-%d.log'
log_rotation_age = 1d
log_rotation_size = 0
하나의 Transaction 에서 파티션 테이블에 여러개인 파티션을 한번에 Query 하는 경우, 하나의 쿼리에서 Lock 이 조회한 파티션 수만큼 발생 가능성이 존재(유의)
pg_catalog.pg_locks view 를 통해 object lock 정보를 확인이 가능
Row level lock
Tuple 에 대한 Lock
MVCC 기반으로 작동하기 때문에 write 충돌 방지에만 사용
shared memory 에 저장되는 것이 아닌 Page 내부의 Touple version 에 저장
메모리에 저장되는 것이 아니기 때문에, Lock 개수에는 영향을 받지 않음
Lock 을 대기하는 프로세스를 대기 큐에 넣을 수 없기 때문에 모니터링이 힘듦
Memory level lock
PostgreSQL에서 말하는 Memory-level lock은 공유 메모리(shared memory) 내에서 이루어지는 경량 잠금(Lightweight Lock, LWLock) 또는 스핀락(spinlock) 계열의 잠금
서버 내부 동기화를 위한 메모리 구조 보호용
Memory level lock 종류
종류
설명
Spinlock
- CPU 단위의 아주 빠른 락 - 매우 짧은 작업 보호 (획득 시간이 매우 짧고 여러 프로세스가 별도의 메모리 영역을 변경하지 못하도록 보호 - 루프 방식으로 돌면서 Lock 획득) - 사용 예 > 카운터 변수 증가 > flags 설정 > WALWriteLock 이전 준비
LWLock (Lightweight Lock)
- PostgreSQL 공유 메모리 내 구조체 보호용 - 읽기 모드(공유) / 쓰기 모드(배타) 지원 - 사용 예 > WALWriteLock : WAL 버퍼에 기록할 때 > BufMappingLock : shared buffer에 페이지 맵핑 시 > CLogControlLock : 트랜잭션 상태 제어 >ProcArrayLock : 트랜잭션 및 백엔드 배열 정보 제어 - PostgreSQL 내부에는 수백 개의 LWLock이 존재
Buffer Pin Lock
- 버퍼를 변경하기 위해 프로세스가 Buffer pin lock을 획득 - 특정 데이터 페이지가 Shared Buffer 에서 제거되지 않도록 보호 - 데이터를 참조하는 동안 해당 페이지가 교체(Evict) 되는 것을 방지 - 페이지 단위로 관리
WAL Buffer Lock
- WAL(Write-Ahead Logging) 메커니즘에서 WAL Buffer를 보호하고 동시성을 제어하기 위해 사용 - WAL Record 생성 → WALInsertLock 획득 요청 → Buffer 공간 예약 및 저장(필요 시) WALBufMappingLock 획득 후 WAL Page 확장 → WALInsertLock 해제 → (커밋 등 조건 시) WALWriteLock 획득 후 디스크로 Write - WALInsertLock :WAL Buffer에 WAL Record를 저장할 때 획득하는 락(default 8) - WALBufMappingLock : WAL Buffer 내에 새로운 WAL Page가 필요할 때(즉, 공간 확장이 필요할 때) 획득하는 락 - WALWriteLock :WAL Buffer의 내용을 디스크로 플러시(쓰기)할 때 사용하는 락
Lock Tranche / Named Locks
- LWLock 그룹화 및 모듈화
Named LWLocks
- 확장 기능이나 커널 모듈에서도 사용 가능
-- 현재 프로세스의 blocking 정보 (간접 확인 가능)
-- 메모리 수준 락은 pg_locks 에 안 나옴
-- row/table-level lock만 기록됨
SELECT * FROM pg_blocking_pids(<pid>);
Advisory Lock (사용자 정의 Lock)
Transaction 외부에서도 사용할 수 있는 Application level 의 lock
Table이나 row와 직접 연결되지 않음
-- 세션 단위 Advisory Lock 획득
SELECT pg_advisory_lock(12345);
-- 세션 단위 Lock 해제
SELECT pg_advisory_unlock(12345);
#현재 Lock 확인: pg_locks 뷰와 pg_stat_activity를 조인하여 어떤 세션이 어떤 Lock을 보유/대기 중인지 확인
SELECT a.pid, a.usename, a.datname, a.state, a.query, l.locktype, l.mode, l.granted
FROM pg_locks l
JOIN pg_stat_activity a ON l.pid = a.pid
WHERE a.state != 'idle';
주요 Lock 종류
Access Share Lock
SELECT 쿼리 실행 시 걸리는 기본 락. 다른 읽기 작업과 충돌하지 않음.
Row Share Lock
외래키 제약조건이 있는 테이블에 INSERT, UPDATE 등 수행 시. 이름과 달리 테이블 수준의 락.
Row Exclusive Lock
INSERT, UPDATE, DELETE 실행 시. 읽기 쿼리와는 충돌하지 않음.
Share Update Exclusive
VACUUM, ANALYZE, CREATE INDEX CONCURRENTLY 등 유지보수 명령 실행 시.
Share Lock
테이블을 공유 모드로 잠금. 읽기는 가능하지만, 동시 업데이트는 불가.
Share Row Exclusive Lock
CREATE TRIGGER, 일부 ALTER 명령 실행 시.
Exclusive Lock
Materialized View 갱신 등에서 사용.
Access Exclusive Lock
DROP TABLE, TRUNCATE 등 DDL 명령에서 사용. 모든 락과 충돌하는 가장 강력한 락.
-- waiting_pid, waiting_query 대기 중인 쿼리 및 세션 정보
-- holder_pid, holder_query 해당 잠금을 보유 중인 쿼리 및 세션
-- locked_relation 충돌 중인 테이블 이름
-- waiting_mode, holder_mode 잠금 모드 (RowExclusiveLock 등)
-- kill_holder_query 해당 holder 세션을 강제 종료하는 SQL 문
WITH lock_conflicts AS (
SELECT
w.pid AS waiting_pid,
w.query AS waiting_query,
w.usename AS waiting_user,
w.application_name AS waiting_app,
w.state AS waiting_state,
w.query_start AS waiting_query_start,
l1.relation::regclass AS locked_relation,
l1.mode AS waiting_mode,
h.pid AS holder_pid,
h.query AS holder_query,
h.usename AS holder_user,
h.application_name AS holder_app,
h.state AS holder_state,
h.query_start AS holder_query_start,
l2.mode AS holder_mode,
-- Kill query 자동 생성
'SELECT pg_terminate_backend(' || h.pid || ');' AS kill_holder_query
FROM
pg_locks l1
JOIN pg_stat_activity w ON l1.pid = w.pid
JOIN pg_locks l2 ON l1.locktype = l2.locktype
AND l1.database IS NOT DISTINCT FROM l2.database
AND l1.relation IS NOT DISTINCT FROM l2.relation
AND l1.page IS NOT DISTINCT FROM l2.page
AND l1.tuple IS NOT DISTINCT FROM l2.tuple
AND l1.virtualxid IS NOT DISTINCT FROM l2.virtualxid
AND l1.transactionid IS NOT DISTINCT FROM l2.transactionid
AND l1.classid IS NOT DISTINCT FROM l2.classid
AND l1.objid IS NOT DISTINCT FROM l2.objid
AND l1.objsubid IS NOT DISTINCT FROM l2.objsubid
AND l1.pid <> l2.pid
JOIN pg_stat_activity h ON l2.pid = h.pid
WHERE NOT l1.granted AND l2.granted
)
SELECT * FROM lock_conflicts
ORDER BY waiting_query_start;
Multi Transactions
Shared lock mode는 서로 호환 가능한 lock mode 로, 요청할 경우 Multi transaction을 허용
Multixact ID (multi transaction id)를 별도로 적용하여 shared lock상태를 저장
Tuple 은 어느 시점에 Transaction ID와 Multixact ID가 동일한 값을 가질 수 있음
Multi transaction 상태는 pgrowlocks extension 을 통해서도 확인 가능
pgrowlocks를 조회하면 lock을 획득한 process, lock mode, tuple 정보 및 multi transaction 상태 등을 확인 가능
현재 상태만 확인이 가능하고, 종료되면 확인이 불가능
Tuple lock waiting
Exclusive lock으로 인해 동일 모드로 lock을 요청하는 다른 Transaction 은 락을 대기할 수 밖에 없음.
pg_locks View를 통해 확인이 가능
# pg_stat_activity : 현재 데이터베이스의 모든 세션 상태(쿼리, 접속자, 실행 시간 등)를 보여주는 뷰
# pg_locks : 현재 데이터베이스 서버의 모든 활성 세션이 보유하거나 대기 중인 Lock 정보를 보여주는 시스템 뷰
# 어떤 세션이 어떤 Lock을 보유하거나 대기 중인지, 쿼리 내용과 Lock 보유 시간까지 한 번에 확인
# datname: 데이터베이스명
# locked_relation: 잠금 대상(테이블명 등)
# mode: Lock 종류
# granted: Lock 보유 여부(true/false)
# query: 실행 중인 쿼리
# lock_age: Lock 보유 시간(경과 시간)
# pid: 프로세스 ID
SELECT
a.datname,
l.relation::regclass AS locked_relation,
l.transactionid,
l.mode,
l.granted,
a.usename,
a.query,
a.query_start,
age(now(), a.query_start) AS lock_age,
a.pid
FROM pg_stat_activity a
JOIN pg_locks l ON l.pid = a.pid
ORDER BY a.query_start;
# blocking session
# Lock으로 인해 대기 중인 세션과 이를 블로킹하는 세션을 한 번에 확인
SELECT
COALESCE(blockingl.relation::regclass::text, blockingl.locktype) AS locked_item,
now() - blockeda.query_start AS waiting_duration,
blockeda.pid AS blocked_pid,
blockeda.query AS blocked_query,
blockedl.mode AS blocked_mode,
blockinga.pid AS blocking_pid,
blockinga.query AS blocking_query,
blockingl.mode AS blocking_mode
FROM pg_catalog.pg_locks blockedl
JOIN pg_stat_activity blockeda ON blockedl.pid = blockeda.pid
JOIN pg_catalog.pg_locks blockingl
ON (
(blockingl.transactionid = blockedl.transactionid)
OR (blockingl.relation = blockedl.relation AND blockingl.locktype = blockedl.locktype)
) AND blockedl.pid != blockingl.pid
JOIN pg_stat_activity blockinga ON blockingl.pid = blockinga.pid
AND blockinga.datid = blockeda.datid
WHERE NOT blockedl.granted
AND blockinga.datname = current_database();
# https://blog.ex-em.com/1928
SELECT current_timestamp AS db_time,
waiter_pid,
w_info.usename AS waiter_user ,
w_info.query AS waiter_query ,
w_info.query_start AS waiter_query_start ,
case
when EXTRACT(EPOCH from current_timestamp - w_info.query_start ) < 0 then 0
else EXTRACT(EPOCH from current_timestamp - w_info.query_start )
end as waiter_elapsed_time,
holder_pid ,
h_info.usename AS holder_user ,
h_info.query AS holder_query ,
h_info.query_start AS holder_query_start,
case
when EXTRACT(EPOCH from current_timestamp - h_info.query_start ) < 0 then 0
else EXTRACT(EPOCH from current_timestamp - h_info.query_start )
end as holder_elapsed_time
FROM (
SELECT snaptime,
locktype,
waiter_pid,
w_cnt,
h_cnt ,
CASE
WHEN h_cnt=Max(h_cnt) OVER(partition BY waiter_pid) THEN holder_pid
END AS holder_pid
FROM (
SELECT current_timestamp AS snaptime,
blocked_locks.locktype AS locktype,
blocked_locks.pid AS waiter_pid,
count(*) over(partition BY blocked_locks.pid) AS w_cnt,
count(*) over(partition BY blocking_locks.pid) h_cnt,
blocking_locks.pid AS holder_pid
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT
FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT
FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT
FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT
FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT
FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT
FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT
FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT
FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT
FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
WHERE NOT blocked_locks.granted ) t ) t2
JOIN pg_catalog.pg_stat_activity w_info
ON w_info.pid = t2.waiter_pid
JOIN pg_catalog.pg_stat_activity h_info
ON h_info.pid = t2.holder_pid
WHERE holder_pid IS NOT null;
db_time |waiter_pid|waiter_user|waiter_query |waiter_query_start |waiter_elapsed_time|holder_pid|holder_user|holder_query |holder_query_start |holder_elapsed_time|
-----------------------------+----------+-----------+----------------------------------------------------+-----------------------------+-------------------+----------+-----------+----------------------------------------------------+-----------------------------+-------------------+
2024-04-30 12:08:49.078 +0900| 2914359|postgresdt |update lock_test set c2 = 'row_update' where c1 = 1;|2024-04-30 12:07:55.777 +0900| 53.301024| 2914369|postgresdt |update lock_test set c2 = 'row_update' where c1 = 1;|2024-04-30 12:07:50.784 +0900| 58.294596|
2024-04-30 12:08:49.078 +0900| 2914369|postgresdt |update lock_test set c2 = 'row_update' where c1 = 1;|2024-04-30 12:07:50.784 +0900| 58.294596| 2914377|postgresdt |update lock_test set c2 = 'row_update' where c1 = 1;|2024-04-30 12:07:45.711 +0900| 63.366759|
Lock_timeout
lock_timeout은 PostgreSQL에서 쿼리가 Table, Index , tuple 등 데이터베이스 객체의 잠금(Lock)을 획득하기 위해 대기하는 최대 시간(밀리초 단위)을 설정하는 parameter
설정 단위: 세션(Session) 또는 트랜잭션(Transaction) 단위로 설정 가능
Default: 0 (disable, 무한정 대기)
적용 대상: 명시적/암시적 Lock 요청(예: DML, DDL, LOCK TABLE 등)
동작: 지정한 시간 내에 Lock을 획득하지 못하면 쿼리가 취소되고, canceling statement due to lock timeout 오류가 발생
statement_timeout과 차이: statement_timeout은 쿼리 전체 실행 시간을 제한하지만, lock_timeout은 Lock 획득 대기 시간만 제한 -> 둘 다 설정되어 있으면, 먼저 도달한 타임아웃이 우선 적용
# ms 단위
set lock_timeout = 5000;
set lock_timeout = '5s';
ALTER TABLE mytable ADD COLUMN newcol int;
Deadlock
PostgreSQL은 데드락 상황을 자동으로 감지하고, 관련 트랜잭션 중 하나를 강제로 중단(ROLLBACK)시켜 교착상태를 해소.
어떤 트랜잭션이 중단될지는 예측할 수 없음
deadlock_timeout parameter
Deadlock 상황을 일정한 주기로 체크하여 감시하는 parameter
Default : 1000ms
Deadlock 방지 및 해결 전략
락 획득 순서 일관성 유지: 모든 트랜잭션이 동일한 순서로 Lock을 획득하도록 설계하면 데드락 발생 가능성을 크게 줄일 수 있음
작은 배치 크기: 한 번에 처리하는 데이터의 범위를 줄여 Lock 충돌 가능성을 낮춤
트랜잭션 분리: DDL(DROP, TRUNCATE 등) 작업과 DML(INSERT, UPDATE 등)을 분리하여 실행
fsync가 on이면, PostgreSQL서버는 fsync()시스템콜을 통해서 변경분을 디스크에 물리적으로 바로 쓴다. 이는 데이터베이스클러스터가 OS나 하드웨어 장애시 consistent한 상태로 복구가 가능함을 보장한다.
fsync를 off한다면, OS가 알아서 메모리에 있는 것을 디스크로 내려쓰게 된다. 언제 무엇이 디스크에 쓰여졌는지 아닌지 알수 없다. 그러므로 성능상 이득을 볼수는 있겠지만, 전원장애나 system crash로가 발생했을때 복구가 불가능할수 있다. 만약 전체 데이터베이스를 쉽게 재생성할수 있는 경우에만 off하도록 한다. 예를들어 백업본으로부터 새로운 데이터베이스 클러스트를 초기 구축하는 경우, 버리고 재생성할 데이터베이스의 데이터 처리, 자주 재생성되는 read-only 데이터베이스 복제본으로 failover에 사용되지 않는 데이터베이스인 경우 사용할 수 있다. 고성능의 하드웨어 장비라고해서 fsync를 끄는 것은 올바르지 않다.
성능을 위해서라면 synchronous_commit을 off하는 것만으로 충분할 것이다.
만약 off하기로 했다면, full_page_writes도 off하는 것을 고려하도록 한다.
WAL 를 사용하여, PITR 지원이 가능
WAL 를 재생하여 복구가 가능
Asynchronous Commit
DB Crash 발생 시, 가장 최근의 Transaction은 유실 가능성 존재(Risk)
다만, transaction 을 더 빠르게 처리가 가능
Default 는 synchronous (동기)
Client에 transaction result를 return 하기 전에, WAL 의 record가 Disk 에 write될 때까지 기다렸다가 ack 처리. -> commit 된 transaction 에 대한 무결성 보장을 의미
다만, 이것에 대한 비용은 발생
이러한 비용을 조금이라도 줄이기 위한 방법으로, disk flush 응답을 받기 전에 WAL buffer에서만 작성 후 ack 하는 방식을 Asynchronous Commit -> Transaction 처리량 향상
synchronous_commit Parameter 를 이용하여 수정이 가능하며, transaction 마다 설정이 가능
off : 클라이언트에 바로 transaction commit을 보냄. 하지만 실제로 트랜잭션이 안전하게 반영(WAL record가 WAL file에 쓰여짐) 되기까지 딜레이가 존재함. 서버 crash났을때 트랜잭션 손실될 수 있음. (최대 delay는 wal_writer_delay(200ms)의 3배). 하지만 fsync와는 달리 off로 한다고 해서 db 일관성에 문제가 되지는 않음. 최근 커밋되어야하는 트랜잭션이 손실될 수는 있으나 database 상태는 이 트랜잭션들이 정상적으로 롤백된 것과 같아서 일관성에 문제 없음.
DROP TABLE 은 synchronous_commit 와 상관없이 동기식으로 처리 : 일관성을 보장하기 위함.
PREPARE TRANSACTION 와 같은 2-phase commit 의 경우도 동기식으로 처리
wal_writer_delay ms 마다 WAL Writer 가 Disk 로 flush 진행
최대 유실 시간은 wal_writer_delay milliseconds * 3 의 risk 가 존재
busy periods(바쁜기간?)에 WAL writer 가 한 번에 Disk 로 flush 를 진행하는 것을 선호로 인해 발생 (정확한 의미는 모르겠습니다. 왜 wal_writer_delay 의 최대 3배의 시간으로 명시했는지.
commit_delay parameter 와 유사하지만, commit_delay 는 synchronous commit 의 방법에 속함
Asynchronous commit 을 설정하면, commit_delay 는 무시
commit_delay 는 transaction 이 WAL disk flush 지연을 유발
checkpoint 이후 각 Disk page를 수정(dml로 인해) 하는 도중에 해당 페이지의 전체 내용을 WAL 에 기록
os crash 발생 시, 진행 중인 페이지 쓰기가 부분적으로만 완료 되어 디스크 상의 페이지에 과거 데이터와 새 데이터가 공존하기 때문에, 복구 진행 시 올바른 복구가 보장되지만 WAL 에 기록하는 데이터량은 증가될 수 밖에 없음
checkpoint 간격을 늘릴 수 있음.
off 하면, 운영 속도가 향상되지만, 시스템 crash 발생 시, 손상된 데이터가 복구 불가능 또는 데이 손사이 발생 가능성 존재
fsync 를 해제했을 때와 유사
PITR 진행 시, WAL 아카이빙 사용에는 영향을 미치지 않음
postgresql.conf 파일 또는 command 로 설정 가능
checkpoint_timeout sec 마다 또는 max_wal_size 가 초과될 경우 checkpoint 발생
default : 5 min (300 sec) / 1 Gb
WAL 에 작성이 안된 경우 checkpoint_timeout 이 되어도 checkpoint 가 발생하지 않음
물론 CHECKPOINT 명령어로 강제 실행은 가능
만약 해당 변수 값들을 줄이며, 더 자주 checkpoint 발생 : DB crash 후 빠른 복구는 가능하지만 Disk I/O 비용 발생
full_page_writes 가 설정된 경우 (default 설정) , check point 발생 후 데이터 페이지 수정이 발생하는 경우 전체 페이지가 기록 -> 더 많은 Disk I/O 발생(시간을 짧게 가져갈수록 disk I/O는 더욱더 증가)
checkpoint_timeout 시간을 충분히 여유있게 가져가는 것을 책에서는 권장하며, checkpoint_warning 로 checkpoint 에 대해 sanity check (온전성 검사?)가 가능
당연하겠지만, checkpoint timeout 보다 더 잦은 checkpoinrt 가 발생하면 max_wal_size 증가 하라는 메시지가 log 에 남음
XLogInsertRecord
Shared memory 내 WAR buffer 에 new record 를 배치하는데 사용
만약 새로운 데이터가 insert 될 공간이 없으면, kernel cache 로 채워진 WAL buffer 일부를 move 시킴 -> 이것은 exclusive lock (대상 data page) 을 유발하기 때문에, 성능에 좋지 않음
일반적으로 XLogFlush 에 의해 WAL buffer 를 WAL file 에 flush 되어야 함.
wal_buffers 를 이용하여 WAL bufferpool 수를 조정 가능하며, full_page_writes 가 설정되어 있고, 시스템이 바쁜경우 wal_buffers 수를 늘려주는 것을 권장
XLogFlush
LogWrite 의 issue_xlog_fsync 의 호출에 의해 XLogFlush 가 WAL buffer 의 내용을 disk 로 flush
commit_delay
commit_delay (ms)는 XLogFlush 내에서 lock 을 획득 하는동안, group commit 을 기다리는 시간(지연시간) parameter
목적은 동시에 commit 되는 transaction 전체에 걸쳐 flush 작업의 비용을 분할할 수 있는 것(다만 transaction 시간은 증가)
commit_delay 가 발생하면, 대기하는 commit record들은 WAL Buffer 에 추가 하여 정합성을 지키는 효과 -> Transaction 대기 시간을 최소화
0 : ( default)그룹 커밋의 효과가 중요
1 : 동시에 commit 이 발생하여 transaction 처리?
2 : 처리량이 commit 속도에 따라 제한 되는 경우 도움 ?
wal_debug 를 활성화 하면, XLogInsertRecord, XLogFlush 의 call 횟수를 확인할 수 있음.
WAL 데이터를 Disk 에 Writer 하는 함수는 XLogWrite and issue_xlog_fsync 존재
WAL 데이터를 동기화하는 데 소요되는 시간은, pg_stat_wal 내의 wal_write_time and wal_sync_time 에 기록
wal_sync_method 가 open_sync 또는 open_datasync 이면, XLogWrite는 WAL 데이터를 Disk 로 flush 하고 데이터 정합성을 보장하고, issue_xlog_fsync 는 어떠한 작업도 하지 않음
wal_sync_method 가 fdatasync , fsync , 또는 fsync_writethrough 가 되면, write opertaion이 WAL buffer 를 kernal cache로 이동하고 issue_xlog_fsync 는 kernal cache 내용을 Disk로 동기화 진행
XLogWrite Write 및 issue_xlog_fsync 가 WAL 데이터를 disk 로 동기화하는 횟수가, pg_stat_wal 에서 wal_write 및 wal_sync 값으로 저장
WAL Internal
WAL 는 rotation 하기 때문에, 관리자가 별도로 disk 관련하여 신경쓰지 않아도 됨
LSN 으로 어느 WAL 파일에 작성해야 하는지 (마지막 지점) 확인
WAL 파일은 Data directory 아래 pg_wal directory 에 segment file 로 저장되며, 16mb
