Инфраструктура. Как сделать резервное копирование нетиповых баз данных «‎1С» на PostgreSQL

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

Напомним, что каталог public_html размещается:

• В корневой директории аккаунта — для основного сайта. В этом случае путь к конфигурационному файлу будет точно такой, как указано в наших примерах;
• В директории конкретного сайта — для всех дополнительных сайтов аккаунта. В этом случае путь к конфигурационному файлу будет начинаться с /директория_сайта/public_html/.

В этой статье мы привели пути размещения конфигурационных файлов для основных популярных CMS и указали строки, содержащие реквизиты подключения к БД.

При использовании нашего хостинга в качестве хоста базы данных будет указан localhost. Если же вы используете базу данных на удаленном сервере, в данном поле должен быть указан адрес соответствующего сервера.

Имя базы и имя пользователя базы данных должны совпадать.

Public-config

Various config files I want to keep synchronized between working environments. SHOULD NOT contain any proprietary code, OR any code that will be bundled with proprietary code.

Also contains various general-use scripts.

Installation instructions

You may get more out of these scripts if you «cherry-pick» them for individual features you want, especially if you already have your own set of config files that you typically use.

git clone https://github.com/BatmanAoD/public-config ~/public-config
~/public-config/install

Note that the install script does not automatically replace existing rc scripts, so you may need to delete them (e.g. rm -f ~/.bashrc) first.

To install tools (stderred, rustc/cargo, etc), use install —tools.

Config files included directly

• most rc files of the form ~/. are included in this directory simply
  as . To set up for use, make symlinks to them, then prepend a ..
• Note:
  .Xmodmap — Should probably be generated instead of included directly..Xkbmap — DEPRECATED, but possibly I should update it to replace .Xmodmap,
  since apparently it’s more portable.
• .Xmodmap — Should probably be generated instead of included directly.
• .Xkbmap — DEPRECATED, but possibly I should update it to replace .Xmodmap,
  since apparently it’s more portable.
• Various general-use scripts, which should be linked to in ~/bin; not
  exactly «config» files, but still used to configure a standardized
  working environment

Config to eventually include directly

• .i3/config
• crontab (how to generate programmatically?)

Other TODO items

• use local variables in Bash functions!
• Refactor .vimrc to give it some organization

Public config holds information okay to display to the world. Public config includes everything in the /opt/conf-meza/public directory. An example public config, as used by enterprisemediawiki.org, can be seen at https://github.com/enterprisemediawiki/emw.o-public-config

public.yml is the primary configuration file for Meza. It holds settings that are okay to display publicly, in contrast to secret.yml that holds sensitive information. public.yml can be used to override anything in defaults.yml. See defaults.yml on Meza’s GitHub repository.

Meza generates LocalSettings.php each time meza deploy is run, and therefore it is not possible to directly edit LocalSettings.php. Instead, configuration set in public.yml defines how LocalSettings.php will look. However, because MediaWiki has an essentially infinite number of settings that Meza can’t possibly account for, Meza has the ability to add to the beginning and end of LocalSettings.php via two directories.

sudo meza deploy monolith —tags mediawiki —skip-tags latest,update.php,verify-wiki,smw-data,search-index,parsoid,mediawiki-core

Any .php file within /opt/conf-meza/public/preLocalSettings.d/ will be included at the top of LocalSettings.php .

The directory /opt/conf-meza/public/postLocalSettings.d works similarly to preLocalSettings.d in that any *.php file in that directory will be appended to LocalSettings.php. However, this directory’s files will be loaded at the end of LocalSettings.php, and as such it is useful to override Meza’s defaults, or defaults set by extensions.

See Meza/Installing additional extensions

Within the public configuration directory (/opt/conf-meza/public) there is a subdirectory wikis/. This holds the individual configurations for each wiki. These directories hold the image file logo.png which is the logo in the top left of each wiki. Similarly you can modify favicon.ico here. Additionally, each wiki can have pre-LocalSettings.php and post-LocalSettings.php files that are loaded just for that wiki, in the same way as described above for all wikis. See section #Modifying_LocalSettings.php.

• ‘Your wiki name’
• $mezaDebug is used to turn debug settings on for all wikis
• $mezaEnableWikiEmail is used to define whether email should be turned on

The above permissions schemes are in ascending order of restrictiveness.

Generating a properly sized logo. png and favicon. ico from a file

To generate properly-sized logo.png and favicon.ico from an existing larger image file, see issue #410 on GitHub.

