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

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

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

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

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

2. Подготовьте инфраструктуруLink to 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СLink to 3. Настройте postgres для оптимальной работы с базами 1С

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Выполните миграцию в продуктиве.Link to 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. Проводите мониторинг длительных запросов после миграции.Link to 7. Проводите мониторинг длительных запросов после миграции.

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

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

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

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

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