起動ログのエントリには、自動バキュームが機能していないことが示されています。pg_stat_user_tables テーブルをクエリすると、直前に実行したバキューム クエリにもかかわらず、last_vacuum 列と last_autovacuum 列が空になっています。pgadmin をデータベースに接続すると、バキュームが機能していないことがわかります。
私は2つのUbuntu Azure VMで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
最後の (自動) バキュームを見つけるためのデータベース上のクエリ (select * from pg_stat_user_tables) では、日付時刻ではなく、最後の (自動) バキュームの空の列が返されます。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
自動掃除機はまだ必要な作業ではないと思います。
したがって、起動時には、実行時に track_counts は無効になります。
私は、iptables を変更するソリューションを探していました。iptable ルールがないと機能しません。ホストとして localhost に接続しました。Azure のファイアウォール設定を変更しました。すべての IP から VM にアクセスするために 5432 を開きました。他のシステムからデータベースにアクセスできるようになりました。レプリケーションの変更のみで conf をデフォルトにリセットしました。サービスを何度も再起動しました。
何が足りないのでしょうか?
答え1
これを修正したい:
ログ: 統計コレクターのソケットでテストメッセージが受信されませんでした
ログ: 統計コレクターを無効にしています機能するソケットがない
統計コレクターは、ローカルホストからの UDP パケットを期待します。それがlocalhost問題ないように見えることを考えると/etc/hosts(具体的には IPv6 に解決されない)、次にもっともらしい説明は、これらのパケットをフィルタリングするファイアウォールがあるということです。
関連している：UDPソケットの作成中に問題が発生しました解決方法: UDP ソケットの作成に関する問題を発見し、解決しました。これは、OS ファイアウォール (iptables) が UDP ソケットの作成を制限していたためでした。
答え2
答えを詳しく説明したい@ダニエル私の問題に対する解決策を教えてくれました。
私は 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 --flushpostgresサーバーを使用して再起動すると、エラーが発生しました動作ソケットが不足しているため統計コレクターを無効にする行ってしまった。
また、iptraf を使用してトラフィックを調査しました ( sudo apt-get install iptraf sudo 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がこの範囲内にあるため、これが機能する理由だと思います。おそらく、確立、関連ルール。
ログは次のようになります:
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
私は幸せです ;）
答え3
リンクによれば、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]-----+
詳細については、こちらを参照してくださいリンク。
また、Azure NSG でポート 5432 を開く必要があります。