1. Canal高可用集群架构设计

第一次在生产环境部署Canal高可用集群时，我踩了不少坑。记得当时凌晨三点还在排查ZooKeeper选举问题，现在回想起来都是宝贵的经验。Canal作为阿里巴巴开源的MySQL binlog增量订阅组件，其高可用架构设计有几个关键点需要特别注意。

核心组件拓扑通常采用三层结构：

• MySQL主从集群（建议至少一主两从）
• Canal Server集群（3节点组成HA）
• ZooKeeper协调服务（3节点或5节点）

这种架构下，ZooKeeper负责维护Canal Server的存活状态和主从选举。当主节点宕机时，从节点会在秒级完成切换。实测下来，我们的生产环境切换耗时平均在1.8秒左右，对业务几乎无感知。

配置参数中有几个容易忽略但至关重要的点：

• canal.zkServers必须配置所有ZooKeeper节点地址
• canal.instance.global.spring.xml必须设置为集群模式
• 每个Canal Server的canal.register.ip需要明确指定

# 典型的高可用配置示例 canal.admin.register.cluster = zk canal.zkServers=192.168.1.101:2181,192.168.1.102:2181,192.168.1.103:2181 canal.instance.global.spring.xml = classpath:spring/default-instance.xml

2. MySQL 8.0专项配置

MySQL 8.0的binlog解析有些特殊注意事项。有次我们升级数据库版本后，突然发现同步延迟飙升，最后发现是默认的binlog_row_image设置问题。

必须检查的MySQL参数：

-- 验证binlog配置 SHOW VARIABLES LIKE 'log_bin'; -- 必须为ON SHOW VARIABLES LIKE 'binlog_format'; -- 必须为ROW SHOW VARIABLES LIKE 'binlog_row_image'; -- 推荐FULL -- 创建专用账号 CREATE USER 'canal'@'%' IDENTIFIED BY 'canal_password'; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';

MySQL 8.0默认使用caching_sha2_password认证插件，这会导致Canal连接失败。解决方法有两种：

1. 修改用户认证方式：

   ALTER USER 'canal'@'%' IDENTIFIED WITH mysql_native_password BY 'canal_password';

2. 或者在Canal的instance配置中添加：

   canal.instance.filter.druid.ddl=true canal.instance.dbUsername=canal canal.instance.dbPassword=canal_password canal.instance.jdbc.driverClassName=com.mysql.cj.jdbc.Driver

3. Elasticsearch 7适配技巧

Elasticsearch 7.x的适配比想象中复杂。曾经因为类型映射问题，导致同步后字段全部变成字符串类型，不得不全量重建索引。

关键配置要点：

# adapter配置示例 outerAdapters: - name: es7 key: es_key hosts: http://es-node1:9200,http://es-node2:9200 mode: rest properties: cluster.name: my_es_cluster security.auth: elastic:password

常见问题处理方案：

1. 日期格式问题：在SQL中预先格式化

   SELECT id, DATE_FORMAT(create_time,'%Y-%m-%d %H:%i:%s') AS create_time FROM orders

2. 索引自动创建：建议预先创建好索引模板

   PUT _template/canal_template { "index_patterns": ["canal_*"], "settings": { "number_of_shards": 3, "number_of_replicas": 1 } }

4. 性能调优实战

经过多次压测，我们总结出这些黄金参数组合：

Canal Server端：

# 内存缓冲区大小（建议16MB-64MB） canal.instance.memory.buffer.size = 16777216 # 批处理大小（500-2000） canal.instance.transaction.size = 1000 # 并行解析线程数（CPU核数的60%） canal.instance.parser.parallelThreadSize = 8

Adapter端：

canal.conf: mode: tcp batchSize: 800 # 单位KB syncBatchSize: 500 # 每次同步记录数 retries: 3 timeout: 120000 # ES操作超时时间

监控指标要特别关注：

• Canal Server的get与ack差值（延迟指标）
• ES的bulk队列长度（建议设置警报阈值）
• MySQL的Seconds_Behind_Master（主从延迟）

5. 故障排查手册

根据我们处理过的上百个工单，这些是最常见的故障场景：

案例1：数据不同步

1. 检查Canal Server日志是否有dump异常
2. 验证MySQL账号权限是否完整
3. 查看ZooKeeper上注册的节点状态

案例2：ES写入失败

# 查看adapter错误日志 tail -f logs/adapter/adapter.log | grep ERROR # 手动测试ES连接 curl -XGET 'http://es-node:9200/_cluster/health?pretty'

案例3：内存溢出在startup.sh中调整JVM参数：

JAVA_OPTS="-server -Xms4g -Xmx4g -XX:NewSize=1g -XX:MaxNewSize=1g"

6. 全量与增量同步策略

生产环境推荐采用混合同步方案：

1. 首次全量同步：

   # 手动触发全量同步 curl -X POST "http://adapter-host:8081/etl/es7/es_key/user_index/user_mapping.yml"

2. 持续增量同步：
   • 通过binlog实时捕获变更
   • 建议设置canal.instance.filter.regex过滤不需要的表

数据一致性保障：

• 定期校验MySQL与ES的count差异
• 重要业务表添加checksum校验
• 建立重试机制处理失败记录

7. 安全防护方案

生产环境必须考虑的安全措施：

1. 网络隔离：
   • Canal Server与MySQL放在同一安全组
   • 限制ES集群的访问IP
2. 认证加密：

   # MySQL SSL连接 canal.instance.jdbc.url=jdbc:mysql://mysql-host:3306/db?useSSL=true # ES安全配置 security.auth: elastic:password

3. 审计日志：
   • 开启Canal的详细日志
   • 记录所有ETL操作

8. 生产环境验证清单

上线前必须验证的10个要点：

1. ZooKeeper集群健康状态
2. MySQL binlog位置是否正确解析
3. ES索引mapping是否符合预期
4. 监控告警是否配置完备
5. 压力测试结果是否达标
6. 故障切换演练是否通过
7. 数据一致性校验工具是否就绪
8. 备份恢复方案是否验证
9. 性能基线数据是否采集
10. 运维文档是否完整

记得有次上线前漏掉了第7项，结果数据差异直到一周后才被发现，导致不得不停服修复。这个教训让我养成了严格检查清单的习惯。