Распространённые ошибки при установке PostgreSQL для 1С и реализация их устранения в продуктах компании Postgres Professional

30.05.23

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

На конференции Infostart Event 2021 Post-Apocalypse выступил релиз-инженер компании Postgres Professional Александр Суботко. Он привел примеры частых ошибок при создании кластера PostgreSQL для 1С и рассказал, как продукты PostgresPro помогают их избежать.

Меня зовут Александр Суботко, я сотрудник компании Postgres Professional, специализируюсь на тестировании кластеров 1С на PostgreSQL. На основе результатов этого тестирования моя компания публикует информацию о совместимости релизов PostgresPro с платформой 1С.

Специфика моей работы заключается в том, что я помогаю нашим клиентам разбираться с настройкой и адаптацией кластера PostgreSQL + 1С, помогаю справляться с возникающими ошибками. Их наличие, в принципе, не удивительно, потому что сам PostgreSQL для 1С – это достаточно свежая тема, он сейчас активно набирает обороты.

Когда я только начинал этим заниматься, я просто искал бесплатную СУБД, чтобы использовать на ней 1С и не платить. Я тогда видел множество мануалов о том, что нужно скачать PostgreSQL с официального сайта, скачать модули PostgreSQL с сайта 1С, все это вместе собрать, установить, настроить... и уже потом как-то использовать.

На любом из этих этапов рядовой пользователь, администратор может совершить множество ошибок. И как раз об этих ошибках я и хотел с вами поговорить.

 

Ошибка 1: неверно установленная локаль в инстансе СУБД

 

 

Первая ошибка, которую я хочу вам показать – это ошибка использования локали. Это когда 1С нам в один прекрасный момент выдает предупреждение:

Ошибка установки или изменения национальных настроек информационной базы. Порядок сортировки не поддерживается базой данных.

Это случается, в основном, когда мы подключаем платформу к СУБД именно средствами 1С – указываем IP-адрес, выбираем пользователя, хост, имя базы данных, нажимаем «Далее», и у нас высвечивается эта ошибка.

К сожалению, текст самой ошибки не объясняет, в чем дело, но благодаря ему мы уже знаем, что проблема в самой базе данных – поэтому идем в базу данных. В PostgreSQL это делается с помощью утилиты psql.

 

 

Вводим в psql команду /l+, видим базу, которую пытались создать – в таблицах LC_COLLATE и LC_TYPE показана её локаль.

1С как отечественная разработка по умолчанию не воспринимает зарубежные кодировки для локали, поэтому, если у вас LC_COLLATE не равен русской локализации, она не запустится.

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

Важно: все примеры ошибок, которые будут здесь указываться, касаются только тех случаев, когда PostgreSQL установлен на Linux-системах (не на Windows). В Linux у вас часто могут возникать ситуации, когда вы можете не знать, какие значения параметров у вас в системе указаны, пока напрямую с ними не столкнетесь. В данном случае ошибка возникает из-за локали, которая установлена в системе по умолчанию.

 

 

Для решения этой проблемы запустите в Linux команду locale-gen с параметром, указывающим на необходимую локаль:

sudo locale-gen ru_RU.UTF-8

А потом в настройках системы укажите эту локаль как язык по умолчанию – это делается кнопкой выбора или командой:

sudo update-locale LANG=ru_RU.UTF8

И перезагрузитесь.

После этого при установке PostgreSQL или переустановке инстанса у нас будет указана именно необходимая локаль.

Есть еще один выход – не переустанавливать PostgreSQL, а установить отдельно второй инстанс с другой локалью. Но тут следует учитывать, что если у вас в системе будет два активных инстанса, то второй инстанс будет устанавливаться на нестандартный порт. Однако при подключении 1С к PostgreSQL у нас нет окна для указания порта, поэтому его придется указывать через двоеточие после IP-адреса. Это не совсем очевидно, поэтому обратите внимание.

По команде:

initdb -D /opt/pgpro_data --data-checksums --encoding=UTF8 --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF8 --lc-ctype=ru_RU.UTF-8 --lc-messages=C

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

 

Ошибка 2: потеря mchar

 

 

Следующая ошибка, про которую я хочу рассказать – это потеря модуля mchar. Этот модуль воспроизводит в PostgreSQL типы данных mvarchar и mchar, аналоги которым есть в MSSQL.

Платформа 1С без данного модуля категорически не может работать, поэтому важно знать, что у вас в системе данный модуль присутствует.

Ошибка проявляется в сообщениях:

Ошибка СУБД: ERROR: type "mvarchar" does not exist

или

Ошибка при выполнении операции с информационной базой. Ошибка СУБД: ERROR: could not open extension control file "mchar.control". No such file or directory

