从从属服务器恢复MySQL数据库

有相当多的背景信息。我将在接近尾声时开始讨论这个问题

我有一个MySQL复制设置，有一个主服务器和两个从服务器。其中一个从机出现电源问题，导致数据库损坏

由于主服务器和其中一个从属服务器在Solaris 10上运行，MySQL数据库位于zfs文件系统上，因此我们有一个快照备份脚本，它执行一项非常具体的任务：

• 用读锁刷新表
• 显示主机状态
  • 将文件/位置记录到数据目录中的文件中
• 使用zfs拍摄数据目录的快照
• 解锁表格

如果没有长时间运行的查询，整个过程大约需要一秒钟

我可以使用在主服务器上以这种方式创建的快照以及记录的主文件/位置数据，作为从服务器上完成数据库恢复的基础

需要恢复的从服务器是不在Solaris上运行的从服务器，它在具有ext4文件系统的Linux上。我正在从主服务器复制快照，但看起来可能需要一周或更长时间，因为主服务器非常繁忙，并且rsync没有获得任何磁盘I/O带宽

我从另一个从属服务器做了一个部分测试拷贝，传输速率好得多。。。所以现在我想试着从那个奴隶身上恢复过来

为此做准备，我在快照脚本中添加了一个步骤（在SHOW MASTER STATUS之后），其中它确实“显示从属状态”，并将Relay\u MASTER\u Log\u文件记录为File，将Exec\u MASTER\u Log\u Pos记录为position。我现在在从属服务器上有几个包含此信息的快照

迫切的问题：在“显示从机状态”中找到的日志重放信息是否足以确保与文件系统快照100%协调，或者脚本在记录从机状态并创建快照之前是否确实需要停止从机

这是在Solaris主服务器和从服务器上运行的mysql版本：

---

/u01/mysql/bin/mysql Ver 14.14发行版5.1.67，适用于sun-solaris2.10（sparc），使用readline 5.1

带读锁的刷新表通常可以与显示从属状态（与显示主状态非常相似）一起使用，以确定相关的二进制日志位置

您也可以通过rsync时依赖磁盘上已经存在的信息来略过这一点，但是您必须注意中继日志索引和文件的错误名称，因为默认情况下它基于从属主机名。您可以通过重命名文件和索引中的引用，或者使用相同的中继日志名来查找

本文件对此进行了讨论，但基本上也是这么做的：

然而。。如果您经常使用临时表，您应该通过检查Slave\u open\u temp\u表来确保当前快照位置没有打开的临时表

---

请参阅：

从机状态确实包括当前正在从机上重播的主日志文件的名称（可能来自中继日志）。现在，我添加了一个查询，以找出每个快照的Slave\u open\u temp\u表的值，然后我就可以知道该快照是否可以有效地用于恢复。快照每小时制作一次，所以应该有很多快照。我的希望是，冲水和锁将确保所有临时表关闭。。。我想我们会发现的。其他细节：当我将数据目录重新同步到我正在恢复的从机时，我不会复制任何二进制日志。它们不是必需的，而且非常庞大。下面是一个现在记录在slaveposition.log文件中的每个快照上的信息示例：快照2015052318：文件mysql-bin.009872，位置13252441附加：mlf mysql-bin.009872，rlf mysql-relay-bin.020175 Slave_open_temp_tables:0