Adding a custom namespace to a wiki

// first define namespace constants. If you have a lot of wikis, and there’s
// possibility that you may want to have the same namespaces across wikis at
// some point, or even merge wikis together, you may want to put these in
// preLocalSettings for all wikis, e.g.

And create a postLocalSettings file like /opt/conf-meza/public/wikis/opot/postLocalSettings.d/customnamespace.php if you want the content searched by default:

В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2023. А также разберем проблемные ситуации и неожиданные ограничения при работе 1С в связке с PostgreSQL. Для Linux все аналогично.

Копирование-восстановление с помощью моментального снимка базы может потребоваться в разных случаях:
— копирование в другую базу в пределах кластера
— копирование в другую базу на другом сервере с более высокой версией PostgreSQL
— восстановление текущей базы
— восстановление некоторых таблиц текущей базы в случае падения 1С и т.д.

Задача 1. Копирование базы 1С на лету во время работы пользователей с сохранением целостности с помощью команд pg_dump.exe, psql.exe

Для этого в общем случае алгоритм следующий:

Шаг 1. Выгружаем с помощью pg_dump.exe все таблицы из базы данных, кроме данных таблицы config (т.е. для config выгружаем только ее схему)

Шаг 2. Выгружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY

— Шаг 1. Выгружаем с помощью pg_dump.exe все таблицы из базы данных, кроме данных таблицы config (т.е. для config  выгружаем только ее схему):

—role «postgres» — роль

—no-password – не спрашивать пароль в пакетном режиме

—format directory – создавать архив в виде каталога для использования параметра —jobs. При этом каждая таблица копируется в отдельный файл в каталоге, что позволяет распараллелить процесс создания архива

—blobs – позволяет выгружать поля большого размера

—encoding UTF8 — кодировка

—verbose – включить подробное комментирование

—exclude-table-data=config — исключить из выгрузки данные таблицы config, т.е. выгрузить только ее схему (config содержит записи: конфигурация, конфигурации поставщиков, отличия основной конфигурации от конфигураций поставщиков). Это требуется, когда база находится на поддержке у двух и более конфигураций поставщика и (или) очень много изменений внесено в конфигурацию. При этом размер изменений основной конфигурации относительно конфигурации одного из поставщиков приближается к 1Гб, что является пределом для поля большого размера в PostgreSQL. А 1С хранит изменения только в одной из записей таблицы config. При небольшом размере конфигурации можно не использовать этот параметр. Но при критическом (если размер хотя бы одной записи таблицы public.config (конфигурации) после чтения и распаковки в стандартный поток вывода stdout превысит 1 Гб) pg_dump.exe завершится с ошибкой:

pg_dump: Ошибка выгрузки таблицы «config»: сбой в PQgetResult().
   об ошибке с сервера: invalid memory alloc request size 11173708065
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;

Если используется —format custom, то архив выгружается в виде одного файла, и ошибка создания архива на таблице public.config обнаружится при выполнении команды pg_restore, что и есть самое неприятное:

(кроме того —format custom не позволит использовать —jobs — распараллеливание)

Наблюдается на больших конфигурациях KA 1.1-2.4, УПП 1.3, ERP 2.4.

Шаг 2. Выгружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY:

Задача 2. Восстановление базы 1С в копию во время работы пользователей с сохранением целостности с помощью команд pg_restore.exe, psql.exe. Для этого в общем случае алгоритм следующий:

Шаг 1. Загружаем с помощью pg_restore.exe все таблицы из архива базы данных, кроме данных таблицы config (т.е. для config  загружаем только ее схему)

Шаг 2. Загружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY

OWNER = postgres

ENCODING = ‘UTF8’

LC_COLLATE = ‘Russian_Russia.1251’

LC_CTYPE = ‘Russian_Russia.1251’

TABLESPACE = pg_default

Если мы время от времени хотим проверять, что база корректно достается из архива, то имеет cмысл автоматизировать шаг 0 в батнике командами psql, dropdb, createdb (добавлено по просьбам читателей):

—if-exists — проверка существования базы

—owner=»postgres» — владелец базы

—encoding=»UTF8″ — кодировка

—locale=»Russian_Russia.1251″ — устанавливает одновременно параметры LC_COLLATE и LC_CTYPE для базы данных.

—tablespace=»pg_default» — указывает табличное пространство, используемое по умолчанию.

