darvecher Nov 21 2019 at 12:08

Практический опыт обновления MySQL 5.7 до версии 8.0

3 min

34K

MySQL*

+30

Comments 12

charliez Nov 21 2019 at 13:59

А зачем базу mysql надо было дампить, проще было выдернуть привилегии пользователей.

darvecher Nov 21 2019 at 14:35

Не понял, как бы это помогло? Есть БД на MySQL 5.7, in-place upgrade падает с ошибкой, как апгрейднуться без дампа? Если есть какой-то способ — расскажите, нам уже не надо, но кому-то ещё поможет :)

charliez Nov 21 2019 at 14:47

Ну как минимум избавило бы от «Column count of mysql.user is wrong» и «Access to system table 'mysql.innodb_index_stats' is rejected.». Из базы mysql нужны только пользователи и их права на базы, а их можно выдернуть так:

> mysql -uroot --skip-column-names -A -e "SELECT CONCAT('SHOW GRANTS FOR ''',user,'''@''',host,''';') AS query FROM mysql.user WHERE user NOT IN ('root')" | mysql  -uroot --skip-column-names -A | sed 's/$/;/g'

на выходе получим привлегии всех юзеров (кроме рута) в виде sql запросов:

  GRANT USAGE ON *.* TO 'bitrix'@'%' IDENTIFIED BY PASSWORD '*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4';
  GRANT ALL PRIVILEGES ON `bitrix`.* TO 'bitrix'@'%';

которые надо будет засунуть в новый mysql.

Да, если используются более сложные привилегии на таблицы, или еще что-то типа proxies_priv, этого не будет достаточно. Но я за 10 лет работы с клиентскими mysql ни разу не видел, чтобы такой функционал использовался.

darvecher Nov 21 2019 at 15:06

Т.е. сделать дамп еще и без mysql.user и потом привилегии отдельно восстановить? Мне кажется общий дамп и upgrade=FORCE меньше телодвижений требует и безопаснее — точно ничего не теряется. Но может кому-то Ваш вариант понравится больше.

pyur Nov 21 2019 at 18:49

как раз на днях пытался перекатиться с 5.7 на 8.0.
вы ещё (кажется) не упомянули про то, что там новый способ авторизации с SHA2.
короче, мигрировал я в итоге на MariaDB 10.4

darvecher Nov 21 2019 at 22:45

Новый способ отключается, если надо, Percona Server при установке вообще спрашивает использовать новый или оставить старый.

vanxant Nov 21 2019 at 19:46

Еще они синтаксис немного покрутили в сторону ужесточения, особенно в датах, так что всякие там битриксы на 8 мускуле падают в рандомных местах.

vk_11 Nov 21 2019 at 22:31

А еще можно через xtrabackup поднимать реплику сразу на 8-м и потом переключаться на нее, это на порядок быстрее чем mysqldump, особенно если у вас данных прилично (больше 1 ТБ). Мы только в процессе обновления, на текущий момент апнуто 3 из 20 бд, но пока проблем не обнаружено.

darvecher Nov 21 2019 at 22:43

Расскажите подробнее, как вы делали? В результате xtrabackup получится же копия на 5.7 или я чего-то не знаю? И если так, то чем оно от inplace-upgrade отличаться будет, который у нас зафейлился :(

Vasyalike Nov 21 2019 at 22:31

Раньше была возможность обновления через слейв. Сделали так 5.5 -> слейв 5.6 -> мастер 5.6 -> слейв 5.7 -> мастер/слейв 5.7. Прошло достаточно гладко, разве что всякие sql_mode:) Не знаете как сейчас с этим?

darvecher Nov 21 2019 at 22:32

Так и обновлялись, сначала слейвы на 8.0, потом переключение и мастер.

johndow Nov 22 2019 at 10:04

В логах должна быть причина фейла in-place upgrade.
В моих текстах это было например из-за
1. In-place upgrade to MySQL 8.0 is not supported if tables contain old temporal columns in pre-5.6.4 format (TIME, DATETIME, and TIMESTAMP columns without support for fractional seconds precision).
2. There must be no partitioned tables that use a storage engine that does not have native partitioning support.

причин там уйма
dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html

после устранения in-place влёт прошёл.