Потоковая репликация и непрерывное архивирование базы данных PostgreSQL - делюсь небольшим опытом

27.10.17

База данных - Архивирование (backup)

Постарался кратко описать опыт настройки потоковой репликации и непрерывного архивирования в PostgreSQL.

Получил "в наследство" систему, в которой в качестве СУБД используется 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.6/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 -Pv

здесь делаем базовую резервную копию и архивируем все в один файл (в моем случае образовался файл с именем base.tar.gz).  В общем изучите возможности pg_basebackup.
Если бы каталог basebackups был не пустой pg_basebackup, то выдаст ошибку:
pg_basebackup: каталог "/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. это моя первая статья, не судите строго

PostgreSQL потоковая репликация непрерывное архивирование

См. также

Журнал изменений с восстановлением состояния ссылочных объектов и архивацией по HTTP / COM (расширение + конфигурация, 8.3.14+, ЛЮБАЯ конфигурация)

Архивирование (backup) Журнал регистрации Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма "История изменений"! Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

19200 руб.

15.05.2017    42517    10    24    

38

BackUPv8 - система резервного копирования баз 1С

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Автоматическое создание копий файловых и серверных информационных баз 1С Предприятие 8 и размещение копий в облаке Яндекс.Диск, локальном или сетевом ресурсе.

1200 руб.

03.09.2014    14728    13    6    

18

Резервное копирование журнала транзакций, наконец-то!

Архивирование (backup) Администрирование СУБД Россия Бесплатно (free)

Постараюсь объяснить, зачем нужно резервное копирование именно журнала транзакций, а не только базы данных, и почему я словно сбросил груз, настроив его - как, покажу, естественно. Кстати, будут скрипты T-SQL (с подробными комментариями) - отличный способ сделать администрирование базы более уютным.

04.12.2023    5865    n_mezentsev    15    

24

Резервное копирование и восстановление 1С баз на PostgreSQL в Windows с помощью pgAdmin, bat-файлов и планировщика

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной инструкции будет описано, как с помощью pgAdmin, bat-файлов и планировщика заданий Windows организовать резервное копирование, восстановление и хранение копий баз данных.

07.10.2022    19815    sapervodichka    36    

142

Архивирование базы в dt и дамп postgres

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Захотелось клиентам выгрузку архива баз, и выгрузку в дт, готовые скрипты с сети не заработали. Может, кому-то поможет. Релиз 8.3.18.1741.

1 стартмани

25.08.2022    4714    2    Gnom-Gluck    6    

6

Утилита копирования баз данных 1С

Архивирование (backup) Платформа 1С v8.3 Абонемент ($m)

Небольшая утилита для копирования файловых баз данных 1С.

1 стартмани

02.06.2022    4236    3    Giblarium    12    

5
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Трактор 1246 27.10.17 10:25 Сейчас в теме
Толковая статья. Наши админы остановились только на первой части. Сделали репликацию. Подскажу, чтобы ещё и непрерывное резервирование сделали.
2. awk 741 30.10.17 09:22 Сейчас в теме
Плюсанул, а Mightnight commander похожий на FAR улыбнуло...
3. KRIHA 111 30.10.17 10:34 Сейчас в теме
(2) ))) ну а что - я с линуксом только начал работать. вот к примеру - подчищать архивные WAL файлы - пытался сгенерить команду, которая бы удаляла файлы, созданные ранее определенной даты-времени.. в общем забил, открыл MC и инсёртом выделил все что надо и F8 ))))))))))
4. awk 741 31.10.17 23:58 Сейчас в теме
(3) Тут линукс не причем. до фара и мс был командир Нортон.
5. KRIHA 111 01.11.17 02:52 Сейчас в теме
(4) ааааааааа, об этом ))))))))
6. viptextil 41 02.11.17 11:15 Сейчас в теме
(3)
...команду, которая бы удаляла файлы, созданные ранее определенной даты-времени...


