Я только что впервые настроил потоковую репликацию в postgres (9.3.5), и хотя потоковая передача работает, как я ожидал, я изо всех сил пытаюсь заставить свой резервный режим запустить archive_command, чтобы я мог сохранить весь журнал файлы.
Мастер postgres.conf:
wal_level = hot_standby
checkpoint_segments = 8
max_wal_senders = 4
wal_keep_segments = 8
Резервный postgres.conf:
wal_level = hot_standby
checkpoint_segments = 8
archive_mode = on
archive_command = 'test ! -f /backup/postgres_archive/constant/%f && cp %p /backup/postgres_archive/constant/%f'
max_wal_senders = 3
wal_keep_segments = 8
hot_standby = on
Резервный recovery.conf:
standby_mode = 'on'
primary_conninfo = 'host=my-host.example.com port=5432 user=replicator password=my_password sslmode=require'
restore_command = 'cp /backup/postgres_archive/constant/%f %p'
trigger_file = '/tmp/postgresql.trigger'
Разрешения на папку, в которую я пытаюсь записать, правильные, и archive_command отлично работает, когда я запускаю его вручную, когда пользователь postgres работает как. Конечно, я попытался изменить команду архива на простое касание (опять же, отлично протестировано как пользователь postgres), но это не имело никакого значения.
Моя БД все еще находится в зачаточном состоянии, поэтому на нее не так много нагрузки. Для этого я просто моделирую это, записывая случайные данные в тестовую таблицу. После фиксации на мастере я сразу вижу изменения, появляющиеся в режиме ожидания, так что я доволен этим.
Я не совсем понимаю, что файлы WAL - это резервные и главные файлы, которые немного отличаются, но похоже, что один или другой предоставил WAL, в который он еще не начал писать (что не с другой). Это нормально?
Если я сделаю select pg_switch_xlog() на главном устройстве, а затем напишите еще немного, и главный и резервный, похоже, переключаются и начинают запись в следующий / тот же файл WAL. Так что это отражает мое понимание того, что происходит.
У меня есть несколько вопросов по этому поводу. Я прочитал каждую страницу руководств postgres по этому поводу, но не смог найти ничего, что могло бы помочь в моем конкретном случае.
Я попытался найти способ заставить postgres показать мне больше информации о том, что он может делать / не делать в файлах журнала, но ничего полезного не дал. Что мне следует изменить в конфигурации при отладке, чтобы в журналы было помещено как можно больше полезной информации?
Что касается того, когда будет выполняться архивация журналов, я полагаю, поскольку мастер как бы контролирует, какой файл WAL активен, он фактически является триггером, когда доставка журналов должна выполняться в резервном режиме. Это правильно?
Кажется, что потоковая репликация работает так, как я ожидал, но попытка запустить доставку журналов в режиме ожидания, похоже, даже не пытается. Что я делаю не так?
Я тоже только что столкнулся с этой проблемой. Ключ здесь на самом деле archive_cleanup_command в "recovery.conf" в режиме ожидания. В режиме ожидания запустится archive_cleanup_command после завершения обработки сегмента WAL с первичного сервера, поэтому вы знаете, что можете сделать резервную копию этого сегмента WAL и всех предыдущих сегментов. В моем "recovery.conf" есть:
archive_cleanup_command = '/var/lib/postgresql/wal_backup_mirror.sh "%r"'
Содержимое этого скрипта (упрощенная версия):
CURRENT_WAL_FILE="$1"
for WAL_FILE in $(find /pg_logs/main -maxdepth 1 -type f | sort | awk "\$0 <= \"/pg_logs/main/${CURRENT_WAL_FILE}\""); do
WAL_NAME=$(basename "$WAL_FILE")
gzip -c "$WAL_FILE" > "/backups/wal/${WAL_NAME}.gz"
#now upload the just created .gz to S3 or some other offsite storage
rm -f "${WAL_FILE}"
done
Обратите внимание, что я удаляю сегмент WAL после его резервного копирования, чтобы мой каталог журналов был чистым в резервном режиме, но есть одно предостережение: будьте осторожны с настройкой каскадной репликации, поскольку резервному серверу, находящемуся дальше по цепочке, могут все еще понадобиться эти файлы.
И последнее замечание: помните, что резервного копирования сегментов WAL недостаточно, оно должно выполняться в сочетании с каким-то обычным полным резервным копированием (pg_basebackup). Мы делаем полные резервные копии ежедневно, а затем просто резервные копии сегментов WAL по мере необходимости в течение дня.