Comments 12
А зачем базу mysql надо было дампить, проще было выдернуть привилегии пользователей.
Не понял, как бы это помогло? Есть БД на MySQL 5.7, in-place upgrade падает с ошибкой, как апгрейднуться без дампа? Если есть какой-то способ — расскажите, нам уже не надо, но кому-то ещё поможет :)
Ну как минимум избавило бы от «Column count of mysql.user is wrong» и «Access to system table 'mysql.innodb_index_stats' is rejected.». Из базы mysql нужны только пользователи и их права на базы, а их можно выдернуть так:
на выходе получим привлегии всех юзеров (кроме рута) в виде sql запросов:
которые надо будет засунуть в новый mysql.
Да, если используются более сложные привилегии на таблицы, или еще что-то типа proxies_priv, этого не будет достаточно. Но я за 10 лет работы с клиентскими 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 ни разу не видел, чтобы такой функционал использовался.
как раз на днях пытался перекатиться с 5.7 на 8.0.
вы ещё (кажется) не упомянули про то, что там новый способ авторизации с SHA2.
короче, мигрировал я в итоге на MariaDB 10.4
Еще они синтаксис немного покрутили в сторону ужесточения, особенно в датах, так что всякие там битриксы на 8 мускуле падают в рандомных местах.
А еще можно через xtrabackup поднимать реплику сразу на 8-м и потом переключаться на нее, это на порядок быстрее чем mysqldump, особенно если у вас данных прилично (больше 1 ТБ). Мы только в процессе обновления, на текущий момент апнуто 3 из 20 бд, но пока проблем не обнаружено.
Раньше была возможность обновления через слейв. Сделали так 5.5 -> слейв 5.6 -> мастер 5.6 -> слейв 5.7 -> мастер/слейв 5.7. Прошло достаточно гладко, разве что всякие sql_mode:) Не знаете как сейчас с этим?
В логах должна быть причина фейла 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 влёт прошёл.
В моих текстах это было например из-за
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 влёт прошёл.
Sign up to leave a comment.
Практический опыт обновления MySQL 5.7 до версии 8.0