1)gitlab:/alibaba/canal
2)主要原理介绍:/alibaba/canal/wiki/canal%E4%BB%8B%E7%BB%8D
2)运维操作文档:/alibaba/canal/wiki/AdminGuide
下文的介绍,基于大家对上述文档的基本了解!
1)Canal版本为:1.0.24
2)通过Canal同步数据库数据变更事件,并由下游的消费者消费,将数据转存到ES或者跨机房的DB中。
一、设计目标
1、监控canal组件以及客户端消费者
2、通过平台,能够实时查看监控数据。canal问题的定位应该快速,且运行状态数据可见。
3、按需提供报警策略。
4、平台支持添加canal集群的监控。
5、canal组件的部署和使用遵守约定,canal的实施应该快速。
大家希望构建一个canal服务:根据用户需求,能够快速构建canal集群,包括环境隔离;此外canal组件、上游的MySQL、下游的consumer等数据链路的整体状态都在监控之中,且数据可见。大家希望任何利益相关者,都可以参与到数据决策中,并按需提供报警、预警机制。
二、基于Canal架构设计
1、整体架构
1)、每个Canal 集群应该至少有2个Canal实例,软硬件配置应该对等。大家不应该在同一个Cluster的多个节点上,配置有任何差异。
2)、一个Canal可以多个“instances”,每个instance对应一个“MySQL实例”的一个database(专业来说,一个instance对应一个MySQL实例,支持其上的多个databases);简单而言,大家认为一个instance相当于一个逻辑Slave。
3)、由2、可以得出,每个Canal Instance的全局处理的数据总量与一个正常的MySQL Slave相同,如果保持同等SLA,从Canal instance角度考虑,它的硬件能力应该与MySQL Slave保持相同。(同为单线程处理)。
4)、原则上,每个Canal可以支持“数十个instance”,但是instance的个数最终会影响instance同步数据的效能。大家建议,一个Canal尽量保持一个instance;除非Slave数据变更极小,大家才会考虑合并instances,以提高Canal组件的利用效率。
5)、每个instance,一个单独的处理线程,用于负责“binlog dump”、“解析”、“入队和存储”。
6)、Canal集群模式,必须依赖Zookeeper,但是对Zookeeper的数据交互并不频繁。
7)、Canal集群运行态,为“M-S”模式。但是“M-S”的粒度为“instance”级别。如果当前Canal的instance,与MySQL建立连接并进行binlog解析时,发生一定次数的“网络异常”等,将会判定为当前instance失效,并stop(备注:此时会删除注册在ZK的相关临时节点)。同时,集群中的每个Canal都会注册所有“destination”(每个destination将有一个instance服务)的状态变更事件,如果“临时节点”被删除(或者不存在),则会出发抢占,抢占成功,则成为此instance的Master。
(源码:CanalController.initGlobalConfig(),
ServerRunningMonitor.start(),
HeartBeatHAController.onFailed()
)
8)、根据7、,大家得知,如果Canal组件中有多个instances,有可能这些instances的Master会分布在不同的Canal节点上。
9)、在运维层面,大家基于“default-instance.xml”配置,基于“spring”模式;每个instance的配置,放置在各自的文件夹下。(${canal.root}/conf/${destination}/instance.properties)
10)、每个Canal节点,在启动时会初始化一个“嵌入式server”(NettyServer),此server主要目的是向Consumer提供服务。server的“ip:port”信息会注册在ZK中,此后Consumer通过ZK来感知。
(源码:
ServerRunningMonitor.initRunning(),
ClusterNodeAccessStrategy构造方法,
ZookeeperPathUtils.getDestinationServerRunning(destination)
)
11)、在Canal运行期间,可以动态的增加instances配置、修改instances配置。
2、Canal内部组件解析
1)Canal节点,可以有多个instances,每个instance在运行时为一个单独的Spring Context,对象实例为“CanalInstanceWithSpring”。
2)每个instances有一个单独的线程处理整个数据流过程。
3)instance内部有EventParser、EventSink、EventStore、metaManager主要四个组件构成,当然还有其他的守护组件比如monitor、HA心跳检测、ZK事件监听等。对象实例初始化和依赖关系,可以参见“default-instance.xml”,其配置模式为普通的Spring。
(源码参见:SpringCanalInstanceGenerator)
4)Parser主要用于解析指定”数据库”的binlog,内部基于JAVA实现的“binlog dump”、“show master status”等。Parser会与ZK交互,并获取当前instance所有消费者的cursor,并获其最小值,作为此instance解析binlog的起始position。目前的实现,一个instance同时只能有一个consumer处于active消费状态,ClientId为定值“1001”,“cursor”中包含consumer消费binlog的position,数字类型。有次可见,Canal instance本身并没有保存binlog的position,Parser中继操作是根据consumer的消费cursor位置来决定;对于信息缺失时,比如Canal集群初次online,且在“default-instance.xml”中也没有指定“masterPositiion”信息(每个instance.properties是可以指定起始position的),那么将根据“show master status”指令获取当前binlog的最后位置。
(源码:MysqlEventParser.findStartPosition())
5)Parser每次、批量获取一定条数的binlog,将binlog数据封装成event,并经由EventSink将消息转发给EventStore,Sink的作用就是“协调Parser和Store”,确保binglog的解析速率与Store队列容量相容。
(参见源码:AbstractEventParser.start(),
EntryEventSink.sink()
)
6)EventStore,用于暂存“尚未消费”的events的存储队列,默认基于内存的阻塞队列实现。Store中的数据由Sink组件提交入队,有NettyServer服务的消费者消费确认后出队,队列的容量和容量模式由“canal.properties”中的“memory”相关配置决定。当Store中容量溢满时,将会阻塞Sink操作(间接阻塞Parser),所以消费者的效能会直接影响instance的同步效率。
7)metaManager:主要用于保存Parser组件、CanalServer(即本文中提到的NettyServer)、Canal Instances的meta数据,其中Parser组件涉及到的binlog position、CanalServer与消费者交互时ACK的Cursor信息、instance的集群运行时信息等。根据官方解释,大家在production级别、高可靠业务要求场景下,metaManager建议基于Zookeeper实现。
其中有关Position信息由CanalLogPositionManager类负责,其实现类有多个,在Cluster模式下,建议基于FailbackLogPositionManager,其内部有“primary”、“failback”两级组合,优先基于primary来存取Position,只有当primary异常时会“降级”使用failback;其配置模式,建议与“default-instance.xml”保持一致。
(参看源码:CanalMetaManager,PeriodMixedMetaManager)
3、Consumer端
1)Consumer允许分布式部署,多个对等节点互备。但是任何时候,同一个destination的消费者只能有一个(client实例),这种排他、协调操作由zookeeper承担。在Cluster模式下,指定zkServer的地址,那么Consumer将会从meta信息中获取指定destination所对应的instance运行在哪个Canal节点上,且CanalServer(即NettyServer)的ip:port信息,那么此时Consumer将根据“ip:port”与NettyServer建立连接,并进行数据交互。
(参见源码:SimpleCanalConnector.connect(),
ClientRunningMonitor.start()
)
2)Consumer有序消费消息,严格意义上说,大家强烈建议Consumer为单线程逐条处理。尽管研发同学,有很多策略可以让消息的处理过程使用多线程,但是对于消息的ACK将需要特殊的关注,而且非有序情境下,或许会对你的数据一致性有一定的影响。
3)消费者的消费效率,取决于“业务本身”,大家建议业务处理尽可能“短平快”。如果你的业务处理相对耗时,也不建议大家再使用“比如MQ、kafka”等其他异步存储做桥接,因为这本质上对提高endpoint端效能没有太大帮助,反而增加了架构的复杂性。
4)大家严格限制:消费者在处理业务时,必须捕获所有异常,并将异常的event和处理过程的exception打印到业务日志,以备将来进行数据补偿;捕获异常,有助于Consumer可以继续处理后续的event,那么整个canal链路不会因为一条消息而导致全部阻塞或者rollback。
5)Consumer单线程运行,阻塞、流式处理消息,获取event的方式为pull + batch;每个batch的size由配置决定,一个batch获取结束后,将会逐个调用业务的process方法,并在整个batch处理结束后,按需进行ack或者rollback。
6)需要注意:rollback操作是根据batchId进行,即回滚操作将会导致一个batch的消息会被重发;后续有重复消费的可能,这意味着业务需要有兼容数据幂等的能力。
7)消费者的ClientId为定值:1001,不可修改。
三、部署与最佳实践(建议)
1、Canal集群部署
1)Production场景,节点个数至少为2,考虑到Canal自身健壮性,也不建议Canal单组集群的节点数量过多。
2)Canal节点为“网络IO高耗”、“CPU高耗”(并发要求较高,体现在instance处理、consumer交互频繁)型应用,对磁盘IO、内存消耗很低。
3)不建议Canal与其他应用混合部署,大家认定Canal为核心组件,其可用性应该被保障在99.99%+。
4)每个Canal集群的instances个数,并没有严格限制,但其所能承载的数据量(TPS,包括consumer + binlog parser)是评估instances个数的主要条件。考虑到Production级别数据变更的场景不可控,大家建议每个Canal集群的instance个数,应该在1~3个。
5)对于核心数据库、TPS操作较高的数据库,应该使用单独的Canal。
6)Canal集群的个数多,或者分散,或者利用率低,并不是大家特别关注的事情,不要因为过度考虑“资源利用率”、“Consumer的集中化”而让Canal负重。
7)Canal的配置,绝大部分可以使用“默认”,但是要求在Production场景,instance模式必须使用Spring,配置方式采用“default-instance.xml”。“default-instance.xml”默认配置已满足大家HA环境下的所有设计要求。(版本:1.0.24)
8)Canal机器的配置要求(最低):4Core、8G;建议:8Core、16G。
9)Canal的上游,即MySQL实例,可以是“Master”或者任意level的Slave,但是无论如何,其binlog_format必须为ROW,通过使用“show variables like ‘binlog_format””来确定。目前已经验证,使用mixed模式可能导致某些UPDATE操作事件无法被消费者解析的问题。
2、Zookeeper集群
1)Zookeeper集群,要求至少3个节点。网络联通性应该尽可能的良好。
2)多个Canal Cluster可以共享一个ZK集群,而且建议共享。那么只需要在canal.properties文件中“zkServers”配置项增加“rootPath”后缀即可,比如“10.0.1.21:2181,10.0.1.22:2181/canal/g1”。但是不同的Canal cluster,其rootPath应该不同。大家约定所有的Canal集群,rootpath的都以“/canal/”开头。(这对大家后续的ZK监控比较有利,大家只需要遍历”/canal”的子节点即可知道集群信息)
3)业界也有一种通用的部署方式,zookeeper集群与canal共生部署,三个节点,每个节点上都部署一个ZK和canal;这种部署模式的出发点也是比较简单,分析canal问题时只需要通过本地zk即可。(仅为建议)
4)需要非常注意,rootpath必须首先创建,否则canal启动时将会抛出异常!
3、Consumer集群
1)Consumer实例为普通application,JAVA项目,Spring环境。
2)Consumer集群至少2个节点,分布式部署。运行态为M-S。
3)每个Consumer实例为单线程,Consumer本身对CPU、内存消耗较低,但是对磁盘有一定的要求,因为大家将会打印大量的日志。建议磁盘为200G + ,logback的日志格式应该遵守偶司规范,后续承接ELK基础数据平台。
4)一个Application中,允许有多个Consumer实例。
5)Consumer的业务处理部分,必须捕获全部异常,否则异常逃逸将可能导致整个链路的阻塞;对于异常情况下,建议进行日志记录,稍后按需进行数据补偿。
6)Consumer的业务处理部分,大家要求尽可能的快,业务处理简单;最重要的是千万不要在业务处理部分使用比如“Thread.sleep”、“Lock”等阻塞线程的操作,这可能导致主线程无法继续;如果必须,建议使用分支线程。
7)如果你对消息的顺序、事务不敏感,也允许你在业务处理部分使用多线程,这一部分有一定的歧义,所以需要开发者自己评估。从原理上说,多线程可以提高消息消费的效率,但是对数据一致性可能会有影响。但是Consumer的Client框架,仍然坚守单线程、有序交付。
8)在CanalServer和Consumer端,都能指定“filter”,即“过滤不关注的schema消息”;在CanalServer启动时将会首先加载“instance.properties”中的filter配置并生效,此后如果instance的消费者上线且也指定了filter,那么此filter信息将会被注册ZK中,那么CanalServer将会基于ZK获取此信息,并将Consumer端的filter作为最终决策;由此可见,大家在Consumer端指定filter的灵活性更高(当然隐蔽性也增加,这对排查问题需要一些提前沟通),无论如何,CanalServer不会传送“不符合filter”的消息给Consumer。
4、Filter规则描述:适用于instance.properties和Consumer端的subscribe()方法
1) 所有表:.* or .*\\..*
2) canal schema下所有表: canal\\..*
3) canal下的以canal打头的表:canal\\.canal.*
4) canal schema下的一张表:canal.test1
5) 多个规则组合使用:canal\\..*,mysql.test1,mysql.test2 (逗号分隔)
5、运行状态监控
非常遗憾的是,Canal监控能力相当的弱,内部程序中几乎没有JMX的任何export机制,所以如果需要监控比如“slave延迟”、“消费速率”、“position”等,需要开发代码。思路如下:
1)开发一个JAVA WEB项目。
2)读取ZK中的相关META信息,解析出每个destination对于的slave地址,并创建JDBC连接,发送“show master status”等指令,查看此slave binlog的位置,用于判断Canal延迟。
3)读取ZK中相关META信息,解析出每个destination对应的consumer cursor,与2)进行对比,用于判定consumer的消费延迟。
四、Canal核心配置样例
1、canal.properties (${canal.root}/conf)
Java代码 ## 当前canal节点部署的instances列表,以“,”分割 ##比如:test,example canal.destinations= example ##canal配置文件主目录,保持默认即可。 ##除非你为了提高canal的动态管理能力,将conf文件迁移到了其他目录(比如NFS目录等) canal.conf.dir = ../conf # 是否开启“instance”配置修改自动扫描和重载 ##1)conf.dir目录下新增、删除instance配置目录 ##2)instance配置目录下的instance.properties变更 ##不包含:canal.properties,spring/*.xml的配置变更 ##如果环境隔离、测试充分的环境下,或者应用试用初期,可以开启 ##对于高风险项目,建议关闭。 canal.auto.scan = true canal.auto.scan.interval = 5 ##instance管理模式,Production级别大家要求使用spring canal.instance.global.mode = spring ##直接初始化和启动instance canal.instance.global.lazy = false ##Production级别,HA模式下,基于default-instance.xml ##需要即备的ZK集群,且不应该修改此文件的默认配置。 ##如果有自定义的场景,应该新建${instance}-instance.xml文件 canal.instance.global.spring.xml = classpath:spring/default-instance.xml ##canal server的唯一标识,没有实际意义,但是大家建议同一个cluster上的不同节点,其ID尽可能唯一(后续升级) ##数字类型 canal.id = 1 ##canal server因为binding的本地IP地址,建议使用内网(唯一,集群可见,consumer可见)IP地址,比如“10.0.1.21”。 #此IP主要为canalServer提供TCP服务而使用,将会被注册到ZK中,Consumer将与此IP建立连接。 canal.ip = ##conal server的TCP端口 canal.port = 11111 ##Production场景,HA模式下,比如使用ZK作为服务管理,此处至少指定“多数派ZK Node”的IP列表 ##如果你的多个Canal Cluster共享ZK,那么每个Canal还需要使用唯一的“rootpath”。 canal.zkServers = 10.0.1.21:2818,10.0.1.22,10.0.2.21:2818/canal/g1 # flush data to zk ##适用于metaManager,基于period模式 ##metaManager优先将数据(position)保存在内存,然后定时、间歇性的将数据同步到ZK中。 ##此参数用于控制同步的时间间隔,建议为“1000”(1S),单位:ms。 ##运维或者架构师,应该观察ZK的效能,如果TPS过于频繁,可以提高此值、或者按Canal集群分离ZK集群。 ##目前架构下,Consumer向CanalServer提交ACK时会导致ZK数据的同步。 canal.zookeeper.flush.period = 1000 ##canal将parse、position数据写入的本地文件目录,HA环境下无效。 ##(file-instance.xml) canal.file.data.dir = ${canal.conf.dir} canal.file.flush.period = 1000 ##内存模式,EventStore为Memory类型时。(default-instance.xml) ##可选值: ##1) MEMSIZE 根据buffer.size * buffer.memunit的大小,限制缓存记录的大小,简答来说,就是内存容量大小限制 ##2) ITEMSIZE 根据buffer.size进行限制,简单来说,就是根据event的条数限制。 ##如果Canal上的instances个数有限,且Consumer的消费效率很高,甚至接近或者高于binlog解析效率,那么可以适度增加memory有关的数值。 ##此外batchMode还与消费者的batchSize有些关系,消费者每次能消费的数据量,取决于此mode。 ##如果mode为itemSize,则consumer每次获取的消息的条数为batchSize条。 ##如果mode为memSize,那么consumer消费的数据总量为batchSize * memunit canal.instance.memory.batch.mode = MEMSIZE canal.instance.memory.buffer.size = 16384 canal.instance.memory.buffer.memunit = 1024 # 所能支撑的事务的最大长度,超过阈值之后,一个事务的消息将会被拆分,并多次提交到eventStore中,但是将无法保证事务的完整性 canal.instance.transaction.size = 1024 # 当instance.properties配置文件中指定“master”、“standby”时,当canal与“master”联通性故障时,触发连接源的切换, ##那么切换时,在新的mysql库上查找binlog时需要往前“回退”查找的时间,单位:秒。 ##良好架构下,大家建议不使用“standby”,限定一个数据库源。因为多个源时,数据库的调整频繁、协调不足,可能会引入一些数据问题。 canal.instance.fallbackIntervalInSeconds = 60 ## 有关HA心跳检测部分,主要用在Parser管理dump连接时使用。 ## 大家在HA环境时建议开启。 canal.instance.detecting.enable = true #如果你需要限定某个database的可用性验证(比如库锁), #最好使用复杂的、有效的SQL,比如:insert into {database}.{tmpTable} …. canal.instance.detecting.sql = select 1 ##心跳检测频率,单位秒 canal.instance.detecting.interval.time = 6 ##重试次数 ##非常注意:interval.time * retry.threshold值,应该参考既往DBA同学对数据库的故障恢复时间, ##“太短”会导致集群运行态角色“多跳”;“太长”失去了活性检测的意义,导致集群的敏感度降低,Consumer断路可能性增加。 canal.instance.detecting.retry.threshold = 5 #如果在instance.properties配置了“master”、“standby”,且此参数开启时,在“探测失败”后,会选择备库进行binlog获取 #建议关闭 canal.instance.detecting.heartbeatHaEnable = false # CanalServer、instance有关的TCP网络配置,建议保持抱人 work.receiveBufferSize = 16384 work.sendBufferSize = 16384 work.soTimeout = 30# Parser组件,有关binlog解析的过滤 ##是否过滤dcl语句,比如“grant/create user”等 canal.instance.filter.query.dcl = false ##dml语句:insert/update/delete等 canal.instance.filter.query.dml = false ##ddl语句:create table/alter table/drop table以及一些index变更 canal.instance.filter.query.ddl = false canal.instance.filter.table.error = false canal.instance.filter.rows = false # binlog格式和“镜像”格式检测,建议保持默认 canal.instance.binlog.format = ROW,STATEMENT,MIXED canal.instance.binlog.image = FULL,MINIMAL,NOBLOB # ddl是否隔离发送,保持默认 canal.instance.get.ddl.isolation = false
canal.properties为全局配置,约束所有的instances、CanalServer等。
2、instance.properties (${canal.root}/conf/{instance})
Java代码 ## 每个instance都会伪装成一个mysql slave, ## 考虑到binlog同步的机制,大家需要指定slaveId,注意此ID对于此canal前端的MySQL实例而言,必须是唯一的。 ## 同一个Canal cluster中相同instance,此slaveId应该一样。 ## 大家约定,所有Canal的instance,其slaveId以“1111”开头,后面补充四位数字。 canal.instance.mysql.slaveId = 11110001# 数据库相关:master库 ##备注,master并不是要求是“MySQL 数据库Master”, ## 而是Canal instance集群模式下,HA运行态中“master”(首选节点) ## 当在故障恢复、Canal迁移时,大家需要手动指定binlog名称以及postition或者timestamp,确保新Canal不会丢失数据。 ## 数据库实例地址,ip:port canal.instance.master.address = 127.0.0.1:3306 ##指定起始的binlog文件名,保持默认 canal.instance.master.journal.name = ##此binlog文件的position位置(offset),数字类型。获取此position之后的数据。 canal.instance.master.position = ##此binlog的起始时间戳,获取此timestamp之后的数据。 canal.instance.master.timestamp =##standby库 ##考虑到偶司现状,暂不使用standby #canal.instance.standby.address = #canal.instance.standby.journal.name = #canal.instance.standby.position = #canal.instance.standby.timestamp =# 数据库连接的用户名和密码 # 貌似Consumer与CanalServer建立连接时也用的是此用户名和密码 canal.instance.dbUsername = canal canal.instance.dbPassword = canal # 默认数据库 canal.instance.defaultDatabaseName = canal.instance.connectionCharset = UTF-8# schema过滤规则,类似于MySQL binlog的filter # canal将会过滤那些不符合要求的table,这些table的数据将不会被解析和传送 # filter格式,Consumer端可以指定,只不过是后置的。 ## 无论是CanalServer还是Consumer,只要有一方指定了filter都会生效,consumer端如果指定,则会覆盖CanalServer端。 canal.instance.filter.regex = .*\\..* # table black regex canal.instance.filter.black.regex =
3、default-instance.xml (${canal.root}/conf/spring)
建议保持默认
如果觉得《mysql阈值查询 canal安装需要安装数据库吗 – 数据库 – 前端 mysql模糊查询单词》对你有帮助,请点赞、收藏,并留下你的观点哦!