Master挂掉后的恢复

不保证Exactly Once，会有重复数据

原回答者GitHub用户agapple

在 Canal 的架构中，当 MySQL 主库挂掉后，新的从库被提升为新的主库时，Canal 客户端会重连到新的主库，并尝试定位到与原主库对应的位置继续进行 binlog 解析。

如果 Canal 客户端在重连到新的主库后无法定位到原主库的位置，则可能会存在漏解析或重复解析 binlog 的情况。这取决于 Canal 客户端能否正确管理自己的 binlog 解析位置。

为了保证 Canal 中的 Change Event 是 Exactly Once 的，可以采取以下措施：

在 Canal 客户端重连到新的主库后，确保其能够正确地定位到与原主库对应的 binlog 位置。

Canal 客户端可以通过设置 GTID（Global Transaction ID）模式来避免重复解析 binlog。GTID 可以唯一标识每个事务，并且不会因为主从切换而改变。因此，在启用 GTID 模式后，Canal 可以确保不会重复解析 binlog。

对于无法使用 GTID 的情况，Canal 客户端可以在 MySQL 主库上创建一个专门用于 Canal 的账户，并为该账户指定 REPLICATION SLAVE 权限。Canal 客户端使用该账户连接到主库进行 binlog 解析，从而避免因其他应用的操作而导致 binlog 位置发生变化。

总之，为了保证 Canal 中的 Change Event 是 Exactly Once 的，需要在 Canal 客户端正确管理 binlog 解析位置的基础上，使用一些技术手段来避免重复解析或漏解析 binlog。