1. File-based Log Shipping Replication
File-based Log Shipping Replication 설정 확인
PostgreSQL 프로세스조회를 통해서 file-based Log Shipping 설정이 되었는지 확인할 수 있습니다. Main Server에서는 archiver 프로세스가 작동하며, Standby Server에서는 Main Server에서 전송하는 WAL 파일을 대기하는 프로세스가 작동합니다.
Main Server 프로세스
Main Server가 Standby Server에 000000010000000000000014 WAL 파일을 전송했다는 것을 의미합니다.
Standby Server 프로세스
Standby Server는 Main Server에 000000010000000000000015 WAL 파일을 전송받기를 대기하는 상태를 의미합니다. 다른 표시로 프로세스가 "postgres: startup recovering 000000010000000000000015"와 같이 조회되는 경우 recovering이라고 표시되지만, 000000010000000000000015 WAL 파일을 대기하고 있는 상태를 말합니다. 즉, Standby Server에서 waiting과 recovering의 의미는 크게 중요 하지 않으며, 뒤에 나열된 WAL 파일을 수신하기 위해 대기 중임을 의미합니다.
File-based Log Shipping Replication 동기화 확인
File-based Log Shipping은 WAL 파일이 OS Level에서 scp 또는 cp 명령등으로 전달되기 때문에 Catalog를 통해 동기화 여부를 확인할 수 없습니다. 따라서, 프로세스 작동여부와 Main Server와 Standby Server의 Log를 확인하여 동기화 여부를 판단할 수 있습니다.
Main Server에서 WAL Switch가 발생하면 postgresql.conf에 작성된 archive_command 명령을 통해 Standby Server로 WAL 파일이 전송됩니다.
Standby Server는 Main Server로부터 전달받은 WAL 파일을 Restore 합니다.
Standby Server는 restore_command 명령으로 필요한 WAL 파일 Restore를 지속적으로 시도합니다. Main Server로부터 필요한 WAL 파일이 Archive Directory에 전달되면 Restore가 수행된 후 다음 WAL 파일 Restore를 시도합니다. 이와 같은 이유로 Log에
cp: cannot stat …과 같은 내용이 계속 기록됩니다.File-based Log Shipping Replication 실패
Standby Server OFF 등 여러 이유로 인해 Standby Server에서 필요로 하는 WAL 파일이 없을 경우 Replication은 중단되었다고 볼 수 있습니다. 아래 예시에서 Standby Server는 00000001000000000000001A WAL 파일 Restore를 시도하지만, WAL 파일이 없으므로 실패합니다.
Main Server에서 WAL Switch가 발생하여 archive_command 명령을 통해 Standby Server로 WAL 파일(00000001000000000000001B)이 전송됩니다.
Standby Server의 Archive Directory를 보면 00000001000000000000001A WAL 파일이 존재하지 않습니다.
위 예시와 같이 00000001000000000000001A WAL 파일은 존재하지 않고 그다음00000001000000000000001B WAL 파일이 존재할 경우 Standby Server는 00000001000000000000001A WAL 파일의 부재를 알지 못하며 아래와 같이 Standby Server는 00000001000000000000001A WAL 파일 Restore를 시도합니다. 00000001000000000000001A 이후의 WAL 파일이 Main Server에서 전송되지만, Standby Server에서는 00000001000000000000001A WAL 파일 Restore를 하지 못했기 때문에 이후 WAL 파일에 대해 Restore 시도를 하지 않습니다.
Standby Server에서 필요로 하는 WAL 파일이 Main Server의 Archive Directory 등에 보관되어 있다면, 해당 WAL 파일에 대한 Restore가 가능하여 Replication은 유지될 수 있으나, 보관하고 있지 않다면 Replication은 중단(실패)된 것으로 볼 수 있습니다. 이러한 경우 현재까지의 Main Server 상태로 Standby Server를 재구성해야 Replication을 재개할 수 있습니다.
2. Streaming Replication
Streaming Replication 설정 확인
Streaming Replication 설정 확인은 PostgreSQL 프로세스 조회로 확인할 수 있으며, Catalog를 통해서도 확인할 수 있습니다. 프로세스 조회 시
walsender, walreceiver, startup 세 가지 프로세스가 동작하고 있는지 확인하면 됩니다. walsender 프로세스는 Main Server에서 실행되며, walreceiver, startup 프로세스는 Standby Server에서 실행됩니다. Standby Server의 walreceiver 프로세스가 Main Server의 walsender 프로세스가 전달하는 WAL Recode를 수신하는 역할을 담당하므로, walreceiver 프로세스가 동작하고 있지 않다면 Replication 설정은 실패한 것으로 볼 수 있습니다.Main Server 프로세스
Main Server에서 walsender 프로세스가 7번 WAL 파일의 000060 WAL Record를 Standby Server로 전송하는 중이라는 것을 확인할 수 있습니다.
Standby Server 프로세스
Standby Server의 walreceiver는 Main Server의 walsender로부터 7번 WAL 파일의 000060 WAL Record를 전송받고 있음을 확인할 수 있습니다.
Streaming Replication 모니터링
Streaming Replication 설정이 완료되면, 각 Server에서는 아래와 같은 Catalog에서 Replication에 대한 내용을 확인할 수 있습니다.
Main Server에서 확인 가능한 Catalog
Catalog Name | Description |
pg_stat_replication | Replication에 대한 통계 확인 |
pg_replication_slots | Replication Slot에 대한 정보 확인 |
Standby Server에서 확인 가능한 Catalog
Catalog Name | Description |
pg_stat_wal_receiver | WAL Receiver에 대한 통계 확인 |
Catalog에 대한 설명은
PostgreSQL Replication - Catalog에서 확인할 수 있습니다.Catalog 내용을 확인하기에 앞서 Replication Monitoring시 접하는
write, flush, replay 용어에 대해 먼저 알아보겠습니다.구분 | 설명 |
Write | 트랜잭션이 Commit 되면 해당 트랜잭션에 의해 변경된 내용을 순차적으로 WAL Record에 기록합니다. |
Flush | WAL Record에 기록된 변경 내용이 디스크에 안전하게 저장합니다. 이를 통해 내구성을 확보할 수 있으며 서버 장애 발생 시 데이터 손실을 방지할 수 있습니다. 또한, Standby Server로 전송하는 내용을 신뢰할 수 있습니다. |
Replay | Main Server로 부터 WAL Record를 수신하고 생성된 순서대로 Database에 적용하여 Main Server와 동기화시킵니다. |
Main Server Catalog 확인
- WAL Sender 프로세스 PID는 42435이고, replicauser로 접속하였습니다.(replicauser의 oid는 16384입니다.)
- WAL Receiver가 접속한 서버 IP는 10.10.45.231이고, 57364 Port를 통하여 2023-05-17 15:58:22에 접속하였습니다. client_hostname과 backend_xmin은 관련 파라미터가 설정되지 않아 NULL로 표시되었습니다.
- Replication은 현재 Streaming 중이며, 0/2F08ED40까지 WAL Record를 보냈고 Standby Server에서 0/2F08ED40 WAL Record를 적용하고 있습니다.
- Write, Flush, Replay 단계에서 지연은 1초 미만입니다.
- physical_slot 이름으로 생성된 Replication Slot은 physical로 생성되었으며, PID가 42435인 프로세스가 사용하고 있습니다.
- 이 Slot이 유지되기 위해서는 트랜잭션 ID의 xmin이 756부터 필요합니다.
- Standby Server가 필요로 할 수 있는 가장 오래된 WAL Record는 0/2F08ED78 입니다.
본 예시에서 Replication Slot이 Physical Type으로 생성되었기 때문에 plugin, datoid, database, confirmed_flush_lsn, two_phase Column은 NULL로 표시됩니다.
Standby Server Catalog 확인
- WAL Receiver 프로세스의 PID는 24021이고, 현재 Streaming 중입니다.
- 0/2D000000에서 0/2F08ED78까지 WAL 데이터(LSN)는 전송받아 적용하였습니다.
- Replication이 수행할 때 Timeline ID는 1이었고, 현재도 1로 유지되고 있습니다.
- WAL Sender 프로세스의(Main Server) IP는 10.10.45.230이고 5432 Port를 사용하며 physical_slot이름의 Replication Slot을 통하여 WAL 데이터가 전송됩니다.
- Replication이 연결된 후 현재까지 전송받은 WAL 데이터의 크기는 약 33MB입니다.(0/2F08ED78 - 0/2D000000)
전송된 WAL 데이터크기 조회는 pg_wal_lsn_diff Funcation으로 확인할 수 있습니다.
SELECT pg_wal_lsn_diff( '0/2F08ED78', '0/2D000000' ) / 1024 / 1024 ;
Replication 관련 Funcation에 대한 설명은 PostgreSQL Replication - Funcation을 참조하세요.Streaming Replication TEST
Main Server에서 입력한 데이터가 Standby Server로 반영되는지 확인해 보겠습니다. Main Server에서 Table을 생성하고, 현재시간을 입력합니다.
Main Server에서 입력한 데이터가 Standby Server에서 조회가 됨을 확인할 수 있습니다.
Standby Server는 Read-Only 성격으로 인해 오직 SELECT만 가능합니다.
3. Logical Replication
Logical Replication 설정 확인
Logical Replication 설정 확인은 PostgreSQL 프로세스 조회로 확인할 수 있으며, Catalog를 통해서도 확인할 수 있습니다. 프로세스 조회 시
walsender, logical replication worker 두 가지 프로세스가 동작하고 있는지 확인하면 됩니다. walsender 프로세스는 Main Server에서 실행되며, logical replication worker 프로세스는 Standby Server에서 실행됩니다. Main Server 프로세스 (게시자-Publisher)
walsender 프로세스가 작동하면 Logical Replication이 설정되었음을 확인할 수 있습니다.
Standby Server 프로세스 (구독자-Subscriber)
logical replication worker 프로세스가 작동하면 Logical Replication이 설정되었음을 확인할 수 있습니다.
Logical Replication 모니터링
Logical Replication 설정이 완료되면, 각 Server에서는 아래와 같은 Catalog에서 Replication에 대한 내용을 확인할 수 있습니다.
Main Server에서 확인 가능한 Catalog
Catalog Name | Description |
pg_publication | Logical Replication의 Publication에 대한 정보 확인 |
pg_publication_tables | Publication에 포함된 Table 확인 |
pg_replication_slots | Logical Replication이 구성된 Slot에 대한 정보 확인 |
pg_stat_replication_slots | Replication Slot에 대한 통계 확인(Since PostgreSQL 14) |
pg_stat_replication | Replication에 대한 통계 확인 |
Standby Server에서 확인 가능한 Catalog
Catalog Name | Description |
pg_subscription | Subscription에 대한 정보 확인 |
Catalog에 대한 설명은
PostgreSQL Replication - Catalog에서 확인할 수 있습니다.Main Server Catalog 확인
pg_publication Catalog를 통하여 Publication의 정보를 확인할 수 있습니다. - Publication명은 my_publication 이고(pubname), Owner는 postgres 입니다(pubowner).
- 일부 Table으로 구성되어 있으며(puballtables=f), INSERT, UPDATE, DELETE, TRUNCATE에 대해 Replication을 수행합니다.(pubinsert, pubupdate, pubdelete, pubtruncate)
pg_publication Catalog에서 확인 한 Publication에 구성된 Table 목록을 pg_publication_tables Catalog를 통하여 확인할 수 있습니다.- my publication은 public Schema의 replication_table_01, replication_table_02 Table로 구성되어 있습니다.
Logical Replication은 Replication Slot을 사용합니다. Logical Replication에서 사용되는 Slot에 대한 정보를
pg_replication_slots Catalog를 통하여 확인할 수 있습니다.- Replication Slot명은 my_subscription 입니다.(slot_name)
예시에서는 Standby Server에서 Logical Slot을 지정하지 않고 Subcription을 생성하였기 때문에, Subscription명으로 Replication Slot명이 지정되었습니다.(기본값)
- pgoutput 모듈(plugin)을 사용하여 Logical Replication을 수행하며(slot_type), 임시적으로 생성된 Slot은 아닙니다(temporary).
- Replication 대상 Database는 postgres 입니다(datoid, database).
- 현재 Replication Slot은 Active 상태이며(active), Replication을 담당하는 프로세스ID는 3290입니다(active_pid).
- Replication Slot을 유지하기 위한 Catalog 트랜잭션 xmin은 758 입니다(catlog_xmin).
PostgreSQL 14 버전 부터
pg_stat_replication_slots Catalog가 생성되어 Replication Slot에 대한 통계정보를 확인할 수 있습니다.- Logical 디코딩 하면서
logical_decoding_work_mem을 초과한 트랜잭션 수는 2개이고(spill_txns) 디스크로 237회 넘어갔으며(spill_count) 디스크로 넘어간 데이터 양은 15,851,997,849 Bytes(spill_bytes) 입니다.
- my_subscription Replication Slot을 통해 37개의 디코딩된 트랜잭션을(total_txns) Plugin으로 전송했습니다. 그 크기는 178,269,828 Bytes(total_bytes) 입니다.
디스크로 Spill되는 횟수는
logical_decoding_work_mem 파라미터 설정을 따릅니다. 기본값은 64MB입니다.pg_stat_replication Catalog에서 Logical Replication에 대한 통계를 확인할 수 있습니다.
- WAL Sender 프로세스 PID는 13161이고, repluser로 접속하였습니다.(repluser의 oid는 16384 입니다.)
- WAL Receiver가 접속한 서버 IP는 10.10.45.231이고, 55036 Port를 통하여 2023-05-03 17:25:14에 접속하였습니다. client_hostname과 backend_xmin은 관련 파라미터가 설정되지 않아 NULL로 표시되었습니다.
- Replication은 현재 Streaming 중이며, 4/5620E6E0 까지 WAL Record를 보냈고 Standby Server에서 4/5620E6E0 WAL Record를 적용하였습니다.
- 현재 Replication의 Write, Flush, Replay 단계에서 지연은 없고, Standby Server에서 받은 마지막 응답시간은 2023-06-08 10:07:13 입니다.
Standby Server Catalog 확인
Standby Server에서는 Main Server의 walsender로 부터 전달받은 내용을 단순히 복원(Replay)하기 때문에 Replication에 대한 통계를 확인할 수 없습니다. 따라서 Standby Server에서는 Subscription 즉, Main Server의 접속정보정도만 확인이 가능합니다.
함께 보면 좋은 아티클