Проблема может возникнуть, если при установке PostgreSQL вы не проконтролируете список устанавливаемых пакетов – например, вы установите только клиент и сервер, а необходимый пакет contrib не установите. Так обычно происходит, когда люди хотят перейти на PostgreSQL «на скорую руку», скачивая установочный пакет с официального сайта, где данные модули просто не предусмотрены.

Это как раз то, о чем я говорил в начале. Если вы хотите использовать оригинальный PostgreSQL, вам придется отдельно докачивать для него модули с официального сайта 1С, а потом собирать это всё вместе, что не совсем удобно.

 

 

Если вы столкнулись с такой ошибкой, проверьте наличие модуля mchar в вашей базе данных – введите в консоли запрос, который выбирает все записи из таблицы pg_available_extensions, где имя равняется mchar.

Здесь показано, что PostgreSQL нашел имя этого модуля, его версию, но не вывел его установленную версию. Это как раз является результатом ошибки, потому что именно сам модуль в системе есть, но он не установлен.

Далее вы можете проверить, почему данный модуль не установился; почему он присутствует, но 1C его не видит...

Но конкретно в данном случае само приложение psql подключено к базе postgres, которая автоматически создается при создании инстанса, а конфигурацию 1С мы устанавливали в другую базу. Это тоже немаловажно учитывать и смотреть модули, которые мы пытаемся установить, в нужном месте.

 

Ошибка №3: непригодность СУБД

 

 

Следующая ошибка – достаточно интересный случай. Система сообщает, что СУБД не пригодна для использования.

Ошибка при выполнении операции с информационной базой. Ошибка СУБД: DATABASE не пригоден для использования.

К сожалению, эта ошибка малоинформативная, и ее текст мало о чём говорит.

Но она, так же как и предыдущие ошибки, проявляется при создании информационной базы в СУБД из 1С, причем она характерна для более свежих версий PostgreSQL (потом объясню, почему).

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

 

 

Для диагностики можно использовать следующие четыре параметра:

  • log_connection и log_disconnection – чтобы смотреть, когда платформа 1С подключается и отключается от PostgreSQL;

  • log_min_duration_statement – показывает все запросы к базе данных, время выполнения которых превысило указанное значение. В данном примере указано значение 0 – это значит, что PostgreSQL будет записывать абсолютно все запросы, которые к нему поступают. Так мы сможем диагностировать данную ошибку.

  • log_rotation_age – опциональный параметр, который позволяет все логи совместить в один файл. Это может быть полезно, если вы будете проводить тестирование с какого-либо определенного периода, который PostgreSQL может занести в отдельный файл. Иначе мы видим, что 1С подключилась в один момент, лог-файл закончился, и мы не увидели, где он отключился. Чтобы видеть всю картину в целом, а не рассматривать несколько картинок, нам желательно весь лог объединить в один.

 

 

Мы заходим в лог и видим – 1С подключилась, выполнила некоторый запрос и отключилась.

Запрос, который мы тут видим – это обычный SELECT. 1С спрашивает: «покажи, пожалуйста, установленные версии из таблицы активных расширений, имя которых – mchar, fulleq и fasttrun».

В ответ PostgreSQL нам выдает, что такие версии есть, они установлены, вот их список.

Если бы он ничего не выдал, значит у вас версий не было

Если же он показал, но 1С всё равно не работает, мы начинаем думать, почему. Смотрим последние релизы этих расширений, требуемые для использования с платформой 1С, и видим, что самая последняя версия – это 2.1, а здесь у нас 2.0.

И тут оказывается, что из-за того, что версии расширений малы, 1С не проходит проверку PostgreSQL, и нужная нам база данных не может быть установлена. Это случается из-за использования PostgreSQL, в которую эти расширения добавлены вручную. В случае, если вы используете свежую версию 1С, она эти расширения просто не воспринимает.

Очень важно не злоупотреблять тем, что PostgreSQL является open-source решением. Понимать, что нужно соблюдать очень большое количество правил, а 1C ошибок не прощает.

 

Ошибка №4: потеря данных

 

 

Следующая интересная ошибка – это потерянные данные.

Ошибка СУБД: XX000: ERROR: MultiXactId XXXXX has not been created yet -- apparent wraparound

или

Ошибка СУБД: ERROR: relation "_inforg14471" does not exist

Причем, это ошибка не столько 1С, сколько любых систем.

Представьте, что вы уже вовсю работаете с 1С – у вас всё настроено, вы уже пережили все ошибки, всё потрясающе.

И вдруг где-нибудь отрубили свет. Вы прекрасно понимаете, что СУБД PostgreSQL могла не закончить транзакцию, не успеть что-то записать в базу данных. Вы включаете электричество, запускаете 1C, видите, что всё работает – фух.

