Миграция с MSSQL Server на PostgreSQL. Предпосылки

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

Зачем переходить

Действительно, зачем переходить, если и так всё работает?

Этот вопрос сейчас выглядит скорее риторическим, хотя еще пару лет… Но текущие реалии в России диктуют свои сценарии организации ИТ-ландшафта на всех предприятиях, особенно на государственных. Кроме того, многие отрасли в России, и IT – не исключение, движутся семимильными шагами в сторону импортозамещения. Причём не на бумаге.

Вот три наиболее распространённые причины миграции баз данных на PostgreSQL (далее просто PG), которыми руководствуются компании.

1. Законодательство РФ. Для многих предприятий перевод ИТ-системы на PG является процессом неизбежным, т.к. согласно Указу Президента РФ от 30.03.2022 № 166 с 1 января 2025 г. «органам государственной власти, заказчикам запрещается использовать иностранное ПО на принадлежащих им значимых объектах критической информационной инфраструктуры». А значит ИТ-подразделения этих государственных и окологосударственных организаций вынуждены озаботиться процессом миграции, чтобы уложиться в обозначенный срок.
2. Геополитика и санкции. Введение санкций против России или отдельных компаний, а также уход с российского рынка многих зарубежных вендоров привели к тому, что и коммерческие организации стали всерьез рассматривать российский софт как альтернативу MSSQL или Oracle – отсутствие поддержки, отсутствие обновлений может привезти как к проблемам совместимости, так и к проблемам информационной безопасности из-за возможных уязвимостей в ПО. Если вопросы обновлений еще можно порешать, то отсутствие поддержки вендора может стать критичным.
3. Стоимость владения. «Ванильная» PG вообще бесплатна и для некоторых коммерческих организаций этот вариант вполне возможен. Но мы его не будем рассматривать, т.к., во-первых, в единый реестр российских программ и баз данных «ванильный» PostgreSQL не может быть включен. А во-вторых, многие коммерческие сборки имеют сразу на борту наиболее оптимальные настройки и модули для повышения производительности 1С:Предприятие, что для больших систем очень важно. Ну и поддержку вендора никто не отменял. Поэтому рассматриваем какие-то коммерческие сборки, но с более гуманным ценником, нежели MS SQL.

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

Нюансы перехода на PostgreSQL крупных баз данных

Сам процесс перехода представляется специалистами зачастую несколько поверхностно. И, более того, происходит даже спонтанно – поджимают сроки, появилось вдруг подходящее технологическое окно и процесс пошел. Но информации из форумов и типовых рекомендаций вендоров, собранных второпях, может оказаться совсем недостаточно для ВАШЕЙ системы, и многие пользователи терпят неудачу.

И терпят неудачу на разных этапах. На этапе переноса данных, на этапе нагрузочного или функционального тестирования, на этапе перехода пользователей. Самое неприятное – это получить большие проблемы уже на этапе опытной эксплуатации, когда пользователи работают на новой платформе несколько дней или недель, и всплыла ошибка, например функциональная, которая никак не тестировалась или не могла быть протестирована на более ранних этапах. Или нагрузка на тестовом стенде моделировалась неверно, что-то не учли. А обратного пути уже нет, надо ее решать «на горячую».

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

1. Выбор платформы

Под платформой я имею в виду версию PG, версию Linux, архитектуру и аппаратные ресурсы.

Версии ПО обычно выбирается из соображений требований информационной безопасности предприятия, совместимости и возможности поддержки со стороны вендора.

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

Для более точной оценки следует провести небольшое нагрузочное тестирование ряда основных операций в вашей ИС – в текущей и предполагаемой архитектуре. Причем, это не обязательно должен быть полноценный сервер. Можно в однопользовательском режиме снять нужные метрики и дальше экстраполировать их на требуемое количество пользователей/сеансов/документов и прочее. Таким образом, вы получите необходимые ресурсы будущих серверов в «идеальных» условиях – это отправная точка, ниже которой лучше не опускаться.

2. Настройка PG

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

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

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

3. Миграция без остановки системы

Сам подход к миграции платформы без остановки работы пользователей, а значит без простоев системы востребован и даже необходим, во-первых, для больших и очень больших систем, а во-вторых, для предприятий непрерывного цикла, где система работает 24/7 и нет даже намека на технологические окна. То есть, для них смена платформы (версии 1С, редакции СУБД, или целиком СУБД – не важно) очень рискованное мероприятие, которое грозит остановками работы информационной системы, а значит торможением бизнеса и убытками.

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

