手工打造ticdc集群

    TiCDC 是一个通过拉取 TiKV 日志实现的 TiDB 增量数据同步工具，具有还原数据到与上游任意 TSO 一致状态的能力，同时提供开放数据协议，支持其他系统订阅数据变更。TiCDC 运行时是无状态的，借助 PD 内部的 etcd 实现高可用。TiCDC 集群支持创建多个同步任务，向多个不同的下游进行数据同步。

 

    本着学习探索套路，从版本源码编译，监控展示，服务systemd管理，任务管理，任务异常处理，理论知识收集等进行整理……通过手动部署服务组件，加深对自动化集群部署的新套路，同时也能够系统了解服务在自动化部署过程中是如何实现，服务与任务的角色，加深对ticdc集群维护的认知，对后期集群tiup部署出现异常具有可控性，对线上使用能够快速定位一般问题。

tidb与ticdc组合

ticdc内部逻辑实现：

capture:ticdc运行进程,多个capture组成一个ticdc集群，负责kv change log的同步

    1、每个capture负责拉取一部分kv change log

    2、对拉取一个或多个kv change log进行排序

    3、向下游还原事务或按照ticdc open protocol协议进行输出，协议指：是一种行级别的数据变更通知协议，为监控、缓存、全文索引、分析引擎、异构数据库的主从复制等提供数据源。以事件为基本单位向下游复制数据变更事件，支持的事件分为： 

        1、Row Changed Event:代表一行的数据变化，在变化变更时候该EVENT被发出，包含变更后该行的相关信息

        2、DDL Event:代表DDL变更，在上游成功执行DDL后发出,DDL Event会广播到每一个MQ PARTITION中

       3、Resolved Event：代表一个特殊的时间点，表示在这个事件点前收到的Event事完整的

协议约束：rce(Row Changed Event)

       1、正常情况下，一个版本的rce只会发出一次，特殊情况下(节点故障、网络分区等)，同一个版本的rce可能会发送多次

       2、同一张表中的每一个版本第一次发出的rce在事件流中一定事按TS（timestamp）顺序递增的

       3、resolved event会被周期性的广播到各个MQ partition，Resolved event意味着任何TS小于resolved event ts的event已经发送给下游

      4、DDL event将被广播到各个mq partition

     5、一行数据的多个rce一定会被发送到同一个MQ PARTITION中

RCE下的DML事件定义:

      insert事件:输出新增的行数据

      update事件，输出新增的行数据("u")以及修改前的行数据("p") ，仅当old value特性开启时，才会输出修改前的行数据

     delete事件，输出被删除的行数据，当OLD VALUE开启时，delete事件中包含删除的行数据中所有列，当old value特性关闭，delete事件仅包含handlekey列

capture作用总结如下：

     1、puller负责拉取tikv的change log，对拉取的change log排序(基于表级别)

    2、基于processor这个内部逻辑线程，每个processor负责同步一张或多张表的数据变更，一个capture节点可以运行多个processor线程，向下游输出

    3、高可用:多个CAPTURE组成一个ticdc集群，每个capture角色分为owner/非owner，owner负责节点集群的调度，并且所有的capture都会注册到PD，一旦onwer异常,会触发选举新的onwer，并且owner会在其他processor节点异常时，将processor管理的同步任务调度到其他capture节点

cdc数据同步顺序与一致性性

    1、cdc对所有的DDL/DML都能至少输出一次

     2、在TIKV/CDC集群故障期间可能会重复发相同的DDL/DML，处理规则：

         1、mysql sink可重复执行DDL，对于下游的可重入的DDL（truncate table）直接成功，对于下游不可重入的DDL（create table）执行失败，CDC会忽略错误继续同步

             1、cdc不拆分单表事务，保证单表事务的原子性

             2、不保证下游事务的执行顺序和上游完全一致

             3、以表为单位拆分跨表事务，不保证跨表事务的原子性

             4、保证单行的更新与上游更新顺序一致

       2、kafka sink会发送重复的消息，重复消息不会破坏resolved TS的约束，用户可以在KF消费端进行过滤

cdc同步限制

    cdc只能同步至少存在一个有效索引的表，有效索引规则为：

        1、主键(primary key)为有效索引

        2、存在唯一索引为有效索引

            1、索引中每一列在表结构中明确定义非空(not null)

             2、索引中不存在虚拟生产列(virtual genrated columns)

      ##在4.0.8以后对于同步没有有效索引的表不进行同步限制，添加参数     

 enable-old-value = true
 force-replicate = true

         需要注意:对于没有有效索引的表，INSERT 和 REPLACE 等操作不具备可重入性，因此会有数据冗余的风险。TiCDC 在同步过程中只保证数据至少分发一次，因此开启该特性同步没有有效索引的表，一定会导致数据冗余出现。如果不能接受数据冗余，建议增加有效索引，譬如增加具有 AUTO RANDOM 属性的主键列

官方各个源码下载路径:

         :https://codeload.github.com/pingcap/ticdc/tar.gz/refs/tags/v4.0.13

         #v4.0.13 可根据实际进行下载版本，修改对应的值即可

1、编译cdc服务设置goproxy路径，避免编译失败

      export GOPROXY=goproxy.cn,direct

