Миграция интернет-магазина с MySQL на PostgreSQL

Мы подготовили для технического директора «ЭлектроМир» детальное сравнение MySQL и PostgreSQL по ключевым параметрам, влияющим именно на их сценарий использования:

Ключевой аргумент — архитектурный. PostgreSQL использует единый WAL (Write-Ahead Log) как для восстановления после сбоев, так и для репликации. Это делает репликацию принципиально стабильнее: если сервер может восстановиться после crash, значит реплика гарантированно синхронизируется. В MySQL два отдельных журнала (InnoDB redo log + binlog) требуют двухфазного коммита между собой, что создаёт архитектурную точку отказа.

Мы разработали план миграции с нулевым простоем, разделённый на 5 фаз. Общая длительность — 4 недели:

# Фаза 1 (неделя 1): Подготовка
# - Аудит MySQL-схемы: типы данных, триггеры, хранимые процедуры
# - Установка PostgreSQL 16 на отдельный сервер
# - Маппинг типов данных MySQL → PostgreSQL

# Фаза 2 (неделя 2): Миграция схемы и данных
# - Конвертация DDL (CREATE TABLE)
# - Перенос данных через pgloader
# - Верификация целостности

# Фаза 3 (неделя 3): Миграция логики
# - Переписывание хранимых процедур
# - Адаптация ORM-запросов в приложении
# - Оптимизация индексов

# Фаза 4 (неделя 4): Тестирование
# - Нагрузочное тестирование
# - A/B сравнение MySQL vs PostgreSQL
# - Подготовка rollback-плана

# Фаза 5 (суббота, 02:00): Переключение
# - Остановка записи в MySQL
# - Финальная синхронизация
# - Переключение приложения на PostgreSQL
# - Мониторинг 24 часа

Для переноса 85 ГБ данных мы использовали pgloader — специализированный инструмент для миграции из MySQL в PostgreSQL. Он автоматически конвертирует типы данных, переносит индексы и constraints:

-- Конфигурация pgloader
-- /etc/pgloader/electromir.load

LOAD DATABASE
    FROM mysql://readonly:password@mysql-server:3306/electromir
    INTO postgresql://migrate:password@pg-server:5432/electromir

WITH include drop, create tables, create indexes,
     reset sequences, downcase identifiers,
     batch rows = 10000, batch size = 100MB,
     prefetch rows = 10000

SET PostgreSQL PARAMETERS
    maintenance_work_mem to '2GB',
    work_mem to '512MB'

CAST type tinyint to boolean using tinyint-to-boolean,
     type int when unsigned to bigint,
     type datetime to timestamptz

ALTER SCHEMA 'electromir' RENAME TO 'public'

INCLUDING ONLY TABLE NAMES MATCHING
    ~/products/, ~/orders/, ~/users/, ~/categories/,
    ~/order_items/, ~/reviews/, ~/inventory/
;

Миграция 85 ГБ заняла 2 часа 14 минут. После переноса мы запустили скрипт верификации, который сравнил количество строк и контрольные суммы для каждой таблицы:

-- Верификация после миграции
-- Скрипт сравнивает количество строк MySQL vs PostgreSQL

-- MySQL:
SELECT 'products' AS tbl, COUNT(*) AS cnt FROM products
UNION ALL
SELECT 'orders', COUNT(*) FROM orders
UNION ALL
SELECT 'users', COUNT(*) FROM users;

-- PostgreSQL (должно совпасть):
SELECT 'products' AS tbl, COUNT(*) AS cnt FROM products
UNION ALL
SELECT 'orders', COUNT(*) FROM orders
UNION ALL
SELECT 'users', COUNT(*) FROM users;

-- Результат:
--   tbl      | mysql_cnt | pg_cnt   | match
-- -----------+-----------+----------+-------
--  products  | 1,847,293 | 1,847,293 | OK
--  orders    | 8,234,019 | 8,234,019 | OK
--  users     |   892,445 |   892,445 | OK

После переноса данных мы провели оптимизацию, используя преимущества PostgreSQL, недоступные в MySQL.

Одной из главных причин миграции была нестабильная репликация MySQL. В PostgreSQL мы настроили потоковую репликацию на основе WAL — тот же журнал, который используется для crash recovery:

# Конфигурация primary (postgresql.conf)
wal_level = replica
max_wal_senders = 5
wal_keep_size = 2GB
synchronous_commit = on
synchronous_standby_names = 'replica1'

# pg_hba.conf — разрешаем подключение реплики
host replication replicator 10.0.2.0/24 scram-sha-256

# На реплике: инициализация
pg_basebackup -h primary-server -D /var/lib/postgresql/16/main \
    -U replicator -P -R -Xs

# -R создаёт standby.signal и настраивает primary_conninfo
# После запуска реплика автоматически синхронизируется

За 2 месяца эксплуатации: 0 сбоев репликации (против 2 сбоев в месяц на MySQL). Отставание реплики стабильно менее 100 мс, что позволяет направлять на неё все read-запросы.

Переключение мы провели в субботу ночью, в окно минимального трафика. Процедура заняла 18 минут — от остановки записи в MySQL до первого ответа PostgreSQL:

# Хронология переключения (время МСК)

02:00 — Активация maintenance-страницы
02:02 — SET GLOBAL read_only = ON на MySQL
02:03 — Финальный дамп новых данных (delta: 1247 строк за 2 часа)
02:05 — Импорт delta в PostgreSQL
02:08 — Верификация: подсчёт строк, контрольные суммы
02:12 — Переключение connection string в приложении
02:14 — Рестарт application servers (4 инстанса)
02:16 — Smoke tests: оформление заказа, поиск, каталог
02:18 — Отключение maintenance-страницы
02:18 — Мониторинг: все метрики в норме

Итоговые результаты миграции за первый месяц на PostgreSQL:

Клиент отметил рост конверсии на 18% за первый месяц — прямое следствие ускорения каталога и поиска. Стоимость проекта: 2.1 млн рублей за 4 недели работы команды из 3 инженеров. Подробнее о миграции баз данных читайте на itfresh.ru.