Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / MySQL Новый топик    Ответить
 Ускорение миграции/изменения таблиц в MySQL?  [new]
_webdev_
Member

Откуда: Germany
Сообщений: 522
Здравствуйте, поделитесь пожалуйста мыслями, опытом.

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

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

Как можно улучшить сию ситуацию?
Как делаете миграции вы? Как решали такую проблему?
Где почитать о улучшениях при миграции/изменении БД?
Решит ли частично проблемы переезд с MySQL на PostreSQL?

Спасибо!
9 окт 19, 09:03    [21990050]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение миграции/изменения таблиц в MySQL?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7902
поставить на сервер быстрые диски?

сомневаюсь, что перевод на PostgeSQL что-то поменяет, а может даже сделает и хуже. У "промышленных" СУБД типа Oracle, скорее всего есть специальные решения для систем 24x7, но и то явно в EE редакции (дофига денег)

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

честно говоря, IMHO проблема выглядит как-то надуманной. Что бы в нормальной рабочей системе требовалось регулярно менять основые таблицы.... бред какой-то. Не каждый же день выходят major патчи требущие изменения структур, даже если система в режиме разработки, пусть даже минор патчи раз в 1-2 недели, но major патчи чаще чем раз в 1-2 месяца... когда Вы эти изменения тестировать-то успеваете?
9 окт 19, 15:19    [21990561]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение миграции/изменения таблиц в MySQL?  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 19449
_webdev_
продуктивная БД достаточно большая и изменение таблицы(добавление колонки, изменение значений) с 10-15 миллионами записей может длится часами. Что призводит к блокировке таблицы

Добавление поля? это вообще онлайновая операция и должна выполняться почти мгновенно. Ищите, где косячите...

Изменение 15kk значений за несколько часов? у вас там первый пень и 32 метра оперативы, что ли, или БД на дискетку пишется?
В крайнем случае - создание дополнительного поля, навешивание триггеров на его обновление при изменении поля-источника, потом копирование с обработкой чуньками по 5-10 тысяч, затем быстро лок-дроп-ренейм.
9 окт 19, 15:41    [21990589]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение миграции/изменения таблиц в MySQL?  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 881
Leonid Kudryavtsev
сомневаюсь, что перевод на PostgeSQL что-то поменяет, а может даже сделает и хуже

Ну как postgresql dba я знаю как вносить изменения схемы на живой проект без downtime или с секундными локами. Если приложение уверено, что только оно умеет вносить миграции (неправильно) - то это сложнее. Некоторые такие якобы умные штуки даже банальный create index concurrently не умеют...

Для mysql - например вот в этот раздел документации смотреть надо: https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html
Потом перконовский pt-online-schema-change, какие-нибудь пляски вокруг репликации. mysql я не админил, детально не распишу.
9 окт 19, 15:43    [21990592]     Ответить | Цитировать Сообщить модератору
 Несколько db-schemas в одном SpringBoot App - перформенс?  [new]
_webdev_
Member

Откуда: Germany
Сообщений: 522
Спасибо за ответ и мнение..

Leonid Kudryavtsev
честно говоря, IMHO проблема выглядит как-то надуманной. Что бы в нормальной рабочей системе требовалось регулярно менять основые таблицы.... бред какой-то. Не каждый же день выходят major патчи требущие изменения структур, даже если система в режиме разработки, пусть даже минор патчи раз в 1-2 недели, но major патчи чаще чем раз в 1-2 месяца... когда Вы эти изменения тестировать-то успеваете?
- Вот так как-то и живём. Да, всё верно, релизимся раз в 2 недели. Такие апдейты, действительно бывают не часто, но бывают и каждый раз вспоминается, что нужно как-то оптимизировать...
9 окт 19, 16:21    [21990637]     Ответить | Цитировать Сообщить модератору
 Несколько db-schemas в одном SpringBoot App - перформенс?  [new]
_webdev_
Member

Откуда: Germany
Сообщений: 522
Akina
Добавление поля? это вообще онлайновая операция и должна выполняться почти мгновенно. Ищите, где косячите...
- буду. Уже почитал о этом. Спасибо.

Akina
Изменение 15kk значений за несколько часов? у вас там первый пень и 32 метра оперативы, что ли, или БД на дискетку пишется?
Не знаю, сколько миллионов точно, но база весит около 20Гиг. Никак нет, вполне себе продуктивный Galera Cluster, правда какие у него параметры не знаю..


Akina
В крайнем случае - создание дополнительного поля, навешивание триггеров на его обновление при изменении поля-источника, потом копирование с обработкой чуньками по 5-10 тысяч, затем быстро лок-дроп-ренейм.
- пасиб
9 окт 19, 16:24    [21990640]     Ответить | Цитировать Сообщить модератору
 Несколько db-schemas в одном SpringBoot App - перформенс?  [new]
