Досвід обслуговування бази 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. Ці команди виконують збір сміття, виконання збору статистики про базу даних для роботи планувальника запитів, переіндексацію:
VACUUM FULL VERBOSE ANALYZE;
REINDEX DATABASE baza1c_81 FORCE;
(Хоча з FULL у першій команді краще для себе визначитися ще раз самостійно, http://wiki.PostgreSQL.org/wiki/VACUUM_FULL та у документації PostgreSQL див. VACUUM).
Першим кроком у 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 за фактом працює від 6 до 8 години.
Третім кроком додаємо в cron рядок виконання другої команди:
30 3 * * 1 /var/lib/pgsql/backups/reindex.sh, врахуємо час на роботу vacuum.sh;
Командаreindex.sh виконується не більше 1 години.
І кожного понеділка база готова до ефективної роботи.
А час іде. Подумуємо про використання дисків SSD для розміщення WAL. І знайомство з варіантом роботи у 64-bit системі відбулося.
PS Якщо починаєте редагувати postgresql.conf, тоді після змінпереконайтеся в успішному старті PostgreSQL з новим postgresql.conf. Також необхідно переконатися в успішному створенні архівної копії, найкраще відновивши базу на резервному сервері з архівної копії.
PS Розрахунок собівартості. іноді цей розрахунок починає дуже сильно замислюватися про щось своє. Так ось, у цьому випадку можна спробувати відключити в конфігураційному файлі PostgreSQL autovacuum, виконати стоп-старт "Менеджер ліцензій-сервер підприємства-PostgreSQL". Після розрахунку собівартості у конфігураційному файлі повернути все назад, стоп-старт. Оцінити час розрахунку і дійти невтішного висновку необхідність повтору цих действий.
Швидше за все, вже не PS, а далі. Хвора тема – зупинення менеджера ліцензій. І найточніше ця зупинка прикладається в п'ятницю, ввечері. Це коли підходить час у цеху запустити 1С і додати до системи звіт виробництва за зміну, або на складі готової продукції йде відвантаження у другу зміну. В інші дні вирішити цю проблему допомагає віддалений доступ, але в п'ятницю.
Кілька зауважень на 2011 рік.
Поставили диски SSD для WAL та Log PostgreSQL. Intel X25 – 2 шт. А ось що це дало, сказати складно, минулі виміри були за однієї бази, а зараз у PostgreSQL їх уже кілька. Та й база зросла. Ось відключити SSD і подивитися, але на робочому сервері це не вийде.
Проблема: Після оновлення УПП з 1.2.х на 1.3.х не працює створення резервної копії засобами СУБД PostgreSQL, а саме робота pg_dump завершується з помилкою - «pg_dump: Команда була: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;». Вирішення цієї проблеми наведено у статті //infostart.ru/public/18771/. Для виконання запитів використовуємо PgAdminIII 1) "SELECT FROM Config WHERE DataSize> 125829120” - побачити, що такий запис є; 2) "DELETE FROM Config WHERE DataSize > 125829120";
Але при наступному оновленні конфігурації можливо будуть проблеми, які можна вирішити, прочитавши //infostart.ru/public/68793/.
Проблема Як тільки з 60 залишається вільними 1-3 ліцензії, тоді 1С у користувача починає сильно гальмувати у своїй роботі. Рішення поки що не знайшли.