■ 개요
Unlogged Objects는 WAL 파일에 테이블의 생성만 기록되며, 이후의 변동 사항은 기록되지 않는 오브젝트 입니다.
Temporary Table 및 Sequence도 Unlogged Object에 속합니다.
카탈로그를 조회하면 해당 오브젝트가 Logged인지 Unlogged인지 확인할 수 있습니다.
조회 방법
pg_class 카탈로그의 relpersistence 컬럼을 조회하면 type을 확인할 수 있습니다.p
= permanent table/sequenceu
= unlogged table/sequencet
= temporary table/sequence
postgres=# CREATE TABLE t1(i int);
CREATE TABLE
postgres=# SELECT oid, relname, relfilenode, relpersistence FROM pg_class WHERE relname='t1';
-[ RECORD 1 ]--+-------
oid | 123972
relname | t1
relfilenode | 123975
relpersistence | p
postgres=# CREATE UNLOGGED TABLE t2(i int);
CREATE TABLE
postgres=# SELECT oid, relname, relfilenode, relpersistence FROM pg_class WHERE relname='t2';
-[ RECORD 1 ]--+-------
oid | 123981
relname | t2
relfilenode | 123981
relpersistence | u
postgres=# CREATE TEMPORARY TABLE t3(i int);
CREATE TABLE
postgres=# SELECT oid, relname, relfilenode, relpersistence FROM pg_class WHERE relname='t3';
-[ RECORD 1 ]--+-------
oid | 123986
relname | t3
relfilenode | 123986
relpersistence | t
Logged ↔ Unlogged 전환
ALTER 명령어를 수행하여 Unlogged Object를 Logged Obejct로 변경할 수 있습니다.
Logged Table을 Unlogged Table로 변경하는 것은 부하가 크지 않지만, 반대로 Unlogged Table을 Logged Table로 변경하는 경우 부하가 크기 때문에 주의가 필요합니다.
전환방법
- Table 전환
-- Unlogged Table을 Logged Table로 변경하는 경우
ALTER TABLE 테이블명 SET LOGGED;
-- Logged Table을 Unlogged Table로 변경하는 경우
ALTER TABLE 테이블명 SET UNLOGGED;
- Sequence 전환
-- Unlogged Sequence를 Logged Sequence로 변경하는 경우
ALTER SEQUENCE 시퀀스명 SET LOGGED;
-- Logged Sequence를 Unlogged Sequence로 변경하는 경우
ALTER SEQUENCE 시퀀스명 SET UNLOGGED;
전환 속도
약 2GB의 데이터가 들어있는 동일한 테이블을 변환하는 속도를 비교해보겠습니다.
List of relations
Schema | Name | Type | Owner | Persistence | Access method | Size | Description
--------+----------------+-------+----------+-------------+---------------+---------+--- ----------
public | normal_table | table | postgres | permanent | heap | 2191 MB |
public | unlogged_table | table | postgres | unlogged | heap | 2191 MB |
(2 rows)
- Unlogged to Logged
postgres=# \timing
Timing is on.
postgres=# ALTER TABLE normal_table SET UNLOGGED;
ALTER TABLE Time: 16278.593 ms (00:16.279)
2. Logged to Unlogged
postgres=# \timing
Timing is on.
postgres=# ALTER TABLE unlogged_table SET LOGGED;
ALTER TABLE Time: 176321.375 ms (02:56.321)
전환시 WAL 생성량
- Unlogged to Logged
Unlogged Table을 Logged Table로 변경 시 데이터에 대한 WAL 파일이 생성되는 것을 확인할 수 있습니다.
# Unlogged Table 생성 시 WAL 용량
postgres=# CREATE UNLOGGED TABLE unlogged_table(i int, d text);
CREATE TABLE
postgres=# \! du -sh $PGDATA/pg_wal
17M /var/lib/pgsql/15/data/pg_wal
# Unlogged Taable에 1000만건의 데이터 삽입 시 WAL 용량
postgres=# INSERT INTO unlogged_table SELECT i, i::text, md5(i::text) FROM generate_series(1,10000000) as i;
INSERT 0 10000000
postgres=# \! du -sh $PGDATA/pg_wal
17M /var/lib/pgsql/15/data/pg_wal
# Logged로 변환 시 데이터에 대한 WAL 파일 생성 용량
postgres=# ALTER TABLE unlogged_table SET LOGGED;
ALTER TABLE
postgres=# \! du -sh $PGDATA/pg_wal
1009M /var/lib/pgsql/pg/15/data/pg_wal
- Logged to Unlogged
Logged Table을 Unlogged로 변경 시에는 WAL 변경 사항이 거의 없는것을 확인할 수 있습니다.
# 변경 전 WAL 용량
postgres=# \! du -sh $PGDATA/pg_wal
1009M /var/lib/pgsql/15/data/pg_wal
postgres=# ALTER TABLE unlogged_table SET UNLOGGED;
ALTER TABLE
# 변경 후 WAL 용량
postgres=# \! du -sh $PGDATA/pg_wal
1009M /var/lib/pgsql/15/data/pg_wal
Temporary Table과의 차이점
Temporary Table은 Unlogged Table에 속하며, 아래의 차이점들이 있습니다.
1. Temporary Table은 세션 종료시 삭제되나, Unlogged Table은 복구 모드 진입 제외 형상 유지
2. Temporary Table은 다른 세션과 데이터를 공유할 수 없으나 Unlogged Table은 데이터 공유 가능
3. Temporary Table은 메모리 영역을 temp_buffers를 사용하고, Unlogged Table은 shared_buffers를 사용
Logged vs Unlogged vs Temporary 테이블 Page Header 비교
# Logged Table
postgres=# CREATE TABLE normal_table(i int, d text);
CREATE TABLE
postgres=# INSERT INTO normal_table SELECT gs as i, gs::text as d FROM generate_series(1,10) as gs;
INSERT 0 10
postgres=# SELECT * FROM page_header(get_raw_page('normal_table',0));
lsn | checksum | flags | lower | upper | special | pagesize | version | prune_xid
-------------+----------+-------+-------+-------+---------+----------+---------+-----------
19/E7657078 | 0 | 0 | 64 | 7872 | 8192 | 8192 | 4 | 0
(1 row)
# Unlogged Table
postgres=# CREATE UNLOGGED TABLE unlogged_table(i int, d text);
CREATE TABLE
postgres=# INSERT INTO unlogged_table SELECT gs as i, gs::text as d FROM generate_series(1,10) as gs;
INSERT 0 10
postgres=# SELECT * FROM page_header(get_raw_page('unlogged_table',0));
lsn | checksum | flags | lower | upper | special | pagesize | version | prune_xid
-----+----------+-------+-------+-------+---------+----------+---------+-----------
0/0 | 0 | 0 | 64 | 7872 | 8192 | 8192 | 4 | 0
(1 row)
# Temporary Table
postgres=# CREATE TEMPORARY TABLE temp_table(i int, d text);
CREATE TABLE
postgeres=# INSERT INTO temp_table SELECT gs as i, gs::text as d FROM generate_series(1,10) as gs;
INSERT 0 10
postgres=# SELECT * FROM page_header(get_raw_page('temp_table',0));
lsn | checksum | flags | lower | upper | special | pagesize | version | prune_xid
-----+----------+-------+-------+-------+---------+----------+---------+-----------
0/0 | 0 | 0 | 64 | 7872 | 8192 | 8192 | 4 | 0
(1 row)
Logged Table, Unlogged Table, Temporary Table 모두 lsn을 제외한 헤더는 동일한 것을 확인할 수 있습니다.
■ Unlogged 설정이 가능한 Object 종류
- Table(unlogged, temporary)
- Table에 걸려있는 Index는 자동으로 변환됩니다.
- Sequence
■ 활용도
- 마이그레이션 및 ETL 등 초기 데이터 구성 시
- 임시 대규모 데이터 세트(일정량 사용 후 폐기)
- 정적 데이터에서도 사용 가능
■ 제약 사항 및 주의사항
1. 비정상 종료 시 데이터가 삭제됩니다.
- Unlogged Table t4를 생성하고 데이터 개수를 조회합니다.
postgres=# CREATE UNLOGGED TABLE t4 AS SELECT * FROM t1;
SELECT 100
-- 조회 시 정상적으로 100건의 데이터가 출력되는 것을 확인할 수 있습니다.
postgres=# SELECT COUNT(*) FROM t4;
-[ RECORD 1 ]
count | 100
- 정상적으로 DBMS를 재기동 합니다.
[postgres@rhel87:~]$ pg_ctl restart
waiting for server to shut down.... done
server stopped waiting for server to start....2023-12-07 13:22:23.563 KST [104649] LOG: redirecting log output to logging collector process 2023-12-07 13:22:23.563 KST [104649] HINT: Future log output will appear in directory "/var/lib/pgsql/15/log". done
server started
- 데이터를 다시 조회해도 데이터가 멀쩡한 것을 확인할 수 있습니다.
[postres@rhel87:~]$ psql
psql (15.4)
Type "help" for help.
postgres=# SELECT COUNT(*) FROM t4;
count
-------
100
(1 row)
- 비정상 종료 시의 결과를 확인하기 위해 immediate 옵션을 주고 DBMS를 종료 및 기동합니다.
[postgres@rhel87:~]$ pg_ctl stop -m immediate
waiting for server to shut down.... done
server stopped
[postgres@rhel87:~]$ pg_ctl start
waiting for server to start....2023-12-07 13:27:37.573 KST [106748] LOG: redirecting log output to logging collector process 2023-12-07 13:27:37.573 KST [106748] HINT: Future log output will appear in directory "/var/lib/pgsql/15/log". done
server started
- 다시 Unlogged Table 조회 시 데이터가 삭제된 것을 확인할 수 있습니다.
[postgres@rhel87:~]$ psql
psql (15.4)
Type "help" for help.
postgres=# SELECT COUNT(*) FROM t4;
count
-------
0
(1 row)
2. Standby 서버에서 Unlogged Object 접근이 불가능 합니다.
- 오브젝트의 생성이 기록되기 때문에, Streaming 구성 시 Standby에서 오브젝트가 존재하는 것은 카탈로그에서 조회할 수 있지만 오브젝트에 직접 접근하는 것은 불가능 합니다.
postgres=# SELECT * FROM t4;
ERROR: cannot access temporary or unlogged relations during recovery
3. Logical Replication 대상으로 지정이 불가능 합니다.
postgres=# CREATE PUBLICATION test_nlog FOR TABLE t4;
ERROR: cannot add relation "t4" to publication
DETAIL: This operation is not supported for unlogged tables.
■ 성능 테스트
1. 환경 구성
Host Computer | CPU : AMD Ryzen 5950x 16 Core 32 Threads MEM : 64GB HostOS : Windows 10 pro 22H2 Virtualiztion : VMware Pro 16.2.4 |
---|---|
Bench Server | CPU : 4 vCore MEM : 8GB OS : RHEL 8.7 Storage : NVME SSD PCI-E 3.0 |
Postgres Server | CPU : 8 vCore MEM : 16GB OS : RHEL 8.7 PostgreSQL : 15.4 (enUS.UTF-8) Storage : NVME SSD PCI-E 3.0 |
Windows 10을 사용하는 Host Computer에 VMware pro 16을 사용하여 Virtual Machine 2개를 생성하였습니다.
Bench Server VM과 Postgres Server VM은 물리적으로 다른 SSD 디스크에 존재합니다.
PostgreSQL 설정은 아래와 같이 2가지 케이스로 나누어 수행합니다.
- 튜닝없이 DBMS 설치 시 기본 값
- 엔지니어 설치 시 OLTP 기본 튜닝 값
2. WAL 생성량 비교
Logged Table과 Unlogged Table의 WAL 생성량을 비교해보겠습니다.
WAL Level은 Backup 및 Streaming Replication이 가능한 replica
입니다.
2-1. Logged Table WAL 생성량 확인
(int, text, text) 3 컬럼으로 구성된 1000만건의 데이터 적재시 테이블 사이즈는 965MB입니다.
WAL 생성량은 약 1.3GB가 생성되었습니다.
[postgres@rhel87:pg_wal]$ du -sh $PGDATA/pg_wal
17M /var/lib/pgsql/15/data/pg_wal
[postgres@rhel87:pg_wal]$ psql -c "CREATE TABLE normal_table AS SELECT i, md5(i::text) as d1, md5(i::text||'test') as d2 FROM generate_series(1,10000000) AS i"
SELECT 10000000
[postgres@rhel87:pg_wal]$ du -sh $PGDATA/pg_wal
1.3G /var/lib/pgsql/15/data/pg_wal
[postgres@rhel87:pg_wal]$ psql -c "\dt+ normal_table"
List of relations Schema | Name | Type | Owner | Persistence | Access method | Size | Descr iption
--------+--------------+-------+----------+-------------+---------------+--------+------ -------
public | normal_table | table | postgres | permanent | heap | 965 MB |
(1 row)
2-1. Unlogged Table WAL 생성량 확인
테이블 사이즈는 965MB로 동일합니다.
하지만, 테이블 명세를 저장하는데 필요한 WAL 레코드를 제외하고 INSERT 데이터는 WAL에 기록되지 않으므로 WAL 파일 용량 증가분이 거의 없다는 것을 확인할 수 있습니다.
[opensql@rhel87:~]$ du -sh $PGDATA/pg_wal
17M /var/lib/pgsql/15/data/pg_wal
[opensql@rhel87:~]$ psql -c "CREATE UNLOGGED TABLE unlogged_table AS SELECT i, md5(i::text) as d1, md5(i::text||'test') as d2 FROM generate_series(1,10000000) AS i"
SELECT 10000000
[opensql@rhel87:~]$ du -sh $PGDATA/pg_wal
17M /var/lib/pgsql/15/data/pg_wal
[opensql@rhel87:~]$ psql -c "\dt+ unlogged_table"
List of relations Schema | Name | Type | Owner | Persistence | Access method | Size | Des cription
--------+----------------+-------+----------+-------------+---------------+--------+---- ---------
public | unlogged_table | table | postgres | unlogged | heap | 965 MB |
(1 row)
3. DML 성능 테스트
DML 성능 테스트를 위해 동일한 구조의 테이블을 생성합니다.
DBMS는 튜닝되지 않은 PostgreSQL 기본 설정 값을 사용합니다.
성능 수치를 확인에 변수를 줄이기 위해 VACUUM FULL을 먼저 수행하고 테이블을 생성합니다.
테스트 케이스가 변경될 경우 DBMS 종료 후 OS Cache를 제거하고 다시 수행합니다.
VACUUM FULL
CREATE normal_table(a int, b text, c text);
CREATE unlogged_table(a int, b text, c text);
INSERT 비교
- Logged Table에 1000만건의 데이터(약 730MB)
postgres=# \timing
Timing is on.
postgres=# EXPLAIN ANALYZE VERBOSE INSERT INTO normal_table SELECT i, i::text, md5(i::text) FROM generate_series(1,10000000) as i;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------
Insert on public.normal_table (cost=0.00..225000.00 rows=0 width=0) (actual time=14656.685..14656.686 rows=0 loops=1)
-> Function Scan on pg_catalog.generate_series i (cost=0.00..225000.00 rows=10000000 width=68) (actual time=614.639..5137.148 rows=10000000 loops=1)
Output: i.i, (i.i)::text, md5((i.i)::text)
Function Call: generate_series(1, 10000000)
Query Identifier: 3237300200010068429
Planning Time: 0.357 ms
Execution Time: 14661.348 ms
(7 rows)
Time: 14669.219 ms (00:14.669)
- Unlogged Table에 1000만건의 데이터(약 730MB)
postgres=# \timing
Timing is on.
postgres=# EXPLAIN ANALYZE VERBOSE INSERT INTO unlogged_table SELECT i, i::text, md5(i::text) FROM generate_series(1,10000000) as i;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------
Insert on public.unlogged_table (cost=0.00..225000.00 rows=0 width=0) (actual time=7298.414..7298.415 rows=0 loops=1)
-> Function Scan on pg_catalog.generate_series i (cost=0.00..225000.00 rows=10000000 width=68) (actual time=407.198..4513.126 rows=10000000 loops=1)
Output: i.i, (i.i)::text, md5((i.i)::text)
Function Call: generate_series(1, 10000000)
Query Identifier: 8058826992256061428
Planning Time: 0.345 ms
Execution Time: 7303.826 ms
(7 rows)
Time: 7308.763 ms (00:07.309)
결론 : 14.5초 vs 7초
약 2배의 속도가 차이나는 것을 확인할 수 있습니다.
UPDATE 비교
- Logged Table에 INSERT 했던 1000만건의 데이터를 업데이트
postgres=# EXPLAIN ANALYZE VERBOSE UPDATE normal_table SET b=b||'1';
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Update on public.normal_table (cost=0.00..218458.08 rows=0 width=0) (actual time=23337.485..23337.486 rows=0 loops=1)
-> Seq Scan on public.normal_table (cost=0.00..218458.08 rows=10000006 width=38) (actual time=0.202..2406.971 rows=10000000 loops=1)
Output: (b || '1'::text), ctid
Query Identifier: 5693397500576509468
Planning Time: 0.781 ms
Execution Time: 23338.216 ms
(6 rows)
Time: 23347.899 ms (00:23.348)
- Unlogged Table에 INSERT 했던 1000만건의 데이터를 업데이트
postgres=# \timing
Timing is on.
postgres=# EXPLAIN ANALYZE VERBOSE UPDATE unlogged_table SET b=b||'1';
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Update on public.unlogged_table (cost=0.00..192757.12 rows=0 width=0) (actual time=6397.049..6397.050 rows=0 loops=1)
-> Seq Scan on public.unlogged_table (cost=0.00..192757.12 rows=7943930 width=38) (actual time=0.166..1390.881 rows=10000000 loops=1)
Output: (b || '1'::text), ctid
Query Identifier: -8396718207785166465
Planning Time: 0.640 ms
Execution Time: 6397.319 ms
(6 rows)
Time: 6401.718 ms (00:06.402)
결론 : 23.3초 vs 6.4초
약 4배의 속도가 차이나는 것을 확인할 수 있습니다.
DELETE 비교
- Logged Table에 INSERT 했던 1000만건의 데이터를 삭제
postgres=# \timing
Timing is on.
postgres=# EXPLAIN ANALYZE VERBOSE DELETE FROM normal_table;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
Delete on public.normal_table (cost=0.00..172897.30 rows=0 width=0) (actual time=5593.441..5593.442 rows=0 loops=1)
-> Seq Scan on public.normal_table (cost=0.00..172897.30 rows=7943930 width=6) (actual time=0.157..1160.935 rows=10000000 loops=1)
Output: ctid
Query Identifier: -433751269493074352
Planning Time: 0.717 ms
Execution Time: 5594.256 ms
(6 rows)
Time: 5660.149 ms (00:05.660)
- Unlogged Table에 INSERT 했던 1000만건의 데이터를 삭제
postgres=# \timing
Timing is on.
postgres=# EXPLAIN ANALYZE VERBOSE DELETE FROM unlogged_table;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------
Delete on public.unlogged_table (cost=0.00..172897.30 rows=0 width=0) (actual time=2274.142..2274.143 rows=0 loops=1)
-> Seq Scan on public.unlogged_table (cost=0.00..172897.30 rows=7943930 width=6) (actual time=0.145..944.959 rows=10000000 loops=1)
Output: ctid
Query Identifier: -1796587468789272974
Planning Time: 0.682 ms
Execution Time: 2274.368 ms
(6 rows)
Time: 2277.701 ms (00:02.278)
결론 : 5.6초 vs 2.2초
약 2.5배의 속도가 차이나는 것을 확인할 수 있습니다.
종합 결과
3. TPC-C 성능 테스트
WAL Insert에 따른 성능 차이를 확인하기 위해 DML이 자주 일어나는 OLTP 모델의 벤치마크 시나리오인 TPC-C 시나리오를 이용하여 결과를 확인합니다.
TPC-C는 오픈소스인 benchmarksql-5.0을 사용하여 수행합니다.
DML을 많이 발생 시키기 위하여 세션은 100개, WAREHOUSE는 200으로 설정 하였습니다.
편차를 줄이기 위해 10분씩 5회 수행하고 평균치를 기준으로 값을 비교합니다.
동일한 데이터 상태를 유지하기 위해, 데이터 적재 후 VMware의 Snapshot기능을 이용하였습니다.
수행 순서
1. benchmarksql 데이터 적재 후 Snapshot 생성
2. OS 재기동 및 Snaptshot으로 초기화
3. DBMS 기동
4. 벤치마크 수행
5. 결과확인
TPC-C 수행 결과
회차 | Logged | Unlogged | Logged(Tune) | Unlogged(Tune) |
---|---|---|---|---|
1 | 3447.02 | 27870.18 | 18203.72 | 38286.53 |
2 | 2156.42 | 28002.44 | 19146.58 | 39168.85 |
3 | 2392.72 | 24790.93 | 15845.01 | 38611.44 |
4 | 1548.6 | 29342.07 | 23956.78 | 41661.42 |
5 | 2378.56 | 27801.83 | 17819.14 | 38213.29 |
평균 tpmC | 2384 | 27561 | 18993 | 39188 |
디스크를 하나로 사용하고, shared_buffers도 기본 값인 128MB이다 보니, 자원 경쟁이 치열하여 위와 같은 상당한 차이가 발생 하였습니다.
아래는 OLTP 기준 기본 튜닝을 적용한 다음 성능을 비교해 본 결과입니다.
결론
WAL Write로 인해 발생되는 I/O 부하는 무시할 수 없는 수준이며, 설정값에 따라 2배~10배 가까이 엄청난 성능 차이가 발생합니다.
■ 백업 및 복구
데이터가 백업 되는지 알아보기 위해 10건의 더미 데이터가 있는 테이블을 생성하겠습니다.
postgres=# CREATE TABLE normal_table AS SELECT i, i::text as d FROM generate_series(1,10) as i;
SELECT 10
postgres=# CREATE UNLOGGED TABLE unlogged_table AS SELECT i, i::text as d FROM generate_series(1,10) as i;
SELECT 10
postgres=# SELECT COUNT(*) FROM normal_table ;
count
-------
10
(1 row)
postgres=# SELECT COUNT(*) FROM unlogged_table ;
count
-------
10
(1 row)
Logical Backup
- pg_dump
수행 명령어 :pg_dump -h /var/run/postgresql -f dump.sql
.
pg_dump는 Unlogged Table의 데이터가 백업 가능하며--no-unlogged-table-data
옵션 사용 시 Unlogged Table의 데이터를 제외하고 테이블 명세(DDL)만 추출하게 됩니다.
### dump.sql
--
-- Data for Name: normal_table; Type: TABLE DATA; Schema: public; Owner: postgres
--
COPY public.normal_table (i, d) FROM stdin;
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
\.
--
-- Data for Name: unlogged_table; Type: TABLE DATA; Schema: public; Owner: postgres
--
COPY public.unlogged_table (i, d) FROM stdin;
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
\.
- pg_dumpall
수행 명령어:pg_dumpall -f dumpall.sql
pg_dumpall도 마찬가지로 옵션을 사용하지 않을 시 Unlogged Table의 데이터가 백업 가능하며--no-unlogged-table-data
옵션 사용 시 Unlogged Table의 데이터를 제외하고 테이블 명세(DDL)만 추출하게 됩니다.
### dumpall.sql
--
-- Data for Name: normal_table; Type: TABLE DATA; Schema: public; Owner: postgres
--
COPY public.normal_table (i, d) FROM stdin;
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
\.
--
-- Data for Name: unlogged_table; Type: TABLE DATA; Schema: public; Owner: postgres
--
COPY public.unlogged_table (i, d) FROM stdin;
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
\.
Physical Backup
- pg_basebackup : Replication Protocol을 사용하므로 백업 및 복구가 불가능 합니다.
- barman
- postgres method : pg_basebackup을 동일하게 사용하므로 백업 및 복구가 불가능합니다.
- rsync : 백업은 가능하나, 복구시에 데이터가 삭제 되는것은 동일합니다. relation 파일을 덮어 쓰는 형태로 복구할 수는 있으나, MVCC 관리에 의해 데이터 조회가 불가능 할 수 있습니다.
- pgbackrest : temporary 및 unlogged object는 백업 대상에서 제외됩니다. 따라서 백업 및 복구가 불가능합니다.
결론
Logical 백업으로만 데이터 백업이 가능하니, Physical Backup 이후에 Unlogged Table만 Logical Backup을 수행하여 보관하는 것이 권장됩니다.