有相当多的背景信息。我将在接近尾声时提出这个问题。
我有一个MySQL复制设置，有一个主服务器和两个从服务器。我们遇到了一个奴隶的电源问题，导致数据库损坏。
由于主服务器和其中一个从服务器在Solaris 10上运行，并且zfs文件系统上有MySQL数据库，因此我们有一个执行特定任务的快照备份脚本：
如果没有长时间运行的查询，整个过程大约需要一秒钟。
我可以在主服务器上使用以这种方式创建的快照以及记录的主文件/位置数据，作为从站上完整数据库恢复的基础。
需要恢复的从属服务器是未在Solaris上运行的从属服务器，它位于具有ext4文件系统的Linux上。我正在从主服务器复制快照，但看起来可能需要一周或更长时间，因为主服务器非常繁忙且rsync没有获得任何磁盘I / O带宽。
我从其他从服务器上做了部分测试副本，并且传输速率更好......所以现在我想尝试从该从服务器恢复。
为此做准备，我在快照脚本中添加了一个步骤（在SHOW MASTER STATUS之后），它执行了＃34; SHOW SLAVE STATUS＆＃34;并将Relay_Master_Log_File记录为文件，将Exec_Master_Log_Pos记录为位置。我现在在从属服务器上有几个包含此信息的快照。
灼热的问题：＆＃34; FLUSH TABLES WITH READ LOCK＆＃34;命令足以确保在＆＃34; SHOW SLAVE STATUS＆＃34;中找到日志重播信息。 100％与文件系统快照协调，或者脚本在记录从属状态并制作快照之前是否真的需要做STOP SLAVE？
这是在Solaris主从服务器上运行的mysql版本：
/ u01 / mysql / bin / mysql Ver 14.14使用readline 5.1为sun-solaris2.10（sparc）分发5.1.67
答案 0 :(得分：0)
具有READ LOCK的FLUSH表通常可以与SHOW SLAVE STATUS一起使用（与您的SHOW MASTER STATUS非常相同），以确定相关的二进制日志位置。
您还可以通过依赖rsync上已存在于磁盘上的信息来跳过这种情况，但是您必须注意中继日志索引，并且文件名称错误，因为它基于从属主机名默认情况下。您可以通过重命名文件和重命名索引中的引用，或者使用相同的relay-log-name命名。
本文件谈到了这一点，但它基本上只是在做同样的事情： 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