Не удается найти "файл истории времени", чтобы заставить репликацию работать

Question

Я использую PostgreSQL 9.4, пытаясь запустить репликацию.

Что я делаю, черпая вдохновение из инструкций в вики и документации:

1. SELECT pg_start_backup('clone', true);
2. rsync базы данных к потенциальной реплике
3. SELECT pg_stop_backup();
4. rsync из папки pg_xlog в будущую копию

Я запускаю реплику, и она говорит:

LOG:  fetching timeline history file for timeline 3 from primary server
FATAL:  could not receive timeline history file from the primary server:
    ERROR:  could not open file "pg_xlog/00000003.history": No such file or directory

Естественно, я ищу файл .history в pg_xlog/ на обоих серверах, но его нет.

Я просматриваю документы, чтобы выяснить, что

Чтобы использовать резервную копию, вам необходимо сохранить все файлы сегментов WAL, созданные во время и после резервного копирования файловой системы. Чтобы помочь вам в этом, функция pg_stop_backup создает файл истории резервного копирования, который немедленно сохраняется в области архива WAL. Этот файл назван в честь первого файла сегмента WAL, который необходим для резервного копирования файловой системы. Например, если начальным файлом WAL является 0000000100001234000055CD, файл истории резервного копирования будет иметь имя, например, 0000000100001234000055CD.007C9330.backup.

Однако так получилось, что после того, как я сделал pg_stop_backup() , в pg_xlog/ и нигде больше ничего подобного не было.

Итак, где я могу получить этот "файл истории времени"?

Answer 1

Согласно сообщению « Шесть для двоих» , вы можете просто создать файл, а затем он перейдет к настройке репликации, но по сути это ошибка PostgresSQL, где он нуждается в этом файле, даже если он неприменим или удален по операция.

Когда PostgreSQL продвигает новый основной сервер, он создает маркер временной шкалы в виде небольшого текстового файла, помещенного в каталог файлов WAL. Этот файл позволяет достичь восстановления по времени при некоторых довольно сложных сценариях отработки отказа и возврата.

Так что, похоже, вам придется воссоздать файл. Вы можете найти очень хорошее резюме файла .history в вики Postgres. Поскольку информация находится в формате .pdf, ее, как правило, сложнее проиндексировать, поэтому у вас могут возникнуть проблемы с поиском документа, если вы еще не знаете, что он там.

Но мы никогда не вернемся к этому графику, потому что это до нашего обновления. Все, что нам нужно для восстановления потерянного файла - это достаточно хорошее число. И вы можете получить один, запустив:

# SELECT pg_current_xlog_location();
 pg_current_xlog_location
--------------------------
 1/38F70328
(1 row)

Создайте макет файла .history в каталоге WAL с этими значениями и т.д. Реплика сразу сможет начать.

_{источник}

Создайте файл с этими (приведенными выше) результатами, но с ожидаемым именем для ошибки.

---

Дополнительные ресурсы

• Понимание временных рамок PostgreSQL

• Функции системного администрирования

  Имя: pg_current_xlog_location()

  Тип возврата: текст

  Описание: Получить текущее местоположение записи журнала транзакций.

  pg_current_xlog_location отображает текущее местоположение записи журнала транзакций в том же формате, который использовался вышеупомянутыми функциями. Аналогично, pg_current_xlog_insert_location отображает текущую точку вставки журнала транзакций. Точка вставки является "логическим" концом журнала транзакций в любой момент, в то время как место записи является концом того, что было фактически записано из внутренних буферов сервера. Расположение записи - это конец того, что можно проверить извне сервера, и обычно это то, что вам нужно, если вы заинтересованы в архивировании частично полных файлов журнала транзакций. Точка вставки доступна главным образом для отладки сервера. Обе эти операции предназначены только для чтения и не требуют прав суперпользователя.

  Вы можете использовать pg_xlogfile_name_offset для извлечения соответствующего имени файла журнала транзакций и смещения байтов из результатов любой из вышеперечисленных функций.

  Аналогично, pg_xlogfile_name извлекает только имя файла журнала транзакций. Когда указанное местоположение журнала транзакций находится точно на границе файла журнала транзакций, обе эти функции возвращают имя предыдущего файла журнала транзакций. Обычно это желаемое поведение для управления поведением архивирования журнала транзакций, поскольку предыдущий файл является последним, который в настоящее время необходимо архивировать.

  _{источник}