2、执行执行编译，成功后会生成bin目录，有cdc服务

3、启动cdc服务，启动服务建议指定PD集群，集群可能会涉及到某些原因得切换，引发其他问题

#nohup cdc server --pd=http://172.20.118.103:2379,http://172.20.112.255:2379,http://172.20.235.147:2379 --log-file=./logs/ticdc_3.log --addr=172.16.0.75:8303 --advertise-addr=172.16.0.75:8303 --data-dir=/home/ticdc-4.0.8/8303 &

#nohup cdc server --pd=http://172.20.118.103:2379,http://172.20.112.255:2379,http://172.20.235.147:2379 --log-file=./logs/ticdc_2.log --addr=172.16.0.75:8302 --advertise-addr=172.16.0.75:8302 --data-dir=/home/ticdc-4.0.8/8302 &

#nohup cdc server --pd=http://172.20.118.103:2379,http://172.20.112.255:2379,http://172.20.235.147:2379 --log-file=./logs/ticdc_1.log --addr=172.16.0.75:8301 --advertise-addr=172.16.0.75:8301 --data-dir=/home/ticdc-4.0.8/8301 &

4、查看CDC集群，相对应得角色情况

# cdc cli capture list --pd=http://172.20.118.103:2379,http://172.20.112.255:2379,http://172.20.235.147:2379

这种方式启动，在PD切换或者触发一些其他情况引发整个ticdc挂掉，因此可以加入systemd进行管理

在相应的目录下添加添加脚本

 cat /etc/systemd/system/ticdc-8301.service
[Unit]
Description=ticdc-8301 service

[Service]
ExecStart=/etc/ticdc/run_8301.sh

Restart=always
RestartSec=15s
[Install]
WantedBy=multi-user.target


[root@xhhost75 system]# cat /etc/ticdc/run_8301.sh 
#!/usr/bin/bash
/usr/bin/cdc server --pd=http://172.20.118.103:2379,http://172.20.112.255:2379,http://172.20.235.147:2379 --log-file=/home/ticdc-4.0.8/logs/ticdc_1.log --addr=172.16.0.75:8301 --advertise-addr=172.16.0.75:8301 --data-dir=/home/ticdc-4.0.8/8301

其他端口类似

4、添加cdc监控

    1、导入dashboard模板,注意集群名字

        模板下载路径:test-cluster-TiCDC-1640072726116.json-互联网文档类资源-CSDN下载

    2、导入模板后，对模板参数进行修改

     

 

 

 

5、修改prometheus配置在conf目录下

   1、引入ticdc.rules.yml配置

        配置文件路径:ticdc.rules.yml-互联网文档类资源-CSDN下载

    2、修改prometheus.yml添加内容，具体根据实际情况来处理

在rule_files加入一行记录
rule_files:
    - 'ticdc.rules.yml'
添加job_name名称
- job_name: "ticdc"
  honor_labels: true
  static_configs:
  - targets:
    - '172.16.0.75:8301'
    - '172.16.0.75:8302'
    - '172.16.0.75:8303'
    

6、创建同步任务，直接创建任务属于增量同步，需要在目标端存在对应的信息库。

    #cdc cli changefeed create --pd=http://172.20.118.103:2379,http://172.20.112.255:2379,http://172.20.235.147:2379  --sink-uri="tidb://dlan:root123@172.16.0.11:4000/" --changefeed-id="tidb-task21" --sort-engine="unified" --config ./tidb_cdc.yml

##指定的配置文件信息，rules设置的信息目标需要先存在，

[root@xhhost75 ticdc-4.0.8]# cat tidb_cdc.yml
# 指定配置文件中涉及的库名、表名是否为大小写敏感
# 该配置会同时影响 filter 和 sink 相关配置，默认为 true
case-sensitive = true
#time-zone = "Asia/Shanghai"
##
#同步没有索引的表
#force-replicate = true
# 是否输出 old value，从 v4.0.5 开始支持
enable-old-value = true
[filter]
ignore-txn-start-ts = [1, 2]
# 忽略指定 start_ts 的事务
# 过滤器规则
# 过滤规则语法：https://docs.pingcap.com/zh/tidb/stable/table-filter#表库过滤语法
rules = ['check_ticdc.*','sysbench_test.*']

[mounter]
# mounter 线程数，用于解码 TiKV 输出的数据
worker-num = 16
[cyclic-replication]
sync-ddl = false

6、重启dashboard服务即可 ，效果：

      最终总结下当前使用情况

         1、创建任务名称无法重复使用，无法被彻底删除，通过procesor能够看到

         2、目前没有很明确的压测报告，业内反馈同步2000表会存在一些问题

         3、能够调整的优化参数，目前貌似只有，或者通过增加资源

worker-count=64
batch-replace-size=200

       4、ticdc对下游的写入没法通过连接做到负载均衡，存在压力情况下，估计只能基于库表同步指定不同的tidb-server节点

       5、不同版本存在差异比较大，建议用v4.0.14+，之前版本测试存在各种问题

       6、加好集群监控，以便及时发现问题

       7、建议修改gc时间，万一出问题能够有充足时间来修复

       8、异常恢复后，同步时间会比较久