postgresql 跟踪計數和 autovacuum 不起作用

在啟動日誌條目中表明 autovacuum 不起作用。儘管我之前執行了真空查詢，但我查詢了 pg_stat_user_tables 表並且 last_vacuum 和 last_autovacuum 列是空的。將 pgadmin 連接到數據庫表明真空不工作。

我在兩個 Ubuntu Azure VM 上使用 postgresql。一台VM設置為master，第二台是通過流的方式複制的數據庫。粗略描述在https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps。

除了 autovacuum 之外，一切似乎都很有效。在啟動過程中會記錄以下錯誤：

LOG:  test message did not get through on socket for statistics collector
LOG:  disabling statistics collector for lack of working socket
WARNING:  autovacuum not started because of misconfiguration
HINT:  Enable the "track_counts" option.
LOG:  database system was shut down at 2017-01-19 14:07:13 UTC
DEBUG:  checkpoint record is at 38/F6000028

在 postgresql.config 我使用以下設置：

track_counts = on  
autovacuum = on
log_autovacuum_min_duration = 200 
autovacuum_max_workers = 1  
autovacuum_naptime =960
autovacuum_vacuum_threshold = 128 
autovacuum_analyze_threshold = 256

對數據庫進行查詢（從 pg_stat_user_tables 中選擇 *）以查找最後一個（自動）vacuum 會為最後一個（auto）vacuum 提供空列，而不是日期時間。就在我執行 VACUUM FULL VERBOSE 之前；這給了我真空結果。

如果我通過以下方式查詢真空設置：

select *
from pg_settings 
where name like 'autovacuum%'

這是結果：

"autovacuum";"on"<br />
"autovacuum_analyze_scale_factor";"0.1"
"autovacuum_analyze_threshold";"256"
"autovacuum_freeze_max_age";"200000000"
"autovacuum_max_workers";"1"<br />
"autovacuum_multixact_freeze_max_age";"400000000"
"autovacuum_naptime";"960"<br />
"autovacuum_vacuum_cost_delay";"20"
"autovacuum_vacuum_cost_limit";"-1"
"autovacuum_vacuum_scale_factor";"0.2"
"autovacuum_vacuum_threshold";"128"
"autovacuum_work_mem";"-1"

這些是“track_”結果：

"track_activities";"on"
"track_activity_query_size";"1024"
"track_commit_timestamp";"off"
"track_counts";"off"
"track_functions";"none"
"track_io_timing";"off"

pg_hba.conf（沒有複製和網路/使用者設置）如下所示：

local   all             all                                     trust
host    all             all             localhost               trust
host    all             all             10.1.1.5/32             md5
host    all             all             127.0.0.1/32            md5
host    all             all             0.0.0.0 0.0.0.0         md5

/etc/hosts：

127.0.0.1       localhost
127.0.1.1       ubuntu
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

這是 ’netstat -ant|grep 5432’ 如果清理並格式化的結果。

User@Machine:/datadrive/log/postgresql/pg_log$ netstat -ant|grep 5432
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN
tcp       39      0 InternIpMaster:5432           InternIpSlave:36338          ESTABLISHED
tcp        0      0 InternIpMaster:5432           IpJob:63814     TIME_WAIT
tcp        0      0 InternIpMaster:5432           IpJob:22192      TIME_WAIT
tcp        0      0 InternIpMaster:5432           IpJob:47729      TIME_WAIT
tcp        0      0 InternIpMaster:5432           IpJob:55663      TIME_WAIT
tcp6       0      0 :::5432                 :::*                    LISTEN

我不認為 autovacuum 需要工作，因為

因此，在啟動期間，track_counts 在執行時被禁用。

我一直在尋找改變 iptables 的解決方案。如果沒有任何 iptable 規則，它將無法工作。我已作為主機連接到 localhost。我已更改 Azure 中的防火牆設置。我打開 5432 以從所有 ip 訪問 vm。我能夠從其他系統訪問數據庫。我已將 conf 重置為預設值，僅更改了複製。我多次重新啟動服務。

我錯過了什麼？

我想詳細說明@Daniel給出的答案以及我的問題的解決方案。

我已經設置了 iptables 以便像這樣訪問 postgresql：

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5432 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -j DROP

我以為這已經足夠了。但是，當我使用sudo iptables --flush並重新啟動 postgres 伺服器時*，由於缺少工作套接字*而禁用統計收集器的錯誤消失了。

我還使用 iptraf 來調查流量 ( sudo apt-get install iptraf sudo iptraf)。我注意到流量來自伺服器的 ip 本地（子網）地址，但來自不同的埠。這是從機上的流量（沒有天藍色的流量）。

SubnetIpSlave:22
SubnetIpSlave:45622
SubnetIpSlave:44770
SubnetIpSlave:48948
SubnetIpMaster:5432

我假設此流量被 iptables 阻止，因為它沒有通過環回。因此我清理了 iptables。這是結果：

sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A INPUT -p icmp -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5432 -j ACCEPT
sudo iptables -A INPUT -s 10.1.1.0/24 -j ACCEPT
sudo iptables -A INPUT -j DROP

我包括了子網。我認為這就是它起作用的原因，因為 SubnetIpSlave 和 SubnetIpMaster 都在這個範圍內。我可能被允許刪除ESTABLISHED,RELATED規則。

日誌看起來應該：

2017-01-24 09:19:38 UTC [1482-1] LOG:  database system was shut down in recovery at 2017-01-24 09:17:41 UTC
2017-01-24 09:19:38 UTC [1483-1] [unknown]@[unknown] LOG:  incomplete startup packet
2017-01-24 09:19:38 UTC [1482-2] LOG:  entering standby mode
2017-01-24 09:19:38 UTC [1482-3] DEBUG:  checkpoint record is at 5D/F2042CA8

我很開心 ;）

你想解決這個問題：

日誌：統計收集器的套接字上的測試消息未通過日誌：由於缺少工作套接字而

禁用統計收集器

統計資訊收集器需要來自 localhost 的 UDP 數據包。鑑於localhost在您的情況下看起來不錯/etc/hosts（特別是它不能解析為 IPv6），下一個更合理的解釋是有防火牆過濾這些數據包。

相關：創建 UDP 套接字的問題已解決： 找到並解決了創建 UDP 套接字的問題。這是因為作業系統防火牆（iptables）限制創建 UDP 套接字。

引用自：https://serverfault.com/questions/827326