大家好！ 最近大表哥没有更新是因为在准备PTCA的考试。 这个是TIDB的一个入门的认证吧而且是免费的。
报名地址参考链接： https://learn.pingcap.com/learner/certification-center
PingCap目前是开放了2个考试： PTCA 和 PTCP。 围绕这2门的考试，PingCap的university 推出了2个相关的视频课程。 都是免费的。
301: https://learn.pingcap.com/learner/course/30002 --这个是PTCA
302: https://learn.pingcap.com/learner/course/120005-- 这个是PTCP
理论上来说，PTCA的考试比较基础，侧重于一些运维的基本操作。
PTCP 侧重于一些分布式原理性的方面的概念的理解。
PTCA的考试大纲如下：
考核目标与要求：
PCTA （PingCAP Certified TiDB Associate）是 PingCAP 公司认证 TiDB 数据库专员的缩写。PCTA 要求具备安装部署及日常运维分布式关系型数据库的能力。PCTA 需要学习并熟练掌握 TiDB 架构原理、安装部署、周边工具等基础知识。
考试形式&计分规则
PCTA 认证考试为远程在线考试，考试时长 60 分钟，共 60 道题（单选 30 道，多选 30 道，每题 1 分）满分 60 分，36 分为及格 （通过线以答题正确率 60%为基准，根据试卷难度系数，略有小幅波动）
考试范围
课程模块 内容列表
TiDB 数据库体系架构 分布式数据库原理
分布式 SQL 引擎
分布式存储系统
基于分布式架构的 HTAP 数据库
TiDB 典型应用场景及用户案例
TiDB 集群管理 TiDB Cluster 部署
TiDB 的连接管理
TiDB 的配置
用户管理与安全
TiDB 文件与日志管理
TiDB 的监控
TiDB Cluster的升级
TiDB 备份恢复 备份恢复策略
适用备份恢复工具 BR 进行备份恢复
TiDB 数据迁移 数据导出工具 Dumpling
数据导入工具 TiDB Lightning
数据迁移工具 TiDB Data Migration（DM）
TiDB 数据同步与复制 数据同步工具 TiDB Binlog
数据同步工具 TiCDC
大表哥个人认为备考期一周足够了， 把视频要看完， 讲师的语速较慢，可以2倍速来播放提高收听的效率。
当然了考证简单，重要的知识点，大表哥汇总了一下：以便日后会用到：
1)集群搭建以及集群管理：
tiup 命令相关： 命令指南： Available Commands: check Perform preflight checks for the cluster. -- 集群安装之前的OS层面的环境检查或者检查运行中的集群的健康状态 deploy Deploy a cluster for production --部署集群的命令 需要跟上参数部署的文件 start Start a TiDB cluster --启动集群的命令 stop Stop a TiDB cluster --关闭集群的命令 restart Restart a TiDB cluster --重启集群的命令 scale-in Scale in a TiDB cluster --集群缩容的命令 scale-out Scale out a TiDB cluster --集群扩容的命令 destroy Destroy a specified cluster --销毁集群的命令 clean (EXPERIMENTAL) Cleanup a specified cluster --清除集群的命令 upgrade Upgrade a specified TiDB cluster --集群升级的命令 display Display information of a TiDB cluster --显示集群状态的命令 prune Destroy and remove instances that is in tombstone state --标记删除或者销毁实例 list List all clusters --列出所有的集群 audit Show audit log of cluster operation --显示集群的审计日志 import Import an exist TiDB cluster from TiDB-Ansible --导入已经存在的TIDB集群 edit-config Edit TiDB cluster config. --修改集群中的参数 查询所有的集群： tiup cluster list; 查询集群状态命令： tiup cluster display tidb-test 关闭集群命令： tiup cluster stop tidb-test 集群关闭的顺序如下： 1)altermanager,grafana,prometheus 2)tidb server 3)tikv 4)pd 5)node exporter 启动集群的命令： tiup cluster start tidb-test 集群启动的顺序如下： 1)pd 2)tikv 3)tidb server 4)altermanager,grafana,prometheus 5)node exporter TIDB 升级相关： TiDB 目前暂不支持版本降级或升级后回退。 从文档上来看 TIDB4.0是个分水岭： ================================================== 注意 如果原集群是 3.0 或 3.1 或更早的版本，不支持直接升级到 5.4 及后续修订版本。你需要先从早期版本升级到 4.0 后，再从 4.0 升级到 5.4 及后续修订版本。 =================================================== 4.0之后的版本是可以直接升级到TIDB 5.4的 4.0之前的版本 必须要先升级到 4.0 检查参数不兼容：删除如下参数 pessimistic-txn.enabled server.request-batch-enable-cross-command server.request-batch-wait-duration 检查运行中的集群的健康程度： tiup cluster check <cluster-name> --cluster online 升级集群的方式： tiup cluster upgrade <cluster-name> v5.4.0 offline 升级集群的方式： tiup cluster stop <cluster-name> tiup cluster upgrade <cluster-name> <version> --offline tiup cluster start <cluster-name> 升级中如果报错，该如何处理： tiup cluster audit tiup cluster replay <audit-id> 如果升级过程中，等待选举leader的时间过长： tiup cluster upgrade <cluster-name> <version> --force TIUP 启动部分组件： 该命令支持通过 -R 和 -N 参数来只启动部分组件。 [-N <nodes>]： 节点的IP:端口 [-R <roles>]： role比如tidb,tikv, pd tiup cluster start ${cluster-name} -N 1.2.3.4:2379,1.2.3.5:2379 重命名集群： tiup cluster rename ${cluster-name} ${new-name} 重命名集群会重启监控（Prometheus 和 Grafana）。 重命名集群之后 Grafana 可能会残留一些旧集群名的面板，需要手动删除这些面板。 清除集群的命令： 清除数据： tiup cluster clean ${cluster-name} --data 清除日志： tiup cluster clean ${cluster-name} --log 清除数据+日志： tiup cluster clean ${cluster-name} --all tiup cluster clean ${cluster-name} --all --ignore-role prometheus tiup cluster clean ${cluster-name} --all --ignore-node 172.16.13.11:9000 tiup cluster clean ${cluster-name} --all --ignore-node 172.16.13.12 销毁集群： tiup cluster destroy ${cluster-name} ================================================================================= 扩容与缩容相关的： 需要编辑 scale-out.yaml 的文件： tidb_servers: - host: 10.0.1.5 ssh_port: 22 port: 4000 status_port: 10080 deploy_dir: /data/deploy/install/deploy/tidb-4000 log_dir: /data/deploy/install/log/tidb-4000 tikv_servers: - host: 10.0.1.5 ssh_port: 22 port: 20160 status_port: 20180 deploy_dir: /data/deploy/install/deploy/tikv-20160 data_dir: /data/deploy/install/data/tikv-20160 log_dir: /data/deploy/install/log/tikv-20160 pd_servers: - host: 10.0.1.5 ssh_port: 22 name: pd-1 client_port: 2379 peer_port: 2380 deploy_dir: /data/deploy/install/deploy/pd-2379 data_dir: /data/deploy/install/data/pd-2379 log_dir: /data/deploy/install/log/pd-2379 ====这里注意如果什么也不设置，那么会继承global设置的参数 修改集群的配置文件命令： tiup cluster edit-config tidb-test reload命令使修改的参数生效： tiup cluster reload ${cluster-name} [-N <nodes>] [-R <roles>] 1)执行扩容命令的步骤： tiup cluster check <cluster-name> scale-out.yaml --cluster --user root 2)自动修复检查的错误 tiup cluster check <cluster-name> scale-out.yaml --cluster --apply --user root 3) 执行扩容的命令： tiup cluster scale-out <cluster-name> scale-out.yaml 增加TIFLASH 节点的模板： tiflash_servers: - host: 10.0.1.4 增加TICDC 节点的命令： cdc_servers: - host: 10.0.1.3 gc-ttl: 86400 data_dir: /data/deploy/install/data/cdc-8300 - host: 10.0.1.4 gc-ttl: 86400 data_dir: /data/deploy/install/data/cdc-8300 4)集群缩容的命令： tiup cluster scale-in <cluster-name> --node 10.0.1.4:8300 ============================================================= TIDB 备份和恢复的工具： 1)SST 文件：存储 TiKV 备份下来的数据信息 2)backupmeta 文件：存储本次备份的元信息，包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值 3)backup.lock 文件：用于防止多次备份到同一目录 SST 文件以 storeID_regionID_regionEpoch_keyHash_cf 的格式命名。格式名的解释如下： storeID：TiKV 节点编号 regionID：Region 编号 regionEpoch：Region 版本号 keyHash：Range startKey 的 Hash (sha256) 值，确保唯一性 cf：RocksDB 的 ColumnFamily（默认为 default 或 write）
TIDB的集群的配置：
TIDB 的配置分为： 1.系统配置 --数据库层 保存在TIKV（不包括PD,TIKV,只有 TIDB SERVER层的配置） 支持 session global 级别的参数 2.集群配置 --存储每个节点的配置文件中 需要通过tiup 来修改 需要重启节点之后才生效 集群参数修改命令： tiup cluster edit-config $cluster_name tiup cluster reload $cluster_name -N node -R role TIDB 默认的是 SI 快照隔离 show configs 查看集群中的参数 TIDB 文件和日志类型： TIDB 只有配置文件和日志文件， PD,TIKV： 配置文件和日志文件和数据文件 deploy-dir：软件路径，log，配置 data-dir：数据文件 TIDB 的用户名大小写敏感 创建角色：create role admin@'%' 1）角色无密码， 2）被锁定 3）set role all -- 是角色生效 4）角色存在mysq.user里面 create user 才能修改密码 ship-grant-table: 忘记root 密码 集群的扩容： tiup cluster scale-out 配置文件 TIFLASH 的扩容不一样： 需要开启参数 集群的缩容： tiup cluster scale-in 配置文件 TIFLASH的缩容不一样： 需要清理tiflash上的副本 集群重命名： tiup cluster rename --重启监控 清理集群数据： tiup cluster clean -all --data --log 销毁集群： tiup cluster deploy 集群打patch ： tiup cluster patch TIDB 集群升级步骤： 1.先升级 tiup 2.删除废弃的参数 3.检查集群的将康状态 4.默认是滚动升级不停机（--offline是设置离线升级的参数） PD.TIKV 主从会切换 升级报错： tiup cluster audit tiup cluster erplay audit-id TIDB 集群升级不能够回退版本
关于TIDB时区的修改：
1)优先使用 TZ 环境变量 2)如果失败，则从 /etc/localtime 的实际软链地址提取。 3)如果上面两种都失败则使用 UTC 作为系统时区。 Global:SET GLOBAL time_zone = timezone; Session: SET time_zone = timezone; timezone的格式如下： 'SYSTEM' 表明使用系统时间 相对于 UTC 时间的偏移，比如 '+10:00' 或者 '-6:00' 某个时区的名字，比如 'Europe/Helsinki'，'US/Eastern' 或 'MET' 这2个函数受到影响： NOW() 和 CURTIME() 的返回值都受到时区设置的影响。 1个数据类型 收到影响： 只有 Timestamp 数据类型的值是受时区影响的。可以理解为，Timestamp 数据类型的实际表示使用的是（字面值 + 时区信息）。其它时间和日期类型，比如 Datetime/Date/Time 是不包含时区信息的，所以也不受到时区变化的影响。
BR的原理和最佳实践:
最佳实践 下面是使用 BR 进行备份恢复的几种推荐操作： 推荐在业务低峰时执行备份操作，这样能最大程度地减少对业务的影响。 BR 支持在不同拓扑的集群上执行恢复，但恢复期间对在线业务影响很大，建议低峰期或者限速 (rate-limit) 执行恢复。 BR 备份最好串行执行。不同备份任务并行会导致备份性能降低，同时也会影响在线业务。 BR 恢复最好串行执行。不同恢复任务并行会导致 Region 冲突增多，恢复的性能降低。 推荐在 -s 指定的备份路径上挂载一个共享存储，例如 NFS。这样能方便收集和管理备份文件。 在使用共享存储时，推荐使用高吞吐的存储硬件，因为存储的吞吐会限制备份或恢复的速度。 BR 默认会分别在备份、恢复完成后，进行一轮数据校验，将文本数据同集群数据比较，来保证正确性。在迁移场景下，为了减少迁移耗时，推荐备份时关闭校验(--checksum=false)，只在恢复时开启校验。 BR的2个基本的命令： backup & restorte 命令查看备份show backups 命令查看恢复show restores BR 全备份的命令： br backup full --pd "${PDIP}:2379" -s "local:///tmp/backup" 命令行各部分的解释如下： backup：br 的子命令 full：backup 的子命令 -s 或 --storage：备份保存的路径 "local:///tmp/backup"：-s 的参数，保存的路径为各个 TiKV 节点本地磁盘的 /tmp/backup --pd：PD 服务地址 "${PDIP}:2379"：--pd 的参数 ****************建议在各个节点挂载 NFS 网盘，或者直接备份到 S3 对象存储中。 BR的一级子命令包括： br backup br restore BR的二级子命令包括： full：可用于备份或恢复全部数据。 db：可用于备份或恢复集群中的指定数据库。 table：可用于备份或恢复集群指定数据库中的单张表。 备份的性能相关： --ratelimit 限制速度 ****请尽量禁止将在线服务的数据备份到 TiKV 的数据盘 实例全备命令: 限速128MB br backup full \ --pd "${PDIP}:2379" \ --storage "local:///tmp/backup" \ --ratelimit 128 \ --log-file backupfull.log 选择性过滤表的备份： --filter 注意这里是 including包含的意思： br backup full \ --pd "${PDIP}:2379" \ --filter 'db*.tbl*' \ --storage "local:///tmp/backup" \ --ratelimit 128 \ --log-file backupfull.log 如果是保存到S3的话： --storage "s3://${Bucket}/${Folder}" 增量备份 必须要指定上一次的备份时间戳：--lastbackupts br backup full\ --pd ${PDIP}:2379 \ --ratelimit 128 \ -s local:///home/tidb/backupdata/incr \ --lastbackupts ${LAST_BACKUP_TS} 如何获得上一次备份的时间戳： LAST_BACKUP_TS=`br validate decode --field="end-version" -s local:///home/tidb/backupdata | tail -n1` BR命令恢复数据： ***在恢复前必须将所有备份的 SST 文件复制到各个 TiKV 节点上 --storage 指定的目录下。 全部恢复： br restore full \ --pd "${PDIP}:2379" \ --storage "local:///tmp/backup" \ --ratelimit 128 \ --log-file restorefull.log 恢复单个数据库： br restore db \ --pd "${PDIP}:2379" \ --db "test" \ --ratelimit 128 \ --storage "local:///tmp/backup" \ --log-file restorefull.log 恢复单个表的命令： br restore table \ --pd "${PDIP}:2379" \ --db "test" \ --table "usertable" \ --ratelimit 128 \ --storage "local:///tmp/backup" \ --log-file restorefull.log 指定恢复多个表： --filter br restore full \ --pd "${PDIP}:2379" \ --filter 'db*.tbl*' \ --storage "local:///tmp/backup" \ --log-file restorefull.log 从S3上恢复数据： br restore full \ --pd "${PDIP}:2379" \ --storage "s3://${Bucket}/${Folder}" \ --s3.region "${region}" \ --ratelimit 128 \ --send-credentials-to-tikv=true \ --log-file restorefull.log 获得备份表的统计信息，包含有多少个KV，表的大小： admin checksum table order_line 备份过程中，可以监控备份的CPU：Backup CPU Utilization 备份成功后的回显信息的含义： 备份耗时：total take(Full backup time): 31.802912166s 程序运行总耗时：total take(real time): 49.799662427s 备份数据大小：total size(MB): 5997.49 备份吞吐：avg speed(MB/s): 188.58 备份 KV 对数：total kv: 120000000 校验耗时：["backup checksum"=17.907153678s] 计算各表 checksum、KV 和 bytes 信息总和的耗时：["backup fast checksum"=349.333µs] 备份 Region 总数：["backup total regions"=43] 备份存档经压缩后在磁盘中的实际大小：[Size=826765915] 备份存档的快照时间戳：[BackupTS=422618409346269185] 通过以上数据可以计算得到单个 TiKV 实例的吞吐为：avg speed(MB/s)/tikv_count = 62.86 多线程备份： --concurrency（默认是 4） bin/br backup table \ --db batchmark \ --table order_line \ -s local:///br_data/ \ --pd ${PD_ADDR}:2379 \ --log-file backup-nfs.log \ --concurrency 16 恢复过程中的监控：参考TIKV的写入CPU，IO 恢复日志中的信息的含义： 恢复耗时：total take(Full restore time): 17m1.001611365s 程序运行总耗时：total take(real time): 16m1.371611365s 恢复数据大小：total size(MB): 353227.18 恢复 KV 对数：total kv: 5659888624 恢复吞吐：avg speed(MB/s): 367.42 Region Split 耗时：take=49.049182743s 校验耗时：restore checksum=6m34.879439498s 恢复存档在磁盘中的实际大小：[Size=48693068713] 如果 TiKV 资源使用没有明显的瓶颈，可以尝试调大 --concurrency 参数（默认为 128），示例如下： bin/br restore table --db batchmark --table order_line -s local:///br_data/ --pd 172.16.5.198:2379 --log-file restore-concurrency.log --concurrency 1024 备份中出现的常见错误： 备份日志中出现 key locked Error 日志中的错误消息：log - ["backup occur kv error"][error="{\"KvError\":{\"locked\": 如果在备份过程中遇到 key 被锁住，目前 BR 会尝试清锁。少量报错不会影响备份的正确性。 备份失败 日志中的错误消息：log - Error: msg:"Io(Custom { kind: AlreadyExists, error: \"[5_5359_42_123_default.sst] is already exists in /dir/backup_local/\" })" 若备份失败并出现以上错误消息，采取以下其中一种操作后再重新备份： 更换备份数据目录。例如将 /dir/backup-2020-01-01/ 改为 /dir/backup_local/。 删除所有 TiKV 和 BR 节点的备份目录。 备份和恢复支持的 第三方存储： Amazon S3 s3://bucket-name/prefix/of/dest/ Google Cloud Storage (GCS) gcs://bucket-name/prefix/of/dest/ Azure Blob Storage (Azblob) azure://container-name/prefix/of/dest/ 还支持不写入任何设备： noop:// noop:// BR自动调节的功能： 1）可以手动的修改 TIKV的参数 backup.num-threads 2）限速 --ratelimit 5.4版本新的参数： v5.4.0 及以上版本后，自动调节功能默认关闭，需手动开启 backup.enable-auto-tune ： false 命令修改： tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v <true|false> 使用 local storage 的时候，BR 备份的文件会存在哪里？ 在使用 local storage 的时候，只会在运行 BR 的节点生成 backupmeta，在各个 Region 的 Leader 节点生成备份文件。 并且备份不会存在副本，因为只在每个region的leader 节点备份 BR 恢复的数据无法被同步到下游，因为 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。 会的，BR 会备份表的 SHARD_ROW_ID_BITS 和 PRE_SPLIT_REGIONS 信息，并恢复成多个 Region。 如果 BR 备份的集群有 TiFlash，恢复时会将 TiFlash 信息存进 TableInfo。此时如果恢复的集群没有 TiFlash，则会报该错误。计划在未来版本中修复该错误。 BR backupTS 默认是在备份开始前，从 PD 获取到的最新时间戳。可以使用 pd-ctl tso timestamp 来解析该时间戳，以获得精确值，也可以通过 backupTS >> 18 来快速获取估计值。 BR 不会备份统计信息（v4.0.9 除外）。所以在恢复存档后需要手动执行 ANALYZE TABLE 或等待 TiDB 自动进行 ANALYZE。 强烈不建议在单个集群中同时使用多个 BR 进程进行恢复
数据迁移工具DM
同步工具DM：
-数据上游：mysql 源数据库
-数据下游：tidb
-同步方式支持：全量和增量，支持分库分表之后的数据表的合并
-数据量的限制：建议1TB之下的同步
支持全量和增量，兼容MYSQL语法的数据库
支持分库分表的合并
DM 的架构原理包含的组件：
DM-MASTER：负责管理调度工作
DM-WORKER: 读取源头数据库的信息（远端需要开启MySQL的binlog）,DM-work 和 数据源是 1对1的关系
DM-CTL:操作的命令行，启动迁移任务，
DM的特点：（异步迁移）
兼容MYSQL协议的数据库同步
支持异构表的迁移
支持分库分表之后的数据表的合并
初始化DM的拓扑文件的命令：
tiup dm template > template.yaml
部署DM的命令：
tiup dm deploy ${name} ${version} template.yaml --user tidb
查看DM的可用版本：
tiup list dm_master
查看集群中的DM
tiup dm list
检查DM的状态：
tiup dm display ${name}
启动DM：
tiup dm start ${name}
配置同步的任务：
1) binlog 打开
2) 数据过滤：表的过滤 table allow & block list
3)binevent filter: 操作过滤INSERT,DETELE,DROP,TRUNCATE
4) table routing: 表的路由 mapping 上下游的表
DMCTL 添加数据源：
任务配置文件：
启动DM的命令：
tiup dmctl --master-addr 0000 start-task ./task.yaml
启动之前检查DM的任务的命令：
tiup dmctl --master-addr 0000 check ./task.yaml
暂停任务：
tiup dmctl --master-addr 0000 pause-task ./task.yaml
恢复任务：
tiup dmctl --master-addr 0000 resume-task ./task.yaml
查询任务的状态：
tiup dmctl --master-addr 0000 query-status ./task.yaml
停止任务：
tiup dmctl --master-addr 0000 stop-task ./task.yaml
性能优化：
导出
rows : 单表多线程 threads = 4
chunk-filesize 默认是 64M
导入：
pool-size 默认是16
增量复制：
worker-count: 16
batch: 100条提交
源端数据库的版本限制：
mysql 版本5.5以上
导出工具DUMPLING:
-数据上游：mysql,TIDB
-数据下游：sql,csv
-导出支持：以文件的形式
-数据量的限制：建议在数据量较小的环境下
Dumpling 为数据库的导出工具： SQL,CSV的格式。 属于逻辑备份，热备，全量备份（不支持增量备份）
需要连接
合适场景：数据量小，导入效率低
安装 tiup install dumping:
dumping 的账户的权限：
select
reload
lock tables
replication client
导出的命令：
dumping:
--filetype ： SQL | csv
--where: 数据过滤 （只有CSV格式可以使用 where 条件）
--filter： 库表级别的过滤
--B： 数据库
--T： 表
dumping 导出的文件包括：
1.metadata文件
2.建库语句
3.建表语句
4.数据SQL文件
dump的metadata: binlog的时间抽
dumping 导出的数据一致性问题：
--consistency: flush：flush table with read lock
snapshot: MVCC 快照读
lock：lock备份表
none： 没有一致性
auto： 根据目标数据库
性能优化：
-t 并发数
-r 单个文件的行数
导入工具Lightning:
-数据上游：csv,sql 文件
-数据下游：tidb
-导入支持：以文件的形式
-数据量的限制：如果使用 Local-backend 进行数据导入，TiDB Lightning 运行后，TiDB 集群将无法正常对外提供服务
导入模式-》建立schema和表->分割表-》读取SQLdump-》写入本地临时存储文件=》导入TIKV集群=》 校验和分析=》普通模式
lightning 的后端模式 backend：
import-backend: 需要额外组件 tikv-importer (直接导入TIKV,不支持事务，会影响到业务系统)
local-backend: 本地排序和存储 (直接导入TIKV,不支持事务，会影响到业务系统)
tidb-backend: 通过执行SQL来导入，连接TIDB 导入 目标表可以不为空
lightning 对磁盘量的要求： 1TB* 3副本 * 2份（本地模式 localbackend ）
安装： tiup install lightning
配置导入文件 lightning.toml
通过 lightning 命令进行导入
断点续传的功能：开启checkpoint
保存在文件中或者 mysql
数据过滤： 参数 -f 'db.table'
[mydumper] filter=['db.table1','db.table2']
启动的web界面： --server_mode --status-addr
数据捕获工具TiCDC：
数据捕获工具TiCDC：
-数据上游：TIDB
-数据下游：tidb,mysql,kafka...
-导入支持：
-数据量的限制：
TiCDC 是通过捕获TIKV层日志的变化来实现的。（KV change data）
高可用 2 个实例
性能
支持丰富的下游
TICDC的组件是 capture 组件
部署：
TICDC_server：
TICDC 的管理工具： cdc cli or tiup cdc cli
创建ti cdc 任务的命令：
tiup cdc cli changefeed create
--pd=
--sink-url=
--changefeed-id=
--start-ts 源端开始的TSO
--target-ts 结束的TSO
下游是mysql/tidb:
work-count: 制定下游的并发度 默认是16
max-txn-row:下游执行SQL BATCH 的大小
下游是Kafka：
protocol: 指定输出的协议， canal，avro
max-message-bytes: 消息的大小限制
列出CDC的同步任务：
cdc cli changefeed list --pd=
查看某个具体CDC任务
cdc cli changefeed query -s --pd --changefeed-id=
停止某个CDC的任务
cdc cli changefeed stop --pd --changefeed-id=
恢复某个CDC的任务
cdc cli changefeed resume --pd --changefeed-id=
删除某个CDC的任务
cdc cli changefeed remove --pd --changefeed-id=
无法做到在线修改CDC任务的属性：需要暂停任务
cdc cli changefeed pause -c --pd=
cdc cli changefeed update -c --pd=
cdc cli changefeed resume -c --pd=
TICDC 同步对表的要求：
1.表中有主键或者非空唯一的索引
2.不支持虚拟列的同步
3.不支持RAWKV的集群
4.不支持 SEQUENCE的DDL
数据捕获工具Tibinlog：
数据捕获工具Tibinlog：
-数据上游：TIDB
-数据下游：tidb,mysql,kafka...
-导入支持：
-数据量的限制：必须与tidb的版本兼容
收集binlog到下游数据库： 5.0之前的版本可以使用， 5.0之后推荐TICDC
TI binlog 的组件：
Pump 组件负责捕获数据的变化
Drainer 组件负责数据的排序 每一个Drainer 对接一个数据库 ，支持relay log
TIDB 的binlog 是 row格式的， 记录事务提交顺序记录的，只记录提交的事务
记录主键信息，开始的时间抽，提交的时间抽
binlogctl 是管理 TIDB BINLOG 的工具
支持的下游系统： MYSQL/TIDB
本地文件系统
kafka
BINLOG 组件不需要单独安装： 版本大于2.0
启动pump 进程： pump --config pump.toml
启动 Drainer 进程： drainer --config Drainer.toml --initial-commit-st 指定开始同步的时间戳 （不定义的话，就是当前的时间）
查看 pump和drainer 的进程的状态：
binlogctl --pd-url= -cmd pumps
binlogctl --pd-url= -cmd drainers
暂停和下线pump 的进程
binlogctl --pd-url= -cmd pause-pump --node-id
binlogctl --pd-url= -cmd offline-pump --node-id
暂停和下线drainer 的进程
binlogctl --pd-url= -cmd pause-drainer --node-id
binlogctl --pd-url= -cmd offline-drainer --node-id
数据库在线校验工具sync-diff-inspector：
数据库在线校验工具sync-diff-inspector： -数据上游：TIDB -数据下游：mysql -导入支持： -数据量的限制：对于 MySQL 和 TiDB 之间的数据同步不支持在线校验, 不支持 JSON、BIT、BINARY、BLOB 等类型的数据
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