_webdev_
Member

Откуда: Germany
Сообщений: 522
Akina
Добавление поля? это вообще онлайновая операция и должна выполняться почти мгновенно. Ищите, где косячите...
- буду. Уже почитал о этом. Спасибо.

Akina
Изменение 15kk значений за несколько часов? у вас там первый пень и 32 метра оперативы, что ли, или БД на дискетку пишется?
Не знаю, сколько миллионов точно, но база весит около 20Гиг. Никак нет, вполне себе продуктивный Galera Cluster, правда какие у него параметры не знаю..


Akina
В крайнем случае - создание дополнительного поля, навешивание триггеров на его обновление при изменении поля-источника, потом копирование с обработкой чуньками по 5-10 тысяч, затем быстро лок-дроп-ренейм.
- пасиб
9 окт 19, 16:29    [21990652]     Ответить | Цитировать Сообщить модератору
 Несколько db-schemas в одном SpringBoot App - перформенс?  [new]
_webdev_
Member

Откуда: Germany
Сообщений: 522
Melkij
Для mysql - например вот в этот раздел документации смотреть надо: https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html
Потом перконовский pt-online-schema-change, какие-нибудь пляски вокруг репликации. mysql я не админил, детально не распишу.
Пасиб
9 окт 19, 16:29    [21990655]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение миграции/изменения таблиц в MySQL?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7902
_webdev_
Вот так как-то и живём. Да, всё верно, релизимся раз в 2 недели. Такие апдейты, действительно бывают не часто, но бывают и каждый раз вспоминается, что нужно как-то оптимизировать...


вопрос на 90% решается организационно. Если "окно" для накатов патчей все равно есть, то накатить их ночью, в выходные - лично я проблемы не вижу

проблема только тогда, когда о них "и каждый раз вспоминается". Тогда понятно, предложение к коллегам неожиданно остаться поработать вечером, когда у них уже совершенно другие планы (например выпить пива в пятницу вечером) - может вызвать только негатива на кривых "патче-писателей"

если же админы об этом заранее за неделю знают + не от программистов, а от начальство + им это как-то компенсируется + есть удаленный доступ из дома.... просьба запустить скрипт ночью или в выходные - без проблем. AFAIK & IMHO

ну и IMHO

любое усложнение скрипта - возрастание вероятности не штатных ситуаций, сбоев при накате - а любой сбой при накате, это не 10-30 минут "подождать", это от полдня до пары дней стояния на ушах все конторы (а то и хуже)

плюс не копить все изменения на один раз. Я сейчас, например, все изменения структур/справочников (которые не ломают старый функционал), сразу на прод скидываю. Когда тестирование закончится, нужно будет накатить только пакеты.

IMHO
9 окт 19, 16:44    [21990671]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение миграции/изменения таблиц в MySQL?  [new]
Alex_Ustinov
Member

Откуда: Nickel
Сообщений: 2914
_webdev_,
Я как то пытался думать, как быстрее поменять колесо на ходу, в итоге приходится останавливаться и все упирается в скорость откручиивания болтов. Так что железо и в африке железо
10 окт 19, 06:12    [21990982]     Ответить | Цитировать Сообщить модератору
 Несколько db-schemas в одном SpringBoot App - перформенс?  [new]
_webdev_
Member

Откуда: Germany
Сообщений: 522
Leonid Kudryavtsev
вопрос на 90% решается организационно. Если "окно" для накатов патчей все равно есть, то накатить их ночью, в выходные - лично я проблемы не вижу

проблема только тогда, когда о них "и каждый раз вспоминается". Тогда понятно, предложение к коллегам неожиданно остаться поработать вечером, когда у них уже совершенно другие планы (например выпить пива в пятницу вечером) - может вызвать только негатива на кривых "патче-писателей"
- Да, всё известно. Просто хотелось бы поменьше таких ситуаций где админы жалуются...
10 окт 19, 08:16    [21991003]     Ответить | Цитировать Сообщить модератору
 Несколько db-schemas в одном SpringBoot App - перформенс?  [new]
_webdev_
Member

Откуда: Germany
Сообщений: 522
Alex_Ustinov
Я как то пытался думать, как быстрее поменять колесо на ходу, в итоге приходится останавливаться и все упирается в скорость откручиивания болтов. Так что железо и в африке железо
))))Картинка с другого сайта.

Кста, Спрашивал вчера Galera Cluster -> /3 nodes / 60 Gb RAM / HDD Cluster
10 окт 19, 08:17    [21991004]     Ответить | Цитировать Сообщить модератору
Все форумы / MySQL Ответить