Как восстанавливается перезагрузка WAL-файла PostgreSQL?

Первичный серверКак восстанавливается перезагрузка WAL-файла PostgreSQL?

# postgresql.conf 
wal_level = hot_standby 
archive_mode = on 
archive_timeout = 10 
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'

Резервный сервер

hot_standby = on

Я скопировал /archive/* в основной сервер для $PGDATA/pg_xlog в режиме ожидания, и ничего не случится. Когда я перезапустить резервный сервер, я получил сообщение об ошибке из журнала сервера:

2016-11-21 17:56:09 CST [17762-3] LOG: invalid primary checkpoint record 
2016-11-21 17:56:09 CST [17762-4] LOG: record with zero length at 0/6000100 
2016-11-21 17:56:09 CST [17762-5] LOG: invalid secondary checkpoint record 
2016-11-21 17:56:09 CST [17762-6] PANIC: could not locate a valid checkpoint record 
2016-11-21 17:56:09 CST [17761-1] LOG: startup process (PID 17762) was terminated by signal 6: Aborted 
2016-11-21 17:56:09 CST [17761-2] LOG: aborting startup due to startup process failure

Вопросы:

это достаточно для синхронизации данных на резервный сервер, просто скопировав /archive/* на первичном сервере в $PGDATA/pg_xlog в в режиме ожидания?
Как и когда восстанавливается файл WAL, запускаемый на горячем резервном сервере? Проверяет ли резервный сервер его каталог $PGDATA/pg_xlog для новых файлов WAL? Или мне нужно запускать его вручную?
Я говорю о горячего резерва, не потоковой репликации; поэтому я предполагаю, что мне не нужно настраивать conninfo. Я прав?
После настройки hot_standby = on и перезагрузки сервера, я все еще могу сделать INSERT без ошибок. Как настроить, чтобы сделать его действительно доступным только для чтения?

источник

2016-11-21 Frozen Flame

Это похоже на то, что вы не инициализировали резервную базу данных правильно.

В файле журнала указано, что PostgreSQL даже не начнет реплицироваться, поскольку он не может найти действительную контрольную точку для начала.

Что содержит файл backup_label в каталоге данных вашего резерва? Если этот файл не существует, это, вероятно, проблема.

Неужели этот резервный компьютер неожиданно прекратил работать или он никогда не работал? Как именно вы создали резерв?

источник

2016-11-21 12:03:55

Шаги I после создания резервной копии: 1. 'psql postgres -c" выберите pg_start_backup ('backup') "'. 2. Скопируйте каталог $ PGDATA в файловую систему режима ожидания. 3. 'psql postgres -c" выберите pg_stop_backup() "'. 4. Установите 'hot_standby = on' в' postgresql.conf'. 5. Перезапустите сервер postgresql. –

Это выглядит хорошо (если у вас есть 'fsync = on'). Возможно, вы не скопировали достаточно архивов WAL, а тот, который содержит контрольную точку из 'backup_label', не существует. У вас есть файл 'backup_label', верно? Прочтите запись «START WAL LOCATION» и убедитесь, что там есть соответствующий файл WAL. –

Вы должны сначала создать резервную систему с базового резервного хранилища низкого уровня. Вы не можете создать новый экземпляр и использовать pg_dump и pg_restore. Я предполагаю, что это вы пытались сделать.

Самый простой способ сделать подходящую резервную копию базы - использовать pg_basebackup. Другие варианты обсуждаются в руководстве, но на самом деле, просто используйте:

pg_basebackup -X stream -D standby_datadir_location -h master_ip

или аналогичный.

Только после того, как у вас есть действующая базовая резервная копия, вы можете запустить восстановление архива или поточную репликацию. Самый простой способ - включить репликацию потоковой передачи. Let pg_basebackup сделайте это за вас, отправив флаг -R.

Если вы хотите восстановить архив, вы должны добавить restore_command в резервный recovery.conf, который копирует архивы из местоположения архива в режим ожидания.

Все это покрыто the manual.

источник

2016-11-21 12:54:42

Как восстанавливается перезагрузка WAL-файла PostgreSQL?

ответ

Смежные вопросы