В записях журнала запуска указано, что автоочистка не работает. Я запрашиваю таблицу 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
Запрос (выберите * из 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. Без каких-либо правил iptable это не будет работать. Я подключился к localhost в качестве хоста. Я изменил настройки брандмауэра в Azure. Я открыл 5432, чтобы получить доступ к виртуальной машине со всех IP. Я могу получить доступ к базе данных из других систем. Я сбросил конфигурацию по умолчанию с изменениями только репликации. Я перезапускал службу много раз.
Что мне не хватает?
Вы хотите это исправить:
LOG: тестовое сообщение не прошло через сокет для сборщика статистики
LOG: отключение сборщика статистики для отсутствие работающей розетки
Сборщик статистики ожидает UDP-пакеты от localhost. Учитывая чем localhost отлично смотрится в твоем /etc/hosts (в частности, он не разрешается для IPv6) следующее более правдоподобное объяснение состоит в том, что есть брандмауэр, фильтрующий эти пакеты.
Связанный: Проблема при создании сокетов UDP решено с помощью: Обнаружена и устранена проблема создания сокетов UDP. Это произошло из-за ограничений брандмауэра ОС (iptables) на создание сокетов UDP.
По вашей ссылке,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.
Я хочу уточнить ответ @ Дэниел дал и решение моей проблемы.
Я настроил 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-адресе (подсети) сервера, но на разных портах. Это трафик на ведомой машине (без лазурного трафика).
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
Я счастлив ;)