Обслуживание базы данных на PostgreSQL

Публикация № 1242304

Администрирование - Администрирование СУБД

обслуживание backup postgre резервное копирование

Предысторией создания данного продукта был перевод одного из своих клиентов на PostgreSQL. Серверная платформа не позволяла установить там pgAdmin. А скриптами и планировщиками пользоваться неудобно. Поэтому пришла идея реализовать обслуживание баз данных PostgreSQL средствами 1С.

Решение выполнено в виде отдельной конфигурации. При желании можно внедрить ее в другую конфигурацию, т.к. все объединено в пределах одной подсистемы.

Смысл разработки заключается в следующем.

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

Доступны 4 операции: сохранение (backup), сжатие (vacuum), реиндексация (reindex) и восстановление (restore).

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

Для каждой операции и каждой базы создается отдельное регламентное задание.

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

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

Создавалось все в авральном режиме, поэтому сразу могу выделить несколько недостатков:

1. Кургузая справка, но администраторы, думаю, разберутся.

2. Нет лога.

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

Буду рад услышать пожелания и сообщения о багах.

Доработки планируются при достаточной востребованности.

Разработка и отладка велась на платформе 1С 8.3.13.1644, под Windows 10 и Windows Server 2008 R2.

Скачать файлы

Наименование Файл Версия Размер
Обслуживание БД PostgreSQL:

.dt 188,99Kb
27.05.20
4
.dt 1.0 188,99Kb 4

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Бэнни 124 02.06.20 09:13 Сейчас в теме
Бекап делаете с помощью pg_dump?
2. andrewbc 287 02.06.20 12:38 Сейчас в теме
3. Бэнни 124 02.06.20 17:23 Сейчас в теме
(2) для создания корректного бекапа, через вашу конфигурацию, получается, нужна остановка сервера 1С?
4. tolik_unix 02.06.20 17:34 Сейчас в теме
(3) Через pg_dump останавливать сервер 1С не нужно!! Но после восстановления базы из дампа, нужно сделать vacuum full (только на восстановленной базе), т.к.в дампе не хранятся индексы.
7. D_astana 93 03.06.20 07:00 Сейчас в теме
(4) Ну и признак анализа тоже добавить надо, ибо если автоанализ настроен неправильно, база без актуальной статистики будет после восстановления.

А вообще для кого это? Для бухгалтеров? Установить pg_probackup для ванильной версии делов на 15 мин. Зато получаем возможность восстановления вплоть посекундно, архивирование wal, автоочистку старых копий, авточистку архивных wal, проверку роботоспособности сделанной копии и все бесплатно.

Скрипт вакуума и реиндексации по 1 строчке.
8. Бэнни 124 03.06.20 22:49 Сейчас в теме
(4)
А что станет с открытыми транзакциями в момент pg_dump? Информации о них не станет, и можем получить замечательные ошибки после развертывания, разве нет?
9. ansh15 04.06.20 09:44 Сейчас в теме
(8) В документации пишут, что
Дампы, создаваемые pg_dump, являются внутренне согласованными, то есть, дамп представляет собой снимок базы данных на момент начала запуска pg_dump

Наверное, позаботились о том, чтобы незавершенные транзакции не попадали в этот снимок базы..
5. andrewbc 287 02.06.20 18:33 Сейчас в теме
(3) Сервер 1С останавливать не нужно, даже не нужно срубать сеансы и соединения
(4) Спасибо за информацию, потестирую. Но я делал просто restore - и база нормально работала.
6. tolik_unix 02.06.20 21:18 Сейчас в теме
(5) База работает, но при значимых нагрузках чувствуются тормоза. При этом, если дамп распаковать в предыдущую тестовую базу, то база вообще может не открываться пока не будет выполнен vacuum full.

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

vacuum - это не сжатие. Да, vacuum может приводить к уменьшению размера базы, но это совершенно иная операция.
Оставьте свое сообщение

См. также

Публикаций не найдено

Попробуйте расширить область поиска, проверьте поисковый запрос и повторите попытку.

Или закажите индивидуальную разработку вашего решения.

Создать заказ на разработку