Файловая репликация на основе доставки журналов появилась в версии 8.2 сервера PostgreSQL, то есть за четыре с небольшим года до выпуска версии 9.0. Эта форма проста, надежна и требует мало ресурсов. Эта техника по большей части заменена потоковой репликацией в версии 9.0, но ее все еще можно с удобством использовать как часть стратегии резервного копирования. Полезно разобраться, как это работает, поскольку она может применяться в начальной фазе настройки потоковой репликации в большой системе. Внимательно наблюдайте за задержкой репликации в течение периода выравнивания. В это время задержка репликации гораздо больше, чем в обычное время. Рекомендуется отключить режим горячего резервирования только на время начального периода.
Не выполняйте команды вручную — напишите скрипт, даже если вы занимаетесь тестированием или просто исследуете возможности. Если что-то пойдет не так, вы захотите быстро все запустить сначала, и набор команд вручную не только потребует усилий, но и явится дополнительным источником ошибок. Файлы лога транзакции пишутся на главном сервере. Если установить параметр wai_ievei, то собираться будут все данные, и WAL не будет оптимизироваться. Файлы WAL посылаются с главного сервера командой archive_command, и резервный сервер читает файлы WAL с помощью команды restоre_command, а затем применяет изменения. Файл посылается после его достижения полного размера, или когда проходит время archive_timeout с тех пор, как кто-либо из пользователей выполнял запись в лог транзакции. Если сервер долго не пишет новых данных в лог транзакции, то файлы сменяются каждые checkpoints imeout секунд — это нормально и не представляет проблемы. Поскольку архив находится на резервном сервере, restore_command — обычная команда копирования. Если бы архив находился на третьей системе, надо было бы либо монтировать удаленную файловую систему, либо использовать команду для копирования по сети.
Рубрика: Женский интерес