Mysql обновление через репликацию

По существу сказать нечего, но

У сервиса, у которого база стоит на единственной древней ноде, максимальное время простоя точно не 10 минут. Просто руководство об это еще не знает :)

Сталкивался. В итоге оставил на InnoDB.

Разверни один из бакапов на тестстенде, поразвлекайся. Штатные бд-разрабы есть, штуки 3?

2. С oldsql снять подный дамп (все БД и таблицы)
3. Перенести дамп на newsql, импортировать
4. Настроить репликацию master-slave между oldsql и newsql

Это делается в несколько другой последовательности:

0. отключить все сервисы которые цепляются к oldsql.

1. Переделать конфиг oldsql как master с row-based репликацию, потом временно запустить в read-only режиме.

2. С oldsql снять годный ПОЛНыЙ дамп (все БД и таблицы И ПРОЦЕДУРы И АККАУНТы и т.д.), и ЗАОДНО с этом дампе снять и записать позицию для слейва для синхронизации с бинлогах.

3. Можно запустить обратно oldsql нормально в read-write (и сервисы)

Далее можно конфигурить слейв как и когда удобно:

После того как он сконфигурен (пустым) - импортировать дамп, выставить ему позицию в бинлогах на мастере к которой дамп привязан - запустить синхронизацию. По идее, слейв мастера догонит.

1. Разные версии mysql на хостах, есть проблемы с репликацией?

Скорее всего будут. Нужно читать доки - но разница в версий слишком большая - а это всегда было слабым местом при mysql репликации.

Я бы для верности сделал без репликацию:

• подготавливаем наперед полностью сервер с newsql и необходимое окружение (пока oldsql работает).
• Потом в один присест: выключаем все сервисы, выставляем oldsql в read-only, делаем полный дамп, импортируем его на новом сервере в newsql, переключаем конфиги сервисов чтобы работали с машине где newsql, выключаем oldsql полностью, запускаем сервисы.

Дополнительный даунтайм (по сравнению со сценарием с репликации), будет на:

• перетаскивание дампа с одного сервера на другого
• импортирование дампа в newsql
• переключениe конфигов apps/services чтобы конектились к newsql

Это возможно, не так много (зависит от размера базы).

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

Руководство знает, этот сервер глубокое legacy и там сама софтина в процессе обновления, тогда и БД по нормальному развернем, пока надо сделать чтобы пару есяцев прожило как есть.

Потом в один присест: выключаем все сервисы, выставляем oldsql в read-only, делаем полный дамп, импортируем его на новом сервере в newsql, переключаем конфиги сервисов чтобы работали с машине где newsql, выключаем oldsql полностью, запускаем сервисы.

ну вот я примерно так и собирался сделать, но там 30 минут выход (дамп (хотя на тесте я дамп на живую делал с --single-transaction), копия, рестор) и еще 30 я закладываю на непредвиденные проблемы.

Это возможно, не так много (зависит от размера базы).

~800Mb в gz виде полный дамп (все БД, все таблицы)

с –single-transaction

Это тоже ок.

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

ну вот я примерно так и собирался сделать, но там 30 минут выход (дамп (хотя на тесте я дамп на живую делал с –single-transaction), копия, рестор) и еще 30 я закладываю на непредвиденные проблемы.

Да пусть и три часа, у тебя просто нет выбора, если база вообще как-то важна.

Вероятность что репликация с такой древнючей версией сработает, имхо не больше 1%. Хотя можно взять старейшую версию mariadb, если она совместима по докам, и потом апгрейдить…

Руководству тоже будет поука, не держать legacy.

Ну ок, тогда пойду согласовывать ночные работы. Мне тоже кажется что проще и надежнее без репликации сделать.

Имхо слишком много подводных камней и шагов для такой системы.

Я бы просто ночью сделал бекап и перенёс на новый сервер. Ну будет простой не 10 минут, а час-два. Зато никаких неожиданных несовместимостей версий, проблем с ролями и бинлогами.

Заодно и расскажешь.

Я делал так

2. С oldsql снять подный дамп (все БД и таблицы)

2.1 включить мастер репликацию на oldsql. ЕМНИП нужен будет рестарт сервера.

2.2 снять дамп с работающей базы с ключиком, который запоминает позицию на мастере –master-data

5. Ночью, отключть все сервисы которые цепляются к mysql

5. Дождаться, пока слейв догонит мастер и сделать слейв новым мастером.

ЕМНИП я делал statement based репликацию, не знаю, лучший ли это вариант, но у меня проблем не было.

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

Не надо никаких дампов снимать. Примерно так (это краткое описание шагов, ниже обязательные уточнения):

