Tantor - российская СУБД и платформа для управления базами данных на основе PostgreSQL. 

Далее в статье под postgres понимается именно СУБД Tantor, но данный план миграции подойдет для любой СУБД, основанной на PostgreSQL.

1.Определите базу, которую будете переводить первой. 

Начинать желательно с небольшой и простой базы, чтобы на ней ваши инженеры и dba могли обкатать технологию перевода, а также научились создавать копии продуктивных баз на postgres для разработчиков.

Следует учитывать, что сервер 1С предприятия на Linux будет работать только с СУБД postgres, поэтому всегда сначала переводите СУБД, а только потом сервер приложений на Linux.

2. Подготовьте инфраструктуру

Необходимо поднять сервера субд для перевода тестовой и продуктивной базы на postgres.

На тестовом сервере мы выполняем п.3 и 4. Также на них ваши dba могут изучить и применить методики для того, чтобы потом они могли успешно сопровождать базы в продуктиве. Разработчикам тестовые сервера нужны, чтобы на них заниматься воспроизведением проблемных запросов и их отладкой в целях оптимизации. Также рекомендуем посмотреть видео по работе с планами запросов на postgres - https://www.youtube.com/playlist?list=PLt0vzWoDuwcRWoeVHeJuDhnXRnjiMMTOF

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

Также не забудьте настроить репликацию, но делать это лучше после миграции базы, чтобы во время миграции не получить проблем с WAL, а также повышенную нагрузку на диски и CPU.

Для баз уровня критичности Mission critical и Business critical рекомендуем на одном сервере СУБД размещать только одну базу. Для Business operational и Office productivity тоже можно применять данную рекомендацию, если позволяют ресурсы.

3. Настройте postgres для оптимальной работы с базами 1С

В отличии от MS SQL Server postgres требует настройки для работы с базами 1С. Мы подробно рассмотрели как настроить postgres под максимальную производительность в отдельной статье.

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

4. Подготовьте и проведите нагрузочное тестирование.

Проводить нагрузочное тестирование рекомендуем для систем уровня критичности Mission critical и Business critical.

Для систем уровня Business operational и Office productivity как правило время, потраченное на проведение нагрузочного тестирования, несопоставимо с потерями от времени деградации функционала после миграции.

Нагрузочное тестирование можно проводить в 2х вариантах: многопользовательское тестирование согласно стандартам 1С и упрощенное. Рассмотрим их.

Многопользовательское тестирование согласно стандартам 1С.

Данное тестирование подразумевает написание тестового сценария с помощью конфигурации Тест-Центр для эмуляции многопользовательской работы, максимально приближенной к боевой. Порядок следующий:

  • Необходимо составить сценарий тестирования. Его можно составить совместно с аналитиками, которые хорошо знают какие бизнес-процессы происходят в мигрируемой ИС, либо можно собрать логи технологического журнала кластера 1С в продуктивной базе для определения профиля нагрузки и по ним определить какая операция с какой периодичностью каким количеством пользователей выполняется.
  • По итогам анализа собранных данных составить тестовый сценарий работы пользователей.
  • Реализовать нагрузочный тест с использованием конфигурации Тест-Центр, входящей в состав 1С:КИП.
  • Провести несколько итераций нагрузочных тестов на предыдущем программном обеспечении и на Postgres, моделирующих параллельную работу пользователей в реальной системе.
  • По итогам тестов сравнить результаты работы двух СУБД, при необходимости провести работы по оптимизации.

К минусам данного подхода относится то, что необходимо довольно много ресурсов разработчика/эксперта 1С на разработку тестового сценария.

Упрощенное тестирование.

Данный вид тестирования подразумевает тестирование бизнес-пользователями или аналитиками, которые в тестовой базе выполняют критичные для бизнеса операции.

