Меня зовут Александр Суботко, я сотрудник компании 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.
