План переноса MySQL → PostgreSQL: приложение рядом с Битрикс

Зачем отделять приложение от MySQL основного сайта

Типичный стек Битрикс остаётся на MySQL, но смежный микросервис можно перевести на PostgreSQL без трогания боевой базы интернет‑магазина. Ниже — практический план на примере отдельного сервиса вроде us-mortgage: сначала код и схема, затем остановка, перенос данных и переключение.

1. Привести код к PostgreSQL

Локально переключаем подключение на pgsql, гоняем тесты и смоук. Если проект наследовался от условного Laravel‑шаблона, синхронизация через git merge template может подтянуть готовые правки конфигурации Docker, database.php, удаление секций mysql и пр.

Отдельно проверьте: миграции с json/binary → jsonb/longText/jsonb по необходимости; опасные первичные ключи JWT — таблицы вроде jwt_public_keys лучше исключить из переноса данных и перевыпустить; внешние ключи: в MySQL индекс под FK создаётся автоматически, в PostgreSQL часто нужно добавить индекс вручную.

2. Поднять базы PostgreSQL и пользователей

Создайте нужные базы под dev/test/production и назначьте владельцев/GRANT через стандартные команды (CREATE DATABASE, CREATE USER, при необходимости \c … и привилегии на schema public). Конкретный SQL зависит от именования окружений; используйте единые префиксы сервиса и секретов из вашего секрет‑хранилища.

3. Чистая миграция — только схема

Убедитесь, что везде активно подключение pgsql (databases.php, очередь, мониторинг). Временно укажите рабочий хост Postgres в конфиге и выполните art migrate (или ваш аналог) — чтобы получить пустую схему. Первичный сид можно не жалеть: дальнейший truncate всё равно очистит таблицы перед загрузкой.

Почему не полагаться на авто‑схему pgloader целиком: настройка unsigned, типов и индексов часто дороже, чем уже готовые миграции приложения.

4. Короткая остановка сервиса

Стоп приложения через CI/CD/GitLab так, чтобы не шли новые транзакции и не ломалась ссылочная целостность на время копирования.

5. pgloader — только данные

Пример .load-файла (подставьте хосты, пароли и имя базы):

LOAD DATABASE
 FROM mysql://USER:PASSWORD@mysqlhost/us-mortgage-develop
 INTO postgresql://USER:PASSWORD@localhost/us-mortgage-develop

 WITH data only, truncate, reset sequences
 SET maintenance_work_mem to '128MB', work_mem to '12MB', search_path to 'public'

 BEFORE LOAD DO $$ ALTER SCHEMA public RENAME TO "us-mortgage-develop"; $$
 AFTER LOAD DO $$ ALTER SCHEMA "us-mortgage-develop" RENAME TO public; $$

 EXCLUDING TABLE NAMES MATCHING ~/telescope_/, ~/failed_jobs/, ~/jwt_public_keys/
;

Схема временно переименовывается под ограничения pgloader, затем возвращается в public. Исключаем служебные таблицы и те, где данные недопустимы к переносу между движками.

После загрузки задайте ALTER DATABASE ... SET search_path TO 'public' при необходимости.

6. Конфиг и запуск на Postgres

Обновите переменные деплоя: DB_CONNECTION=pgsql, хост/порт, имя базы и роль пользователя для dev/test и prod раздельно; убедитесь, что нет дублирующихся ключей env ниже по манифесту.

Связь с типовым сайтом на Битрикс

Основной каталог заказов остаётся на MySQL; этот пайплайн для отдельного сервиса (расчёт, ипотека, внешние интеграции). Так вы не смешиваете миграции ядра Битрикс с экспериментами по Postgres.