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 по мере необходимости в течение дня.

Другие вопросы по тегам