duckula3/checkpoint

发布 : 2020-12-21 浏览 :

检查点服务管理

  对于binlog监听来说会有一些元数据要存储,如:监听的表的字段信息(binlog不含有字段名),要做到高可用(HA)能正常启动需要存储字段名的历史(会增删字段), 当前监听的位点信息(filename+pos+gtid)等,目的就是为了HA能正常启动。我们称当前的监听位点为checkpoint(借用flink的概念)。

  在duckula2中checkpoint是不可定制的,只有zookeeper一种方案。对于duckula3来说支持3种模式,它们各用应该场景:

  • net.wicp.tams.common.binlog.alone.checkpoint.CheckPointMemory(内存模式):

    它会把所有的元数据存储在内存中,当监听重启或断电后,元数据全部消失,不能做HA,但它有速度快,依赖少(不依赖其它东西来存储)等特点。如果要做HA,那么只能以嵌入式的方式使用duckula3,这时候它就可以使用宿主程序来做HA,比如:flink,它有自己完备的checkpoint机制,那么duckula3提供的flink source则会在flink做checkpoint保存的时候让其代为保存duckula的相关元数据,当启动时,duckula3提供的flink source又会从flink保存的checkpoint中拿到先前保存的元数据,灌到内存中,完成了HA。

  • net.wicp.tams.common.binlog.alone.checkpoint.CheckPointH2db(H2db模式)

    它会在本机启一个h2db数据库,然后把元数据保存到这个h2db数据库中,当重启时,使用相同的h2db数据库文件再次启动这个数据库,这样HA就可以实现了,但它有一个问题,就是跨主机启动的时候,在另一台主机上并不能拿到上次运行的主机上的数据库文件,这样HA会失败,所以只它适合于单机版,duckula3默认就是使用这种模式,对于linux用户建议使用一个守护进程,当监听进程死了的时候在本机重新拉取一个新的进程来做HA。

  • net.wicp.tams.common.binlog.alone.checkpoint.CheckPointMysql(mysql模式)

    这是最完备的HA解决方案,它需要配置一个用于存储元数据的数据库(一般来说一个数据库实例配置一个),且监听帐号对这个数据库具有建表权限。duckula会把所有的元数据存储到这个指定的数据库中,并以groupid为分布式锁,对于同一个groupid只能启动一个监听程序,这样即使监听代码嵌入到应用程序中时,布署了3个应该程序做HA时,也只会启动一个监听程序。

  • net.wicp.tams.common.binlog.alone.checkpoint.CheckPointZookeeper(zookeeper模式)

    暂未测试,就是与duckula2类型,使用zookeeper存储元数据和完成分布式锁功能。

主界面:

  入口:系统配置->检查点服务管理

image-20201221155049712

支持通过主程序版本进行搜索,上面的小框是它的“新增/修改”界面。

字段说明

检查点名:用于标识这个检查点服务的,需要能一看就懂的检查点服务

检查点类型:就是上面介绍的几种

主机/端口/默认数据库/用户名/密码:如果是mysql数据库的话就需要配置,其它类型不需要配置

按钮说明:

  • 查询/新增/修改/删除 按钮为默认意义,不细说。
本文作者 : andy.zhou
原文链接 : https://rjzjh.gitee.io/2020/12/21/duckula3/duckula3-checkpoint/
版权声明 : 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处!

知识 & 情怀 | 二者兼得

微信扫一扫, 向我投食

微信扫一扫, 向我投食

支付宝扫一扫, 向我投食

支付宝扫一扫, 向我投食

留下足迹