有大量的背景信息。我将在接近尾声时回答这个问题。
我有一个 MySQL 复制设置，其中有一个主服务器和两个从服务器。我们的一个从站出现电源问题，导致数据库损坏。
由于主服务器和其中一个从服务器在 Solaris 10 上运行，MySQL 数据库位于 zfs 文件系统上，因此我们有一个快照备份脚本来执行非常具体的任务:
- 使用读锁刷新表
- 显示大师状态
- 将文件/位置记录到数据目录中的文件中。
- 使用 zfs 拍摄数据目录的快照。
- 解锁表格
如果没有长时间运行的查询，整个过程大约需要一秒钟。
我可以使用在主服务器上以这种方式创建的快照以及记录的主文件/位置数据，作为从属服务器上完整数据库恢复的基础。
需要恢复的从属服务器不是在 Solaris 上运行的从属服务器，而是在带有 ext4 文件系统的 Linux 上运行的从属服务器。我正在从主服务器复制快照，但看起来可能需要一周或更长时间，因为主服务器非常繁忙，并且 rsync 没有获得任何磁盘 I/O 带宽。
我从其他从服务器进行了部分测试副本，传输速率要好得多......所以现在我想尝试从该从服务器恢复。
为此做准备，我在快照脚本中添加了一个步骤(在 SHOW MASTER STATUS 之后)，其中执行“SHOW SLAVE STATUS”并将 Relay_Master_Log_File 记录为文件，将 Exec_Master_Log_Pos 记录为位置。我现在在从属服务器上有几个包含此信息的快照。
最紧迫的问题:“FLUSH TABLES WITH READ LOCK”命令是否足以确保“SHOW SLAVE STATUS”中找到的日志重播信息与文件系统快照 100% 协调，或者在记录从站状态并制作快照之前，脚本实际上需要执行 STOP SLAVE 操作吗？
这是在 Solaris 主服务器和从服务器上运行的 mysql 版本:
/u01/mysql/bin/mysql Ver 14.14 Distrib 5.1.67，适用于使用 readline 5.1 的 sun-solaris2.10 (sparc)
最佳答案
FLUSH TABLES AND READ LOCK 通常可以与 SHOW SLAVE STATUS 一起使用(与 SHOW MASTER STATUS 非常相似)来确定相关的二进制日志位置。
您也可以通过在 rsync 时依靠磁盘上已有的信息来跳过这一点，但是您必须注意中继日志索引，并且文件将具有错误的名称，因为它基于从机主机名默认情况下。您可以通过重命名文件和重命名索引中的引用来发现这一点，或者只是使用相同的中继日志名称。
本文档讨论了这一点，但基本上只是做同样的事情: https://dev.mysql.com/doc/refman/5.6/en/replication-howto-additionalslaves.html
但是..如果您经常使用临时表，您应该通过检查 Slave_open_temp_tables 来确保您快照的位置当前没有打开临时表
参见:https://dev.mysql.com/doc/refman/5.6/en/replication-features-temptables.html
关于mysql - 从从服务器恢复 MySQL 数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30409503/