canal客户端连接不上mysql需检查四点：一是mysql开启log-bin且binlog_format=row；二是创建专用用户并授予select、replication slave、replication client权限；三是确保canal服务端destination名称与c#客户端订阅名一致；四是c#客户端连接canal服务端默认端口11111，非mysql的3306端口。
Canal客户端连接不上MySQL怎么办
Canal本身不直接运行在C#中，它是个Java服务，C#只能作为客户端去消费其推送的binlog数据。连不上最常见的原因是MySQL没开binlog、用户权限不足或网络不通。
确认以下几点：
-
my.cnf中已启用log-bin，且binlog_format = ROW（Canal只支持ROW模式） - MySQL创建专用用户并授权：
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%' IDENTIFIED BY 'canal'; FLUSH PRIVILEGES; - Canal服务端配置的
destination名称要和C#客户端订阅时传入的一致（如example），否则会报no available destination - C#客户端用的是TCP直连，端口默认是
11111，不是MySQL的3306——别填错端口
用DotNetCore.Canal.Client消费binlog数据
目前最稳定的C# Canal客户端是开源库 DotNetCore.Canal.Client（注意不是 CanalSharp，后者已长期未维护且不兼容Canal 1.1.7+）。
安装包：dotnet add package DotNetCore.Canal.Client
基础用法示例：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
<pre class="brush:php;toolbar:false;">var client = new CanalClient("127.0.0.1", 11111, "example");
await client.ConnectAsync();
await client.SubscribeAsync(); // 订阅全库全表
<p>while (true)
{
var message = await client.GetMessagesAsync(100); // 拉取最多100条
foreach (var entry in message.Entries)
{
if (entry.EntryType == EntryType.RowData && entry.StoreValue.Length > 0)
{
var rowData = ProtocolSerializer.Deserialize<rowdata>(entry.StoreValue);
Console.WriteLine($"{entry.Header.TableName}: {rowData.EventType}");
}
}
}</rowdata></p>注意：GetMessagesAsync
StoreValue 是Protobuf序列化后的二进制，必须用库自带的 ProtocolSerializer 反序列化，自己用 JsonConvert 会失败。如何过滤指定库表或事件类型
Canal服务端支持通过 filter 配置白名单，但C#客户端无法动态改filter——所有过滤必须在服务端配好，或在客户端代码里手动判断。
推荐做法：服务端设宽泛过滤（如 test\..*），客户端再做二次筛选：
- 检查
entry.Header.TableName和entry.Header.DatabaseName - 跳过
EventType == EventType.QUERY（DDL语句，无行数据） - 对
INSERT/UPDATE/DELETE分别处理：rowData.EventType对应枚举值 - 更新事件中，
rowData.BeforeColumns和rowData.AfterColumns都非空，注意判空再取值，否则NRE
Canal同步延迟高或丢数据怎么排查
延迟和丢数据通常不是C#侧的问题，而是链路中某环出了瓶颈：
- MySQL主库写入压力大 → binlog刷盘慢 → Canal拉取滞后 → 查
SHOW MASTER STATUS对比Exec_Master_Log_Pos和当前position - Canal服务端JVM内存不足 → Full GC频繁 → 日志里出现
GC overhead limit exceeded - C#客户端消费太慢（比如每条都写磁盘/发HTTP请求）→ 消息堆积 → Canal服务端内存溢出自动断连 → 建议加本地队列缓冲 + 批量提交
- 没正确ACK：调用
client.AckAsync(batchId)是必须的，否则Canal认为消息未消费成功，下次还会重推（造成重复）
真正难处理的是DDL变更（如加字段）导致反序列化失败——RowData 结构变动后，旧客户端会抛 InvalidProtocolBufferException，必须重启客户端或热加载schema映射逻辑。