Как по итогам данного тестирования понять есть ли проблемы? Тут есть несколько вариантов анализа результатов:

  1. Обратная связь от тестировщиков.
  2. Сравнить APDEX в тестовой базе и продуктивной по исследуемым ключевым операциям.
  3. Во время тестирования собрать технологический журнал и исследовать запросы, которые выполнялись больше критичного на ваш взгляд времени.
  4. Во время тестирования собрать технологический журнал и сравнить его данные с собранным технологическом журналом из продуктивном базы. 

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

5. Выполните тестовую миграцию на postgres.

Перед переводом в продуктиве базу нужно в обязательном порядке тестово мигрировать с mssql на postgres для того, чтобы:

  • Замерить время миграции для расчета технологического окна
  • Убедиться, что при загрузке в postgres не будет каких-то ошибок, прерывающих процесс

Если вы миграцию осуществляете путем выгрузки/загрузки из DT, то следует учитывать, что при выгрузке файла платформа 1С сохраняет данные в каталоге пользователя сервера 1С предприятия, поэтому в нем должно быть достаточно места, иначе при выгрузке можно получить ошибку "Недостаточно памяти". Доступное место равно размеру получаемого DT-файла.

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

6. Выполните миграцию в продуктиве.

На текущий момент для платформы 1С 8.3.24 доступны 2 варианта миграции: через DT и автономный сервер.

Порядок действий при миграции через DT (допустим наша база называется ERP):

  1. Настройте postgres для ускорения загрузки из DT - настройки описаны здесь
  2. Заблокируйте базу ERP, чтобы в нее не могли войти пользователи и не работали РЗ
  3. Создайте в консоли кластера базу ERP_pg, указать путь к серверу СУБД postgres, где будет размещаться данная база. Заблокировать РЗ и сеансы, чтобы никто не мог в нее зайти кроме вас.
  4. Выгрузите ERP в DT
  5. Зайдите в конфигуратор базы ERP_pg и начните загрузку из DT.
  6. После окончания загрузки зайдите в режим предприятия, и убедитесь что база работает.
  7. Зайдите в свойства базы ERP и поменяйте путь к СУБД на такой же, как у базы ERP_pg. Если свойства не изменяются или после их изменения не можете зайти в базу ERP, то удалите ее из консоли кластера и создайте заново.
  8. Удалите из консоли кластера базу ERP_pg, т.к. она не нужна.
  9. Выполните ANALYZE базы ERP
  10. Верните настройки postgres к боевому режиму, т.е. откатите изменения настроек из п. 1.
  11. Разблокируйте РЗ и сеансы в базе ERP.
  12. Включите репликацию базы и настройте процесс ее бекапирования согласно вашим стандартам.

При миграции средствами автономного сервера порядок действий такой же, только вместо пунктов 4 и 5 будет прямая переливка данных из одной базы в другую. Пример готового скрипта с описанием можно взять с сайта ИТС.

7. Проводите мониторинг длительных запросов после миграции.

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

Идеальным способом для обнаружения таких ключевых операций является подсистема БСП "Оценка производительности"(APDEX), которая наглядно вам покажет как было до миграции, и как стало после нее.

А найти конкретный проблемный запрос вы сможете с помощью данных технологического журнала или модуля "Advanced analytics" платформы Tantor - https://docs.tantorlabs.ru/tp/2.0/instances/pg_monitor/pg_monitor.html

Как правило встречаются следующие виды проблем в запросах на postgres:

  1. Использование разыменования в условиях соединения (обращение через 2 точки). В данном случае необходимо заранее вычислить значение, которое используется в условиях соединения и по возможности использовать ВЫРАЗИТЬ, чтобы сократить количество таблиц, с которыми будет происходить соединение.
  2. Если в запросе используется соединение с виртуальной таблицей СрезПоследних и запрос работает медленно, то нужно вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице.
  3. Если в запросе используется соединение с виртуальными таблицами и запрос содержит много соединений, то рассмотреть варианты упрощения данного запроса путем разбития на временные таблицы.