То есть сформулируем первые два нюанса, о которых надо помнить и обязательно прорабатывать сценарии решения:

1. Переход пользователей без остановки или с минимально-допустимой остановкой системы.
2. Сценарии отката пользователей на старую систему в случае форс-мажоров. Здесь нужно заложиться на допустимое время простоя системы, возможную синхронизацию данных из «новой системы» обратно в «старую» или же смириться с их потерями в случае принятия решения об откате.

Для решения этих двух вопросов мы рекомендуем нашу технологию репликации DBReplication, которая обеспечивает обмен и синхронизацию данных между разными СУБД MS SQL и PG.

Основная идея – это онлайн асинхронная репликация данных из MSSQL в PostgeSQL, при которой первоначальный перенос и конвертация данных может проходить сколь угодно долгое время. Но! Все инкрементальные изменения, возникшие за период переноса, потом докачаются из очереди, и система репликации через какое-то время переходит в режим работы online.

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

При этом на целевой БД в PostgreSQL (а её копий можно сделать сколь угодно много) можно заранее отрабатывать проверку функциональности и производительности, имея возможность в полуавтоматическом режиме сравнивать результаты работы одного и того же функционала и сравнивать результаты производительности (например, по APDEX).

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

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

Как только пользователи переходят на новую архитектуру, репликация включается в обратную сторону:

Это позволит в случае форс-мажора переключить пользователей на старую архитектуру MS SQL до устранения сбоев в новой PG.

4.      Мониторинг PostgreSQL

Инструмент мониторинга производительности нужен, во-первых, на этапе функционального и нагрузочного тестирования, а во-вторых, уже в продуктиве. Обязательно! Must have! Как бы тщательно не проводилось тестирование, выбор настроек серверов и т.д., реальная пользовательская нагрузка может и будет создавать прецеденты, которые нужно расследовать, понимать причины и методы исправления. Понимать критичность просадки в тех или иных запросах. Например, вы запустили пользователей в новую систему и поняли, что длительность некоторых операций/запросов стала хуже. Хотя ничего такого на тестовом стенде не предвещало. Нужно оперативно понять количество таких запросов, разброс метрик, блокировочную картину, потребление ресурсов запросами, а не севером в целом. Одно дело если таких запросов единицы, а другое дело, если их сотни тысяч за день и что сразу критично для всех бизнес-процессов.

У вас должен быть под рукой инструмент, который поможет выяснить основные проблемные места в системе за минимальные сроки. Точное понимание проблемы – это уже половина дела и позволит привлечь правильные ресурсы – своих специалистов или профильных компаний. Без качественного мониторинга переход на новую архитектуру может ухудшить метрики основных операций (APDEX), привести к срыву сроков проект и даже к остановке работы информационной системы 1С.

В качестве инструмента многие годы мы используем и рекомендуем к использованию мониторинг производительности Perfexpert.

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

5.  Прогноз роста нагрузки: горизонтальное масштабирование

Об этом этапе задумываются при планировании перехода чуть больше, чем «никто». А ведь важно не просто перейти на новую архитектуру, но и обеспечить стабильную и устойчивую работу системы на годы вперед. Предусмотреть возможный рост нагрузки, связанный как с сезонными факторами, так и с ростом бизнеса, когда нагрузка на ИТ-систему увеличивается в разы. Иначе придется потом бороться с проблемами просадки производительности «на горячую».

Обычно серверы СУБД плохо поддаются масштабированию. Их кластеризация носит скорее эффект отказоустойчивости, нежели балансировки нагрузки. Тем не менее, такие решения есть и могут позволить вам не попасть в сложную ситуацию после миграции, когда выделенные для СУБД серверные ресурсы «неожиданно» кончились и система встала колом. Пока идет разбор полетов можно попытаться распределить нагрузку по остальным нодам кластера.

На борту PG есть штатная кластеризация. Мы со своей стороны тоже предлагаем свои модули, адаптированные к системам на базе 1С:Предприятие, которые позволяют:

• Оптимизировать «на лету» запросы от сервера 1С, которые нельзя оптимизировать средствами 1С.
• Перераспределять нагрузку между нодами кластера, отправляя на дополнительные часть запросов на чтение. Более того, вторичные ноды могут обладать другими настройками сервера СУБД, которые будут более оптимальны для тех групп запросов, которые вы туда перенаправляете.

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