Ускорение миграции/изменения таблиц в MySQL?

Question

[web_dev]

Хочется улучшить/ускорить миграцию MySQL базы данных.
У нас стандартный подход, скрипты в liquibase, выкатывается новая версия, скрипты запускаются.

Но продуктивная БД достаточно большая и изменение таблицы(добавление колонки, изменение значений) с 10-15 миллионами записей может длится часами. Что приводит к блокировке таблицы и так д. Поэтому деплой с изменениями стараются делать когда не слишком много запросов и так д.
Хотя имеется достаточно продуктивный Galera Cluster.
Решит ли частично проблемы переезд с MySQL на PostreSQL?

Answer 1

[Дмитрий Шицков]

По мускул нашёл такие не слишком простые варианты
https://m.habr.com/ru/post/121129/

Postgresql частично решит проблемы.мно только в случае добавления нового столбца в таблицу и без значения по умолчанию. Такой Alter вызовет лишь кратковременные блокировку для изменения метаданных таблицы. Т.е. сперва создаётся пустой столбец, а затем порциями туда начинаете мигрировать данные и в конце, при необходимости, выставляете Default значение.
В помощь таким миграция будет правило - поддерживать на уровне БД и кода версии базы n и n-1. Это ещё упростит и случаи когда придётся откатываться на прошлую версию ПО.

Comments

[web_dev]

Огромное спасибо за линк и мнение.
С него я вышел на метод фейсбука https://github.com/facebookincubator/OnlineSchemaChange

Буду благодарен за другие идеи.

Answer 2

[Михаил Бобков]

Попробуйте.
https://github.com/github/gh-ost
Используем для миграции нагруженных таблиц.

Comments

[web_dev]

Wow, thanks. )))
работает стабильно? Не жалуетесь?

[Михаил Бобков]

Проблем не было.

Answer 3

[ayazer]

1) гитхабовский gh-ost.
+: работает через бинарный лог, потому может мигрировать таблицу даже если в ней есть триггеры.
-: работает через бинарный лог, потому (относительно) медленный т.к. в какой-то момент начинает переливать данные где-то с такой-же скоростью как они появляются.

2) перконовская pt-online-schema-change
+: работает через триггеры (которые умеют грузить все доступные ядра)
-: работает через триггеры, потому если триггеры уже есть - использовать перкону не выйдет.

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

+ в новых версиях Mysql можно использовать online ddl для тех-же задач.

Comments

[web_dev]

Спасибо за комментарий. Очень полезно.

Answer 4

[Олег Клещук]

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

Comments

[web_dev]

Спасибо за мысль.