Многие пользователи только после таких случаев начинают думать о резервном копировании. Но только вместо бэкапов они пользуются тем, что в 1С есть очень удобная функция – выгрузить в .dt. И вот они в очередной раз выгружают dt-ник и тут – бамс – вываливается ошибка СУБД: такая-то колонка не найдена.

Вроде бы всё работает, сама 1C запускается, но вы не можете снять бэкап – в тот момент, когда 1С пытается обратиться к каким-то данным, у нее это не получается, и она ругается.

Точно так же может быть, что в конфигурации сломались данные, к которым вы редко обращайтесь, и эту ошибку вы видите только тогда, когда пытаетесь на них посмотреть.

Любую потерю данных необходимо как-либо восстанавливать.

Если вы можете восстановить потерянные данные из предыдущего бэкапа, вам нужно будет поменять таблицу, которая указана в ошибке. В случае на картинке – это таблица inforg14471. Вы можете найти эту таблицу в бэкапе и восстановить её утилитами.

 

 

Но в случае, если у вас нет бэкапа, и вам прям жизненно необходимо поднять эту базу данных, есть лайфхак: в PostgreSQL есть параметр zero_page_damage. Он позволяет запустить СУБД, даже если в ней какие-либо данные сломаны, потеряны или просто не могут быть считаны.

С помощью этого параметра мы поднимаем работоспособность базы данных, и потом уже пытаемся снять дамп, чтобы из него в дальнейшем восстановить данные. Для этого мы используем утилиту pg_dump.

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

При этом мы должны столкнуться с ошибкой, которую видели ранее, только теперь нам об этом говорит не 1C, а сам PostgreSQL: такая-то таблица не может быть найдена.

Эта проблема решается добавлением исключений: если мы не можем восстановить данные, мы можем хотя бы их исключить таблицы с ошибками, чтобы сделать нормальный бэкап, на котором у нас 1С заработает.

Мы сталкиваемся с этой ошибкой, видим таблицу, в которой потеряны данные, и ставим её в исключение.

После данного исключения мы пытаемся продолжить снимать бэкап, и если мы опять столкнулись со следующей таблицей, то точно так же можно добавлять в исключения.

Исключений может быть сколько угодно, PostgreSQL нас в этом не ограничивает.

 

Как избежать ошибок

 

Теперь я как сотрудник компании Postgres Professional хочу показать вам, как возможность избежать этих ошибок реализована в продуктах, которые мы представляем.

 

 

В первую очередь, самая простая наша версия – PostgreSQL1C.

Данная сборка полезна тем, что в репозиториях, которые представляет наша компания, есть такое понятие, как метапакет – он позволяет при установке установить всё необходимое и умеет адаптироваться под вашу систему.

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

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

Но в принципе, установка метапакета уже представляет собой готовое решение.

 

 

Более серьезное решение в нашей линейке продуктов – PostgresPro Standard.

Именно с данной версии мы начинаем сертифицировать наши продукты по ФСТЭК, чтобы отвечать требованиям руководящих документов и технических условий, так же как и 1С. Сертификат ФСТЭК помогает убедить наших клиентов, что у нас есть гарант качества, что у нас всё безопасно, и мы можем рекомендовать себя для Enterprise-проектов.

 

 

Но для Enterprise-проектов мы рекомендуем всё-таки наше издание PostgresPro Enterprise, в котором есть доработанная функциональность не только для платформы 1С, но и для различных высоконагруженных систем и прочего.

Так как мы здесь в основном говорим про 1С, я хотел бы выделить очень удобную особенность Enterprise решения – это Compress File System (CFS, сжатая файловая система), которая устанавливается в базе данных PostgreSQL в виде раздела для сжатых данных.

С помощью данного решения мы можем сжать данные примерно до 60 процентов.

Допустим, если у нас база 100 гигабайт и есть 40 гигабайтов оперативки, то с помощью CFS PostgreSQL позволяет всю базу данных поднять в оперативку, и в дальнейшем уже с ней работать, минуя полностью нагрузку на жесткий диск, что и является ключевой особенностью.

Как было сказано ранее, 1C любит работать с временными таблицами, из-за чего у нас неплохо так набивается буфер.

Но в случае с 1С это позволяет больше работать с данными в самой оперативке.

Даже если ваша база даже в сжатом состоянии не помещается в буфер обмена, возможность работать с временными таблицами в оперативной памяти позволяет выравнять нагрузку на жесткий диск, что достаточно удобно в высоконагруженных системах.

 

 

По ссылкам 1c.postgres.ru и postgrespro.ru вы можете лучше ознакомиться с нашими продуктами.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.

См. также

Администрирование СУБД Системный администратор Программист

