Одна из возможных версий переезда с MySQL на PostgreSQL

[headliner1985]

Насчёт уменьшения объема данных, это просто была дефрагментация. Если бы вы просто перезалили данные в новую mysql размер тоже уменьшился бы.

[SimSonic]

Это, действительно, выглядит весьма правдоподобной версией. Спасибо :)

[murkin-kot]

но мы прикинули, что переезд в PostgreSQL позволит нам решить ряд попутных технических вопросов

Что за вопросы? Повышение конкурентоспособности разработчиков на рынке труда путём добавления в резюме строчки с модной БД?

[SimSonic]

Я пытался это донести в тексте, но попробую собрать ещё раз вместе.

• Переработать миграции, схлопнув всю их историю за несколько лет, что ускорит выполнение тестов.

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

• Исправить проблемные миграции старых лет, которые уже не проходят валидацию на новой версии Liquibase, которая тянется Spring Boot 2.7.

• Начать использовать плюшки, которые есть в PostgreSQL, но которых нет в MySQL. К примеру, после миграции несколько колонок перевели на тип CITEXT.

• Модная строчка в резюме — тоже хорошая причина, спасибо за неё.

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

[wapmorgan]

Миграции схлопнуть можно просто записав их все в один sql-файл, которым инициализируется бд.
А для тестов можно вообще готовить образ бд с выполненными миграциями и импортированным перед этим sql-файлом.
У нас на каждый коммит тесты выполняются с бд, образ бд меняется только при добавлении новой миграции (тк хэш образа бд считается на основе списка миграций).

[SimSonic]

Образ бд меняется только при добавлении новой миграции (т.к. хэш образа бд считается на основе списка миграций).

Не могли бы Вы опубликовать детали, как это реализовано? Хеш играет роль тега? Это какой-то кастомный код, который интегрируется с liquibase / flyway для получения итогового хеша миграций? Или отдельная джоба в пайплайне (но тогда как с этим быть локально)?

Если готовить образ для тестов на основе "чистого" с docker hub, то есть небольшой минус: сложнее во время прогона тестов файлы расположить in-memory. Чистый образ сразу запускаем с data-папкой в памяти и все миграции в ней и выполняются. Если у вас в образе уже есть данные, то чтобы таблицы разместить в tmpfs, нужно поменять и entrypoint. Мы смотрели в такую сторону, но глубже не копали.

[wapmorgan]

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

2. Берём md5 от списка файлов в папке с миграциями, он же будет тегом образа.

MIGRATIONS_HASH=`find ${ROOT_DIRECTORY}/migrations/ -type f -exec basename {} \; | grep -v .gitignore | sort | paste -sd ' ' | md5sum - | awk '{print $1}'`

3. Проверяем, если образа с таким тегом (равным хэшу) нет, то собираем: поднимаем все контейнеры обязательные (напр, redis/pgbouncer и само приложение), выполняем миграции, фиксируем контейнер как образ. Пушим в реестр.

4. В ci/cd на тестах просто считаем опять же хэш от списка файла миграций и указываем его как тег образа БД.

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

[wapmorgan]

Это какой-то кастомный код, который интегрируется с liquibase / flyway для получения итогового хеша миграций? Или отдельная джоба в пайплайне (но тогда как с этим быть локально)?

Это просто скрипт сборки образа, который вызывается как локально, так и в ci/cd.
И всё лежит во время тестов в tmpfs, да. Просто в самом образе БД выключен автоматический запуск, а БД лежит по другому пути, и перед стартом тестов происходит копирование в tmpfs-волюм:

    command:
      - bash
      - -c
      - "cp -r /root/pgdata/* /var/lib/postgresql/data && /docker-entrypoint.sh -c shared_preload_libraries=timescaledb"
    tmpfs:
      - /var/lib/postgresql/data

[SimSonic]

Спасибо.

Я думаю, что отвечу за многих – такая статья была бы интересна.

[wapmorgan]

https://habr.com/ru/articles/753444/
1 подзаголовок про БД

[fisher]

А зачем вообще вы мигрировали на постгрес? помимо модной строчки (что конечно большой плюс) вы упомянули "плюшки", но citext сам по себе кажется сомнительной причиной для переезда.

[SimSonic]

На горизонте 1-2 года все проекты должны переехать в него. Это и вектор в организации, и вроде как даже законопроект такой Главный подписывал про системозначимые предприятия. Но тут могу ошибиться.

Мы просто проактивно сделали это первыми.

Не только CITEXT интересен, я его только как пример привёл.

[tsypanov]

• Явно прописан spring-профиль test. Все компоненты, содержащие аннотацию @Scheduled, отключены (через @Profile("!test")). Тесты, в рамках которых нужно проверить логику шедулеров, инжектят сервисы этих шедулеров и дёргают бизнес-логику ручками.

Почему бы не прописать отдельные значения для @Scheduled в application-test.yml?

[SimSonic]

Статистически подавляющая часть наших @Scheduled это не cron, а fixedDelay. Просто так проще, но, действительно, подходы могут быть разные, хоть и приводят к одному и тому же результату.