시작 로그 항목에는 autovacuum이 작동하지 않음이 표시됩니다. pg_stat_user_tables 테이블을 쿼리했는데 직전에 실행한 Vacuum 쿼리에도 불구하고 last_vacuum 및 last_autovacuum 열이 비어 있습니다. pgadmin을 데이터베이스에 연결하면 진공 청소기가 작동하지 않는다는 표시가 나타납니다.
두 개의 Ubuntu Azure VM에서 postgresql을 사용하고 있습니다. 하나의 VM은 마스터로 설정되고, 두 번째 VM은 스트리밍을 통해 복제된 데이터베이스입니다. 대략적으로 설명하면https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps.
autovacuum을 제외하고는 모두 작동하는 것 같습니다. 시작하는 동안 다음 오류가 기록됩니다.
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
마지막 (자동)vacuum을 찾기 위한 데이터베이스의 쿼리(pg_stat_user_tables에서 * 선택)는 날짜/시간 대신 마지막 (자동)vacuum에 대해 빈 열을 제공합니다. 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
아직은 autovacuum에 작업이 필요할 것으로 예상하지 않습니다.
따라서 시작하는 동안 track_counts는 런타임에 비활성화됩니다.
나는 iptables를 변경하는 솔루션을 찾고 있습니다. iptable 규칙이 없으면 작동하지 않습니다. localhost에 호스트로 연결했습니다. Azure에서 방화벽 설정을 변경했습니다. 모든 IP에서 VM에 액세스하기 위해 5432를 열었습니다. 다른 시스템에서 데이터베이스에 액세스할 수 있습니다. 복제 변경 사항만 적용하여 conf를 기본값으로 재설정했습니다. 서비스를 여러 번 다시 시작했습니다.
내가 무엇을 놓치고 있나요?
답변1
이 문제를 해결하고 싶습니다.
로그: 테스트 메시지가 통계 수집기 소켓을 통과하지 못했습니다.
로그: 통계 수집기 비활성화작동 소켓 부족
통계 수집기는 localhost로부터 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 서버를 사용하고 다시 시작하면 오류가 발생합니다.작업 소켓 부족으로 인해 통계 수집기를 비활성화하는 중사라졌다.
또한 itraf를 사용하여 트래픽을 조사했습니다( 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를 열어야 합니다.