出现磁盘空间中断时如何处理 My SQL DB Master 到 Master 的复制

Question

我们有两个节点节点 A 和 B 的主对主复制，两者都在虚拟环境中。最初，节点 A 出现中断（磁盘空间问题）并停止复制。应用程序级流量已转移到节点 B 并重新定位节点 A 数据存储并提供可用空间。

节点 A 已成功启动并启动。在与节点 A 同步时，复制已开始并在节点 B 中出错，并且节点 B 中的 bin 日志已损坏。根本原因仍然是个谜。但是分析日志可以发现一些重复的条目，下面是错误日志信息：

[ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236).
[ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236
111014 20:25:48 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.001067', position 183468345.

在这种情况下我们如何处理复制？我们可以跳过当前的 bin-log 并使用下一个可用的 bin-log 及其位置开始复制。将节点 B 与节点 A 同步是否是个好主意：

CHANGE MASTER TO
  MASTER_HOST='XX.XX.XXX.XXX',
  MASTER_USER='replicate',
  MASTER_PASSWORD='slave',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mysql-bin.001025',
  MASTER_LOG_POS=4,
  MASTER_CONNECT_RETRY=10;

我提出这种情况的主要原因是，我不想恢复数据库并从头开始构建它，其中节点 B 中的数据库备份大约为 80 GB。如何修复复制？

Answer 1

这里有两点需要说明：

1）不可能这个词是一个死的赠品。Client requested master to start replication from impossible position. 这基本上是什么意思：

碰巧二进制日志的文件大小和二进制日志的位置是一回事。从机想从mysql-bin.001067位置183468345读取。由于消息中出现'不可能'这个词，这表明主二进制日志mysql-bin.001067小于183468345字节。要再次进行复制，请跳到下一个二进制日志：

CHANGE MASTER TO 
  MASTER_HOST='XX.XX.XXX.XXX', 
  MASTER_USER='replicate', 
  MASTER_PASSWORD='slave', 
  MASTER_PORT=3306, 
  MASTER_LOG_FILE='mysql-bin.001068', 
  MASTER_LOG_POS=NewPos, 
  MASTER_CONNECT_RETRY=10;
START SLAVE;

NewPos 取决于 MySQL 的版本。

• MySQL 5.6：NewPos = 120
• MySQL 5.5：NewPos = 107
• MySQL 5.1：NewPos = 106
• MySQL 5.0：NewPos = 98
• MySQL 4.x：NewPos = 98

2）您可以考虑使用 Percona 的数据同步工具。

• mk-表校验和
• mk-table-sync

我已经使用这些工具大约 2 年了，它们可以帮助您找出主从表之间的差异，即使主表上的表是 InnoDB 而从表上的同一张表是 MyISAM（前提是这些表具有相同的表结构） ）。

运行这些工具时必须打开复制。

顺便说一句，Percona 有一套新的工具叫做Percona Toolkit。他们从自己的 MAATKIT 工具中分叉出来以制作更好的工具。这些工具可能被称为pt-table-checksum和pt-table-sync。