ML
Там достаточное количество отличий, даже репликация не всегда работать будет, GTID отличаются
Size: a a a
2021 August 13
ML
Бинарно - да
IZ
Ну если ты включишь движок "Aria", оно же не будет совместимо с ванильным MySQL , где этого движка просто нету.
IZ
Хотя я не знаток...
ML
В Марии много своего, если начать придираться - да, в чем-то совместима, но отличий там много и просто так перепрыгнуть с мускула на марию может быть проблематично, а с перконы на ванильный мускул - остановил сервер, снес пакет с перкона сервером, поставил пакет комьюнити эдишн, поднял сервер 🤷♂️
ML
В целом с Марией такое тоже прокатит, но есть ограничения, потому они и пишут в доке - limited drop-in replacement, и чем дальше по версиям, тем отличий больше
ДУ
подозреваю что с мускула на марию переехать проще чем наоборот)
ML
Дампы - логический бэкап
ML
В них просто запросы и данные в тексте
ML
В целом так можно, поменять пакеты, прогнать mysql_upgrade и если движок и там и там используется один, то оно должно работать, но будут нюансы в синтаксисе, в наличие/отсутствии каких-нибудь функций
ML
Одно дело просто данные перетащить, другое дело потом на новой базе крутить старые приложения, скорее всего без доработки напильником по месту будут грабли
OT
Есть таблица на 6.5кк строк, при select where like 'something%' ядра процессора в 100%, запрос отваливается по таймауту - 30 мин. Удвоил ядра, удвоил память, innodb_buffer_pool_size увеличил в соответствии с памятью. Запросы стали выполняться примерно за 9 минут по максимуму, все равно процессор в 100%. Добавил индекс по этому столбцу, теперь максимум время выполнения около 2.5 минут. Что еще можно покрутить?
ML
С шаблоном %что-то% индекс, к сожалению, работать не будет
G
Вроде на один запрос все равно одно ядро будет работать. Покажи Explain, show create table и скажи сколько у тебя строк находит в итоге? На диск нагрузки нет? Еще можешь посмотреть в сторону show profile
G
2.5 минуты по индексу на 6.5 строк это как то многовато
G
Ну и сам запрос покажи