1) установи новый сервер

2) сочини конфиг для нового сервера чтоб он соответствовал старому в плане расположения файлов базы на диске, новый сервер пока не запускаем

3) останови старый

4) удали дефолтные данные нового сервера, включая системную базу mysql, все журналы innodb и прочее

5) перенеси эти несчастные 800мбайт со старого копированием директории с базами (обычно она одна и называется mysql, лежит где-то в /var или где её перенастроили)

6) запусти новый сервер (айпи адрес сразу настрой нужный)

7) запусти mysql_upgrade на нём чтобы оно привело системные таблицы в новый формат

База скорее всего начнёт работать после шестого шага, upgrade для работы не обязателен, но нужно его сделать во избежание возможных проблем.

Уточнения:

Перед реальным переносом проведи ту же самую операцию тестово: всё то же самое, но шаг 3 пропускаем и в шаге 6 айпи адрес не меняем на боевой. После чего проверяешь что всё работает. Заодно выяснишь детали запуска mysql_upgrade (ему наверно нужны какие-то права будут ну там логины пароли или ещё чего - не помню точно). Тест можно проводить сколько угодно раз, после него просто чистишь под ноль все данные (не конфиги) mysql-сервера. Поскольку при тестах старый сервер не будет выключен, файлы могут оказаться немного битыми, но в целом сервер должен их сожрать (ну, может не с первого раза, а придётся второй раз копировать если уж слишком неконсистентные получились).

ЕМНИП я делал statement based репликацию, не знаю, лучший ли это вариант, но у меня проблем не было.

Statement-based можно только если есть абсолютная уверенность, что изменения в базе всегда абсолютно детерминированы (не зависят от внешнего мира/окружения, crypto, random, всяких там датах и т.д.).

Вам наверное, повезло; это может привести к необнаруживаемым ошибкам и неконсистентностей

Например (второй случай), если приложение выкатывает такую последовательность на мастере:

insert into author author.id=uuid(), …..

{select last-insert-id … берет последний primary key для автора какой получился, пусть id=‘blah-blah-87AZ..’)

insert into article …., author.id = ‘blah-blah-87AZ..’

…

… на слейве при statement-репликации такое либо не пройдет, либо данные вообще откатятся и запись будет отсутствовать (если в трансакции, и innodb с foreign key constraint) т.к. для author.id слейв у себя сгенерит другой uuid.

С датами еще хуже

7. запусти mysql_upgrade на нём чтобы оно привело системные таблицы в новый формат

С mysql-5.1 на mysql-8.0/mariadb-10.11 (текущие LTS-версии)?

Да ты очень сильный шутник!

удали дефолтные данные нового сервера, включая системную базу mysql, все журналы innodb и прочее

копированием директории с базами (обычно она одна и называется mysql, лежит где-то в /var или где её перенастроили)

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

Это вообще, эпично :))))

Kolins, НЕ ДЕЛАЙТЕ ТАК НИКОГДА, тем более на разных версий

Обновлял так mysql 5.1 -> mariadb 10.4 (оно тоже «текущее LTS» до сих пор, если что), всё норм сработало. Насчёт 10.11 не проверял и уже не проверю т.к. 5.1 больше нигде не осталось. В любом случае, я предупредил что сначала надо протестировать, так что неожиданных проблем бы не случилось.

Если 5.1 -> 10.11 и правда не подхватит бинарную базу, я бы попробовал 5.1 -> 10.4 -> 10.11 лишь бы с дампами не возиться. Впрочем это уже личные предпочтения, в целом в дампах ничего плохого нет.

Чего не делать? Не тестировать перенос перед окончательным его производством? Последняя цитата именно к этому относилась, но ты конечно не читал и отвечаешь.

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

Твоюжмать, шедевр за шедевром.

Есть фактические возражения? Ты отрицаешь, что тупое копирование файла на не чрезмерно загруженной базе в большинстве случаев даёт вполне рабочий (для тестов, разумеется, а не для прода) результат?

Есть. Как от mysql_upgrade, прыгая через много версий сразу, так до копирования файлов СУБД при невыключенной СУБД.

Эпичные советы от админа локалхоста, хейтящего годами InnoDB/Ubuntu/sudo на ЛОРе.

Чего не делать?

Того, чего не надо - не слушать идиотские советы

цитата именно к этому относилась

Да как бы оно там не было : )

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

То она запросто может скопытится через неделю, не найдя что-то в бинарных файлах/системных баз (или найдя не то, что надо). И что бизнес будет делать - откатываться на бэкап недельной давности? И это если еще повезет

Вообще может, и не скопытится, конечно… : )

Но тут все на авось и соплями держится

