【问题标题】:What is the risk of `mysql_upgrade` without doing `mysqldump`?不做`mysqldump`的`mysql_upgrade`有什么风险?
【发布时间】:2018-09-11 09:33:09
【问题描述】:

几个月前从5.5升级mysql到5.7后,我忘了mysql_upgrade

并且面临一些问题.. mysqlsysperformance_schema 数据库丢失并且 root 权限被破坏。当我尝试做一些 mysql 用户权限的事情时,会弹出很多 Access denied for user 'root'... 消息。

This stack answer 必须解决我的问题。但我需要知道它不会影响任何架构、数据……等等。

因为我的数据库非常庞大。它总计 10 GB,由大约 50 个表组成。恐怕会发生一些不好的事情。我知道答案将是mysqldump。 但是完整备份会花费很长时间,可能需要一个小时。而且企业不会接受这种停机时间。

那么mysql_upgrade不做mysqldump有什么风险呢?

【问题讨论】:

    标签: mysql


    【解决方案1】:

    在没有备份的情况下对数据库进行任何管理的风险高得令人无法接受...不是因为 MySQL 本身的任何限制,而是因为我们正在谈论关于对您的业务至关重要的事情。您支持它的频率应不少于您愿意丢失的数据的时间间隔。

    如果您使用的是 InnoDB,则使用 mysqldump--single-transaction 选项并且应该没有锁定,因为 MVCC 处理一致性。如果你不使用 InnoDB,这本身就是一个问题,但使用 --skip-lock-tables 应该尽量减少锁定。

    请注意,如果您发现正在处理的mysqldump 导致问题,那么应该非常安全 - 使用SHOW PROCESSLIST; 找到转储的线程ID,然后使用@987654326 @ 其中# 是进程列表中转储连接的 ID。

    您引用的答案的潜在问题是 5.1 > 5.5 是受支持的升级路径,因为这两个版本是连续的。 5.5 > 5.7 不是。您应该先升级到 5.6,然后再升级到 5.7,在每个步骤之前和之后运行mysql_upgrade适当版本(适当的意思是实用程序的版本与当前运行的服务器版本相匹配) .

    您可能处于比您想象的更微妙的境地......或者您可能不会。

    鉴于类似的情况,除了完全停止服务器,通过将所有文件复制到新机器来克隆它,并针对克隆测试修复步骤之外,我不想做任何事情。

    如果这个系统是关键业务系统,它应该有一个实时运行的副本服务器,它可以升级为主服务器,并在发生故障时永久替换这台机器。在这种情况下,您可以将修复应用到副本并进行推广。

    Access denied for user 'root'... 可能与架构不兼容相关,也可能不相关。

    【讨论】:

    • 我决定在做mysql_upgrade之前做一个完整的备份。希望一切都会好起来的。
    猜你喜欢
    • 1970-01-01
    • 2010-11-24
    • 2014-01-30
    • 1970-01-01
    • 2011-07-20
    • 1970-01-01
    • 2011-06-11
    • 2019-04-20
    • 2013-05-10
    相关资源
    最近更新 更多