使用AWS (或Linux)上的快照自动化MySQL复制

Question

我目前正在开发一个BASH脚本，根据现有集群的最新快照构建一个新的Aurora集群，然后设置从旧集群到新集群的MySQL复制。在过去，我使用mysqldump和mydumper自动复制，这两种方法都提供了最新的binlog和位置。但是，快照并不那么简单(问题可能是使用标准Linux快照而不是Aurora，尽管在Linux下，您可以在实例启动之前访问二进制日志索引文件)。你不能用RDS来读那些)。

由于快照是现有实例的精确副本，因此您可能认为可以从新实例中获取当前的binlog和位置，并将它们用于change master (或其RDS等效的)语句中的起始位置。但是，情况并非如此(本例来自dev实例，因此流量不多，但是prod实例可以很容易地在快照创建和恢复之间翻滚几个二进制日志)：

老例子：

MySQL [(none)]> show master status;
+----------------------------+----------+--------------+------------------+-------------------------------------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                               |
+----------------------------+----------+--------------+------------------+-------------------------------------------------+
| mysql-bin-changelog.000510 | 98957391 |              |                  | 0e332788-51c9-3440-b8e5-a6edc29aba7e:1-10746050 |
+----------------------------+----------+--------------+------------------+-------------------------------------------------+
MySQL [(none)]> show binary logs;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000498 | 134301760 |
| mysql-bin-changelog.000499 | 134284404 |
| mysql-bin-changelog.000500 | 134647151 |
| mysql-bin-changelog.000501 | 134236349 |
| mysql-bin-changelog.000502 | 134236200 |
| mysql-bin-changelog.000503 | 134238768 |
| mysql-bin-changelog.000504 | 134321441 |
| mysql-bin-changelog.000505 | 134223686 |
| mysql-bin-changelog.000506 | 134275221 |
| mysql-bin-changelog.000507 | 134221341 |
| mysql-bin-changelog.000508 | 134219161 |
| mysql-bin-changelog.000509 | 134222780 |
| mysql-bin-changelog.000510 |  98926253 |
+----------------------------+-----------+
13 rows in set (0.00 sec)

新实例：

MySQL [(none)]> show master status;
+----------------------------+----------+--------------+------------------+-------------------------------------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                               |
+----------------------------+----------+--------------+------------------+-------------------------------------------------+
| mysql-bin-changelog.000513 |      194 |              |                  | 0e332788-51c9-3440-b8e5-a6edc29aba7e:1-10742576 |
+----------------------------+----------+--------------+------------------+-------------------------------------------------+
MySQL [(none)]> show binary logs;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000498 | 134301760 |
| mysql-bin-changelog.000499 | 134284404 |
| mysql-bin-changelog.000500 | 134647151 |
| mysql-bin-changelog.000501 | 134236349 |
| mysql-bin-changelog.000502 | 134236200 |
| mysql-bin-changelog.000503 | 134238768 |
| mysql-bin-changelog.000504 | 134321441 |
| mysql-bin-changelog.000505 | 134223686 |
| mysql-bin-changelog.000506 | 134275221 |
| mysql-bin-changelog.000507 | 134221341 |
| mysql-bin-changelog.000508 | 134219161 |
| mysql-bin-changelog.000509 | 134222780 |
| mysql-bin-changelog.000510 |  88104589 |
| mysql-bin-changelog.000511 |       194 |
| mysql-bin-changelog.000512 |       194 |
| mysql-bin-changelog.000513 |       194 |
+----------------------------+-----------+
16 rows in set (0.01 sec)

正如您所看到的，在旧的日志中有三个额外的二进制日志是不存在的，并且在旧实例上还有一些我们不想丢失的附加事务。所以我的下一个想法是比较这两个实例的二进制日志，然后取第一个主实例上的大小大于副本的日志；或者，如果它们都是相同的，那么使用两个实例上存在的最后一个；这将处理没有向主程序写入新数据的情况。但是，如您所见，新实例有额外的二进制日志(可能是在构建时重新启动时创建的)，这些日志没有真正的数据，但是在比较旧的和新的时会造成极大的破坏。另一个想法是从上一个二进制日志向第一个副本反向工作，但是我想不出一个可靠的方法来以编程的方式确定它是否应该被跳过。跳过194个字节的文件似乎非常粗略。

我不知道如何解决这场冲突。有什么想法吗？

Answer 1

好吧，我想我已经知道怎么做了：

1. 通过副本上的所有二进制日志(show binary logs)进行反向循环(即从最新的开始)
2. 对于每个日志，运行show binlog events ... limit 10并通过egrep -v 'Format_desc|Previous_gtids'进行管道(这可能根据MySQL的版本而有所不同)
3. 给出该语句的任何输出的第一个日志是主程序在快照获取之前编写的最后一个日志。
4. 将该日志的名称和大小作为日志文件和位置传递给change master。