https://mariadb.com/kb/en/upgrading-from-mysql-to-mariadb/

Например, хотя бы эту ссылку надо было дать, с обязательным дополнением, что её надо читать ОЧЕНЬ внимательно.

Мда.

Как от mysql_upgrade, прыгая через много версий сразу

См. следующий ответ.

копирования файлов СУБД при невыключенной СУБД

Чем плохо копировать их в целях тестирования? Ещё раз повторю - заливать итог такого копирования в прод я не предлагал, оно нужно только чтобы заранее выявить возможные проблемы. Такое копирование может добавить проблем, да, но вот спрятать имеющиеся - вряд ли.

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

Это не «незаметно подменят», это называется inplace апгрейд базы. Вполне себе штатная процедура, вон Dimez даже ссылку привёл.

То она запросто может скопытится через неделю, не найдя что-то в бинарных файлах/системных баз (или найдя не то, что надо).

mysql_upgrade как раз и фиксит или как минимум выявляет (поэтому и нужен предварительный тестовый прогон) все эти проблемы.

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

По ссылке кстати как раз видно, что препятствий к бинарному апгрейду 5.1 -> 10.11 судя по всему нет. Дампить надо только если исходная база - mysql 8.0 и мы хотим перейти на mariadb любой из версий. И ещё сложности если исходная 5.0 и древнее, но у нас 5.1 так что нас это не касается. Всякие мелкие косяки с форматом таблиц (типа этого: «In particular, note that the JSON type in MariaDB is a LONGTEXT, while in MySQL it's a binary type.») выявились бы тестовым mysql_upgrad-ом - он бы на этих таблицах упал (скипнул их, точнее) с ошибкой, кстати вспомнил у меня при 5.1 -> 10.4 так тоже было из-за чего-то там - увидел ошибки, сделал на 5.1 нужные alter table, скопировал файлы заново и обновилось норм.

называется апгрейд базы. Вполне себе штатная процедура

mysql_upgrade как раз и фиксит все эти проблемы

Перестань уже врать.

Твоя процедура (подмена кишек), приемлема только при одинаковых версий

Вот Dimez писал

… ссылку надо было дать, с обязательным дополнением, что её надо читать ОЧЕНЬ внимательно

, и ты лайк ему тоже поставил.

Ну и что - прочитал?

У ТС версия mysql5.1 - и хочет его перевести на новый сервер (>=mariadb-10.11)

Что там написано по этому поводу - как для твою «штатную процедуру» подмена кишек, так и для репликации - расскажешь?

подмена кишек,

Нет подмены. У нас есть старые данные и мы к ним ставим новые бинарники. Просто так вышло что новые бинарники у него на новом сервере, потому старые данные туда надо копировать. После установки новых бинарников надо запустить mysql_upgrade чтобы он привёл данные в соответствие.

Ну и кстати, у него то база мелкая, а для всяких огромных иногда дампы оказываются совсем не вариантом как по времени так и по расходу места. И там бинарный апгрейд оказывается по сути единственным вариантом.

Твоя процедура (подмена кишек), приемлема только при одинаковых версий

Там несколько расплывчато сказано, но суть такая:

mysql 8.0 -> mariadb - дамп обязателен

mysql 5.0-and-older -> mariadb - надо смотреть другую инструкцию в которой рассказывается про ещё пачку несовместимостей

mysql -> mariadb одной версии - «просто поставьте одно вместо другого, обычно этого достаточно, впрочем совет про mysql_upgrade вреда не сделает»

mysql -> более новое mariadb - «ставьте и не забудьте проверить несовместимости и вызвать mysql_upgrade»

что препятствий к бинарному апгрейду 5.1 -> 10.11 судя по всему нет.

Где это? Написано, что:

Within the same base version (for example MySQL 5.5 -> MariaDB 5.5, MySQL 5.6 -> MariaDB 10.0 and MySQL 5.7 -> MariaDB 10.2) you can in most cases just uninstall MySQL and install MariaDB and you are good to go. There is no need to dump and restore databases. As with any upgrade, we recommend making a backup of your data beforehand.

Т.е. между теми же версиями можно так делать

If you are using MySQL 8.0 or above, you have to use mysqldump to move your database to MariaDB.

Начиная с 8 MySQL то нельзя

Для очень старых версий есть отдельная ссылка

https://mariadb.com/kb/en/upgrading-to-mariadb-from-mysql-50-or-older/

В самом начале написано для 5.1:

If you upgrade to MariaDB 5.1 from MySQL 5.1 you don’t have to do anything with your data or MySQL clients. Things should «just work». Т.е. то же самое - можно, для одинаковых версий

Ненужно быть гением чтобы понять, что все далее в этой странице относится про миграции с MySQL версии <=5.0 к MariadB 5.1 (см. заголовок страницы и линк, если здравый разум не подсказывает).

Так что если ТС хочет пойти безопасно, «по твоим путем» - никак иначе чем перетаскиванием кишок MySQL 5.1 к MariaDB 5.1 - и далее, апгрейдить MariaDB наверх через версий, пока дойдет до последнюю

Т.е. между теми же версиями можно так делать

Между одинаковыми можно просто заменить бинарники и ничего не делать (обычно даже mysql_upgrade), между разными же обязателен mysql_upgrade и рекомендуется наличие бекапа перед процедурой. О том, что нельзя прыгнуть через все версии, в т.ч. со сменой mysql->mariadb там нигде не сказано.

Так что если ТС хочет пойти безопасно, «по твоим путем» - никак иначе чем перетаскиванием кишок MySQL 5.1 к MariaDB 5.1 - и далее, апгрейдить MariaDB наверх через версий, пока дойдет до последнюю

Для версии 5.1 предварительный переход на mariadb 5.1 смысла практически не имеет. Формат базы, если не использовать mariadb-специфику (такую как например движок aria), был полностью одинаковый. Даже по второй ссылке об этом сказано.

Ну и кстати, у него то база мелкая, а для всяких огромных иногда дампы оказываются совсем не вариантом как по времени так и по расходу места. И там бинарный апгрейд оказывается по сути единственным вариантом.

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

Или по-твоему, «огромных» legacy баз - нужно/можно/позволительно «апгрейдить на авось» в продакшене, путем подмены файлов - чтобы сэкономить время? :))

