Percona MySQL集群全库全表CDC实施、方案选型及断点续传问题咨询

针对你提出的两个疑问，我结合实际生产经验给你拆解一下：

1. 这套MySQL Binlog→Debezium/Maxwell→Kafka→Elasticsearch（Kibana）方案是否合适？ #

完全合适！这是目前工业界处理数据库变更捕获（CDC）+ 可视化检索的主流架构，完美匹配你的需求：

• CDC层：Debezium和Maxwell都是基于MySQL binlog的成熟CDC工具，能精准捕获CREATE/DELETE/UPDATE等所有行级变更，且不会对业务数据库造成侵入式影响；
• 消息缓冲层：Kafka作为中间件，实现了解耦和削峰——既可以缓冲突发的大量变更，也能保证消息的持久化不丢失，同时支持多消费者（比如后续要同步到其他系统也很方便）；
• 可视化层：Elasticsearch的全文检索能力刚好满足你对变更事件的快速检索需求，Kibana则能直观地做仪表盘、事件趋势分析。
  尤其针对Percona MySQL集群，因为集群的binlog是全局一致的，只要选择其中一个节点作为CDC数据源即可，架构兼容性很强。

2. 上百库表的全量捕获+断点续传怎么实现？ #

针对你提到的两个工具的痛点，其实都有成熟的解决办法：

针对Debezium：实现全库全表变更捕获 #

Debezium并非只能指定库表，它支持全实例级别的变更捕获，配置方式很简单：

• 在Debezium MySQL Connector的配置中，不要设置database.include.list（或者用正则.*匹配所有库），同时设置table.include.list=.*（匹配所有表）；
• 主题命名可以配置为${database.server.name}.${database.name}.${table.name}，这样每个表的变更会自动生成独立的Kafka主题，后续同步到ES时也能更灵活地拆分索引；
• 断点续传方面，Debezium默认会把消费的binlog偏移量（offset）存储在Kafka的内部主题__consumer_offsets里，如果你需要更可控的存储，也可以配置offset.storage为自定义Kafka主题，重启后会自动从上次的断点继续消费，完全不用担心断档。

针对Maxwell：解决断点续传问题 #

Maxwell的断点续传其实是默认支持的，你之前遇到的问题大概率是没配置元数据存储：

• Maxwell需要把消费位置（positions）存储在一个MySQL实例中（可以是你的Percona集群中的任意节点，也可以单独部署一个轻量的MySQL），启动时指定--host、--user、--password等连接信息，它会自动创建maxwell库和positions表来维护断点；
• 全库捕获是Maxwell的默认行为，不需要额外指定库表，它会把所有库表的变更输出到默认主题（可配置为maxwell.${database}.${table}实现按表分主题）；
• 重启Maxwell时，它会自动读取positions表中的最后记录，从对应的binlog位置继续消费，不会丢失之前的变更。

额外实践建议 #

• 确保Percona集群的binlog格式为ROW，且binlog_row_image=FULL——这是CDC工具能捕获完整变更数据的前提；
• 建议把CDC工具连接到集群的只读节点/从节点，避免占用主节点的资源；
• 针对上百库表的场景，ES索引可以按「库表+时间」拆分（比如cdc-events-${database}-${table}-yyyy.mm.dd），避免单个索引过大影响检索性能；
• 在Kibana中可以基于database、table、operation（操作类型）等字段创建索引模式，快速实现变更事件的筛选、统计和可视化。

内容的提问来源于stack exchange，提问作者cuteboyucsc