Миграция на PostgreSQL и импортозамещение СУБД
Миграция на PostgreSQL - это смена модели эксплуатации, и только во вторую очередь перенос данных. Мы делаем обе части этой работы: 25 лет сопровождаем MS SQL Server, несколько лет строим и обслуживаем PostgreSQL, поэтому видим переход с обеих сторон.
Начинаем всегда с одного вопроса: нужна ли миграция именно вам. Примерно в трети случаев ответ после аудита - «пока нет». Ниже объясняем, из чего складывается этот ответ.
Кому миграция нужна, а кому - нет
После ухода Microsoft из России сложились четыре типовые ситуации. У каждой своё правильное решение, и миграция - только одно из них.
Для госорганов и значимых объектов критической информационной инфраструктуры использование зарубежных СУБД ограничено законодательно, а закупки требуют реестра отечественного ПО. Здесь вопрос не «стоит ли», а «успеваем ли». Чем раньше сделан аудит и план, тем спокойнее пройдёт сам переход - на PostgreSQL или Postgres Pro из реестра российского ПО.
Если вы купили бессрочные лицензии MS SQL Server до 2022 года, право пользоваться ими у вас никто не отбирал. Это законно. Система работает, обновления безопасности технически доступны. Стоимость владения работающим MS SQL почти всегда ниже стоимости миграции со всеми её рисками. Мы говорим это прямо, хотя продаём миграции: если ваш прод стабилен и расти не собирается - оставайтесь. Вместо вендорской поддержки, которой больше нет, есть мы: сопровождение MS SQL Server без вендора.
Легально расширить лицензии MS SQL сейчас нельзя, параллельный импорт - серая зона с рисками. Рабочая схема: существующий прод остаётся на MS SQL, новые системы строятся на PostgreSQL. Мы сопровождаем обе СУБД, поэтому гибрид для нас - штатный режим, а не компромисс.
Здесь лицензирование сломалось по-настоящему, и ответ зависит от деталей: какие продукты, какие сроки, какая нагрузка. Разбираем на аудите, решение может быть любым из трёх предыдущих.
Подводные камни миграции на PostgreSQL: о чём молчат презентации
PostgreSQL - зрелая, мощная СУБД, мы сами её любим и внедряем. Уважение к инструменту начинается со знания его ограничений. Вот что вы должны знать до старта проекта, а не после.
В MS SQL Server вы привыкли к бэкапу и восстановлению каждой базы отдельно: full, diff, log, откат одной базы на любой момент времени. На одном сервере при этом спокойно живёт сотня баз - типичная картина в бухгалтерском обслуживании, где у каждого клиента своя база, - и восстановление любой из них никак не задевает остальные девяносто девять. В PostgreSQL физический бэкап и point-in-time recovery работают на уровне кластера целиком. Восстановить одну базу на момент времени, не трогая соседние, штатными средствами нельзя. Для одной базы остаётся логический pg_dump - без PITR и медленный на больших объёмах. Единственный способ получить привычную изоляцию - разносить базы по отдельным кластерам, и у этого решения есть своя цена. О ней следующий пункт.
Один инстанс MS SQL динамически распределяет ресурсы между всеми своими базами: ночью идёт закрытие месяца у бухгалтерии - буферный пул работает на неё, днём нагружен склад - память и ядра перетекают туда. Несколько кластеров PostgreSQL так не умеют: у каждого свои shared_buffers, свои процессы, свой запас под пиковую нагрузку, и сосед его простаивающими ресурсами не воспользуется. Суммарно это заметно больше железа под ту же самую работу. Мы называем это аппаратной инфляцией: сервер, который годами тянул сотню баз, при переезде превращается в несколько машин - и совокупно они окажутся мощнее и дороже исходной. Эта строка должна появиться в бюджете миграции до старта, а не после закупки оборудования.
Восстановление на момент времени существует, только пока непрерывна цепочка WAL-файлов. Потерялся один сегмент - цепочка порвалась, и вы узнаете об этом в худший момент. Значит, нужны мониторинг целостности архива, алерты на разрывы, регулярные тестовые восстановления. В MS SQL эту работу за вас делала связка backup log + msdb, здесь её надо построить и сопровождать.
Аналога AlwaysOn «из коробки» нет. Кластер высокой доступности собирается из Patroni, etcd и балансировщика, и этот набор надо уметь готовить, обновлять и чинить. Мы это умеем и делаем, подробнее про кластеры PostgreSQL, но в расчёт стоимости владения эти работы обязаны попасть заранее.
MVCC в PostgreSQL порождает мёртвые строки, которые убирает autovacuum. На нагруженных базах его настройка - непрерывный процесс: не успевает - таблицы пухнут и всё замедляется, слишком агрессивен - мешает работе. В MS SQL этого класса задач нет вообще, поэтому мигрировавшие команды регулярно наступают на эти грабли в первые же месяцы.
Вместо SSMS, SQL Agent и Query Store вы получаете набор: psql, pgbouncer, pg_cron, pg_stat_statements, внешний мониторинг. Всё это работает, всё это бесплатно, но кто-то должен это выбрать, собрать, настроить и поддерживать. Лицензия PostgreSQL не стоит ничего. Владение - стоит, и заметно.
Ничто из перечисленного не отменяет миграцию, если она вам нужна. Это отменяет иллюзию «перенесём за месяц и забудем». Наша работа в том, чтобы все эти пункты были учтены в плане и бюджете до старта, а не всплыли в проде.
Как мы это делаем
Обследуем ваши базы: объёмы, T-SQL-логика, хранимые процедуры, зависимости приложений, требования к восстановлению. Считаем стоимость владения обоих сценариев на горизонте трёх лет. Выдаём письменный отчёт с прямым вердиктом: мигрировать, остаться или гибрид. Вердикт «остаться» получает примерно каждый третий заказчик - и экономит на этом миллионы. Обследование оплачивается отдельно от миграции: его результат имеет ценность сам по себе, даже если переходить вы в итоге не станете.
Переносим одну некритичную базу или подсистему. На ней проверяем конвертацию схемы и кода, замеряем производительность, отрабатываем процедуру отката. Пилот дешевле открытий на боевой системе.
Перенос схемы и данных, конвертация хранимых процедур и T-SQL, настройка бэкапов с учётом кластерной архитектуры, WAL-архива и мониторинга. Параллельный прогон со сверкой результатов до тех пор, пока обе системы не дают одинаковые цифры. Переключение - в согласованное окно, с планом отката.
Первые месяцы после переезда - самые аварийные: вылезает всё, что не поймал пилот. Ведём систему по SLA, настраиваем autovacuum под вашу реальную нагрузку, тюним запросы. Дальше - абонентское сопровождение PostgreSQL или передача вашей команде с обучением.
PostgreSQL из открытых репозиториев, Postgres Pro и российские сборки, в том числе в составе Astra Linux и РЕД ОС - включая закрытый контур без доступа в интернет. Целевую платформу выбираем под ваши требования к сертификации и поддержке, а не по привычке.
Обследование - отдельные работы, они считаются под конкретную систему: объём зависит от того, сколько у вас баз, кода и завязанных на них приложений. Смета на сам переход появляется по итогам обследования и не раньше: назвать цену миграции, не зная, сколько внутри базы живой логики, - значит назвать её наугад. Оплата по этапам, с правом остановиться после любого из них.
Частые вопросы
Можно ли восстановить одну базу PostgreSQL на момент времени, как в MS SQL?
Штатными средствами нет: point-in-time recovery в PostgreSQL работает на уровне кластера целиком. Одну базу можно восстановить из логической копии pg_dump, но без отката на произвольный момент. Если для части баз требование восстановления на момент времени критично, их выносят в отдельные кластеры - это решается на этапе проектирования, с учётом того, что каждый кластер потребует собственных ресурсов (см. пункт про аппаратную инфляцию выше).
Правда ли PostgreSQL бесплатный?
Лицензия - да, бесплатная, включая коммерческое использование. Стоимость владения складывается из другого: работы по настройке бэкапов и WAL-архива, сборка и сопровождение кластера высокой доступности, настройка autovacuum, мониторинг, плюс возможная аппаратная инфляция при разнесении баз по кластерам. По нашему опыту, на нагруженном проде экономия на лицензиях частично уходит в эксплуатацию и железо. Насколько - считаем на аудите под вашу конкретную нагрузку.
Мы остались на MS SQL с бессрочными лицензиями. Это вообще законно?
Да. Бессрочная лицензия даёт право пользоваться купленной версией без ограничения по времени, уход вендора из России этого права не отменяет. Вы теряете возможность легально докупать лицензии и получать вендорскую поддержку. Первое решается гибридной схемой, второе - внешним сопровождением: поддержка MS SQL Server.
Стоит ли переходить на PostgreSQL, если MS SQL работает стабильно?
Если вы частная компания, лицензии бессрочные и рост не упирается в ядра - чаще всего нет. Миграция оправдана при регуляторных требованиях, при невозможности расширяться и для новых систем. Мы делаем аудит с прямым вердиктом и не считаем «оставайтесь» плохим ответом.
Что переносится сложнее всего?
Хранимые процедуры и T-SQL-логика: разница диалектов, поведения сортировок по умолчанию, конвертации типов. По опыту публичных проектов миграции, заметная часть проблем - это скрытые ошибки в старом коде, которые MS SQL прощал, а PostgreSQL нет. Именно поэтому в нашем процессе есть пилот и параллельный прогон со сверкой.
Сколько длится миграция?
Аудит - 1-2 недели. Дальше зависит от объёма кода: небольшая система с простой логикой - 1-2 месяца, система с тысячами хранимых процедур - от полугода. Точный срок появляется после аудита, до него любые цифры - гадание.
Расскажите о задаче - мы предложим подходящий формат.