Postgresql 9.3 Доставка журналов в горячем режиме ожидания
Моя настройка
Я только что настроил потоковую репликацию в 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
Резервное восстановление.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 активен, это фактически триггер, когда доставка журналов должна выполняться в режиме ожидания. Это верно?
Кажется, что потоковая репликация работает, как я и ожидал, но попытка запустить доставку журналов в режиме ожидания, похоже, даже не пытается. Что я делаю неправильно?
1 ответ
Я тоже только что столкнулся с этим вопросом. Ключ здесь на самом деле 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 по мере необходимости в течение дня.