В крупных компаниях, где много типовых и сильно доработанных баз с режимом работы 24/7, переход с MS SQL на PostgreSQL затягивается. Получается гетерогенная структура – когда прод уже на PostgreSQL, а разработка и тестирование – пока на MS SQL. О том, какие варианты помогут постепенно перевести прод с несколькими базами MS SQL на PostgreSQL, не сломав среду тестирования и разработки, пойдет речь в статье.

21.11.2024    3051    a.doroshkevich    7    

14

Администрирование СУБД Системный администратор Платформа 1С v8.3 Бесплатно (free)

Пользовался ранее https://infostart.ru/1c/articles/1120161/#, но она устарела, т.к. службы запускаются через systemctl, да и сами службы слегка изменились. Возможно, где-то на ИТС уже есть нужная инструкция, но мне не попалась.

15.11.2024    392    Baser    2    

1

HighLoad оптимизация Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Россия Бесплатно (free)

Мы исследуем проблему долгого выполнения запросов PostgreSQL при использовании конструкции VALUES: когда она возникает, как на нее можно повлиять, а главное, почему ее продуманная отработка важна для более быстрого функционирования решений на базе 1С

12.11.2024    949    Tantor    20    

14

HighLoad оптимизация Администрирование СУБД Механизмы платформы 1С Программист Платформа 1С v8.3 ИТ-компания Россия Бесплатно (free)

В данной статье мы рассмотрим, как работает механизм временных таблиц на postgres на платформе 8.3.23 и что изменилось в нем при добавлении новых возможностей в платформе 8.3.25. А также на примере покажу, как понимание работы платформы позволяет оптимизировать СУБД для работы с 1С.

29.10.2024    3559    Tantor    38    

35

Администрирование СУБД Системный администратор Программист Бесплатно (free)

CDC - очень мощный механизм, который можно использовать во многих сценариях, возможность развернуть его в Docker показывает простоту и лёгкость данной технологии.

08.10.2024    839    AlexSvoykin    1    

7

Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ и решение ошибок СУБД. Во время реиндексации базы Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось найти объект "ИмяБазы.dbo._RefSInf21806", так как он не существует, или отсутствуют разрешения. Во время проверки целостности Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта "dbo._RefSInf21806".

19.09.2024    4611    Xershi    10    

17

HighLoad оптимизация Администрирование СУБД Архивирование (backup) Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще, как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей-то лабораторной работы? Статья адресована прежде всего специалистам 1С, избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

13.08.2024    3054    1CUnlimited    9    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. kser87 2473 02.06.23 15:55 Сейчас в теме
а вы тексты ошибок в тэги не забивали?
4. vikad 131 06.06.23 11:37 Сейчас в теме
(1) вы имеете в виду, что тексты ошибок нужно продублировать в тексте статьи, чтобы находилось в поиске?
5. kser87 2473 06.06.23 11:42 Сейчас в теме
(4) нет, в редактировании статьи есть специальное место для тэгов.
6. vikad 131 06.06.23 11:47 Сейчас в теме
(5) поиск по тегам работает так же, как поиск по тексту публикации. Теги не добавляются в ключевые слова страницы, если вы имели в виду именно это. И тег - это не два предложения, а максимум два-три слова. Возможно, в движке сайта будет что-то меняться в дальнейшем. Но сейчас так.
2. user1955562 04.06.23 00:53 Сейчас в теме
"Сотрудник" PostgresPro путает названия утилит... Что в конечном продукте? Чем паблик от pro и ent отличается, кроме цены и мифических CFS (что по сути есть оптимизация буфера ОС)?
3. vikad 131 04.06.23 10:01 Сейчас в теме
(2) доклад выложен силами редакции Инфостарта по итогам выступления на конференции. Возможно, сотрудник редакции опечатался. Уточните, что именно напутано.

По поводу отличий - здесь https://infostart.ru/journal/news/mir-1s/ivan-panchenko-postgresql-sovershenstvuetsya-i-1s-tozhe-idet-navstrechu_1806653/ есть цитата:
Там есть инкрементальный бэкап. И есть 64-разрядный счетчик транзакций, который позволяет полностью избежать проблемы, связанные с переполнением этого счетчика – так называемый Wraparound. Это если говорить об Enterprise версии.


Ну и здесь https://infostart.ru/1c/articles/1429971/ тоже отличия перечислены
7. user2033473 23.01.24 12:57 Сейчас в теме
Ошибка в команде initdb -D /opt/pgpro_data --data-checksums --encoding=UTF8 --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF8 --lc-ctype=ru_RU.UTF-8 --lc-meccages=C
8. vikad 131 23.01.24 12:59 Сейчас в теме
Оставьте свое сообщение