Развернуть копию базы 1с postgresql из бэкапа
Настройка непрерывного архивирования в PostgreSQL 9.6
Для возможности восстановления кластера СУБД PostgreSQL и его баз данных на момент времени необходимо обеспечить наличие:
Следует обратить внимание, что утилиты pg_dump и pg_dumpall создают логическую копию, которая не содержит информации для дальнейшего воспроизведения журнала транзакций и потому не подходит для решения задачи восстановления Point-in-Time.
Наиболее простым способом получения базовой резервной копии является утилита pg_basebackup , создающая копию файловой системы всего кластера.
Наличие непрерывной последовательности архивированных файлов WAL, начинающихся не позднее момента создания файловой резервной копии, позволит после восстановления данных из файловой копии воспроизвести журнал на нужный момент времени и привести систему в состояние на этот момент.
Настройка и выполнение резервного копирования
1 - Включаем архивирование WAL на уровне сервера.
В конфигурационном файле postgresql.conf меняем настройки:
wal_level = replica
archive_mode = on
archive_command = 'copy "%p" "C:\\PostgreSQLBackup\\%f"'
- команда, которая будет выполняться при архивировании WAL в момент переключения на его следующий сегмент. Параметр %p автоматически заменяется полным путём к файлу, подлежащему архивации (. \pg_xlog), а %f - именем файла. C:\PostgreSQLBackup\ в данном примере - путь к директории, куда будет производиться архивирование WAL.
В качестве archive_command может быть также указан скрипт, описывающий более сложную логику операций - архивирование файлов, пакетная передача и др., например:
archive_command = 'local_backup_script.sh "%p" "%f"'
В случае, если переключение на следующий сегмент лога и последующее архивирование происходит слишком редко ввиду невысокой интенсивности работы кластера, можно установить значение параметра:
- период в секундах, по достижении которого переключение на новый сегмент произойдет принудительно.
(значение по умолчанию - 0, значение 5 указано в качестве примера и технически может быть любым, отличным от 0)
Необходимо обратить внимание, что в случае, если для кластера существует hot_standby -реплика, которая уже является получателем WAL-архивов, значение параметра max_wal_senders , определяющего количество процессов, выполняющих передачу WAL, должно быть не менее 2.
В конфигурационном файле pg_hba.conf разрешаем пользователю, под которым будет выполняться архивирование, подключение для репликации:
host replication postgres ::1/128 md5
host replication postgres 127.0.0.1/32 md5
Выполняем перезапуск службы сервера.
2 - Приступаем к созданию базовых резервных копий.
Если для кластера включена hot_standby-реплика, лучше использовать именно её для создания резервных копий, чтобы не нагружать master-сервер. Алгоритм выполнения на ведомом сервере будет таким же, но есть несколько настроек, которые необходимо дополнительно выполнить на slave-сервере (описаны в документации к утилите pg_basebackup ).
pg_basebackup -D "D:\Backup" -X fetch - F tar
-D - директория, куда будет скопировано содержимое каталога ..\data. Она должна быть пустой
-F - формат. В данном примере значение tar означает, что содержимое будет добавлено в архив
-X - метод копирования файлов WAL, созданных в процессе создания копии. Значение fetch означает, что файлы будут скопированы в конце процесса.
Выполнение восстановления
Для выполнения восстановления с использованием полной резервной копии и архива WAL необходимо:
1. Остановить сервер баз данных PostgreSQL.
2. Удалить (а лучше - скопировать во временную директорию) содержимое текущего каталога кластера баз данных (. \data).
3. Восстановить (скопировать) файлы необходимой архивной копии, созданной ранее, в текущий каталог данных кластера (…\data). Файлы WAL в директории \ pg_xlog нужно удалить (или заменить на содержимое каталога, скопированного в п.2)
4. Создать конфигурационный фай recovery.conf. В качестве основы можно взять расположенный обычно в директории …\share файл recovery.conf.sample. В нем необходимо выполнить настройку:
restore_command = 'copy "C:\\PostgreSQLBackup\\%f" "%p"'
- команда, которая будет выполняться для получения созданных ранее архивов WAL (действие, обратное выполняемому командой archive_command в postgresql.conf). Важно, чтобы в случае ошибки restore_command возвращала ненулевой код. По аналогии с archive_command, можно указать в качестве команды скрипт с более сложной логикой.
После запуска сервера получение архивов и их воспроизведение (с помощью команды выше) по умолчанию будет выполняться до последнего файла WAL. Если нужно выполнить восстановление на конкретную точку, эту точку нужно указать в файле recovery.conf .
Например, для восстановления на момент времени:
Или для восстановления на именованную точку:
Такую точку можно создать, например, выполнив в контексте любой из баз кластера запрос:
5. Запустить сервер баз данных. Он будет запущен в режиме recovery и начнет процесс восстановления. По завершении сервер переименует файл recovery.conf в recovery.done и начнет работать в обычном режиме, в том числе разрешит подключения к нему. Если на время выполнения проверки после восстановления нужно запретить соединения с сервером, это лучше всего сделать в конфигурационном файле pg_hba.conf.
Обеспечение возможности быстрого возврата системы в состояние "до изменений"
В процессе эксплуатации часто возникает необходимость перед выполнением каких-либо изменений системы обеспечить возможность их быстрой отмены. При этом создание дополнительного полного бэкапа не всегда возможно (например, могут быть ограничены ресурсы файлового хранилища, процесс копирования может занимать слишком длительное время и др.). По сути для корректного возврата системы в требуемый момент времени необходимо, чтобы в точке восстановления все изменения в базе данных были сброшены на диск и выполнился checkpoint - контрольная точка.
Один из самых простых возможных сценариев решения такой задачи предполагает использование функции резервного копирования pg_start_backup() , которая вместе с pg_stop_backup() используется в утилите pg_basebackup , описанной выше, с той разницей, что утилита автоматически выполняет физическое копирование кластера в соответствии с параметрами, а ручной вызов возлагает ответственность за создание копии на администратора системы и позволяет физическое копирование "пропустить".
Перед выполнением изменений системы :
1. Убеждаемся, что архивирование WAL включено.
2. Подключаемся к серверу баз данных в контексте любой из баз и выполняем запрос:
select pg_start_backup('our_label', true);
Первым параметром указываем имя метки, которое потом будем использовать при восстановлении. Второй параметр означает, что checkpoint будет осуществлен как можно скорее независимо от настроек параметра checkpoint_completion_target.
Далее мы как раз должны были бы выполнить копирование каталога данных, но в данном случае это нам не нужно - можно приступить к плановым изменениям. Перед этим целесообразно сделать снимок виртуальной машины - это не требует много ресурсов, но повысит надежность. Кроме того, снимок можно будет быстро развернуть в тестовом контуре, если это потребуется (конечно же, это никак не заменяет регулярные полные бэкапы кластера).
В случае необходимости отката изменений далее действия не будут отличаться от алгоритма восстановления, описанного выше, за тем исключением, что не нужно удалять каталог кластера и копировать на его место резервную копию - достаточно просто запустить сервер в режиме восстановления, указав в файле recovery.conf созданную метку в качестве recovery_target_name .
Если отмену делать не нужно, выводим сервер из режима резервного копирования, выполнив:
В интернете куча статей, как установить PostgreSQL и залить в него базу из dt.
Но столкнулся с проблемой резервного копирования и восстановления базы средствами PostgreSQL.
т.е. при восстановлении базы сыпались ошибки, и восстановленная копия базы не работала.
Ошибочный алгоритм.
1. Делаем резервную копию скриптом или с помощью pgAdmin III --- получаем файлик bkp.
2. Создаем пустую базу средствами 1С сервера.
3. Восстанавливаем резервную копию скриптом или с помощью pgAdmin III в базу, созданную на шаге 2.
и болт : во время восстановления уже видны ошибки и восстановленая копия получается не рабочая (в конфигуратор пускает, но в предприятие уже не войти, "ошибка аутентификации пользователя" и т.п.)
Правильный алгоритм.
1. Делаем резервную копию скриптом или с помощью pgAdmin III --- получаем файлик bkp.
Пример командного файла :
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "c:\1c_base.backup" "1c_base"
где "1c_base" - имя базы
"c:\1c_base.backup" - имя файла резервной копии
2. Создаем пустую базу средствами Postgre - Я делал pgAdmin III -ом. (и пока не добавляем ее через "Администрирование сервера 1С" )
3. Восстанавливаем резервную копию скриптом или с помощью pgAdmin III в базу созданную на шаге 2.
Пример командного файла :
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\pg_restore.exe" --host localhost --port 5432 --username "postgres" --dbname "1c_base_copy" --role "postgres" --no-password --section pre-data --section data --section post-data --verbose "C:\ 1c_base.backup"
где "1c_base_copy" - имя пустой базы, созданой в шаге 2 средствами PostgreSQL
"c:\1c_base.backup" - имя файла резервной копии
4. Добавляем базу созданную на шаге 2 с восстановленной информацией в список баз на сервере 1С через остнастку "Администрирование сервера 1С".
Вот и все . Всем удачного дня .
Специальные предложения
Текстовые файлы, созданные pg_dump предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:
где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой , так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_БД)
PostgreSQL не восстанавливает текущую базу из дампа.
Поэтому, я восстанавливаю базу так:
dropdb имя_базы
createdb имя_базы
psql имя_базы < файл_дампа
Мой скрипт восстановления для Linux (работает под пользователем postgres):
if [ -z "$1" ] ; then
echo "Скрипт восстановления базы 1С. Параметры: 1 имя директории бэкапа, 2 имя базы 1С" 1>&2
exit
fi
dropdb $base_name
createdb $base_name
gunzip -c $archive_name | psql $base_name
У нас с восстановлением базы из дампа проблем вроде не вылезает, не ругается:
dropdb -U postgres [имя базы]
createdb -U postgres [имя базы]
pg_restore -U postgres -d [имя базы] [имя файла]
Для разграничения архивов по дням: namebase_backup_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup
Если у пользователя установлен пароль: SET PGPASSWORD=123
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\ut11_backup_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "ut11"
pg_dump — это программа для создания резервных копий базы данных Postgres Pro. Она создаёт целостные копии, даже если база параллельно используется. Программа pg_dump не препятствует доступу других пользователей к базе данных (ни для чтения, ни для записи).
Нет, нельзя. Одна операция в 1с меняет данные во многих sql таблицах. Бэкап базы существеннен по времени и у вас нет гарантии, что данные за это время не изменятся. Вы сделаете несколько бэкапов и они будут рабочие, но однажды попадете на восстановление данных.
(14) Не вводите людей в заблуждение.
Не только можно, но и в большинстве случаев это единственный вариант. Например если база весит пару терабайт, работает 24/7/365 и каждый час простоя стоит N килобаксов.
А по поводу длительности операции - там снэпшот создается, так что итоговый бэкап получается вполне себе консистентным.
Не знаю как насчет терабайт, а вот с базой 300Гб (select pg_database_size('base');), которая используется 24/7/365, я сначала был такого же мнения как и вы. Бэкап делался минут 40, в течении которых пользователи плевались и матерились, т.к. предприятие тормозило еще как. Так вот в один прекрасный день, когда неудачно прошло обновление конфигурации и база отказалась запускаться, пришлось воспользоваться самым свежим бэкапом, сделанным таким путем, и каково же было мое недоумение, когда он загрузился без проблем, но при открытии в 1с счет фактур предприятие вылетало. Вы можете возразить, что мол кеши надо было чистить, но все это конечно было сделано. Сейчас система переделана. Два сервера: один мастер, другой слейв. Когда нужно сделать бэкап, слейв теряет соединение с мастером, к нему подключается сервер 1с предприятия и средствами 1с делают бэкап. После этого слейв подключается к мастеру и синхронизируется.
Снепшот может и создается (хотя не уверен, а проверять ваши слова лень), но это снепшот sql базы. А вот 1с в этот момент может что-то активно писать и поменять данные в 1 таблице sql, и тут произойдет снепшот sql, а еще в 10 таблицах не успеет поменять, хотя должна, чтобы поддерживать свою логику. Вы же знаете, что одно добавление в регистр записи, может запускать множество других регистраций и каждая из них будет запускаться как одна транзакция в sql. Поэтому данные в базе у вас обязательно испортятся. Возможно база у вас и загрузится и даже работать будет, но данные будут неполными и это аукнется позже.
(16), А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения? Вы считаете что все движения, связанные с проведением документа в 1С происходят в одной 1С транзакции?
А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения?
Я говорил про сервера postgresql, а не 1с. Уверенности конечно нет, но т.к. бэкап делается средствами 1с, то 1с при обнаружении испорченных данных в документе его просто не выгрузит в бэкап. В результате структура базы будет цела, правда за минусом документа.
Ага, не понял вас сразу. То есть фактически плюсом этого решения является то, что боевая база не тормозит в момент бэкапа? Но вот в плане надёжности такого решения я испытываю сильные сомнения. В момент обрыва связи между серверами postgre вероятность потерять данные не меньше чем при снепшоте. То что потом бэкап делается средствами 1С не панацея. Сталкивался я со случаями, когда бэкап из dt не разворачивался из-за сбойных данных внутри.
Добрый день,
Выполнял выше указанные скрипты. Дамп отрабатывает без ошибок, но при попытки сделать восстановление в пустую созданную БД отрабатывает не корректно с ошибками, база не запускается.
Так же создаю резервные копии как писали в коментах.
Но есть один вопрос. Иногда требуется срочно восстановить какую нибудь копию базы за определенный день. с командной строки я ее восстанавливаю в новую базу созданную посредством psql, но в 1ске то она не появиться надо вручную ее создать или с помощью 1с или через консоль администрирования 1с. А как через командную строку создать базу в 1с?
Хотелось бы рассказать про еще один "чудесный" способ передачи файла с дампом базы от облачного хостера 1С сервера. Возможно это сможет кому-то съэкономить часов 5 драгоценного времени, особенно для таких как я, которые за 15 лет работы с 1С - за ненадобностью postgre в глаза не видели, да и с линуксообразными тоже не особо.
Речь пойдет про Windows платформу, а именно server 2012.
Съезжая с хостинга клиент попросил отдать ему выгрузку базы 1С. В итоге со словами "Вот, могу отдать только SQL дамп. Но без СУБД вы все равно ничего не сможете сделать" - прилетает архив размером 700 мег формата bla_bla_bla_UT11.sql.gz
SQL дамп это прекрасно, подумал я, запуская SQL management studio.
Распаковав это хозяйство получил 1,5 гиг файл формата .sql
Попытки подпихнуть это в MS SQL успехом не увенчались.
Пришлось первый раз разбираться с postgre. Последняя на текущий момент версия была 10, но так как ей нужна была платформа не ниже 8.3.14 - была отправлена в корзину.
Поставил 9.6.7 с сайта 1С.
Ставится запуском postgresql-9.6.7-1.1C(x64).msi все параметры по умолчанию, предлагает указать некий пароль (даже не показывая к какому юзеру/уч.записи он относится), не менее 4х знаков, и после инсталляции запускает Stack Builder который предлагает поставить кучу какого-то не нужного барохла. Закрыл ничего не инсталлируя. pgAdmin 4 это адовая программа, которая открылась всего два раза. Сначала я создал там базу, выбрал в меню "восстановить из бекапа". Меня отправили прописывать какие то пути к скриптам. Что за (. ) - тебе же указали пути при установке! Но нет, надо что-то там в настройках указать. кое как нашел настройки. Попутно хочется добавить, что через 5 минут вглядывания в интерфейс этого . у меня стали болеть глаза. Я почувствовал себя пользователем Windows 3.11 , ни больше ни меньше. Заодно поменял языковую опцию на русский. Это, видимо, было ошибкой - после этого надо было рестартовать сервис, и больше pgAdmin-4 не запустился ни разу. Ну ничего, рядом в папке \bin валялась 3я версия этой чудесной программы. Она всё же согласилась работать, но архив мой открывать и грузить никак не хотела. Кнопка "Загрузить" так активной и не стала.
перерыл кучу всевозможной информации, нашел массу примеров скриптов, которые то запускают pg_restore то psql , причем принципиально понять почему одни используют одно, а другие другое - я никак не мог. Но у всех в примерах дампы были формата *.backup и с моим файлом это никак не хотело работать.
В итоге оказалось, что этот дамп - по сути текстовый набор sql инструкций, который создает таблички и постит туда данные. Некий набор запросов. Очень большой набор запросов.
В итоге строка запука восстановления стала выглядеть так:
система спрашивает пароль, и что бы я ей не указывал - не пускает. Пароль при инсталляции, пароль от системной учетной записи админа, пустой пароль - всё равно валит ошибку
Оказывается он пытается от имени текущей учетной записи windows что то сделать, и наличие у вас хоть прав администратора всея вселенная - его ничуть не смущают, вы всё равно идете лесом.
В итоге команда принимает следующий вид:
, где postgres это по сути SA.
И по экрану радостно побежали заголовки sql запросов. Заняло это минут 30.
Далее прописываем базу в консоле администрирования 1С, пользователь БД - postgres , пароль как раз тот что был при инсталляции.
Добавляем базу в список баз 1С.
И вот, к концу написания данного опуса - у меня на руках уже родимый .dt с которым уже чувствуешь себя хорошо. Работоспособность проверена.
user755340; Gendalf; scanner1980; DFinteX; leks88; eaa; addinaq; defini; goodwill; dimisa; acanta; + 11 – Ответить
Резервное копирование баз данных 1С является обязательным, чтобы в случае непредвиденной проблемы всегда была возможность все восстановить. В статье мы рассмотрим, как произвести резервное копирование и восстановление из копии базы 1 8.3, работающей на PostgreSQL 11.5.
Столкнулся с проблемой резервирования и восстановления бэкпапа на PostgreSQL (оказалось все не так просто как MSSQL). На просторах нашей не объятой сети, найти что то дельное и работающее из коробки очень проблемно, поэтому все пришлось собирать по кусочкам из разных источников, методом проб и ошибок чтобы получить действительно рабочую схему. Также решение проблем, с которыми можно столкнуться.
pg_dump — выгрузить базу данных Postgres:
REM /////////////////////////////////////////////////////////////////////////////////
REM РЕЗЕРВИРВОВАНИЕ ПЕРВОЙ БАЗЫ sibek
REM ПРИМЕР СОЗДАНИЯ РЕЗЕРВНОЙ КОПИИ БАЗЫ ДАННЫХ 1C НА POSTGRESQL
CLS
ECHO OFF
CHCP 866 - установить кодовую страницу 1251 Windows, 866 DOS
REM УКАЗАНИЕ ПЕРЕМЕННЫХ СРЕДЫ POSTGRESQL
SET PGBIN=C:\Program Files\PostgreSQL\11.5-7.1C\bin\
SET PGDATABASE=bdpostgre - Имя базы на Postgre сервере
SET PGHOST=localhost
SET PGPORT=5432
SET PGUSER=postgres - Имя пользователя Postgre сервера
SET PGPASSWORD=password - Пароль пользователя Postgre сервера
REM ПЕРЕХОД В КАТАЛОГ С bat-ФАЙЛОМ (ОТКУДА ЗАПУЩЕН ФАЙЛ)
%~d0
CD %~dp0
REM ФОРМИРОВАНИЕ ИМЕНИ ФАЙЛА ДЛЯ РЕЗЕРВНОЙ КОПИИ И LOG ФАЙЛА ОТЧЕТА
SET DAT=%date:~0,2%%date:~3,2%%date:~6,4% - Получаем текущую дату для имени файла
SET DUMPFILE=D:\1C BackUp\%DAT%-sibek.pgsql.backup - Бэкап файл базы
SET LOGFILE=D:\1C BackUp\%DAT%-sibek.pgsql.log - лог файл процесса
SET DUMPPATH="%DUMPFILE%"
SET LOGPATH="%LOGFILE%"
REM ВЫПОЛНЕНИЕ КОМАНДЫ (ПРОГРАММЫ) ДЛЯ СОЗДАНИЕ РЕЗЕРВНОЙ КОПИИ БАЗЫ
CALL "%PGBIN%\pg_dump.exe" --format=custom --verbose --file=%DUMPPATH% 2>%LOGPATH%
REM ВЫПОЛНЕНИЕ КОМАНДЫ (ПРОГРАММЫ) ЗАВЕРШЕНО, ЕСЛИ ОШИБОК НЕТ ТО КОНЕЦ
IF NOT %ERRORLEVEL%==0 GOTO Error
GOTO Successfull
REM ПРИ ВОЗНИКНОВЕНИИ ОШИБОК УДАЛЯЕТСЯ ПОВРЕЖДЕННЫЙ ФАЙЛ КОПИИ И СООТВЕТСТВУЮЩАЯ ЗАПИСЬ В ЖУРНАЛЕ О ЕЕ СОЗДАНИИ
:Error
DEL %DUMPPATH%
MSG * "Ошибка при создании резервной копии базы данных. Смотрите backup_sibek.log."
ECHO %DATETIME% Ошибки при создании резервной копии базы данных %DUMPFILE%. Смотрите отчет %LOGFILE%. >> backup_sibek.log
GOTO End
REM ЕСЛИ КОПИЯ СДЕЛАНА БЕЗ ОШИБОК ДЕЛАЕТСЯ ЗАПИСЬ В ЖУРНАЛЕ РЕГИСТРАЦИИ
:Successfull
ECHO %DATETIME% Успешное создание резервной копии %DUMPFILE% >> backup_sibek.log
GOTO End
:End
REM УСТАНАВЛИВАЕТСЯ ПАРАМЕТРЫ ДЛЯ КОПИИ ХРАНИТЬ 5 ДНЕЙ ОТ ДАТЫ СОЗДАНИЯ, УДАЛЯТЬ ПО ИСТЕЧЕНИЮ
FORFILES /p "D:\1C BackUp\" /s /m *.* /d -5 /c "CMD /c del /Q @FILE"
ВАЖНО! Убрать все пробелы после параметров (чтобы сразу был перенос строки) иначе работать не будет т.к. пробелы будут считаться как символы.
Если несколько БД то можно сделать для каждой БД отдельный bat-файл, либо скопировать полностью код и вставить в один bat-файл (2-3 раза) в зависимости от количества баз, изменяя только имя базы и имена файлов бэкапа и логов.
2. Автоматическое резервирование по расписанию
Автоматическое резервирование будем настраивать через планировщик задач: Пуск -> Панель управления -> Администрирование» и запускаем Планировщик заданий, в планировщике выбираем пункт Создать задачу.
Заходим в раздел Триггеры там настраиваем расписание выполнения задания
В разделе Действия указываем какое действие выполнять (в нашем случае указываем наш bat-файл), где прописаны все необходимые команды
После выполнения команды в указанной папке будет создан бэкап и лог файлы процесса выполнения.
На этом этап резервирование закончен, переходим в этапу восстановления БД из резервной копии.
3. Восстановление копии БД 1С 8 на PostgreSQL
На этом этапе были небольшие трудности. т.к. не где не было указано конкретно, что надо делать именно так и по другому это не заработает (пришлось догадываться).
Первая проблема. При попытка восстановить БД может возникнуть ошибка:
Не какие регистрации данной DLL (regsvr32), обновление и прочее не помогу, надо данную DLL скопировать в System32 и все заработает как часы.
DLL находится: C:\Program Files\PostgreSQL\11.5-7.1C\pgAdmin 4\bin\python36.dll
DLL скопировать: C:\Windows\System32\python36.dll
Вторая проблема. При восстановление БД в PostgreSQL, она должна быть создана только на Postgre сервер, а в консоле 1С Севера ее быть не должно иначе будет куча ошибок проблем и результат отрицательный (в сравнении с MSSQL таких проблем нет). Так и не разобрался почему, но если настроена связь базы данные на 1с сервере и PostgreSQL сервере то база валится в ошибки (Сервер 1с и PostgreSQL находятся на одном ПК, возможно причина в этом).
Поэтому перед восстановлением создаем базу данных в PostgreSQL, правой кнопкой создать, указываем имя БД, параметры все стандартные по умолчанию.
После чего наживаем правой кнопкой на созданную БД выбираем пункт "Восстановить"
И указываем параметры:
Процесс восстановление займет какое то время.
После этого в базу можно заходить и работать, все работает корректно проблем в работе не было.
Во вложении Bat-файл для копирования 2 баз.
В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2016. А также разберем проблемные ситуации и неожиданные ограничения при работе 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 выгружаем только ее схему):
"\pg_dump.exe" и далее параметры с комментариями
--username "postgres" – имя пользователя
--role "postgres" - роль
--no-password – не спрашивать пароль в пакетном режиме
--format directory – создавать архив в виде каталога для использования параметра --jobs. При этом каждая таблица копируется в отдельный файл в каталоге, что позволяет распараллелить процесс создания архива
--jobs= - подбирается примерно как *2, можно пробовать увеличение или уменьшение параметра, чтобы максимально загрузить систему, не мешая работе пользователей. Практически на каждый процесс запускается копирование одной таблицы из базы данных. Сколько процессов задействовано, столько таблиц и обрабатывается одновременно. С помощью этого параметра можно достигнуть ускорения резервного копирования в 4 раза и более в зависимости от мощности оборудования сервера.
--blobs – позволяет выгружать поля большого размера
--encoding UTF8 - кодировка
--verbose – включить подробное комментирование
--exclude-table-data=config - исключить из выгрузки данные таблицы config, т.е. выгрузить только ее схему (config содержит записи: конфигурация, конфигурации поставщиков, отличия основной конфигурации от конфигураций поставщиков). Это требуется, когда база находится на поддержке у двух и более конфигураций поставщика и (или) очень много изменений внесено в конфигурацию. При этом размер изменений основной конфигурации относительно конфигурации одного из поставщиков приближается к 1Гб, что является пределом для поля большого размера в PostgreSQL. А 1С хранит изменения только в одной из записей таблицы config. При небольшом размере конфигурации можно не использовать этот параметр. Но при критическом ( если размер хотя бы одной записи таблицы public.config (конфигурации) после чтения и распаковки в стандартный поток вывода stdout превысит 1 Гб ) pg_dump.exe завершится с ошибкой:
Если используется --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:
"\psql.exe" – далее параметры
--username "postgres" – имя пользователя
--no-password – не спрашивать пароль в пакетном режиме
Задача 2. Восстановление базы 1С в копию во время работы пользователей с сохранением целостности с помощью команд pg_restore.exe, psql.exe. Для этого в общем случае алгоритм следующий:
Шаг 0. Создаем пустую копию базы средствами pgAdmin.exe или с помощью psql.exe, dropdb, createdb.
Шаг 1. Загружаем с помощью pg_restore.exe все таблицы из архива базы данных, кроме данных таблицы config (т.е. для config загружаем только ее схему)
Шаг 2. Загружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY
Шаг 0. Создаем пустую копию базы средствами pgAdmin.exe или с помощью psql.exe, dropdb, createdb.
Если база данных существует, мы должны сначала удалить ее из кластера с помощью команды DROP DATABASE "", а затем создать заново с помощью команды CREATE DATABASE "". Проще всего это сделать через pgAdmin, так как в нем есть запрос на удаление базы и образец запроса на создание базы. При удалении базы необходимо закрыть все соединения с базой, иначе база не будет удалена. Для Windows запрос на создание базы выглядит так:
CONNECTION LIMIT = -1;
Если мы время от времени хотим проверять, что база корректно достается из архива, то имеет cмысл автоматизировать шаг 0 в батнике командами psql, dropdb, createdb (добавлено по просьбам читателей):
0.1 Перед удалением закрываем все активные соединения с базой , кроме текущего:
"\psql.exe" – далее параметры
--username "postgres" – имя пользователя
--no-password – не спрашивать пароль в пакетном режиме
--command "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = '' AND pid <> pg_backend_pid();"
0.2 Удаляем базу , если она существует без подтверждения об удалении.
" \dropdb.exe"
--username "postgres" – имя пользователя
--no-password – не спрашивать пароль в пакетном режиме
--if-exists - проверка существования базы
--echo - вывод команд SQL, которые выполнит postgreSQL при вызове
0.3 Создаем заново базу после удаления
" \createdb.exe"
--username "postgres" – имя пользователя
--no-password – не спрашивать пароль в пакетном режиме
--echo - вывод команд SQL, которые выполнит postgreSQL при вызове
--owner="postgres" - владелец базы
--locale="Russian_Russia.1251" - устанавливает одновременно параметры LC_COLLATE и LC_CTYPE для базы данных.
--tablespace="pg_default" - указывает табличное пространство, используемое по умолчанию.
Теперь уже не нужно даже лезть в pgAdmin и там корячиться.
Шаг 1. Загружаем с помощью pg_restore.exe все таблицы из архива базы данных, кроме данных таблицы config (т.е. для config загружаем только ее схему):
--username "postgres" – имя пользователя
--role "postgres" - роль
--no-password – не спрашивать пароль в пакетном режиме
--jobs= - подбирается примерно как *2, можно пробовать увеличение или уменьшение параметра, чтобы максимально загрузить систему, не мешая работе пользователей. Практически на каждый процесс запускается восстановление одной таблицы базы данных. Сколько процессов задействовано, столько таблиц и индексов обрабатывается одновременно. С помощью этого параметра можно достигнуть ускорения восстановления базы в 2-3 раза и более в зависимости от мощности оборудования сервера.
--verbose – включить подробное комментирование
Шаг 2. Загружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY
"\psql.exe" – далее параметры
--username "postgres" – имя пользователя
--no-password – не спрашивать пароль в пакетном режиме
О братите внимание на метакоманду \ COPY вместо просто COPY.
\ COPY открывает файл и передает содержимое на сервер, тогда как COPY сообщает серверу, что он сам открывает файл и читает его, что может быть проблематичным по разрешению или даже невозможно, если клиент и сервер работают на разных компьютерах без совместного доступа к файлам между ними.
Соответственно при использовании просто COPY может выскочить следующая ошибка:
Postgres ERROR: Permission denied (не удалось открыть файл для чтения)
Заметим, что архив базы может быть успешно восстановлен на последующих версиях PostgreSQL. В моем случае, я переносил базу с сервера PostgreSQL 9.6 на PostgreSQL 10.3.
Все проходило гладко. Трудности теоретически могут возникнуть в команде \ COPY, т.к. она является платформо-зависимой .
На реальной базе размером 380 Гб за счет распараллеливания было достигнуто ускорение при работе pg_dump - в 4 раза, при работе pg_restore - в 2,5 раза, что весьма существенно, когда процесс занимает несколько часов.
Было: 2 часа на копирование, стало 0,5 часа на копирование; было 10 ч на восстановление, стало 4 ч на восстановление.
После перехода на более мощный сервер получили еще более существенные результаты:
Было: 2 часа на копирование, стало 0,5 часа на копирование; было 10 ч на восстановление, стало 1 ч 40 мин на восстановление. То есть количество ядер процессора и более быстрые диски при тех же параметрах дают значительное ускорение. Теперь чтобы скопировать и развернуть нашу огромную базу требуется всего 2 часа!
Ниже привожу примеры bat-файлов (качайте) для создания архивной копии базы данных DO_PROBA и восстановления в другую базу данных DO_PROBA_COPY. При этом в названии каталогов архива используется дата и время начала архивации и выводятся замеры времени на создание-восстановление. При восстановлении из вновь созданного архива необходимо каждый раз менять дату и время в bat-файле для восстановления (ее можно скопировать из имени каталога архива по образцу). Теперь будьте очень осторожны при восстановлении базы. По просьбам читателей и пользователей в bat-файлы добавлены команды автоматического удаления и создания восстанавливаемой базы в случае ее существования. Не ошибитесь в наименовании базы в команде SET ar_base_to= . Иначе можно легко порушить существующие базы.
СОВЕТ 1: периодически проверяйте (хотя бы раз в неделю) загрузку бэкапа в какую-нибудь тестовую базу и запускайте для проверки работоспособности режим конфигуратора 1С и рабочий режим. Тогда всегда будете уверены в своей архивной копии!
СОВЕТ 2: после отладки копирования и восстановления можно настроить Планировщик заданий (для Windows) на запуск нашего bat-файла по выбранному расписанию. Например, в 3:00 ночи ежедневно, пока никто из пользователей не работает.
Как известно, сисадмины делятся на две категории, это те кто еще не делает бэкапы и кто уже делает. Из первой категории во вторую обычно попадают после какого-либо факапа или после пинка от более опытных коллег. Сегодня мы рассмотрим возможности бэкапирования базы 1С 8.3 средствами PostgreSQL. В качестве стенда используется сервер на centos 7 с postgresql-9.6.
Встроенный в платформу 1С механизм выгрузки/загрузки информационной базы имеет 2 минуса:
- скорость выгрузки/загрузки
- для его использования необходимо завершить все пользовательские сеансы
Это не всегда приемлемо, особенно когда база должна быть доступна в режиме 24/7/365 или размер базы таков, что выгрузка может продолжаться “вечность”. В таких случаях можно сохранять базу средствами СУБД. В MS SQL этот механизм достаточно прозрачен и прост, а вот на postgres есть несколько финтов, которые могут сделать наши бэкапы нежизнеспособными, что при определенном стечении обстоятельств может весьма плачевно сказаться на нашей работе.
PostgreSQL предоставляет нам достаточно обширные механизмы для создания бэкапов. Мы рассмотрим только один, но в двух вариациях.
Вариант 1 (Работа с бэкапами 1С средствами postgresql из терминала)
1.1 Создание бэкапа.
Два последних параметра ключевые в этой операции. Первый (–file) отвечает за место куда мы сохраняем файл бэкапа, второй – база которую мы бэкапим.
1.2 Загрузка базы из бэкапа.
Стоит обратить внимание на один момент. В параметре –dbname мы указываем имя базы, куда загружать наш дамп. На момент загрузки она уже должна быть создана на вашем сервере и она должна быть пустая. Если заливать бэкап в непустую базу, то данные существующей базы просто дополнятся данными из бэкапа.
Вариант 2 (Работа с бэкапами 1С средствами postgresql с использованием pg_admin)
2.1 Создаем бэкап, по шагам:
- Выбираем нашу базу в pg_admin и в контекстном меню выбираем “Резервная копия…”
- Заполняем следующие параметры:
- Имя файла
- Формат: Настраиваемый
- Кодировка: UTF8
- pre-data
- Data (Данные)
- Post-data
- Blobs
2.2 Загрузка базы из бэкапа
- Выбираем базу куда мы заливаем бэкап в pg_admin и в контекстном меню выбираем “Восстановить…”
- Заполняем следующие параметры:
- Имя файла
- Pre-data
- Data (Данные)
- Post-data
Спасибо за внимание, надеюсь что эта небольшая статья вам помогла, буду рад комментариям.
Читайте также: