Проявление проблемы 1: процесс репликации запускается и сразу останавливается.
Причина 1: неправильные настройки ip-адресов репликации в файле pg_hba.conf в каталоге с БД на основном сервере (например D:\Base\data).
На это будут прямо указывать записи в файле keeper.log (C:\Users\...\AppData\Local\Temp\ProSoft-Systems\Redkit).
Решение 1: проверить правильность ip-адресов, прописанных в файле pg_hba.conf в разделе # replication privilege.
При необходимости, добавить ip-адреса резервного сервера.
Причина 2: в процессе репликации не полностью удаляется каталог с БД на реплицируемом сервере и репликация прекращается
Решение 2: проверить, пуст ли каталог БД на резервном сервере. Если нет, удалить файлы вручную. Если не дает вручную, завершить процессы, которые заблокировали доступ к файлам.
Проявление проблемы 2: процесс репликации доходит почти до конца, останавливается и запускается вновь. Часто проявляется особенность что раньше репликация работала, но после перезагрузки резервного сервера вдруг перестала.
Быстрое решение без выяснения причины: в dbctl перевести сервера в ручной режим, запустить процесс репликации вручную.
Причина 1: БД очень большая. Долго запускается сервер БД на резервном сервере. В автоматическом режиме из-за настроек таймаутов keeper не дожидается запуска сервера БД и начинает процесс репликации вновь и не может его завершить, так как в это время сервер все-таки стартует.
Решение 1: необходимо выставить в keeper.ini на обоих серверах
waitCtlUtil=true
ctlUtilTimeout=600000
waitRiseUpTimeout=60000
pgctlRetryTimeout=600000
В случае наличия большой базы можно также включить режим pg_rewind, в этом случае вся БД не копируется при репликации с основного на резервный сервер. Копируется только часть данных, которые появились в БД после остановки резервного сервера БД.
Чтобы отрабатывал pg_rewind надо включить дополнительно настройки в файле keeper.ini
usePgRewind
createReplicationSlotOnPrimary
(при включении этой настройки нужно иметь в виду, что WAL-ы в отсутствии резервного сервера будут копиться на основном сервере до тех пор, пока на не кончится место на диске. В postgres 13 есть настройка max_slot_wal_keep_size для ограничения размера WAL, хранимого для слота репликации - это если есть возможность простоя резервного сервера в течение 2-3 дней, может и больше - зависит от свободного места на диске. Если резервный сервер обычно быстрее восстанавливается, то можно ее не выставлять).
Причина 2: неправильно прописан параметр log_directory в postgresql.conf.
Решение 2: проверить, что путь, прописанный в параметре, указан верно.
Часто в параметре указывают абсолютный путь, но при этом на основном сервере существует диск D, а на резервном база находиться на диске E.
Использовать относительный пусть, как указано в документации: ../log
Причина 3: не существует каталога с логами.
В файле postgresql.conf все прописано правильно, но каталог, куда указывает путь для записи логов, не создан.
Решение 3: создать каталог вручную.
Причина 4: нет прав на запись в каталог логов.
В файле postgresql.conf все прописано правильно, каталог существует, но в свойствах каталога стоит чекюокс "только для чтения" или у пользователя нет прав на запись в каталог.
Решение: предоставить необходимые права.
Причина 5: файл логов заблокирован другим процессом.
Например, если открыть файл логов postgres блокнотом и, не закрывая его, перезапустить базу, то postgres будет пытаться записать в файл логи, но ОС этого сделать не даст.
Решение 5: закрыть сторонний процесс.
Иногда сложно определить какой процесс занял файл.
Можно попробовать вырезать и вставить файл логов в другое место. ОС скажет, что файл занят, и может подсказать каким процессом.
Если не получилось найти процесс, который занимает файл, перезагрузите систему.
В случае, если ОС на базе linux, можно воспользоваться командами lsof или lsfd. lsof /var/data/logs покажет все процессы, которые сейчас держат открытыми файлы в указанном каталоге.
В случае, если с логами всё в порядке, а служба всё равно не запускается, посмотреть файлы логов keeper.ini и dbctl.ini с обоих серверов, часто там прямым текстом написана причина.
Если по логам не удается разобраться, то может помочь ручной запуск сервера БД через командную строку.
Для этого надо дождаться завершения копирования файлов базы.
В командной строке зайти в каталог с исполняемыми файлами БД и выполнить команду запуска системы pg_ctl start.
Будет написано, почему система не запустилась.