杀死正在“复制到 tmp 表”的复制 MySQL 进程是否安全？答案

【问题标题】：Is it safe to kill a replicating MySQL-process which is 'copying to tmp table'?杀死正在“复制到 tmp 表”的复制 MySQL 进程是否安全？
【发布时间】：2010-01-27 13:46:57
【问题描述】：

我在主 MySQL（5.0，Linux）服务器上遇到问题：我尝试向表行添加注释，该注释转换为 ALTER TABLE 命令。现在该过程停留在“复制到 tmp 表”上，复制了 100'000'000+ 行。磁盘 IO 使用率高得令人不安。

由于 master 正在使用复制，我不确定是否可以终止此进程。从机还没有看到 ALTER TABLE 命令。

（为了明确一点：我说的是从 MySQL-PROCESSLIST 中杀死进程，而不是 MySQL-Daemon-process 本身。）

【问题讨论】：

标签： mysql process replication

【解决方案1】：

是的，你可以杀死它——在事务提交之前，ALTER 不会进入二进制日志，即直到 ALTER 完成。所以slave不会看到也不会执行，master会回滚到旧的表结构。

您可以使用 show binlog events 或 mysqlbinlog 实用程序轻松验证 ALTER 是否尚未出现在二进制日志中。

【讨论】：

【解决方案2】：

不，这不安全。仅当您拥有数据库的完整备份（最近）时，才能在出现问题时进行恢复。可能会有一些锁，然后您最终会锁定桌子，可能会损坏钥匙。

如果您为如此大的数据库添加新列，建议您这样做。这更容易

创建表模式的复制品
在该表为空时对其运行更改，
从原始数据中插入插入... () 从...中选择字段。

这要快得多。然后显然将表重命名为原始。

【讨论】：

我说的是内部进程，而不是 mysqld 进程本身。

【解决方案3】：

您可以终止该操作，但可能会发生两种情况：

从架构与主架构不一致（因此：）
从属服务器上的复制可能会停止。

当复制停止时，您可以尝试通过在从服务器上输入跳过“alter table”指令来手动修复从服务器：

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; SLAVE START;

【讨论】：