Содержание
Пришло время поговорить о восстановлении базы данных PostgreSQL из архива, так как к тому времени, когда Вы с этим столкнетесь, Вы уже должны будите уметь это делать, для того чтобы оперативно восстановить работу базы и соответственно всех приложений, которые работают с ней. Иначе Вы можете получить всякого рода выговоры от руководства за простой процесса производства.
Чуть ранее мы с Вами рассмотрели возможность создания резервной копии базы данных PostgreSQL в материале Как создать архив базы PostgreSQL, а теперь пора научиться восстанавливать базы из backup.
Если Вы знаете, как создается backup в PostgreSQL, то понимаете, что это делается достаточно просто, поэтому и восстановить базу также не составит труда.
Мы с Вами рассматривали два варианта создания архива, через графический интерфейс pgAdmin и через командную строку, поэтому и восстанавливать мы будем также двумя способами. Только в отличие от создания backup, через батник (для ежедневной автоматической архивации) который нам был нужен практически только для того, чтобы автоматизировать этот процесс и забыть про него, при восстановлении нам такая автоматизация не нужна, так как не каждый день приходится восстанавливать базу данных. Но мы все равно рассмотрим вариант через bat-файл, только для того чтобы Вы знали, как это делается и в случае необходимости оперативно восстановили базу, путем простого запуска батника, так как через графический интерфейс, согласитесь, займет немного больше времени.
Итак, приступим, если Вы помните, что при архивации использовалась утилита pg_dump.exe, то при восстановлении используется утилита pg_restore.exe
Примечание! Как и при создании архива, в качестве примера мы использовали локальный сервер PostgreSQL 8.4, на Windows 7, так и сегодня мы будем использовать именно данные версии СУБД и ОС.
Восстанавливаем базу через pgAdmin
Открываем pgAdmin, подключаемся к серверу, выбираем правой кнопкой мыши базу, и щелкаем «Восстановить»
Затем открывается окно восстановления базы, где Вы можете задать параметры восстановления, в частности выбрать архив, я здесь поставил галочку «Очистить перед восстановлением» так как если ее не ставить достаточно часто база восстанавливается с ошибкой (но все равно восстанавливается), и жмем «ОК»
После Вам останется, дождаться восстановления и нажать кнопку «Завершить»
Восстанавливаем базу с помощью батника
Для этого открываем блокнот (удобней Notepad++) и вставляем в него следующие команды (символ ^ это перенос строки):
Где, не трудно догадаться первая строка это запуск утилиты, вторая это подключение к серверу, третья выбор базы для восстановления, параметры восстановления и соответственно из чего это все восстанавливать. Только одно замечание, при восстановлении проверьте путь к архиву, т.е. необходимо выбрать актуальный архив на момент восстановления, чтобы не получилось ситуации, когда Вы якобы восстановили базу, только скажем прошлогодней версии, а пользователи смотрят и удивляются:)
Нам останется только сохранить этот текстовый документ с расширением .bat и проверить его работу.
Как видите, восстанавливать базу не так страшно как кажется.
На сегодня все, в следующих статьях мы будем рассматривать, как можно создавать и восстанавливать backup базы данных, но только уже на СУБД MSSql 2008.
Во время работы с базой данных postgresql в 1С необходимо периодически выполнять задачи по бэкапу базы данных и ее восстановлению. Для увеличения производительности рекомендуется регулярно проводить очистку, анализ и переиндексацию базы 1С. Для автоматизации процессов по архивации и обслуживанию я написал небольшие скрипты с пояснениями. Ими и хочу поделиться с вами.
Данная статья является частью единого цикла статьей про сервер Debian.
Введение
Ранее я рассказывал о том, как установить и настроить postgresql для работы с 1С, а затем как провести анализ производительности базы 1С и по возможности увеличить быстродействие. После успешного выполнения первых двух задач, мы можем приступать к эксплуатации системы. Когда рабочая база 1С уже на сервере, обязательно нужно настроить ее регулярный бэкап. Желательно так же периодически проводить очистку и переиндексацию sql базы. Это увеличит ее быстродействие. Выполнять эти операции лучше всего автоматически, в нерабочее время. Именно этим мы и займемся в этой статье.
Бэкап и восстановление базы 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 строку, приведя ее к такому виду:
После этого надо перезапустить постгрес, чтобы изменения вступили в силу.
Бэкап базы данных выполняется простой командой:
| postgres | имя пользователя базы данных |
| base1c | название бд с 1С |
| pigz | архиватор |
| base1c.sql.gz | файл, куда будет сохранена резервная копия |
Обращаю внимание на архиватор pigz. Я его использую, потому что он умеет жать данные, нагружая все ядра процессора, в отличие от gzip. Прирост производительности 2-3 раза. Рекомендую. На debian он ставится из стандартного репозитория:
В centos из epel:
Попробуйте вручную в консоли выполнить команду и посмотреть на результат. Вы должны получить заархивированный файл с текстовыми sql командами в открытом виде. Теперь попробуем восстановить базу данных 1С из архива. Тут будут нюансы. Первым делом разархивируем файл:
Файл будет распакован, а архив удален. Чтобы сохранить архив, можно использовать такую команду:
Создадим на сервере новую базу данных, в которую будем восстанавливать резервную копию. Перед этим посмотрим список баз данных на сервере:
Создаем новую базу данных:
Смотрим, что получилось:
Базу данных создали. Теперь загружаем в нее наш бэкап 1с:
Ждем приличное время. Оно будет зависеть от размера базы. После того, как восстановление завершено, можно идти в консоль кластера 1С и добавлять новую базу, указывая в качестве базы postgresql только что созданную базу с загруженным архивом.
Я сначала пошел по другому пути. Создал в консоли пустую базу, загрузил в нее бэкап через консоль postgresql. Архив вроде бы загрузился, но в базу я не мог войти, не проходила авторизация. То есть возникли какие-то проблемы. Когда сделал, как описал выше, без проблем все заработало сразу. Проверил базу, все было в порядке.
После того, как вы убедитесь, что все в порядке, можно написать небольшой скрипт, который мы добавим в cron для регулярного бэкапа нашей базы 1С. Я его сделал совсем простым, ничего лишнего, только 1 база. Я считаю, что если баз не много и вручную не представляет труда написать несколько строчек скрипта, то лучше все сделать без циклов и лишних переменных. Если у вас больше одной базы, то просто скопируйте строки и замените названия баз. Вот сам скрипт:
Я указал в названии файла с бэкапом 1с базы использовать текущую дату с точностью до минуты. В лог я пишу информацию с точностью до секунды, чтобы было точно видно, сколько длился бэкап. Просто для справки информация, можно обойтись и без лога совсем. В конце удаляю из папки все архивы старше 3-х дней. Я обычно сервером с бэкапами забираю информацию с целевых хостов. То есть я буду подключаться к sql серверу и забирать с него архивы и уже на сервере бэкапов буду их хранить и ротировать в зависимости от желаемой глубины архива. А здесь я удаляю почти сразу архивы, не храню их, чтобы не занимать место. Если вы будете хранить их долгосрочно на этом же сервере, то просто измените цифру 3 на нужное вам число дней, за которые вы хотите иметь архивную копию своей базы 1С.
Использование программы PostgreSQL Backup
Для бэкапа базы данных постгрес есть удобная и бесплатная для двух баз программа под windows — PostgreSQL Backup. Я ее установил, проверил, сделал бэкап, потом восстановил из бэкапа. Все отлично работает. Из полезных функций:
- встроенный планировщик
- автоматическое сжатие бэкапа
- отправка оповещений на email
Программа, простая, понятная и приятная на вид. Попробуйте, возможно вам будет достаточно такого варианта. К сожалению, она не умеет восстанавливать из бэкапа. Для этого архив придется перенести на сервер, распаковать и загрузить в базу через консоль, как я показывал выше.
Обновление статистики и реиндексация в postgresql
С бэкапами разобрались, теперь настроим регламентные операции на уровне субд, чтобы поддерживать быстродействие базы данных. Тут особых комментариев не будет, в интернете очень много информации на тему регламентных заданий для баз 1С. Я просто приведу пример того, как это выглядит в postgresql.
Выполняем очистку и анализ базы данных 1С:
Реиндексация таблиц базы данных:
Завернем все это в скрипт с логированием времени выполнения команд:
Сохраняем скрипт и добавляем в планировщик. Хотя я для удобства сделал еще один скрипт, который объединяет бэкап и обслуживание и уже его добавил в cron:
Добавялем в /etc/crontab:
Проверяем лог файл и наличие бэкапа. Не забывайте делать проверочное регулярное восстановление бд из архива.
Описанные выше операции очистки и переиндексации можно делать в ручном режиме в программе под windows — pgAdmin. Рекомендую ее установить на всякий случай. Достаточно удобно и быстро можно посмотреть информацию или выполнить какие-то операции с базой данных посгрес.
Заключение
Вот и все, что я хотел рассказать по поводу бэкапа и обслуживания баз postgresql в связке с 1С. Если у кого есть еще полезная информация, прошу поделиться в комментариях. Возможно с бэкапом есть какие-то нюансы, особенно на больших базах. Но мне негде тестировать, больших рабочих баз более 10 гб у меня нет под рукой, а с теми что были, все отлично работает.
Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.
Инструменты пользователя
Инструменты сайта
Содержание
Резервное копирование и восстановление в PostgreSQL. Существуют три принципиально различных подхода к резервному копированию данных PostgreSQL:
Восстановление после сбоя
Если работа сервера аварийно завершается, в логе сервера появляется сообщение с уровнем важности PANIC.
Восстановление после сбоя. Все изменения данных записываются на диск только после их гарантированного журналирования в WAL. Следует заметить, что изменения в базе данных не пишутся на диск в момент фиксации транзакции. Они записываются позже в фоновом процессе.
В логе WAL есть контрольный точки (checkpoints).
Логическое резервирование (SQL)
Ключи pg_dump:
Логическое резервирование заключается в создании текстового файла с командами SQL. Такой файл можно передать обратно на сервер и воссоздать базу данных в том же состоянии, в котором она была во время бэкапа. У PostgreSQL для этого есть специальная утилита — pg_dump. При выполнении pg_dump, таблицы блокируются минимально, только запрет на изменение структуры таблицы.
базу данных «dbname» потребуется создать перед восстановлением и пользователя (которому принадлежит восстанавливаемая база данных)
Пример
Пример: Полное логическое (SQL) резервирование и восстановление БД mbillcz5054. Алгоритм:
Если вы хотите исключить какие-либо таблицы из дампа, не забудьте сделать схему этой таблицы, чтобы в будущем Вы ее могли восстановить на новом сервере, например исключим таблицу cdr из дампа и создадим ее схему: