Nas entradas do log de inicialização indicam que o autovacuum não está funcionando. Eu consulto a tabela pg_stat_user_tables e as colunas last_vacuum e last_autovacuum estão vazias, apesar da consulta de vácuo que executei antes. Conectar o pgadmin ao banco de dados indica que o vácuo não está funcionando.
Estou usando o postgresql em duas VMs do Ubuntu Azure. Uma VM é configurada para ser a master, a segunda é o banco de dados replicado por meio de streaming. Descrito aproximadamente emhttps://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps.
Tudo parece funcionar, exceto o aspirador automático. Durante a inicialização o seguinte erro é registrado:
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
No postgresql.config eu uso as seguintes configurações:
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
Uma consulta (selecione * em pg_stat_user_tables) no banco de dados para encontrar o último (auto) vácuo fornece colunas vazias para o último (auto) vácuo em vez de uma data e hora. Foram pouco antes de eu executar o VACUUM FULL VERBOSE; e isso me deu resultados de vácuo.
Se eu consultar as configurações de vácuo com:
select *
from pg_settings
where name like 'autovacuum%'
Este é o 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"
Estes são os 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"
O pg_hba.conf (sem replicação e configurações de rede/usuário) fica assim:
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
o /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 é o resultado de 'netstat -ant|grep 5432' Ele foi limpo e formatado.
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
Não espero que o autovácuo precise de trabalho ainda por causa do
Portanto, durante a inicialização, track_counts são desabilitados em tempo de execução.
Tenho procurado soluções para alterar o iptables. Sem quaisquer regras de iptable, não funcionará. Eu me conectei ao localhost como host. Alterei as configurações do firewall no Azure. Abri o 5432 para acessar a vm de todos os ip's. Consigo acessar o banco de dados de outros sistemas. Redefini o conf para o padrão apenas com alterações de replicação. Reiniciei o serviço várias vezes.
O que estou perdendo?
Responder1
Você quer consertar isso:
LOG: a mensagem de teste não foi transmitida no soquete do coletor de estatísticas
LOG: desabilitando o coletor de estatísticas parafalta de tomada de trabalho
O coletor de estatísticas espera pacotes UDP do host local. Considerando que localhostparece bom para você /etc/hosts(especificamente, não resolve para IPv6), a próxima explicação mais plausível é que há um firewall filtrando esses pacotes.
Relacionado:Problema na criação de soquetes UDPresolvido com: Encontrado e resolvido o problema na criação de soquetes UDP. Foi por causa do firewall do sistema operacional (iptables) que restringiu a criação de soquetes UDP.
Responder2
Quero detalhar a resposta@Danieldeu e a solução para o meu problema.
Eu configurei o iptables para obter acesso ao postgresql assim:
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
Presumi que isso fosse suficiente. Porém quando usei sudo iptables --flushe reiniciei o servidor postgres o errodesabilitando o coletor de estatísticas por falta de soquete de trabalhose foi.
Também usei o iptraf para investigar o tráfego ( sudo apt-get install iptraf sudo iptraf). Percebi que um tráfego originou-se no endereço IP local (sub-rede) do servidor, mas em portas diferentes. Este é o tráfego na máquina escrava (sem o tráfego azul).
SubnetIpSlave:22
SubnetIpSlave:45622
SubnetIpSlave:44770
SubnetIpSlave:48948
SubnetIpMaster:5432
Presumo que esse tráfego esteja bloqueado pelo iptables, pois não passa pelo loopback. Portanto eu limpei o iptables. Este é o 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
Eu incluí a sub-rede. Acho que é isso que faz funcionar, pois SubnetIpSlave e SubnetIpMaster estão nessa faixa. Provavelmente estou autorizado a remover oESTABELECIDO, RELACIONADOregra.
O log parece que deveria:
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
Eu estou feliz ;)
Responder3
De acordo com o seu link, You should now be able to ssh freely between your two servers as the postgres user.então, você precisa configurar a relação de confiança para o usuário postgres do mestre para o escravo e do escravo para o mestre.
Você pode usar ssh-keygenpara criar um par de chaves com senha em branco.
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]-----+
Mais informações consulte istolink.
Além disso, você precisa da porta aberta 5432 no Azure NSG.