这对我来说是新的。我一直在网上搜索,但没有结果。
我有一个服务器,Server A,它已经运行了几周了,它是一台新服务器。我为这个服务器设置了FDW来访问来自2个数据库( public
B1和db B2)的所有表,我们称之为Server B。所有表都“存储”在服务器A上3个不同数据库(db A1、A2、A3)上的特定模式上。There也是 streaming replication
此服务器和服务器C
以下是我对外籍家政工人的总结:
pg_hba
上添加条目以接受所有连接,create user fdwuser
,重新加载配置文件CREATE SERVER foreign\_referensi FOREIGN DATA WRAPPER postgres\_fdw OPTIONS (host '10.10.8.40', port '5432', dbname 'db\_reference');
整个过程是成功的。I可以从服务器A访问服务器B上的外部表。好吧没问题。
现在,我使用SELECT COUNT(*) FROM pg_ls_dir('pg_wal') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';
检查WAL文件。It显示了一些2100+文件。这是令人担心的。
以下是服务器A上的设置:
archive_command cd .
archive_mode on
checkpoint_completion_target 0.9
checkpoint_flush_after 32
checkpoint_timeout 300
wal_level replica
wal_keep_segments 8
max_wal_senders 10
max_wal_size 8192
hot_standby on
然后我做一些检查:
select * from pg_catalog.pg_stat_activity
有250个条目,以backend_type
= parallel worker
或client backend
为主select * from pg_catalog.pg_stat_archiver
Failed_count =0,Archived_count = 71;select * from pg_catalog.pg_stat_archiver
。它现在写着: Failed_count = 0;Archived_count = 3;-由于某些原因,它似乎被重置了select * from pg_catalog.pg_stat_replication
。结果:state = streaming
sync_state = async
我想这台服务器似乎很忙。
问题:
archived_count
要重置?archive_command cd .
?发布于 2022-11-10 15:29:39
导入外部模式需要生成WAL,因为它需要将这些表的描述输入系统目录。但是它不应该生成大量的WAL,除非这些外部模式有大量的表(即重要的表和列的数量,而不是表中的行数)。因为只记录表的描述,而不记录内容)。
所以最有可能的是,FDW与此无关。它是生成WAL的其他东西,也是导致WAL被保留的另一些东西(可能是复制槽)。
您可以在保留的WAL上运行pg_waldump
,试图找出造成这种情况的原因。这是不容易理解的,所以最好先考虑一下你的系统正在做什么,而不是FDW先想出理论。
https://dba.stackexchange.com/questions/319437
复制相似问题