web-dev-qa-db-ja.com

postgresqlのトラック数とautovacuumが機能していない

起動ログのエントリは、自動真空が機能していないことを示しています。 pg_stat_user_tablesテーブルにクエリを実行すると、直前に実行したバキュームクエリにもかかわらず、last_vacuum列とlast_autovacuum列が空になります。 pgadminをデータベースに接続すると、バキュームが機能していないことが示されます。

2つのUbuntuAzureVMでpostgresqlを使用しています。 1つはVMがマスターになるように設定され、2つ目はストリーミングによって複製されたデータベースです。おおまかに説明されています https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps

自動真空を除いて、すべてがうまく機能しているようです。起動時に、次のエラーがログに記録されます。

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 FULLVERBOSEを実行する直前でした。そしてこれは私に真空の結果を与えました。

次の方法で真空設定を照会した場合:

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 | grep5432'の結果です。クリーンアップしてフォーマットした場合。

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

オートバキュームに必要な作業はまだないと思います。

したがって、起動中、track_countsは実行時に無効になります。

私はiptablesを変更するソリューションを探していました。 iptableルールがないと、機能しません。ホストとしてローカルホストに接続しました。 Azureのファイアウォール設定を変更しました。すべてのIPからVMにアクセスするために5432を開きました。他のシステムからデータベースにアクセスできます。レプリケーションを変更するだけで、confをデフォルトにリセットしました。何度もサービスを再開しました。

何が足りないのですか?

4
Bart Dirks

@ Daniel 与えられた答えと、私の問題の解決策について詳しく説明したいと思います。

次のようにpostgresqlにアクセスするためにiptablesを設定しました。

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 iptrafSudo iptraf)。トラフィックがサーバーのIPローカル(サブネット)アドレスで発生しているが、異なるポートで発生していることに気付きました。これは、スレーブマシン上のトラフィックです(Azureトラフィックなし)。

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

私は幸せです ;)

1
Bart Dirks

これを修正したい:

ログ:統計コレクターのソケットでテストメッセージが送信されませんでした
LOG:動作中のソケットの不足の統計コレクターを無効にする

統計コレクターは、ローカルホストからのUDPパケットを想定しています。 localhost/etc/hostsで正常に見える(具体的にはIPv6に解決されない)よりも、次のもっともらしい説明は、これらのパケットをフィルタリングするファイアウォールがあるということです。

関連: DPソケットの作成の問題 解決方法:UDPソケットの作成の問題を見つけて解決しました。これは、OSファイアウォール(iptables)がUDPソケットの作成を制限しているためです。

2
Daniel Vérité

リンクによると、_You should now be able to ssh freely between your two servers as the postgres user._したがって、postgresユーザーのマスターからスレーブおよびスレーブからマスターへの信頼関係を設定する必要があります。

_ssh-keygen_を使用して、パスワードが空白のキーのペアを作成できます。

shui@shui:~$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/shui/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/shui/.ssh/id_rsa. Your public key has been saved in /home/shui/.ssh/id_rsa.pub. The key fingerprint is: SHA256:mCyBHNLeEdCH2VqBjhtOC8njVLSXnjU7V9GbufK+hlE shui@shui The key's randomart image is: +---[RSA 2048]----+ |..++.*.. .. | | o.+B = .. | |.o+=.B o . + | |o+= *oooo . E | |o+.+.o+oS. . . | | .+ . o o . | | = | | . o | | oo. | +----[SHA256]-----+詳細については、こちらを参照してください リンク

また、AzureNSGでポート5432を開く必要があります。

1
Shui shengbao