Вы здесь

Опыт обслуживания базы 1С в PostgreSQL

Знакомство с СУБД 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, которая идет в комплекте с СУБД, оформилось две команды по обслуживанию базы «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'а должна быть последняя пустая строка. Если файл 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 минут на работу pgdump.sh по созданию архива;

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

#!/bin/sh
# reindex BD

PIDEL=`pidof Xvfb`
if [ ! "$PIDEL" = "" ]; then

##иногда выгрузка из 1С в WINE зависает
kill -9 $PIDEL
fi

################
# stop 1c-server
/bin/sh /etc/rc.d/rc.1c stop
############################

#kill all running session nx
/bin/sh /etc/NX/bin/nxserver --cleanup

sleep 150

########################
###перешли на stop start
/bin/sh /etc/NX/bin/nxserver --stop
/bin/sh /etc/rc.d/rc.sshd stop
rm /tmp/.nX*
rm /tmp/.X*
rm /tmp/.X11-unix/X29 ## следы от запуска Xvfb
######################################

/bin/killall nxserver
/bin/killall nxnode
/bin/killall nxagent

#
sleep 150

/bin/sh /etc/rc.d/rc.sshd start
/bin/sh /etc/NX/bin/nxserver --start

#################

# start 1c-server
sleep 150

/bin/sh /etc/rc.d/rc.1c start
sleep 150

################################

su postgres -c /var/lib/pgsql/backups/vacuumdb.sh

В 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;

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

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

Оригинал статьи: http://www.oit-company.ru/publ/opyt_obsluzhivanija_bazy_1s_v_postgresql/1-1-0-174. Вы можете поблагодарить автора оригинальной статьи на infostart'е.

Комментарии

Привет. А не подскажешь, сколько по времени REINDEX происходит ? И есть ли какая либо возможность, чтобы при работе этой команды доступ к серверу сохранялся ? А то как запускаешь - то все, ни один коннект не получить.

Лучше спросить автора статьи http://www.infostart.ru/public/73910/