Примитивная инструкция PostgreSQL + 1C на Ubuntu 20.04.md

Введение

Ранее я рассказывал о том, как установить и настроить postgresql для работы с 1С, а затем как провести анализ производительности базы 1С и по возможности увеличить быстродействие. После успешного выполнения первых двух задач, мы можем приступать к эксплуатации системы. Когда рабочая база 1С уже на сервере, обязательно нужно настроить ее регулярный бэкап. Желательно так же периодически проводить очистку и переиндексацию sql базы. Это увеличит ее быстродействие. Выполнять эти операции лучше всего автоматически, в нерабочее время. Именно этим мы и займемся в этой статье.

Во время работы с базой данных postgresql в 1С необходимо периодически выполнять задачи по бэкапу базы данных и ее восстановлению. Для увеличения производительности рекомендуется регулярно проводить очистку, анализ и переиндексацию базы 1С. Для автоматизации процессов по архивации и обслуживанию я написал небольшие скрипты с пояснениями. Ими и хочу поделиться с вами.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.

Данная статья является частью единого цикла статьей про сервер Debian.

Знакомство с СУБД PostgreSQL было определено выходом версии платформы «1С:Предприятие 8.1», в которой была реализована поддержка СУБД PostgreSQL. Но все встречи с PostgreSQL проходили на резервном сервере (с ОС Linux), где методом тестового использования решался вопрос об использовании PostgreSQL в качестве СУБД для рабочей базы 1С. В это время на основном сервере (с ОС Linux) база 1С работала в файл-серверном режиме.

До поры до времени шел процесс перехода со старой системы на 1С — нормативно справочная информация была перенесена заранее, а в это время переносились текущие остатки. Количество пользователей (менее 10) и размер файла базы 1С (менее 3Gb) позволяли работать в файл-серверном режиме.

Шло время. Пользователи по мере внедрения переводились из старой системы в 1С. Количество пользователей росло. Размер файла базы данных тоже увеличивался в размере. Настало время подключать к базе 1С удаленных пользователей в терминальном режиме (FreeNX). Количество лицензий опять пришлось увеличить. Хорошо, что получилось поменять один ключ на ключ с большим количеством пользовательских лицензий и количество компьютеров для менеджера лицензий не увеличилось.

И тут произошло самое скучное — размер базы данных 1С вырос до неприличных размеров. Все вместе, количество одновременно работающих в 1С пользователей более 10 и размер файла базы данных 1С более 4Gb, стало очень негативно сказываться на производительности работы пользователей в 1С.

Настало время серьезного знакомства с возможностью размещения базы 1С в СУБД PostgreSQL. Пользуясь знакомством с СУБД PostgreSQL, переезд на SQL-версию размещения данных 1С прошел быстро и без жертв (сервер с ОС Linux).

Время шло. Размер системного каталога PostgreSQL с базой 1C достиг размера 35Gb. Размер dt-файла выгрузки базы 1С стал где-то около 1.2Gb, а развернутая база на его основе 16Gb. Пришло время придумать что-то еще для обеспечения производительной работы пользователей в 1С. Пользуясь документацией PostgreSQL, которая идет в комплекте с СУБД, оформилось две команды по обслуживанию базы «baza1c_81» в PostgreSQL. Эти команды выполняют сбор мусора, выполнение сбора статистики о базе данных для работы планировщика запросов, переиндексацию:

   REINDEX DATABASE baza1c_81 FORCE;
   VACUUM FULL VERBOSE ANALYZE;