Зажигай еще.

Для версии 5.1 предварительный переход на mariadb 5.1 смысла практически не имеет. Формат базы, если не использовать mariadb-специфику (такую как например движок aria), был полностью одинаковый. Даже по второй ссылке об этом сказано.

Ох… Скажи прямо - по-твоему, с любой версии MySQL<8 можно сразу подсунуть его файлы данных как есть, к MariaDB 10.11 - и после отработки апгрейд скрипта MariaDB 10.11 - все будет чики пуки?

Скажи тогда, зачем они там это прямо так и не написали, а вместо этого растекались объяснять что можно within the same base version

Within the same base version (for example MySQL 5.5 -> MariaDB 5.5, MySQL 5.6 -> MariaDB 10.0 and MySQL 5.7 -> MariaDB 10.2) you can in most cases just uninstall MySQL and install MariaDB and you are good to go. There is no need to dump and restore databases. As with any upgrade, we recommend making a backup of your data beforehand.

О том, что нельзя прыгнуть через все версии, в т.ч. со сменой mysql->mariadb там нигде не сказано.

А здравый разум, что говорит? : ))

Что если прямо «не сказано» - так значит нормально положиться на авось - что сработает, и позднее внезапного фола не будет?

А то - что даже сам MySQL между собой - официально не поддерживает апгрейд перепрыгиванием между версий:

https://dev.mysql.com/doc/refman/5.7/en/upgrade-paths.html

?

Upgrade that skips versions is not supported. For example, upgrading directly from MySQL 5.5 to 5.7 is not supported.

Ну и ну.

Между пунктами 3 и 4 не хватает пункта «Все протестировать»!

Просто остановить БД, скопировать дамп, перевести и развернуть - около часа по времени выходит

Ну и норм.

Максимальное время простоя (недоступность БД) - 10 минут.
Есть древнючий сервер

А если он у вас сдохнет, а он рано или поздно сдохнет, как «10 минут» можно будет обосновать?

БД связана с radius для авторизации клиентов. если БД недоступна то клиенты не смогут авторизовываться - это критично, от того и ограничение в 10 минут.

Вообще сделал экспорт БД без логов. Стала меньше 10 раз, буду такую переносить, только прежде надо проверить что хранимые процедуры нормально отрабатывают (radius состоит из perl скриптов, которые активно эти процедуры используют, он следующий на очереди) после переноса ну и пользователей перетащить отдельно.

БД связана с radius для авторизации клиентов. если БД недоступна то клиенты не смогут авторизовываться - это критично, от того и ограничение в 10 минут.

Тю. Берите пример с того же сбера: У нас проф работы, сервис будет доступен через три часа... ан нет, не срослось, через пять часов... ан, нет...ну вы поняли.
Ну или как большинство ИСП поступает, рассылка на тему «у нас будут проводится проф работы, возможны перебои».
Но если хотите совсем по фэншую, настройте репликацию со старого на новый.

чел, у тебя только четыре звезды, гасить ещё рано :(