В записях журнала запуска указано, что автовакуум не работает. Я запрашиваю таблицу pg_stat_user_tables, и столбцы last_vacuum и last_autovacuum пусты, несмотря на запрос на вакуум, который я только что выполнил. Подключение pgadmin к базе данных показывает, что вакуум не работает.
Я использую postgresql на двух виртуальных машинах Ubuntu Azure. Одна виртуальная машина настроена как главная, вторая — реплицированная база данных с помощью потоковой передачи. Примерно описано в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. Без каких-либо правил iptables это не будет работать. Я подключился к localhost как к хосту. Я изменил настройки брандмауэра в Azure. Я открыл 5432 для доступа к виртуальной машине со всех IP-адресов. Я могу получить доступ к базе данных из других систем. Я сбросил конфигурацию на значения по умолчанию, изменив только репликацию. Я перезапускал службу много раз.
Что я упускаю?
решение1
Вы хотите это исправить:
LOG: тестовое сообщение не прошло через сокет для сборщика статистики
LOG: отключение сборщика статистики дляотсутствие рабочей розетки
Сборщик статистики ожидает пакеты UDP от localhost. Учитывая, что localhostу вас все выглядит нормально /etc/hosts(в частности, он не преобразуется в IPv6), следующим более правдоподобным объяснением является то, что эти пакеты фильтрует брандмауэр.
Связанный:Проблема при создании UDP-сокетоврешено с помощью: Нашел и решил проблему с созданием UDP-сокетов. Она была из-за того, что брандмауэр ОС (iptables) ограничивал создание UDP-сокетов.
решение2
Я хочу подробнее остановиться на ответе.@Дэниелдал и решение моей проблемы.
Я настроил iptables, чтобы получить доступ к postgresql, следующим образом:
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 --flushи перезапустил сервер postgres, ошибкаотключение сборщика статистики из-за отсутствия рабочего сокетапропал.
Я также использовал iptraf для исследования трафика ( sudo apt-get install iptraf sudo iptraf). Я заметил, что трафик возник на локальном IP-адресе (подсети) сервера, но на разных портах. Это трафик на подчиненной машине (без трафика Azure).
SubnetIpSlave:22
SubnetIpSlave:45622
SubnetIpSlave:44770
SubnetIpSlave:48948
SubnetIpMaster:5432
Я предполагаю, что этот трафик блокируется iptables, поскольку он не проходит через loopback. Поэтому я почистил 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]-----+
Более подробную информацию можно найти здесь.связь.
Также вам необходимо открыть порт 5432 на Azure NSG.