find /PathToFiles -type f -mtime +3 -exec rm {} \;

Удаляет файлы, созданные более трех дней назад.
teflon; as; +2 Ответить
7. KRIHA 111 02.11.17 14:48 Сейчас в теме
(6) Виктор, спасибо. Но я имел ввиду следующее - есть четкая граница по дата-времени - например 2017-11-02 02:00:00. Я хочу вбить в команду эту отметку и команда удаляет все что созданное ранее. А так - получается - нужно вашу команду запустить ровно в два часа ночи 5-го ноября. Я утрирую конечно :)).
8. viptextil 41 05.11.17 13:27 Сейчас в теме
(7) То, о чем Вы просите - ручной режим. Автоматизация предполагает выполнение определенных действий регулярно.
Если требуется очистка именно в 02:00:00, то cron это позволяет. В нем есть очень гибкие настройки. Если тонкости настроек не хватает, важно помнить, что с помощью cron, запускаются скрипты, уж там всяких условий понапихать можно.
9. KRIHA 111 06.11.17 12:12 Сейчас в теме
(8) да, тут есть о чем подумать. Если я правильно понял, вы говорите об автоматизации процесса создания новой базовой резервной копии в связке с удалением "лишних" WAL файлов, сформированных до нее (новой базовой резервной копии). Тогда да - загоняем все в скрипт и т.д. Пока знаний для этого у меня не достаточно.
10. Vismut 52 23.07.21 09:08 Сейчас в теме
Привет, можешь дать свои контактные данные? Есть вопросы по этой теме.
11. KRIHA 111 23.07.21 12:22 Сейчас в теме
нет, не могу дать, спрашивай здесь.
12. KRIHA 111 23.07.21 12:29 Сейчас в теме
или в личных сообщениях на этом ресурсе.
13. Vismut 52 25.07.21 12:56 Сейчас в теме
(12)
В лс не могу писать т.к новый пользователь
Поэтому буду писать сюда)
На работе дали задание сделать отказоустойчивую систему. Линукс начал изучать относительно недавно. Твоя статья идеально подходит, но в ней не написано про восстановление журналов. Я сейчас все это буду тестить, если будут вопросы отпишу.
Сама система должна выглядеть след образом:
Утром делается полный бэкап после чего через каждые 30 минут делается копия журнала и так каждый день, старые журналы удаляются на 2-е сутки
14. Vismut 52 30.07.21 10:55 Сейчас в теме
(12)

Делал по второй части твоей статьи. Как я понял это полный бэкап, а как делать бэкап журналов и их восстанавливать?
15. KRIHA 111 11.08.21 13:38 Сейчас в теме
ну как - у вас получается? расскажите
16. Vismut 52 11.08.21 15:27 Сейчас в теме
Да, написал статью https://infostart.ru/1c/articles/1495441/
Сейчас буду возиться с репликацией
17. KRIHA 111 11.08.21 15:48 Сейчас в теме
Плюсую. Я в свое время написал эту статью-шпаргалку для себя, когда у меня была задача и как админа\девопса помимо 1сничества на том месте работы, потом это стало не актуально (на другом месте работы) и я дальше не стал развиваться по части познания всех тонкостей postgres а на текущей работе у меня тоже postgres, но меня к администрированию полноценному сервака СУБД не пускают, то есть PGAdmin сижу и все. cron-ы бекапы и всякая иная хрень меня не волнуют - есть для этого штатные девопсы.
Но я вспоминаю ковыряние в centos и настройках postgres с теплом и нежностью.
18. mixasma 13 17.10.23 16:29 Сейчас в теме
А если в конфигураторе сделали изменения базы с добавлением например реквизита документа, репликация не останавливается?
19. KRIHA 111 19.10.23 10:03 Сейчас в теме
(18) имхо добавление реквизита и любые другие изменения базы данных не различимы для процессов СУБД
20. KRIHA 111 19.10.23 10:03 Сейчас в теме
Оставьте свое сообщение