En las entradas del registro de inicio se indica que el vacío automático no funciona. Consulto la tabla pg_stat_user_tables y las columnas last_vacuum y last_autovacuum están vacías a pesar de la consulta de vacío que ejecuté justo antes. Conectar pgadmin a la base de datos da la indicación de que la aspiradora no está funcionando.
Estoy usando postgresql en dos máquinas virtuales de Ubuntu Azure. Una VM está configurada para ser la maestra, la segunda es la base de datos replicada mediante streaming. Aproximadamente descrito enhttps://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps.
Todo parece funcionar excepto el autovacío. Durante el inicio se registra el siguiente error:
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
En postgresql.config utilizo la siguiente configuración:
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
Una consulta (seleccione * de pg_stat_user_tables) en la base de datos para encontrar el último vacío (automático) proporciona columnas vacías para el último vacío (automático) en lugar de una fecha y hora. Fueron justo antes de ejecutar VACUUM FULL VERBOSE; y esto me dio resultados de vacío.
Si consulto la configuración de vacío con:
select *
from pg_settings
where name like 'autovacuum%'
Este es el resultado:
"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"
Estos son los resultados de 'track_':
"track_activities";"on"
"track_activity_query_size";"1024"
"track_commit_timestamp";"off"
"track_counts";"off"
"track_functions";"none"
"track_io_timing";"off"
El pg_hba.conf (sin la replicación y la configuración de red/usuario) se ve así:
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
el /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
Este es el resultado de 'netstat -ant|grep 5432' si se limpia y formatea.
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
No creo que la aspiradora automática necesite funcionar todavía debido a la
Entonces, durante el inicio, track_counts están deshabilitados en tiempo de ejecución.
He estado buscando soluciones cambiando los iptables. Sin reglas de iptable, no funcionará. Me he conectado a localhost como anfitrión. Cambié la configuración del firewall en Azure. Abrí el 5432 para acceder a la máquina virtual desde todas las IP. Puedo acceder a la base de datos desde otros sistemas. Restablecí la configuración a los valores predeterminados con solo cambios de replicación. Reinicié el servicio muchas veces.
¿Qué me estoy perdiendo?
Respuesta1
Quieres arreglar esto:
LOG: el mensaje de prueba no llegó al socket para el recopilador de estadísticas
LOG: deshabilitando el recopilador de estadísticas parafalta de enchufe que funcione
El recopilador de estadísticas espera paquetes UDP del localhost. Dado que localhostse ve bien en su /etc/hosts(específicamente no se resuelve en IPv6), la siguiente explicación más plausible es que hay un firewall que filtra estos paquetes.
Relacionado:Problema al crear sockets UDPresuelto con: Encontré y resolvió el problema al crear sockets UDP. Fue debido a que el firewall del sistema operativo (iptables) restringe la creación de sockets UDP.
Respuesta2
quiero ampliar la respuesta@Danieldio y la solución a mi problema.
Configuré iptables para poder acceder a postgresql de esta manera:
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
Supuse que esto era suficiente. Sin embargo, cuando usé sudo iptables --flushy reinicié el servidor Postgres, apareció el error.deshabilitar el recopilador de estadísticas por falta de un socket que funcionese había ido.
También utilicé iptraf para investigar el tráfico ( sudo apt-get install iptraf sudo iptraf). Noté que un tráfico se originaba en la dirección IP local (subred) del servidor pero en puertos diferentes. Este es el tráfico en la máquina esclava (sin el tráfico azul).
SubnetIpSlave:22
SubnetIpSlave:45622
SubnetIpSlave:44770
SubnetIpSlave:48948
SubnetIpMaster:5432
Supongo que este tráfico está bloqueado por iptables porque no pasa por el loopback. Por eso limpié las iptables. Este es el resultado:
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
Incluí la subred. Creo que esto es lo que lo hace funcionar, ya que SubnetIpSlave y SubnetIpMaster están en este rango. Probablemente se me permita quitar elESTABLECIDO, RELACIONADOregla.
El registro parece que debería:
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
Yo estoy feliz ;)
Respuesta3
Según su enlace, You should now be able to ssh freely between your two servers as the postgres user.necesita configurar la relación de confianza para el usuario de Postgres de maestro a esclavo y de esclavo a maestro.
Puede utilizar ssh-keygenpara crear un par de claves con una contraseña en blanco.
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]-----+
Más información por favor consulte esto.enlace.
Además, necesita abrir el puerto 5432 en Azure NSG.