开发者社区> 问答> 正文

数据库实例的dump线程在关闭同步任务之后依然存在

tu11.png

otter版本:v4.2.14 重现步骤:

保持mysql中无数据写入,binlog无更新 停用channel 启动channel 步骤2和3每重复一次,mysql dump线程数加1 问题定位: 是监控项目中的Position超时逻辑引起的。

默认为自动恢复,监控周期为600秒。代码逻辑如下:

com.alibaba.otter.manager.biz.monitor.impl.RestartAlarmRecovery.java function processRecovery() channelService.stopChannel(channelId); channelService.startChannel(channelId);

也就是在数据库无写入的情况下,每隔600秒左右,Position超时逻辑便会重启一下channel,从而导致大量dump线程堆积。

原提问者GitHub用户 HorandGao

展开
收起
古拉古拉 2023-06-21 12:23:08 56 0
2 条回答
写回答
取消 提交回答
  • 随心分享,欢迎友善交流讨论:)

    根据您提供的信息,问题可能出现在 Position 超时逻辑上。Position 超时指的是 canal 中的 Position 对象长时间没有更新,可能是由于 canal 服务停止或网络故障等原因导致。为了防止数据丢失和同步延迟,canal 设置了 Position 超时时间,默认为 1 小时。如果在超时时间内没有更新 Position,canal 将会报错并停止同步。

    在您的问题中,当数据库中没有写入数据时,监控逻辑会检查 Position 是否超时,如果超时则会重启 canal 的 channel 服务。如果频繁进行重启操作,可能会导致 canal 的 dump 线程堆积,影响同步效率和性能。

    为了解决这个问题,您可以考虑以下几个方面:

    调整 Position 超时时间。如果您的数据同步较为频繁,可以将 Position 超时时间适当缩短,以避免过长时间没有更新 Position 导致的问题。

    检查 canal 的配置和运行状态。确保 canal 的配置正确,并且服务正常运行,避免出现停止同步或者网络故障等问题。

    确认监控逻辑的正确性。检查监控逻辑是否正确,以及频率是否合理。可以通过日志和监控工具等方式进行确认。

    对 dump 线程进行优化。如果 dump 线程出现堆积,可以考虑对线程池进行优化,增加线程池容量或者调整线程池参数等方式。

    希望以上建议能够帮助您解决问题。

    2023-06-30 17:52:42
    赞同 展开评论 打赏
  • 尝试一下4.2.15版本吧

    原回答者GitHub用户 agapple

    2023-06-21 13:00:52
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
DTCC 2022大会集锦《云原生一站式数据库技术与实践》 立即下载
阿里云瑶池数据库精要2022版 立即下载
多IO线程优化版 立即下载