Получил "в наследство" систему, в которой в качестве СУБД используется PostgreSQL на CentOS. Резервное копирование реализовано с помощью PostgreSQL Backup, которая запускает ночью задание, делает бекап двух баз и отправляет на ftp.

Решил заморочиться отказоустойчивостью.

Просто опишу вкратце что и в какой последовательности делалось по результатам изучения интернета и документации (спасибо postgrespro.ru), то есть не буду тут выкладывать много теории о том как работает PostgreSQL, что такое WAL файлы и т.д.
 

0. УСТАНОВКА PostgreSQL
инструкция по установке PostgreSQL:

команды после # выполняются в системной консоли от пользователя root,
команды после postgres=# - в консоли СУБД от пользователя postgres.

Установить репозиторий и пакеты из него:
# sudo rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm && sudo yum makecache && sudo  yum install postgresql-pro-1c-9.6

Установить системную локаль в ru_RU.utf8:
# localectl set-locale LANG=ru_RU.utf8

Инициализировать кластер СУБД:
# service postgresql-9.6 initdb

Для подключения к базе по сети:
редактируем /var/lib/pgsql/9.6/data/pg_hba.conf :

(если не знаете как редактировать файл, то проще всего установить, если не установлена, программу похожую на far: # yum -y install mc и запустите # mc)

Закомментировать строку
host all all 0.0.0.0/0 ident
Добавить строку
host all all <client host ip> md5
где <client host ip> заменить на адрес машины (или подсети), из которой будете подключаться (ip сервера 1С Предприятие 8). Обязательно с маской
подсети, например: 192.168.1.11/32.

Запустить базу:
# service postgresql-9.6 start
 

Задать пароль пользователю СУБД postgres:
# sudo -u postgres psql
postgres=# alter user postgres password 'yoursecretpassword';\q
                                   

Разрешить на фаерволе подключения к СУБД:
# firewall-cmd --zone=public --add-port=5432/tcp --permanent ; firewall-cmd --reload

Теперь сервер базы данных доступен, можно на сервере 1С предприятия создавать базы и т.д.

 

1. ПОТОКОВАЯ РЕПЛИКАЦИЯ
 

Итак, теперь у нас есть работающая (боевая) СУБД PstgreSQL. Назовем ее MASTER, а сервер, на который будем реплицировать базу SLAVE.

 

Для обеспечения работы потоковой репликации на MASTER-е редактируем файл /var/lib/pgsql/9.6/data/postgresql.conf, добавляем следующие строки:

wal_level = hot_standby (прочитайте про этот параметр в интернете и про WAL файлы в принципе)

max_wal_senders = 4 (количество планируемых слейвов, число 4 - на всякий случай )

max_replication_slots = 4 ( здесь 4 - это количество replication slot'ов - равен максимальному количеству реплик)

hot_standby = on (разрешить запросы на реплике)

hot_standby_feedback = on  (Определяет, будет ли сервер горячего резерва сообщать ведущему или вышестоящему резервному о запросах, которые он выполняет в данный момент)

Параметры hot_standby = on и hot_standby_feedback = on на MASTER-е не играют никакой роли, но мы их определим уже сейчас, так как на одном из следующих этапов при выстраивании потоковой репликации мы скопируем по сути вес data  каталог с MASTER-а на SLAVE, в том числе и этот конфигурационный файл, так что установим эти параметры уже сейчас.

 

На MASTER-е создаем пользователя repluser под которым SLAVE будет подключаться к MASTER-у и таскать WAL из слотов репликации.

# sudo -u postgres psql

postgres=# CREATE ROLE repluser WITH REPLICATION PASSWORD 'супер-секретный-пароль' LOGIN;\q

 

На MASTER-е редактируем /var/lib/pgsql/9.6/data/pg_hba.conf, то есть, обеспечиваем, чтобы в этом файле были такие строчки

host    all             all             <ip_MASTER>/32        md5  
host    all             all             <ip_SLAVE>/32        md5  
host    all             all             <ip_Сервера1С>/32        md5 (эта строчка уже есть, создана на этапе 0.)
host    replication     repluser        <ip_MASTER>/32       md5 
host    replication     repluser        <ip_SLAVE>/32       md5 (разрешаем SLAVE-у подключаться к MASTER-у под пользователем repluser для осуществления потоковой репликации)

По сути, выше описанными разрешениями в файле pg_hba.conf мы разрешаем MASTER-у и SLAVE-у взаимно обращаться друг к другу, поэтому, как и в случае с файлом postgresql.conf, файл pg_hba.conf на обоих серверах может совпадать. Соответственно, в дальнейшем, при необходимости, MASTER может стать SLAVE-ом.

рестарт базы
# service postgresql-9.6 stop
# service postgresql-9.6 start

или 
# service postgresql-9.6 restart

 

ПЕРЕХОДИМ на SLAVE

Выполняем все что в пункте 0. УСТАНОВКА PostgreSQL

Останавливаем базу
# service postgresql-9.6 stop

Удаляем все файлы в директории data:
# rm -rf /var/lib/pgsql/9.6/data/*

Копируем с MASTER-а базу (обратите внимание - запускаем pg_basebackup под пользователем postgres, под которым работает база)
# sudo -u postgres pg_basebackup --host=<ip_MASTER> --username=repluser --pgdata=/var/lib/pgsql/9.6/data --xlog-method=stream --write-recovery-conf

выше написанная команда делает следующее - подключается к MASTER-у под пользователем repluser (команда затребует пароль, его нужно ввести, скорей всего можно в команде этот пароль и прописать, но я не заморачивался), копирует целиком базу вместе с конфигурационными файлами, а так же создает минимально необходимый файл recovery.conf, в котором собственно прописано, что база работает в режиме реплики, а значит пока существует этот файл, то в режиме только для чтения!

Привожу текст файла recovery.conf:
standby_mode = 'on'
primary_conninfo = 'user=repluser password=супер-секретный-пароль host=ip_MASTER port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres'

Как я уже говорил выше, если остановить базу, и переименовать файл recovery.conf, и снова запустить, то база перестает быть репликой.

Запускаем базу
# service postgresql-9.6 start

все :), SLAVE в теперь реплика, и регулярно таскает печеньки данные с MASTER-а

Что можно добавить?

Эта репликация асинхронная. Есть возможность настройки синхронной потоковой репликации. А так же каскадной, а так же и т.д. и т.д. Читайте, изучайте.

Все что сделано выше решит ситуацию, когда у вас внезапно взрывается MASTER - у вас есть актуальная копия, реплика. 

Примерный сценарий таков:
- останавливается SLAVE
- переименовывается recovery.conf
- запускается SLAVE
- на сервере 1С базы переподключаются к SLAVE-у, пользователи начинают работать, а вы решаете - что там случилось с MASTER-ом.

 

2. НЕПРЕРЫВНОЕ АРХИВИРОВАНИЕ

Предположим MASTER не взорвался, а просто кто-то умный запустил обработку, которая перепилила и перекорежила данные и все это торжественно перелетело в реплику на  SLAVE (см. все что написано выше).

Решает организация непрерывного архивирования.

Обязательно прочитайте (спасибо postgrespro.ru):
https://postgrespro.ru/docs/postgresql/9.4/continuous-archiving

чтобы иметь представление о том что такое WAL, файлы-сегменты WAL и т.д.

Вкратце схема следующая: 
- настраиваем непрерывное копирование WAL файлов
- делаем базовую резервную копию, после чего возникает возможность восстановить базу данных на любую временную точку после созданной базовой копии просто "накатывая" необходимое количество WAL файлов. Если базовая резервная копия сделана достаточно давно, то вам придется дольше по времени восстанавливать, накатывая большее количество файлов. Соответственно базовые резервные копии делайте чаще. Старые WAL файлы (созданные до "контрольной точки" сформированной очередной базовой резервной копии) можно "подчищать".

Опишу простейшую систему, когда архивируем на тот же дисковый массив, где и находится собственно база (что неправильно и вы конечно настройте копирование на другой диск, сервер, ftp и т.д.).

На MASTER-е редактируем /var/lib/pgsql/9.6/data/pg_hba.conf, добавляем следующую строчку (или убеждаемся что она уже есть):
local    replication    all        trust
 

Создаем папку archive, в которую будем копировать WAL файлы (обратите внимание - выполняем mkdir под пользователем postgres, чтобы установились нужные права на папку, и база был к ней доступ) 
# sudo -u postgres mkdir -p /var/lib/pgsql/9.6/backups/archive

Редактируем файл /var/lib/pgsql/9.6/data/postgresql.conf
archive_command = 'test ! -f /var/lib/pgsql/9.6/backups/archive/%f && cp %p /var/lib/pgsql/9.6/backups/archive/%f'
(

то есть, задаем желаемую команду оболочки в параметре archive_command. В archive_command символы %p заменяются полным путём к файлу, подлежащему архивации, а %f заменяются только именем файла. Поэтому когда WAL файл готов к копированию (заполнен) вызывается примерно следующая команда:
test ! -f /var/lib/pgsql/9.6/backups/archive/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 /var/lib/pgsql/9.6/backups/archive/00000001000000A900000065

)

# service postgresql-9.6 restart

Создаем папку basebackups, в которую положим заархивированную базовую резервную копию (обратите внимание - выполняем mkdir под пользователем postgres, чтобы установились нужные права на папку, и база был к ней доступ) 
# sudo -u postgres mkdir -p /var/lib/pgsql/9.6/backups/basebackups

Делаем базовую резервную копию:
# pg_basebackup -U postgres -D /var/lib/pgsql/9.6/backups/basebackups -Ft -z -Xf 

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

Кстати, pg_basebackup в папке, куда мы копируем WAL файлы, создал такой файл.

-rw------- 1 postgres postgres      308 окт 24 02:37 00000001000000150000006B.00000028.backup
по сути - это временная метка с которой можно восстанавливать базу из архива.

К сожалению процесс восстановления описать не могу, так как мне еще предстоит его протестировать, обкатать. Надеюсь найти время и дописать статью.

P.S. это моя первая статья, не судите строго