(Хотя с FULL в первой команде лучше для себя определиться еще раз самостоятельно, http://wiki.PostgreSQL.org/wiki/VACUUM_FULL и в документации PostgreSQL см. VACUUM).

Далее дело техники. Определили время запуска. В воскресенье с 17-00 до понедельника 6-00 в базе никого не бывает. В cron отключаем ночное архивирование базы в это время (а архивировать лучше как средствами 1С, так и pgdump).

Первым шагом в cron добавляем строку для создания архива:
Запускаем crontab -e:

   0 17 * * 0 /var/lib/pgsql/backups/pgdump.sh

, где 0-мин, 17-час, *-день, *-месяц, 0-(день недели воскресенье);

Вторым шагом добавляем в cron строку выполнения первой команды :

   0 18 * * 0 /var/lib/pgsql/backups/vacuum.sh

, учтем 30 минут на работу pgdump.sh по созданию архива;

В vacuum.sh делаем стоп-старт сервера предприятия 1C, PostgreSQL, менеджера лицензий и VACUUM :

В vacuumdb.sh :

   #!/bin/sh
   psql -a -f /var/lib/pgsql/backups/vacuum.sql

В vacuum.sql :

   VACUUM FULL VERBOSE ANALYZE;

Команда по факту работает от 6 до 8 часов.

Вторым шагом добавляем в cron строку выполнения второй команды:

   30 3 * * 1 /var/lib/pgsql/backups/reindex.sh

,учтем время на работу vacuum.sh;

В reindex.sh все тоже, что и в vacuum.sh, за исключением одной строчки. Вместо su postgres -c /var/lib/pgsql/backups/vacuumdb.sh напишем su postgres -c /var/lib/pgsql/backups/reindexdb.sh.

В reindexdb.sh :

   #!/bin/sh
   psql -a -f /var/lib/pgsql/backups/reindex.sql

В reindex.sql :

   REINDEX DATABASE baza1c_81 FORCE;

И в каждый понедельник база готова к эффективной работе.

А время идет. Подумываем об использовании SSD-дисков для размещения WAL.

PS. Если начинаете править postgresql.conf, тогда после изменений убедитесь в успешном старте PostgreSQL c новым postgresql.conf.  Также необходимо убедиться в успешном создании архивной копии, лучше всего восстановив базу на резервном сервере из архивной копии.

URL:
Обсуждается: https://www.opennet.ru/tips/info/2417.shtml

Самая примитивная инструкция по установке PostgreSQL 14 + сервер 1C 8.3.20.1710 на Ubuntu 20.04

sudo apt update
sudo apt upgrade

sudo dpkg-reconfigure locales

sudo timedatectl set-timezone Europe/Moscow

timedatectl list-timezones

curl -o pgpro-repo-add.sh https://repo.postgrespro.ru/pg1c-14/keys/pgpro-repo-add.sh
sudo sh pgpro-repo-add.sh

apt-get install postgrespro-1c-14

systemctl --type=service grep postgres Пример вывода: postgrespro-1c-14.service

 Останавливаем PostgreSQLsudo systemctl stop postgrespro-1c-14 Удаляем файлы ранее созданного при установке кластера Вместо 1c-14 может быть другое название каталога, в зависимости от версии.rm -r /var/lib/pgpro/1c-14/data/ Инициализируем новый кластер для 1С с нужной локалью (не обязательно, если по умолчанию локаль в системе "ru_RU.UTF-8").sudo /opt/pgpro/1c-14/bin/pg-setup initdb --tune=1c --locale=ru_RU.UTF-8 Запускаем PostgreSQLsudo systemctl start postgrespro-1c-14

 listen_addresses = 'localhost'listen_addresses = 

 # IPv4 local connections: host all all 127.0.0.1/32 md5 IPv4 local connections:host all all 0.0.0.0/0 password
host all all 127.0.0.1/32 md5

 SUPERUSER PASSWORD ;

Технологическая платформа 1С:Предприятия (64-bit) для Linux

 Имя архива меняется в зависимости от версии платформы 1Сtar -xvzf server64_8_3_20_1710.tar.gz В итоге появится файл "setup-full-8.3.20.1710-x86_64.run" для установки. Он то нам и нужен. Запускаем.sudo ./setup-full-8.3.20.1710-x86_64.run

[16] Russian - Русский

Сервер 1С:Предприятия 8 [y/N] : y
Интерфейсы на различных языках - Русский [Y/n] :y

Пожалуйста, подождите пока программа установит 1С:Предприятие на ваш компьютер. Установка 0% ______________ 50% ______________ 100% #########################################
----------------------------------------------------------------------------
Завершена установка 1С:Предприятие на ваш компьютер.

sudo systemctl --type=service grep srv1cv83

 Добавляем ссылку на файл службыsudo ln -s /opt/1cv8/x86_64/8.3.20.1710/srv1cv83 /etc/init.d/srv1cv83 Включаем службуsudo systemctl srv1cv83
sudo systemctl restart srv1cv83 Проверяем результат, состояние службыsudo systemctl status srv1cv83

● srv1cv83.service - LSB: Starts and stops the 1C:Enterprise daemons Loaded: loaded (/etc/init.d/srv1cv83; generated) Active: active (exited) since Thu 2022-03-24 19:45:25 UTC; 1s ago Docs: man:systemd-sysv-generator(8) Process: 21186 ExecStart=/etc/init.d/srv1cv83 start (code=exited, status=0/SUCCESS)
Mar 24 19:45:20 app1cpg systemd[1]: Starting LSB: Starts and stops the 1C:Enterprise daemons...
Mar 24 19:45:20 app1cpg su[21230]: (to usr1cv8) root on none
Mar 24 19:45:20 app1cpg su[21230]: pam_unix(su-l:session): session opened for user usr1cv8 by (uid=0)
Mar 24 19:45:20 app1cpg su[21230]: pam_unix(su-l:session): session closed for user usr1cv8
Mar 24 19:45:25 app1cpg srv1cv83[21186]: Starting 1C:Enterprise 8.3 server: OK
Mar 24 19:45:25 app1cpg systemd[1]: Started LSB: Starts and stops the 1C:Enterprise daemons.

Знакомство с СУБД PostgreSQL было определено выходом версии платформы «1С:Предприятие 8.1», в которой была реализована поддержка СУБД PostgreSQL. Но все встречи с PostgreSQL проходили на резервном сервере (с ОС Linux), где методом тестового использования решался вопрос об использовании PostgreSQL в качестве СУБД для рабочей базы 1С. В это время на основном сервере (с ОС Linux) база 1С работала в файл-серверном режиме.

До поры до времени шел процесс перехода со старой системы на 1С. Ну это понятно — нормативно справочная информация была перенесена заранее, а в это время переносились текущие остатки, ну и так далее. Количество пользователей (менее 10) и размер файла базы 1С (менее 3Gb) позволяли работать в файл-серверном режиме.

Шло время. Пользователи по мере внедрения переводились из старой системы в 1С. Количество пользователей росло. Размер файла базы данных тоже увеличивался в размере.

Настало время подключать к базе 1С удаленных пользователей в терминальном режиме (FreeNX). Количество лицензий опять пришлось увеличить. Хорошо, что получилось поменять один ключ на ключ с большим количеством пользовательских лицензий и количество компьютеров для менеджера лицензий не увеличилось.

И тут произошло самое скучное — размер базы данных 1С в PostgreSQL вырос до неприличных размеров.

Все вместе — количество одновременно работающих в 1С пользователей более 10 и размер файла базы данных 1С более 4Gb, стало очень негативно сказываться на производительности работы пользователей в 1С.

Настало время серьезного знакомства с возможностью размещения базы 1С в СУБД PostgreSQL. Пользуясь знакомством с СУБД PostgreSQL, переезд на SQL-версию размещения данных 1С прошел быстро и без жертв (сервер с ОС Linux).

Время шло. Размер системного каталога PostgreSQL с базой 1C достиг размера 35Gb. Размер dt-файла выгрузки базы 1С стал где-то около 1.2Gb, а развернутая база на его основе 16Gb. И как-то пришло время придумать что-то еще для обеспечения производительной работы пользователей в 1С. Пользуясь документацией PostgreSQL, которая идет в комплекте с СУБД, оформилось две команды по обслуживанию базы PostgreSQL. Эти команды выполняют сбор мусора, выполнение сбора статистики о базе данных для работы планировщика запросов, переиндексацию :

VACUUM FULL VERBOSE ANALYZE;

REINDEX DATABASE baza1c_81 FORCE;

(Хотя с FULL в первой команде лучше для себя определиться еще раз самостоятельно, http://wiki.PostgreSQL.org/wiki/VACUUM_FULL и в документации PostgreSQL см. VACUUM).

Далее дело техники. Определили время запуска. В воскресенье с 17-00 до понедельника 6-00 в базе никого не бывает. В cron отключаем ночное архивирование базы в это время (а архивировать лучше как средствами 1С, так и pgdump). Помним о том, что в файле cron’а должна быть последняя пустая строка. Если файл cron’а редактировали во внешнем редакторе, тогда делаем crontab -e и в нем — :w, :q.

Первым шагом в cron добавляем строку создание архива :

0 17 * * 0 /var/lib/pgsql/backups/pgdump.sh, где 0-мин, 17-час, *-день, *-месяц, 0-(день недели воскресенье);

Вторым шагом добавляем в cron строку выполнения первой команды :

0 18 * * 0 /var/lib/pgsql/backups/vacuum.sh, учтем 30 минут на работу

Команда по факту работает от 6 до 8 часов.

Третьим шагом добавляем в cron строку выполнения второй команды :

30 3 * * 1 /var/lib/pgsql/backups/reindex.sh, учтем время на работу vacuum.sh;

Команда выполняется не более 1 часа.

И в каждый понедельник база готова к эффективной работе.

А время идет. Подумываем об использовании SSD дисков для размещения WAL. И знакомство с вариантом работы в 64-bit системе состоялось.

PS Если начинаете править postgresql.conf, тогда после изменений убедитесь в успешном старте PostgreSQL c новым postgresql.conf. А также необходимо убедиться в успешном создании архивной копии, лучше всего восстановив базу на резервном сервере из архивной копии.

Несколько замечаний про 2011 год.

Intel X25 —

А вот что это дало, сказать сложно, прошлые замеры были при одной базе, а сейчас в

их уже несколько. Да и база подросла. Вот отключить бы

и посмотреть, но на рабочем сервере это не получится

Но при следующем обновлении конфигурации возможно будут проблемы, которые можно решить прочитав //expert.chistov.pro/public/68793/.

Проблема : При формировании некоторых отчетов 1С вылетает с сообщением о выполняемых недопустимых действиях. Решаем эту проблему обновлением видеодрайвера, или в его свойствах отключаем аппаратное ускорение.

Проблема : Как только из 60 остается свободными 1-3 лицензии, тогда 1С у пользователя начинает сильно тормозить в своей работе. Решения пока не нашли.

Нуждаются ли базы 1С Предприятия на СУБД PostgreSQL в обслуживании ?

Особенно базы «среднего» и «большого» размера, с которыми интенсивно работают пользователи в 1С.

В этой статье мы подробно разберем этот вопрос, и дадим конкретный ответ на него!

Используя утилиту, мы экономим много времени, новички не «парятся» командами, передачей нужных параметров, ничего не пишут «руками» в консоли.

Конечно, данная тема также подымается и на курсе: Администратор 1С!

(К слову вот первая и вторая часть статьи).

Перед нами откроется окно в котором нам доступны различные настройки по обслуживанию базы данных.

Вверху мы видим «Операции» по обслуживанию, а ниже переключатели (они же параметры) по очистке.   

«Операции по обслуживанию» — VACUUM, ANALYZE, REINDEX, CLUSTER соответствуют командам и приложениям которые физически можно найти в папке Bin (Там где установили PostgreSQL).

«Зачем заниматься обслуживанием баз 1С на PostgreSQL?»

Если взять среднюю базу 1С в ~30 Гб которая работает на сервере PostgreSQL и посмотреть так сказать на нее из «внутри», то мы увидим многие избыточные записи их еще называю «мусорные».

Откуда они берутся и что это за записи?

Дело в том, что PostgreSQL самостоятельно не блокирует при изменении данных таблицы и записи от читающих транзакций, этим занимается сам сервер 1С «Кластер серверов».

Вместо этого создаётся копия изменяемой записи, которая становится видна последующим транзакциям, действующие же продолжают видеть данные, актуальные на начало своей транзакции. И в результате, в таблицах скапливаются  устаревшие данные — предыдущие версии измененных записей.

Эти записи лишь «мусор», который скапливается в базе и зря расходует дисковое пространство.

На больших базах, с которыми интенсивно работают пользователи (где много транзакций) это хорошо заметно, базы «распухают» и падает производительность.

Как от него избавится ?

Здесь нам поможет операция VACUUM!

VACUUM способна эффективно очистить базы от всего лишнего!

Простая операция VACUUM (без параметра FULL)

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

Другими словами если мы используем лишь команду VACUUM (без параметра FULL) пользователи могут продолжать работать в 1С, а если используем параметр VACUUM  + FULL, тогда выполняем ее, когда в базе 1С пользователи не работают. (Очень рекомендую делать именно так!).

Если мы говорим с Вами об обслуживании баз 1С Предприятия.

Тогда в приоритете будет использование команды VACUUM  + FULL!

Иначе если использовать просто команду VACUUM освобождённое место не возвращается операционной системе (в большинстве случаев так и происходит).

Оно просто остаётся доступным для размещения данных этой же таблицы.

 VACUUM  + FULL переписывает всё содержимое таблицы в новый файл на диске, не содержащий ничего лишнего, что позволяет возвратить неиспользованное пространство операционной системе. Эта форма работает намного медленнее и запрашивает исключительную блокировку для каждой обрабатываемой таблицы.

А вот еще несколько причин, по которым мы должны использовать VACUUM:

• Для высвобождения или повторного использования дискового пространства, занятого изменёнными или удалёнными строками.
• Для обновления статистики по данным, используемой планировщиком запросов PostgreSQL.
• Для обновления карты видимости, которая ускоряет сканирование только индекса.
• Для предотвращения потери очень старых данных из-за зацикливания идентификаторов транзакций или мультитранзакций.

Можно с уверенность сказать, что основная команда, которая позволяет улучшить производительность  1С в PostgreSQL это VACUUM  + FULL!

2.       «Планировщик запросов»

На СУБД PostgreSQL как впрочем, и в MS SQL, есть такая вещь (механизм) как «Планировщик запросов» (или «оптимизатор» как его еще называют), именно он занимается выбором плана для наиболее быстрого выполнения SQL запроса.

Какими данными руководствуется «Планировщик запросов» ?

«Планировщик запросов» для этих целей использует информацию о распределении данных в таблицах  и уже на основе этой информации строит наиболее оптимальный план выполнения SQL запроса.

Вот этому «Планировщику» мы и должны помогать!

Чтоб он смог строить оптимальные планы запросов, информация в таблицах наших баз данных должна быть актуальной то-есть обновленной!

И здесь нам на помощь приходит команда ANALYZE

ANALYZE также стоит выполнять вместе с VACUUM + ANALYZE! (Если мы говорим о базе 1С).

Выполнив ее, мы тем самим обновим информацию о распределении данных в таблицах.

Чем собственно и поможем «Планировщику запросов» строить свои оптимальные «Планы выполнения SQL запросов».

Иногда меня спрашивают, что же такое этот  «План выполнения SQL запроса» ?

План выполнения SQL запроса — это такая последовательность применения операторов реляционной алгебре к исходным и промежуточным отношениям, которое для конкретного текущего состояния БД (её структуры и наполнения) может быть выполнено с минимальным использованием вычислительных ресурсов.
    

3. «Порча индекса или постоянное увеличение его в размерах» 

Довольно часто в базах 1С «портятся» индексы или увеличиваются в размерах.

Операция REINDEX используется для перестройки существующих индексов.

Реиндексация  — переразмещает и переназначает номера записей, тем самым удаляя некоторый мусор который остаётся в файле, (но уже не нужен базе), упорядочивает, удаляет ошибки.

Почему «распухает» индексная таблица ?

Индекс, он как таблица, содержит блоки со старыми версиями записей. PostgreSQL не всегда может заново использовать эти блоки, и поэтому файл с индексом постепенно увеличивается в размерах. Если данные в таблице часто меняются, то вырасти он может очень быстро.

Следует учитывать, что команда REINDEX, как и VACUUM+FULL, полностью блокирует таблицу, поэтому выполнять её надо только тогда, когда в базе 1С никто не работает.

4. Бэкап и восстановление.

Конечно это не так!

Вы тем самым делаете одну из самых важных операций, по обслуживанию баз данных на СУБД PostgreSQL!

Что происходит во время создания и восстановления «бэкапа» средствами СУБД ?

Создание резервной копии базы средствами PostgreSQL  (выгрузка в dump)- скидывает все записи и структуры базы в файл, оставляет только самое нужное без «мусора».

Восстановление из бэкапа средствами (СУБД) restore — создаёт новый чистый файл базы и аккуратно по порядку укладывает все записи одновременно нумеруя их, соответственно без пустых пространств.

1. Dump и Restore занимает меньше времени чем операции VACUUM и REINDEX!
2. Делает дело качественнее, ускорение работы ощутимее (даже по сравнению с VACUUM!).
3. Иногда значительно сокращает размер самой базы за счёт аккуратной укладки.

Специалистам нужно использовать либо  “cron” или планировщик Windows, использовать набор команд и параметров, писать скрипт, создавать «батники».

Когда и какую операцию выполнять ?

Для примера: На средних базах ~30 гб и 100 пользователей.

1. ANALYZE (БЕЗ VACUUM!) — каждый день (Например, утром, еще до начала работы пользователей в 1С).
2. DUMP  (Резервное копирование) –  исчисляется в зависимости от того сколько времени работы в 1С Вы не можете позволить себе потерять.
3. REINDEX – Делаем раз в неделю для профилактики (Не обязательно, если индексы не «распухают» и делаете часто Dump / Restore).
4. VACUUM  + FULL + ANALYZE – Раз в неделю (лучше всего делать в конце рабочей недели например: пятница).

Так выполняя эти простые действия по обслуживанию баз данных в PostgreSQL, Вы обеспечите стабильную работу пользователей в 1С, улучшите производительность и исключите возможные ошибки.

 P.S. (CLUSTER и FREEZE для администрирования баз данных 1С, использовать не стоит).

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Рассмотрим создание пользователей и баз данных, а также (уже в третий заключительной части статьи) не пройдем мимо обслуживания баз на PostgreSQL.
Ведь как и в MS SQL информационные базы 1С на PostgreSQL, также нуждаются в обслуживании.

В прошлый раз мы закончили с базовыми настройками, подключились к серверу СУБД.
А это значит, что теперь можно создавать пользователя и базы для работы в 1С.

Зачем нам еще один пользователь, ведь у нас же есть наш root «postgres» ?
Создавая еще одного пользователя от имени, которого, мы будем подключать базы на сервере 1С (Кластер серверов) мы тем самым немного повысим безопасность подключения.

Почему немного ?

Давайте создавать такого.

Также на этой вкладке мы можем указать срок действия роли («Роль активна до»), что будет особо актуально для теста.

Часто взломы как раз и происходят на таких брошенных «учетках» слабые пароли делают свое дело.

Если Вам протестировать, тогда совет!  — Сразу ставьте срок действия!

И еще одна полезная опция, это «Максимальное число подключений».

Здесь также стоит ограничиться числом подключений к базе 1С. (Небольшой плюс в сторону безопасности).

И наконец, права. (Вкладка)

К сожалению, для нормальной работы в 1С, нам потребуются права «Суперпользователя».

А также обязательно установим переключатель «Вход разрешен?».

Все остальное можно игнорировать, так как работу по администрированию баз, мы будем выполнять от имени рута «postgres».

Вот теперь уже можно приступать к созданию ИБ в PostgreSQL.

Создавать новую базу для работы в 1С,  следует только с помощью утилиты администрирования кластера серверов (Сервера 1С).

Допускается также и ее создание на «Тонком» или «Толстом клиенте».

Как это сделать, можно посмотреть вот здесь >>.

Казалось бы зачем нам это нужно если базы следует создавать только средствами утилиты или клиента 1С?

А ответ кроется в восстановлении баз данных на СУБД PostgreSQL.

Нам будет нужна «новая база» для последующего восстановления.

Но к этому вопросу мы еще вернемся и разберем все подробно.

Теперь на вкладке «Общие» зададим имя, любое на Ваше усмотрение.

Главное чтоб Вам было понятно, что это за база и для чего она предназначена.

В нашем случаи имя базы  «replica» будет служить для нас «обложкой» для будущих восстановлений из бэкапа если такие потребуются.

(Сменить имя базы можно будет в любой момент.)

Другими словами мы ее создадим и оставим в покое до нужного случая. (Потом это существенно ускорит процесс восстановления из резервной копии).

Теперь идем на вкладку  «Определение» и выполним некоторые настройки.

Таблично пространство: «pg_default».

Правило сортировки: «Russia_Russia.1251».

Также мы можем ограничить число подключений к базе данных, указав соответствующее значение в строке — «Макс. число подключений».

Также хочу обратить Ваше внимание на поле: Шаблон.

Выбрав соответствующий шаблон, мы сможем быстро создать копию базы из него!

Теперь кликнув по кнопке «Сохранить» мы создадим новую информационную базу так сказать шаблон или «обложку» для будущих восстановлений.

Если Вы выполнили все те действия что описаны выше, тогда отлично! мы можем приступить к следующему шагу

Обычно, резервное копирование баз данных в PostgreSQL выполняется при помощи консольных утилит pg_dump и pg_dumpall.

Они будут установлены вместе с PostgreSQL и Вы всегда найдете их в каталоге Bin (Пример: C:\Program Files\PostgresPro 1C\9.6\bin).

Утилиты консольные! и запустив их на выполнение, Вы не увидите интерфейса.

Работать с ними нужно только передав параметры (Выполнив определенный скрипт).

Пример командного файла:

Что и будет для многих новичков весьма кстати!

Так как писать руками ничего не приходится, и все сводится до нескольких кликов мышкой.

pg_dump — это утилита позволяющая делать бэкап базы данных из postgresql. Она сохраняет в файл набор SQL команд которые полностью воссоздают структуру исходной базы данных.

При этом в один момент времени выполняется бэкап только одной базы данных и во многих случаях даже «на горячую».

То-есть когда в базе работают пользователи!

pg_dumpall — используется для бэкапа всего кластера, утилита создает резервную копию всех баз данных, а также сохраняет данные уровня кластера, такие как роли и определения табличных пространств, одним словом все.

«Имя файла» укажем путь к файлу, в который будет упакован наш «бэкап».

Рекомендую указать путь, где будет создан наш «бэкап», + имя файла указать в формате даты и базы которую резервируем. (Как на картинке ниже).

Так мы будем точно знать когда и какой «бэкап» сделали.

В поле «Имя файла»  — можно также указать и уже ранее созданный «бэкап» файла который будет в таком случаи просто перезаписан.

Далее формат! его нужно указать обязательно!

1. Специальный — этот формат архива рекомендуется для средних и больших баз данных, поскольку он по умолчанию сжимается.

2. Tar — этот формат рекомендую выбирать для малых баз и + надежность!

(Коэффициент сжатия в таком случаи оставляем пустое значение , так как Tar не поддерживает сжатие).

(Tar — это файл архива).

3. «Простой» формат нужен, чтоб создать файл сценария с открытым текстом. Будет создан файл сценария с открытым текстом, который содержит инструкции и команды SQL. Файл резервной копии в  «Простом» формате можно отредактировать в текстовом редакторе при необходимости. (Не рекомендую этот формат для «бэкапа» баз 1С!!!).

4. Каталог, этот формат предназначен, чтобы создать архив в формате каталога.

Этот формат файла создает каталог с одним файлом для каждой таблицы и сбрасывается blob! (blob — крупные объекты в резервной копии.) а также файл оглавления, описывающий сбрасываемые объекты в машиночитаемом формате, который может читать pg_restore (Утилита восстановления из резервной копии). Этот формат сжимается по умолчанию. (Не рекомендую его для «бэкапа» баз 1С!!!).

Коэффициент сжатия — здесь можно указать значение коэффициента от 0..до..9, или оставить поле пустым (Кроме Tar).

Кодировку  — указывать не нужно.

Число заданий — указывать не нужно

Число заданий — настройка позволяет указать количество таблиц, которые будут сбрасываться одновременно в параллельной резервной копии. (Оставим пустое).

Имя роли нужно указать рута «postgres».

Настройки на вкладке «Параметры выгрузки» трогать не стоит. (Оставляем их по умолчанию так как у нас база 1С).

«Параметры выгрузки» позволяют лишь ограничить «бэкап», сделать его не полным, что конечно недопустимо в 1С.

После того как все нужные поля заполнены, выполним клик по кнопке «Резервная копия».

Если кликнуть по ссылке «Щёлкните здесь для подробностей», то можно увидеть процесс создания резервной копии онлайн, а также скрипт, что отрабатывает в дынный момент в pg_dump.

Вот и все! резервная копия успешно создана!

Теперь мы можем приступить к восстановлению базы из созданной ранее резервной копии.

Вот и пришло время обратится к нашей чистой базе «обложке»  «replica».

На нее мы накатим наш «бэкап» базы «buh_3».

Формат оставляем по умолчанию «tar или специальный» собственно который и рекомендуется для баз 1С Предприятия.

Имя файла — путь к файлу резервной копии.

Число заданий — оставим пустое.

Имя роли — наш рут «postgres».

Затем клик по кнопке «Восстановить».

Восстановление баз данных в PostgreSQL (в основном, если не текстовый формат «бэкапа») выполняется при помощи утилиты pg_restore.exe.

Утилита  предназначена для восстановления базы данных  из архива, созданного утилитой  в любом из не текстовых форматов. Она выполняет команды, необходимые для восстановления того состояния базы данных, в котором база была сохранена. При наличии файлов архивов,  может восстанавливать данные избирательно или даже переупорядочить объекты перед восстановлением. Примечательно, что разработанный для файлов архива формат не привязан к архитектуре.

Как и создание «бэкапа», так и его восстановление можно подробно отслеживать в онлайне.

Процесс восстановления базы в PostgreSQL не быстрый. И даже чтоб восстановить базу размером всего на ~600 mb ушло (как видите на картинке ниже) — 106 секунд.

Теперь дело за малым.

Удалим старую базу «buh_3» и переименуем «replica» на «buh_3«.

Учтите, что удалить или переименовать базу, в которой продолжают работать пользователи невозможно!

Затем после удаления старой базы «buh_3», сменим имя «replica» на «buh_3» через «Свойства» базы.

Вот и все!

Мы успешно восстановили базу из ранее созданной резервной копии.

В некоторых случаях (и для малых баз 1С), допускается выполнять такие операции руками, но помните, что так Вы рискуете забыть сделать актуальную резервную копию, существует риск, что сработает обычный «человеческий фактор»! 

Конечно для организации «правильных бэкапов»,  процесс создания резервной копии должен быть автоматизирован.

Другими словами резервная копия должна выполнятся автоматом без нашего участия.

Если мы говорим о Windows и новичках администраторах 1С, тогда несомненно лучшим выбором будет программа  

Это бесплатный софт (Две базы бесплатно) со встроенным планировщиком, который запросто можно настроить для автоматического резервного копирования баз 1С на PostgreSQL.

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Обновление статистики и реиндексация в postgresql

С бэкапами разобрались, теперь настроим регламентные операции на уровне субд, чтобы поддерживать быстродействие базы данных. Тут особых комментариев не будет, в интернете очень много информации на тему регламентных заданий для баз 1С. Я просто приведу пример того, как это выглядит в postgresql.

Выполняем очистку и анализ базы данных 1С:

# vacuumdb --full --analyze --username postgres --dbname base1c

Реиндексация таблиц базы данных:

# reindexdb --username postgres --dbname base1c

Завернем все это в скрипт с логированием времени выполнения команд:

# cat /root/bin/service-sql.sh

#!/bin/sh
# Записываем информацию в лог
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start vacuum base1c" >> /var/log/postgresql/service.log
# Выполняем очистку и анализ базы данных
/usr/bin/vacuumdb --full --analyze --username postgres --dbname base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End vacuum base1c" >> /var/log/postgresql/service.log
sleep 2
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start reindex base1c" >> /var/log/postgresql/service.log
# Переиндексирвоать базу
/usr/bin/reindexdb --username postgres --dbname base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End reindex base1c" >> /var/log/postgresql/service.log

Сохраняем скрипт и добавляем в планировщик. Хотя я для удобства сделал еще один скрипт, который объединяет бэкап и обслуживание и уже его добавил в cron:

# cat all-sql.sh

#!/bin/sh
/root/bin/backup-sql.sh
sleep 2
/root/bin/service-sql.sh

Добавялем в /etc/crontab:

# Бэкап и обслуживание БД
1 3 * * * root /root/bin/all-sql.sh

Проверяем лог файл и наличие бэкапа. Не забывайте делать проверочное регулярное восстановление бд из архива.

Использование программы PostgreSQL Backup

Для бэкапа базы данных постгрес есть удобная и бесплатная для двух баз программа под windows — PostgreSQL Backup. Я ее установил, проверил, сделал бэкап, потом восстановил из бэкапа. Все отлично работает. Из полезных функций:

• встроенный планировщик
• автоматическое сжатие бэкапа
• отправка оповещений на email

Программа, простая, понятная и приятная на вид. Попробуйте, возможно вам будет достаточно такого варианта. К сожалению, она не умеет восстанавливать из бэкапа. Для этого архив придется перенести на сервер, распаковать и загрузить в базу через консоль, как я показывал выше.

Создание базы 1С через клиентское приложение

Для создания базы через клиент 1С нужно открыть клиент, нажать кнопку Добавить

Откроется окно в котором нужно выбрать создать базу или добавить существующую, если она была создана через консоль администрирования можно выбрать Добавление существующей базы, при этом нужо будет указать только сервер и имя базы.

Затем нужно выбрать как будет создана база из шаблона или с нуля

В этом окне указывается название базы, которое будет отображатся в списке клиента и выбирается где будет расположена база

В этом окне указываются характеристики базы

В последнем окне указываются дополнительные параметры при необходимости

В файле ibases.v8i, который находится по пути

%AppData%\1C\1CEStart

Создание базы в PostgreSQL бэкап и восстановление ее из dump с помощью pg_dump и pg_restore

sudo su - postgres

Бэкап с помощью pg_dump

pg_dump -Fc BASENAME > /DIR/BASENAME.dump

sudo su - postgres

Создать базу на основе пустого шаблона

createdb -T template0 BASENAME

Вывести список баз

psql -l

Восстановление базы из .dump

pg_restore -d BASENAME /DIR/BASENAME.dump

После создания базы таким образом ее необходимо добавить в кластер через консоль управления кластером, сделать это можно тем же путем, что и при создании базы через консоль.

Автоматизация бэкапа

Можно сделать, чтоб бэкап создавался автоматически в определенное время для этого воспользуемся службой cron
Для создания скрипта создадим файл

touch /DIR/script-pg_dump

В этом файле введем команду для удаления бэкапов старше 30 дней и саму команду бэкапа

#!/bin/bash
find /DIR -mtime +30 -delete
pg_dump -Fc DBNAME > "/DIR/FILENAME--$(date +%Y-%m-%d_%H-%M).dump"

теперь нужно сделать файл исполняемым

chmod ugo+x script-pg_dump

Открыть конфигурационный файл cron

vim /etc/crontab

В открывшемся окне ввести время запуска, пользователя и путь

минуты часы 0 0 0 <пользователь> <путь к файлу скрипта>
52 13 * * * postgres /home/script-pg_dump

Лог cron можно посмотреть по пути

/var/log/cron

Также при ошибках могут приходить сообщения в

/var/spool/mail/root

Создание базы 1С через консоль управления кластером

Открыть консоль управления кластером 1С, затем в дереве открыть ⇒ Console Root ⇒ Центральный сервер 1С ⇒ Кластер ⇒ Информационные базы, нажать ПКМ ⇒ Создать ⇒ Информационная база

После непродолжительного ожидания, если все хорошо база будет создана, при возникновении проблем выведется окно с ошибкой.

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

Бэкап и восстановление базы 1C в бд postgresql

Способов бэкапа базы данных postgresql много. Я буду использовать самый простой — выгрузка базы данных в обычный текстовый sql скрипт с помощью pg_dump. Подробно о работе этой утилиты и ее настройках можно прочитать вот тут — https://postgrespro.ru/docs/postgrespro/9.6/app-pgdump. В сети много примеров и готовых скриптов для решения вопроса архивации баз postgresql. Например, есть вот такой скрипт. Когда я его увидел, мне просто стало лень с ним разбираться. Написать простенький свой мне гораздо проще.

Прежде чем делать непосредственно архив 1С базы, нам нужно разрешить подключаться локально к серверу бд без авторизации. Я единственный пользователь сервера, доступа к нему никто больше не имеет, в интернет он не опубликован, поэтому я сознательно иду на этот шаг, чтобы упростить себе работу. Если для вас этот вариант не подходит, то все дальнейшие скрипты вам нужно будет самим изменить, добавив в них авторизацию. Это не сложно, в описании команд все есть. Я буду все команды выполнять локально от пользователя root.

Редактируем в файле /etc/postgresql/9.6/main/pg_hba.conf строку, приведя ее к такому виду:

local   all             all                                     trust

После этого надо перезапустить постгрес, чтобы изменения вступили в силу.

# systemctl restart postgresql

Бэкап базы данных выполняется простой командой:

# pg_dump -U postgres base1c | pigz > /backup/base1c.sql.gz

Обращаю внимание на архиватор pigz. Я его использую, потому что он умеет жать данные, нагружая все ядра процессора, в отличие от gzip. Прирост производительности 2-3 раза. Рекомендую. На debian он ставится из стандартного репозитория:

# apt-get -y install pigz

В centos из epel:

# yum -y install epel-release
# yum -y install pigz

Попробуйте вручную в консоли выполнить команду и посмотреть на результат. Вы должны получить заархивированный файл с текстовыми sql командами в открытом виде. Теперь попробуем восстановить базу данных 1С из архива. Тут будут нюансы. Первым делом разархивируем файл:

# unpigz /backup/base1c.sql.gz

Файл будет распакован, а архив удален. Чтобы сохранить архив, можно использовать такую команду:

# unpigz -c /backup/base1c.sql.gz > base1c.sql

Создадим на сервере новую базу данных, в которую будем восстанавливать резервную копию. Перед этим посмотрим список баз данных на сервере:

# psql -U postgres -l

Создаем новую базу данных:

# createdb --username postgres -T template0 base1c-restored

Смотрим, что получилось:

Базу данных создали. Теперь загружаем в нее наш бэкап 1с:

# psql -U postgres base1c-restored < /backup/base1c.sql

Ждем приличное время. Оно будет зависеть от размера базы. После того, как восстановление завершено, можно идти в консоль кластера 1С и добавлять новую базу, указывая в качестве базы postgresql только что созданную базу с загруженным архивом.

После создания бэкапа, обязательно проверьте, восстанавливается ли из него база. Отработайте этот момент, протестируйте и запишите куда-нибудь всю последовательность действий. По своему опыту знаю, что если сразу это не проделать, то через полгода-год, совершенно забываешь как ты все организовывал. Приходится заново разбираться и искать информацию, как же восстанавливать базу из архива. Помимо этого, рекомендую регулярно проверять возможность успешного восстановления из бэкапа. Для этого можно отдельный скрипт приспособить, но на всякий случай все равно нужно вручную заходить в базу и лично убеждаться, что она работает.

После того, как вы убедитесь, что все в порядке, можно написать небольшой скрипт, который мы добавим в cron для регулярного бэкапа нашей базы 1С. Я его сделал совсем простым, ничего лишнего, только 1 база. Я считаю, что если баз не много и вручную не представляет труда написать несколько строчек скрипта, то лучше все сделать без циклов и лишних переменных. Если у вас больше одной базы, то просто скопируйте строки и замените названия баз. Вот сам скрипт:

# cat /root/bin/backup-sql.sh

#!/bin/sh
# Устанавливаем дату
DATA=`date +"%Y-%m-%d_%H-%M"`
# Записываем информацию в лог с секундами
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup base1c" >> /var/log/postgresql/service.log
# Бэкапим базу данных base1c и сразу сжимаем
/usr/bin/pg_dump -U postgres base1c | pigz > /backup/$DATA-base1c.sql.gz
echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup base1c" >> /var/log/postgresql/service.log
# Удаляем в папке с бэкапами архивы старше 3-х дней
/usr/bin/find /backup -type f -mtime +3 -exec rm -rf {} \;

Я указал в названии файла с бэкапом 1с базы использовать текущую дату с точностью до минуты. В лог я пишу информацию с точностью до секунды, чтобы было точно видно, сколько длился бэкап. Просто для справки информация, можно обойтись и без лога совсем. В конце удаляю из папки все архивы старше 3-х дней. Я обычно сервером с бэкапами забираю информацию с целевых хостов. То есть я буду подключаться к sql серверу и забирать с него архивы и уже на сервере бэкапов буду их хранить и ротировать в зависимости от желаемой глубины архива. А здесь я удаляю почти сразу архивы, не храню их, чтобы не занимать место. Если вы будете хранить их долгосрочно на этом же сервере, то просто измените цифру 3 на нужное вам число дней, за которые вы хотите иметь архивную копию своей базы 1С.

Заключение

Вот и все, что я хотел рассказать по поводу бэкапа и обслуживания баз postgresql в связке с 1С. Если у кого есть еще полезная информация, прошу поделиться в комментариях. Возможно с бэкапом есть какие-то нюансы, особенно на больших базах. Но мне негде тестировать, больших рабочих баз более 10 гб у меня нет под рукой, а с теми что были, все отлично работает.

Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Если у вас есть желание научиться администрировать системы на базе Linux, но вы с ними никогда не работали и не знакомы, то рекомендую начать с онлайн-курса «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Цена за курс минимальная (символическая). Информация о курсе и цене.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.