☰

Невозможно найти «файл истории временной шкалы», чтобы запустить репликацию.

tag-icon • tag-icon postgresql replication
Невозможно найти «файл истории временной шкалы», чтобы запустить репликацию.

Я использую 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/, ни где-либо еще.

Так где же мне взять этот «файл истории хронологии»?

решение1

В соответствии сШесть на двоихpost, вы можете просто создать файл, а затем продолжить настройку репликации, но по сути это ошибка PostgreSQL, когда ему нужен этот файл, даже если он неприменим или удален в ходе операции.

Примечание: Для Postgresql 10 и более поздних версий функция была переименована вpg_current_wal_lsn()

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

Так что, похоже, вам придется пересоздать файл. Вы можете найти очень хорошее резюме файла .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извлекает только имя файла журнала транзакций. Когда указанное местоположение журнала транзакций находится точно на границе файла журнала транзакций, обе эти функции возвращают имя предыдущего файла журнала транзакций. Обычно это желаемое поведение для управления поведением архивирования журнала транзакций, поскольку предыдущий файл является последним, который в данный момент необходимо архивировать.

    источник

Связанный контент