In den Startprotokolleinträgen wird darauf hingewiesen, dass die automatische Vakuumierung nicht funktioniert. Ich frage die Tabelle pg_stat_user_tables ab und die Spalten last_vacuum und last_autovacuum sind leer, trotz der Vakuumabfrage, die ich gerade zuvor ausgeführt habe. Wenn ich pgadmin mit der Datenbank verbinde, wird angezeigt, dass die Vakuumierung nicht funktioniert.
Ich verwende PostgreSQL auf zwei Ubuntu Azure VMs. Eine VM ist als Master eingerichtet, die zweite ist die per Streaming replizierte Datenbank. Grob beschrieben inhttps://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps.
Bis auf die automatische Vakuumierung scheint alles zu funktionieren. Beim Start wird folgender Fehler protokolliert:
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
In der postgresql.config verwende ich folgende Einstellungen:
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
Eine Abfrage (select * from pg_stat_user_tables) in der Datenbank zum Suchen des letzten (Auto-)Vakuums ergibt leere Spalten für das letzte (Auto-)Vakuum anstelle eines Datums und einer Uhrzeit. War kurz davor, VACUUM FULL VERBOSE auszuführen; und dies gab mir Vakuumergebnisse.
Wenn ich die Vakuumeinstellungen abfrage mit:
select *
from pg_settings
where name like 'autovacuum%'
Dies ist das Ergebnis:
"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"
Dies sind die 'track_'-Ergebnisse:
"track_activities";"on"
"track_activity_query_size";"1024"
"track_commit_timestamp";"off"
"track_counts";"off"
"track_functions";"none"
"track_io_timing";"off"
Die Datei pg_hba.conf (ohne die Replikations- und Netzwerk-/Benutzereinstellungen) sieht folgendermaßen aus:
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
die /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
Dies ist das Ergebnis von „netstat -ant|grep 5432“. Es wurde bereinigt und formatiert.
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
Ich glaube nicht, dass die Autovakuum-Arbeit schon erledigt ist, weil
Daher werden die Track_Counts während des Startvorgangs zur Laufzeit deaktiviert.
Ich habe nach Lösungen gesucht, die die iptables ändern. Ohne iptable-Regeln wird es nicht funktionieren. Ich habe mich mit localhost als Host verbunden. Ich habe die Firewall-Einstellungen in Azure geändert. Ich habe 5432 geöffnet, um von allen IPs aus auf die VM zuzugreifen. Ich kann von anderen Systemen aus auf die Datenbank zugreifen. Ich habe die Konfiguration auf den Standardwert zurückgesetzt und nur Replikationsänderungen vorgenommen. Ich habe den Dienst mehrmals neu gestartet.
Was vermisse ich?
Antwort1
Sie möchten dies beheben:
LOG: Testnachricht kam nicht durch auf Socket für Statistik-Sammler
LOG: Deaktivieren des Statistik-Sammlers fürFehlende funktionierende Steckdose
Der Statistiksammler erwartet UDP-Pakete vom lokalen Host. Da das localhostbei Ihnen in Ordnung aussieht /etc/hosts(insbesondere wird es nicht in IPv6 aufgelöst), ist die nächste plausiblere Erklärung, dass diese Pakete von einer Firewall gefiltert werden.
Verwandt:Problem beim Erstellen von UDP-Socketsgelöst mit: Das Problem beim Erstellen von UDP-Sockets wurde gefunden und behoben. Es lag an der Firewall des Betriebssystems (iptables), die das Erstellen von UDP-Sockets einschränkte.
Antwort2
Ich möchte die Antwort näher erläutern@Danielgab und die Lösung für mein Problem.
Ich habe die iptables so eingerichtet, um Zugriff auf PostgreSQL zu erhalten:
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
Ich nahm an, das wäre genug. Als ich jedoch sudo iptables --flushden Postgres-Server verwendete und neu startete, trat der Fehler aufDeaktivieren des Statistiksammlers wegen fehlendem funktionierenden Socketwar weg.
Ich habe auch iptraf verwendet, um den Datenverkehr zu untersuchen ( sudo apt-get install iptraf sudo iptraf). Mir ist aufgefallen, dass ein Datenverkehr von der lokalen IP-Adresse (Subnetz) des Servers ausging, aber von anderen Ports. Dies ist der Datenverkehr auf der Slave-Maschine (ohne den Azure-Datenverkehr).
SubnetIpSlave:22
SubnetIpSlave:45622
SubnetIpSlave:44770
SubnetIpSlave:48948
SubnetIpMaster:5432
Ich gehe davon aus, dass dieser Datenverkehr von den iptables blockiert wird, da er nicht über den Loopback läuft. Daher habe ich die iptables bereinigt. Dies ist das Ergebnis:
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
Ich habe das Subnetz mit aufgenommen. Ich denke, das ist es, was es zum Funktionieren bringt, denn SubnetIpSlave und SubnetIpMaster liegen in diesem Bereich. Ich darf wahrscheinlich das entfernenETABLIERTE, VERWANDTERegel.
Das Protokoll sieht wie vorgesehen aus:
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
Ich bin glücklich ;)
Antwort3
Laut Ihrem Link You should now be able to ssh freely between your two servers as the postgres user.müssen Sie also die Vertrauensbeziehung für den Postgres-Benutzer vom Master zum Slave und vom Slave zum Master einrichten.
Sie können es verwenden, ssh-keygenum ein Schlüsselpaar mit leerem Passwort zu erstellen.
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]-----+
Weitere Informationen finden Sie hierVerknüpfung.
Außerdem müssen Sie Port 5432 auf Azure NSG öffnen.