Шаг 1. Загружаем с помощью pg_restore.exe все таблицы из архива базы данных, кроме данных таблицы config (т.е. для config  загружаем только ее схему):

братите внимание на

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

Соответственно при использовании просто COPY может выскочить следующая ошибка:

Postgres ERROR: Permission denied (не удалось открыть файл для чтения)

Заметим, что архив базы может быть успешно восстановлен на последующих версиях  В моем случае, я переносил базу с

Все проходило гладко. Трудности теоретически могут возникнуть в команде  т.к. она является платформо-зависимой

На реальной базе размером 380 Гб за счет распараллеливания было достигнуто ускорение при работе pg_dump — в 4 раза, при работе pg_restore — в 2,5 раза, что весьма существенно, когда процесс занимает несколько часов.

Было: 2 часа на копирование, стало 0,5 часа на копирование; было 10 ч на восстановление, стало 4 ч на восстановление.

После перехода на более мощный сервер получили еще более существенные результаты:
Было: 2 часа на копирование, стало 0,5 часа на копирование; было 10 ч на восстановление, стало 1 ч  40 мин на восстановление. То есть количество ядер процессора и более быстрые диски при тех же параметрах дают значительное ускорение. Теперь чтобы скопировать и развернуть нашу огромную базу требуется всего 2 часа!

СОВЕТ 1: периодически проверяйте (хотя бы раз в неделю) загрузку бэкапа в какую-нибудь тестовую базу и запускайте для проверки работоспособности режим конфигуратора 1С и рабочий режим. Тогда всегда будете уверены в своей архивной копии!

СОВЕТ 2: после отладки копирования и восстановления можно настроить Планировщик заданий (для Windows) на запуск нашего bat-файла по выбранному расписанию. Например, в 3:00 ночи ежедневно, пока никто из пользователей не работает.

С 4 по 6 февраля 2023 года в стенах Московского государственного университета состоится конференция по PostgreSQL – PGConf.Russia 2023. Ежегодно она собирает более 500 разработчиков, администраторов баз данных и IT-менеджеров для обмена опытом и профессионального общения.

На этот раз PGConf.Russia будет особенной. Инфостарт совместно с Postgres Pro организует на конференции секцию «Postgres+1C». Мы приглашаем участников сообщества посетить PGConf и даже выступить в качестве докладчика.

Самые популярные CMS

/public_html/bitrix/php_interface/dbconn.php$DBHost  = «localhost»;$DBLogin  = «имя_пользователя_БД»;$DBPassword  = «пароль»;$DBName  = «имя_БД»;

В более поздних версиях, начиная с 14, реквизиты подключения к БД также указываются в файле:

Drupal

В более старых версиях Drupal (6 и ниже) реквизиты указываются в строке $db_url:

Joomla

# указываем Шебанг на баш

#Задаем переменную на дату

#Задаем переменную на имя базы

#Задаем переменную на каталог резервного копирования

#Создаем резервную копию с исключением из выгрузки данных таблицы config

#pg_dump -U postgres —format=directory —jobs=4 —blobs —encoding UTF8 —verbose —exclude-table-data=config —file=$KATALOG $database

#Выгружаем таблицу Config

psql -U postgres —dbname=$database —command «COPY public.config TO ‘$KATALOG/public.config.sql’ WITH BINARY;»

Скрипт Восстановления PostgreSQL

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

#Задаем переменную на дату

#Задаем переменную на имя базы

#Задаем переменную на каталог резервного копирования

#Восстанавливаем базу данных

pg_restore -U postgres —verbose —dbname=$database —jobs=4 $KATALOG

#Восстанавливаем данные в таблицу Config

psql -U postgres —dbname=$database —command «COPY public.config FROM ‘$KATALOG/public.config.sql’ WITH BINARY;»

Предлагаем Вам посмотреть другие ролики:
Распаковочка. Установка сервера 1С:Предприятие и Postrge на операционную систему Linux
Как установить «1С» версии 8.3.21 на Ubuntu версии 22.04
Инфраструктура. Linux и Postgree достойная замена Microsoft

00:00:26 По какой причине возникает ошибка выделения памяти

00:02:10 Проверка базы

00:03:04 Создание резервной копии

00:05:53 Восстановление резервной копии

Прочие CMS

Для PrestaShop версии 1.7 и выше:

PunBB

/public_html/config.inicore.host = «localhost»core.login = «имя_пользователя_БД»core.password = «пароль»core.dbname = «имя_БД»