1. 首页
  2. 文章中心
  3. # Java-数据库

数据库-工具-otter部署otter环境部署&数据同步1. otter部署要求2. 部署步骤附录

81 阅读 0 评论
我是靠谱客的博主 文静百褶裙，这篇文章主要介绍数据库-工具-otter部署otter环境部署&数据同步1. otter部署要求2. 部署步骤附录，现在分享给大家，希望可以做个参考。

文章目录

  • otter环境部署&数据同步
  • 1. otter部署要求
  • 2. 部署步骤
    • 2.1 环境
    • 2.2 部署manager
      • 2.2.1 上传安装包
      • 2.2.2 初始化manager数据库
      • 2.2.3 启动manager
      • 2.2.4 设置node
      • 2.2.4 启动node
    • 2.3 manager配置管理
      • 2.3.1 数据源设置
      • 2.3.2 数据表配置
      • 2.3.3 Canal配置
      • 2.3.4 主备设置
    • 2.4 同步管理
      • 2.4.1 添加AB机房同步channel
      • 2.4.2 设置AB同步管道
      • 2.4.3 设置同步映射关系
      • 2.4.4 初始化AB机房同步数据库
      • 2.4.5 开启同步
  • 附录
    • otter-manager-schema.sql
    • otter-system-ddl-mysql.sql
    • 其他

之前对otter还是比较一知半解的，现在重新在虚拟机环境部署一套环境，并从搭建，配置上顺便描述下otter是怎么工作的。

otter环境部署&数据同步

先说下otter的部署包。

对于canal我们知道单机部署版本有2个部署包一个是canal-deployer，一个是canal-adapter（还有其他的如canal-admin）。canal-deployer实际即canal-server,工作时由canal-server创建canal-instance,由canal-instance连接一个数据源并模拟slave去dump日志binlog，canal-server会将binlog转换成内部数据结构Entry。canal-adapter是canal单机版本另一个部署包，其实也就是canal的消费端实现，canal-server可选择将Entry以tcp,mq等方式传递给canal-adapter，canal-adapter则负责应用到如数据库，es等等

otter是canal的消费端实现。同样有2个部署包，一个是manager-deployer（类似canal-admin）,一个是node-deployer。node-deployer才是canal的消费端，内部自带了一个canal-server，由canal-server拿到binlog转换成Entry，直接给到otter，otter转换自己的内部数据结构EventData后做后续的SETL。S(select)可以认为是转换EventData,这里其实还有封装Batch的操作（为了性能，打乱原有的事务，自己封装合并多条数据再向后传递）。E(extract)即对数据做一些自定义的转换，比如根据数据库数据发送文件，转换数据供T节点获取，视图转换等。我们目前没有比较特别的需求，基本就是做下数据转换供T节点获取，跨机器同步时会涉及ST节点间数据通过网络传输。T(transform)获取E节点的数据并向后传递。L(load)节点拿到数据后应用到数据库（没有实现其他的）。

otter和canal有个类似的问题，都会竞争得到运行，有可能导致压力集中在一台机器上。但相较来说，otter可以选择部分node，竞争只会发生在这些有权限的node中，而canal会在集群所有canal-server中竞争。

1. otter部署要求

  1. otter使用canal，一部分是canal的要求，如需要源数据库开启binlog，且提供有从库相应权限的用户供canal获取binlog。另外对于otter，必须配置为binlog_format必须配置为ROW
  2. otter使用zookeeper做分布式协调，对于双向同步需要跨机房的zookeeper集群来处理数据回环和一致性的问题
  3. 为了优化网络传输性能，ET节点之间数据传输对于HTTP模式需要安装aria2
  4. manager需要数据库来管理node
  5. 对于双A双向同步的数据库，还需要在双A的数据库各增加额外的表解决数据回环和一致性问题。
  6. otter是纯java语言开发，需要安装jdk，建议1.6.25以上
  7. otter使用4.2.18版本，内置canal 1.1.4

2. 部署步骤

2.1 环境

补充下，需要zk大集群环境，目前B机房测试的zk还给kafka使用，所以observer三个节点先去掉了。A,B机房的节点都注册到A机房集群上。

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
zookeeper:
server.0=10.19.161.186:2888:3888
server.1=10.19.161.187:2888:3888
server.2=10.19.161.188:2888:3888
# server.4=10.19.104.234:2888:3888:observer
# server.5=10.19.104.235:2888:3888:observer
# server.6=10.19.104.236:2888:3888:observer
manager:
10.19.161.230
# http://10.19.161.230:8080
admin/admin
db: 10.19.161.232
node:
10.19.161.230
10.19.161.231
10.19.104.237
10.19.104.238
db:
A: jdbc:mysql://10.19.161.232:3306/usercenter_0
B: jdbc:mysql://10.19.104.240:3306/usercenter_0

2.2 部署manager

部署manager和node并启动

2.2.1 上传安装包

复制代码
1
2
3
4
5
6
7
8
9
10
# 登录10.19.161.230
mkdir -p /u02/otter
# 上传node.deployer-4.2.18.tar.gz & manager.deployer-4.2.18.tar.gz 至/u02/otter
# 解压
mkdir -p /u02/otter/node
tar -zxvf /u02/otter/node.deployer-4.2.18.tar.gz -C /u02/otter/node/
mkdir -p /u02/otter/manager
tar -zxvf /u02/otter/manager.deployer-4.2.18.tar.gz -C /u02/otter/manager/
# 依次上传至10.19.161.231，10.19.104.237，10.19.104.238

依次上传至10.19.161.231，10.19.104.237，10.19.104.238

2.2.2 初始化manager数据库

manager-deployer压缩包没有初始化脚本，上git上拿一份 otter-manager-schema.sql。

复制代码
1
2
3
# 连接10.19.161.232
# 执行otter-manager-schema.sql

2.2.3 启动manager

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
# 登录10.19.161.230
# 切换到manager目录
cd/u02/otter/manager
# 修改otter.properties
# vi conf/otter.properties
otter.domainName = 10.19.161.230
otter.database.driver.url = jdbc:mysql://10.19.161.232:3306/otter
otter.database.driver.username = otter
otter.database.driver.password = otter
otter.zookeeper.cluster.default = 10.19.161.186:2181,10.19.161.187:2181,10.19.161.188:2181
# 启动manager
bin/startup.sh

2.2.4 设置node

补充下，需要zk大集群环境，目前B机房测试的zk还给kafka使用，所以observer三个节点先去掉了。A,B机房的节点都注册到A机房集群上。

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
# 登录http://10.19.161.230:8080
# 切换为管理员用户登录 admin/admin
# 添加AB机房zookeeper集群 
# 机器管理/Zookeeper管理
A:
集群名称: A
Zookeeper集群: 10.19.161.186:2181;10.19.161.187:2181;10.19.161.188:2181;	# 注意使用;分隔
描述: A机房zk集群
B:
集群名称: B
Zookeeper集群: 10.19.104.234:2181;10.19.104.235:2181;10.19.104.236:2181;	# 注意使用;分隔， 
描述: B机房zk集群
# 添加AB机房node机器（预先设置分配id，后面node启动需要） 
# 机器管理/Node管理
A-Node1:	# 添加完记录序号1，启动node需要这个序号
机器名称: A-Node1
机器IP: 10.19.161.230
机器端口: 2088
下载端口:
# 默认
Mbean端口:
# 默认
外部IP:
# 外网需要
启用外部IP: 否
zookeeper集群: A
描述: A机房Node节点1
A-Node2:	# 添加完记录序号2，启动node需要这个序号
机器名称: A-Node2
机器IP: 10.19.161.231
机器端口: 2088
下载端口:
# 默认
Mbean端口:
# 默认
外部IP:
# 外网需要
启用外部IP: 否
zookeeper集群: A
描述: A机房Node节点2
B-Node1:	# 添加完记录序号3，启动node需要这个序号
机器名称: B-Node1
机器IP: 10.19.104.237
机器端口: 2088
下载端口:
# 默认
Mbean端口:
# 默认
外部IP:
# 外网需要
启用外部IP: 否
zookeeper集群: B
# 这里后面先换成A了
描述: B机房Node节点1
B-Node2:	# 添加完记录序号4，启动node需要这个序号
机器名称: B-Node2
机器IP: 10.19.104.238
机器端口: 2088
下载端口:
# 默认
Mbean端口:
# 默认
外部IP:
# 外网需要
启用外部IP: 否
zookeeper集群: B
# 这里后面先换成A了
描述: B机房Node节点2

2.2.4 启动node

以A-Node1示例

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 登录10.19.161.230
# 切换node目录
cd /u02/otter/node
# 编辑otter.properties
# vi conf/otter.properties
otter.manager.address = 10.19.161.230:1099
# 创建nid
echo 1 > conf/nid	# 这里1 即上面manager配置node时分配的序号，node根据管理地址向manager注册时会根据序号校验ip等，而且程序中很多地方会需要根据序号取到对应的node
# 启动node
bin/startup.sh
# 查看manager
# http://10.19.161.230:8080/node_list.htm
# A-Node1 已启动

依次再启动A-Node2,B-Node1,B-Node2

2.3 manager配置管理

设置同步的数据表和canal

2.3.1 数据源设置

设置AB机房待同步的数据源

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
# 登录manager http://10.19.161.230:8080/data_source_list.htm
# 配置管理/数据源配置
A-uc:
数据源名称: A-uc
类型: MYSQL
用户名: user
# 有select，connect权限就好了，用作反查数据库和应用数据库
密码: passwd
URL: jdbc:mysql://10.19.161.232:3306/usercenter_0	# 这里设置jdbc:mysql://10.19.161.232:3306好些，但是默认字符集是latin1，下面编码不支持，就指定数据库了
编码: UTF8
验证连接数据源: 恭喜，数据库通过验证！
复制代码
1
2
3
4
5
6
7
8
9
B-uc:
数据源名称: B-uc
类型: MYSQL
用户名: user
密码: passwd
URL: jdbc:mysql://10.19.104.240:3306/usercenter_0	# 注意，这里设置usercenter_0是需要已经先做一次数据全量备份恢复
编码: UTF8
验证连接数据源: 恭喜，数据库通过验证！

2.3.2 数据表配置

设置AB机房待同步的数据表

复制代码
1
2
3
4
5
6
7
8
A:
schema name: usercenter_0	# 也可以用 .* 全匹配
table name: .*
数据源: A-uc
验证连接表: SELECT 未成功	# 配置单表的验证
查询Schema&Table:
# 列出usercenter_0下所有表
复制代码
1
2
3
4
5
6
7
8
B:
schema name: usercenter_0	# 也可以用 .* 全匹配
table name: .*
数据源: B-uc
验证连接表: SELECT 未成功	# 配置单表的验证
查询Schema&Table:
# 列出usercenter_0下所有表

2.3.3 Canal配置

设置canal-instance，连接AB机房数据源。

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# 连接对10.19.161.232，canal连接用户授权
# 比较尴尬，提供的ggs没有grant权限，需要root用户才行（虽然可以搞...但是算了吧...使用@汪松涛建的canal_sync用户）
# canal_sync/canal_sync
# 查询B机房binlog位点信息， 连接10.19.104.240
show master status;	# File:mysql-bin.000001; Position:25363375
# canal配置
A-canal:
canal名称: A-canal
运行模式: 嵌入式
zookeeper集群: A
数据源类型: mysql
数据库地址: 10.19.161.232:3306;
数据库账号: canal
# 这里要用有从库权限可以dump日志的用户
数据库密码: canal
connectionCharset: UTF-8	# 获取binlog指定编码
位点自定义设置: 是
# 指定位置增量更新
是否启用gtid位点: 是
位点信息: {"journalName":"mysql-bin.000001","position":25363376};	# {"journalName":"","position":25363376,"timestamp":0};
是否开启表结构TSDB: 否
# 忘了是啥了，双A用？
存储机制: memory
# memory即可，内嵌的canal，直接在内存转换
内存存储batch获取模式: MEMSIZE	# 默认32M大小=记录数*记录大小，
内存存储buffer记录数: 1024
# 默认32768，32M， 会需要aria2进行http传输，这里控制大小为1M(有用吗？)
内存存储buffer记录单元大小: 1024
HA机制: heartbeat
是否开启心跳: 否
其他参数设置:
meta机制: mixed
# 订阅消费信息存储机制,otter只用了canal的memory，zookeeper & mix(PeriodMixedMetaManager:memory+zookeeper)
索引机制: memory_meta_failback
# position存储机制，otter用了canal的memory,zookeeper,mix(PeriodMixedLogPositionManager:memory+zookeeper),meta,failback(FailbackLogPositionManager:memory+meta)
服务端口: 11111
默认连接超时: 30s
sendBufferSize: 16384	# 16k
receiveBufferSize: 16384 # 16k
切换回退时间: 60
# 大概是切换canal要回退重推？
过滤表达式:
# 过滤binlog 
描述信息: A机房canal
复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
B-canal:
canal名称: B-canal
运行模式: 嵌入式
zookeeper集群: B
数据源类型: mysql
数据库地址: 10.19.104.240:3306;
数据库账号: canal
# 这里要用有从库权限可以dump日志的用户
数据库密码: canal
connectionCharset: UTF-8	# 获取binlog指定编码
位点自定义设置: 否
# 指定位置增量更新
是否启用gtid位点: 否
位点信息:
是否开启表结构TSDB: 否
# canal管理源表结构信息存储，支持memory和database，开启会持久化在manager的数据库
存储机制: memory
# memory即可，内嵌的canal，直接在内存转换
内存存储batch获取模式: MEMSIZE	# 默认32M大小=记录数*记录大小，
HA机制: heartbeat
是否开启心跳: 否
其他参数设置:
meta机制: mixed
# 不知道是啥
索引机制: memory_meta_failback
# 不知道是啥
服务端口: 11111
默认连接超时: 30s
sendBufferSize: 16384	# 16k
receiveBufferSize: 16384 # 16k
切换回退时间: 60
# 大概是切换canal要回退重推？
过滤表达式:
# 过滤binlog 
描述信息: B机房canal

2.3.4 主备设置

提供A机房主备数据库切换用，先不用这个

2.4 同步管理

设置开启AB机房数据同步

2.4.1 添加AB机房同步channel

参数说明见:Manager配置介绍

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
# 登录manager http://10.19.161.230:8080/channel_list.htm
# 同步管理/Channel管理
Channel:
Channel Name: A<->B
同步一致性: 基于当前日志变更
同步模式: 列记录模式
是否开启数据一致性: 是
一致性算法:
单向回环补救
一致性反查数据库延迟阀值(s): 60
描述: AB机房同步Channel

2.4.2 设置AB同步管道

参数说明见:Manager配置介绍， Otter调度模型

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# 登录manager http://10.19.161.230:8080/channel_list.htm
# 同步管理/Channel管理/Pipeline管理
A->B:
Pipeline名字: A->B
Select机器: A-Node1,A-Node2
# 看上去和 canal一样，不能指定优先node? 抢占式压力会抢在一台机器？
Load机器: B-Node1,B-Node2
并行度: 5
# 并行化调度参数，同时仅处理5个process，第一个process未Load，不会继续Select
数据反查线程数: 10
数据载入线程数: 15
文件载入线程数: 15
主站点: 是
同步数据来源: Canal
Canal名字: A-canal
消费批次大小: 4000
# 使用otter文档推荐值
获取批次数据超时时间(毫秒): 500
# 使用otter文档推荐值
描述: A->B
高级设置:
使用batch: 是
是否跳过Select异常: 否
是否跳过Load异常: 否
仲裁器调度模式: 自动选择
# 同一节点使用MEMORY模式block queue + put/take， 非同一节点切换为RPC模式,不会切换为ZOOKEEPER模式
负载均衡算法: Stick
# 第一次选择了node，下一次选择会继续使用该node
传输模式: 自动选择
# 同一节点使用内存，数据小于1M使用rpc(dubbo)，大于1M使用http（file/gzip+aria2），数据默认保存1min，解决TCP协议中的丢包问题控制， 这里没装aria2，可以调整canal：MEMSIZE=1M或选择rac模式
记录Select日志: 是
记录Select详细日志: 否
记录Load日志: 否
记录Load详细日志: 否
dryRun模式: 否
# 只记录load日志，不执行真实同步到数据库的操作
支持ddl同步: 是
跳过ddl异常: 是
文件重复同步对比: 否
文件传输加密: 否
启用公网同步: 否
# 使用外部IP
跳过自由门数据: 否
# 否
跳过反查无记录数据: 否
启用数据表类型转换: 是
兼容字段新增同步: 是
自定义同步标记: NOT2C
# 级联同步
复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
B->A:
Pipeline名字: B->A
Select机器: B-Node1,B-Node2
# 看上去和 canal一样，不能指定优先node? 抢占式压力会抢在一台机器？
Load机器: A-Node1,A-Node2
并行度: 5
# 并行化调度参数
数据反查线程数: 10
数据载入线程数: 15
文件载入线程数: 15
主站点: 否
同步数据来源: Canal
Canal名字: B-canal
消费批次大小: 4000
# 使用otter文档推荐值
获取批次数据超时时间(毫秒): 500
# 使用otter文档推荐值
描述: B->A
高级设置:
使用batch: 是
是否跳过Select异常: 否
是否跳过Load异常: 否
仲裁器调度模式: 自动选择
# 同一节点使用MEMORY模式block queue + put/take， 非同一节点切换为RPC模式,不会切换为ZOOKEEPER模式
负载均衡算法: Stick
# 第一次选择了node，下一次选择会继续使用该node（ET之间）
传输模式: 自动选择
# 同一节点使用内存，数据小于1M使用rpc(dubbo)，大于1M使用http（file/gzip+aria2），数据默认保存1min，解决TCP协议中的丢包问题控制， 这里没装aria2，可以调整canal：MEMSIZE=1M或选择rac模式
记录Select日志: 是
记录Select详细日志: 否
记录Load日志: 否
记录Load详细日志: 否
dryRun模式: 否
# 只记录load日志，不执行真实同步到数据库的操作
支持ddl同步: 否
# 双向同步
跳过ddl异常: 是
文件重复同步对比: 否
文件传输加密: 否
启用公网同步: 否
# 使用外部IP
跳过自由门数据: 否
# 否
跳过反查无记录数据: 否
启用数据表类型转换: 是
兼容字段新增同步: 是
自定义同步标记: NOT2C
# 级联同步

2.4.3 设置同步映射关系

设置AB同步映射

参数参考:映射规则配置

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 点击A->B管道，进入A->B映射关系管理
# 这里数据表直接只设置了一个，不是很好看，新增2对数据表
# A-uc:usercenter_0:uc_user_[0-127];B-uc:usercenter_0:uc_user_[0-127]
# A-uc:usercenter_0:uc_user_address_[0-127];B-uc:usercenter_0:uc_user_address_[0-127]
A->B:
A-uc:usercenter_0:uc_user_[0-127]:
源数据表: uc_user_[0-127]	# A-uc
目标数据表: uc_user_[0-127]	# B-uc
权重: 5

视图模式: include
# extract视图处理，不用视图，无所谓
EventProcessor文本:
# extract自定义处理
FileResolver: CLAZZ
FileResolver文本:
# extract文件处理
A-uc:usercenter_0:uc_user_address_[0-127]:
源数据表: uc_user_address_[0-127]	# A-uc
目标数据表: uc_user_address_[0-127]	# B-uc
权重: 4
# 优先于uc_user同步
A-uc:usercenter_0:.*:
A-uc:usercenter_0:.*:
源数据表: .*	# A-uc
目标数据表: .*	# B-uc
权重: 5
复制代码
1
2
3
4
5
6
7
8
B->A:
B-uc:usercenter_0:.*:
A-uc:usercenter_0:.*:
源数据表: .*	# A-uc
目标数据表: .*	# B-uc
权重: 5

2.4.4 初始化AB机房同步数据库

双A机房数据库同步需要对双A机房数据库添加额外数据库控制数据同步一致性，otter-system-ddl-mysql.sql

参数说明见:Manager配置介绍

复制代码
1
2
3
4
# 连接A机房数据库10.19.161.232
# 执行otter-system-ddl-mysql.sql（可不用新建retl用户，只要数据连接用户otter/canal?可以访问retl数据库即可）
# 连接B机房数据库10.19.104.240同样操作

2.4.5 开启同步

复制代码
1
2
3
# 同步管理/Channel管理
# 启动

碰到了一个问题，canal指定position老是报错，可能哪里姿势不对，直接去掉了A-canal;

没装aria2会报错A->B同步会download error，将传输模式改成rpc

附录

otter-manager-schema.sql

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `otter` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_bin */;
USE `otter`;
SET sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
CREATE TABLE `ALARM_RULE` (
`ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`MONITOR_NAME` varchar(1024) DEFAULT NULL,
`RECEIVER_KEY` varchar(1024) DEFAULT NULL,
`STATUS` varchar(32) DEFAULT NULL,
`PIPELINE_ID` bigint(20) NOT NULL,
`DESCRIPTION` varchar(256) DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`MATCH_VALUE` varchar(1024) DEFAULT NULL,
`PARAMETERS` text DEFAULT NULL,
PRIMARY KEY (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `AUTOKEEPER_CLUSTER` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`CLUSTER_NAME` varchar(200) NOT NULL,
`SERVER_LIST` varchar(1024) NOT NULL,
`DESCRIPTION` varchar(200) DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `CANAL` (
`ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`NAME` varchar(200) DEFAULT NULL,
`DESCRIPTION` varchar(200) DEFAULT NULL,
`PARAMETERS` text DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
UNIQUE KEY `CANALUNIQUE` (`NAME`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `CHANNEL` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`NAME` varchar(200) NOT NULL,
`DESCRIPTION` varchar(200) DEFAULT NULL,
`PARAMETERS` text DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
UNIQUE KEY `CHANNELUNIQUE` (`NAME`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `COLUMN_PAIR` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`SOURCE_COLUMN` varchar(200) DEFAULT NULL,
`TARGET_COLUMN` varchar(200) DEFAULT NULL,
`DATA_MEDIA_PAIR_ID` bigint(20) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_DATA_MEDIA_PAIR_ID` (`DATA_MEDIA_PAIR_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `COLUMN_PAIR_GROUP` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`DATA_MEDIA_PAIR_ID` bigint(20) NOT NULL,
`COLUMN_PAIR_CONTENT` text DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_DATA_MEDIA_PAIR_ID` (`DATA_MEDIA_PAIR_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `DATA_MEDIA` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`NAME` varchar(200) NOT NULL,
`NAMESPACE` varchar(200) NOT NULL,
`PROPERTIES` varchar(1000) NOT NULL,
`DATA_MEDIA_SOURCE_ID` bigint(20) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
UNIQUE KEY `DATAMEDIAUNIQUE` (`NAME`,`NAMESPACE`,`DATA_MEDIA_SOURCE_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `DATA_MEDIA_PAIR` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`PULLWEIGHT` bigint(20) DEFAULT NULL,
`PUSHWEIGHT` bigint(20) DEFAULT NULL,
`RESOLVER` text DEFAULT NULL,
`FILTER` text DEFAULT NULL,
`SOURCE_DATA_MEDIA_ID` bigint(20) DEFAULT NULL,
`TARGET_DATA_MEDIA_ID` bigint(20) DEFAULT NULL,
`PIPELINE_ID` bigint(20) NOT NULL,
`COLUMN_PAIR_MODE` varchar(20) DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_PipelineID` (`PIPELINE_ID`,`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `DATA_MEDIA_SOURCE` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`NAME` varchar(200) NOT NULL,
`TYPE` varchar(20) NOT NULL,
`PROPERTIES` varchar(1000) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
UNIQUE KEY `DATAMEDIASOURCEUNIQUE` (`NAME`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `DELAY_STAT` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`DELAY_TIME` bigint(20) NOT NULL,
`DELAY_NUMBER` bigint(20) NOT NULL,
`PIPELINE_ID` bigint(20) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_PipelineID_GmtModified_ID` (`PIPELINE_ID`,`GMT_MODIFIED`,`ID`),
KEY `idx_Pipeline_GmtCreate` (`PIPELINE_ID`,`GMT_CREATE`),
KEY `idx_GmtCreate_id` (`GMT_CREATE`,`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `LOG_RECORD` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`NID` varchar(200) DEFAULT NULL,
`CHANNEL_ID` varchar(200) NOT NULL,
`PIPELINE_ID` varchar(200) NOT NULL,
`TITLE` varchar(1000) DEFAULT NULL,
`MESSAGE` text DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `logRecord_pipelineId` (`PIPELINE_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `NODE` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`NAME` varchar(200) NOT NULL,
`IP` varchar(200) NOT NULL,
`PORT` bigint(20) NOT NULL,
`DESCRIPTION` varchar(200) DEFAULT NULL,
`PARAMETERS` text DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
UNIQUE KEY `NODEUNIQUE` (`NAME`,`IP`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `PIPELINE` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`NAME` varchar(200) NOT NULL,
`DESCRIPTION` varchar(200) DEFAULT NULL,
`PARAMETERS` text DEFAULT NULL,
`CHANNEL_ID` bigint(20) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
UNIQUE KEY `PIPELINEUNIQUE` (`NAME`,`CHANNEL_ID`),
KEY `idx_ChannelID` (`CHANNEL_ID`,`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `PIPELINE_NODE_RELATION` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`NODE_ID` bigint(20) NOT NULL,
`PIPELINE_ID` bigint(20) NOT NULL,
`LOCATION` varchar(20) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_PipelineID` (`PIPELINE_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `SYSTEM_PARAMETER` (
`ID` bigint(20) unsigned NOT NULL,
`VALUE` text DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `TABLE_HISTORY_STAT` (
`ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`FILE_SIZE` bigint(20) DEFAULT NULL,
`FILE_COUNT` bigint(20) DEFAULT NULL,
`INSERT_COUNT` bigint(20) DEFAULT NULL,
`UPDATE_COUNT` bigint(20) DEFAULT NULL,
`DELETE_COUNT` bigint(20) DEFAULT NULL,
`DATA_MEDIA_PAIR_ID` bigint(20) DEFAULT NULL,
`PIPELINE_ID` bigint(20) DEFAULT NULL,
`START_TIME` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`END_TIME` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_DATA_MEDIA_PAIR_ID_END_TIME` (`DATA_MEDIA_PAIR_ID`,`END_TIME`),
KEY `idx_GmtCreate_id` (`GMT_CREATE`,`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `TABLE_STAT` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`FILE_SIZE` bigint(20) NOT NULL,
`FILE_COUNT` bigint(20) NOT NULL,
`INSERT_COUNT` bigint(20) NOT NULL,
`UPDATE_COUNT` bigint(20) NOT NULL,
`DELETE_COUNT` bigint(20) NOT NULL,
`DATA_MEDIA_PAIR_ID` bigint(20) NOT NULL,
`PIPELINE_ID` bigint(20) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_PipelineID_DataMediaPairID` (`PIPELINE_ID`,`DATA_MEDIA_PAIR_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `THROUGHPUT_STAT` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`TYPE` varchar(20) NOT NULL,
`NUMBER` bigint(20) NOT NULL,
`SIZE` bigint(20) NOT NULL,
`PIPELINE_ID` bigint(20) NOT NULL,
`START_TIME` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`END_TIME` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `idx_PipelineID_Type_GmtCreate_ID` (`PIPELINE_ID`,`TYPE`,`GMT_CREATE`,`ID`),
KEY `idx_PipelineID_Type_EndTime_ID` (`PIPELINE_ID`,`TYPE`,`END_TIME`,`ID`),
KEY `idx_GmtCreate_id` (`GMT_CREATE`,`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `USER` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`USERNAME` varchar(20) NOT NULL,
`PASSWORD` varchar(20) NOT NULL,
`AUTHORIZETYPE` varchar(20) NOT NULL,
`DEPARTMENT` varchar(20) NOT NULL,
`REALNAME` varchar(20) NOT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
UNIQUE KEY `USERUNIQUE` (`USERNAME`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE
`DATA_MATRIX` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`GROUP_KEY` varchar(200) DEFAULT NULL,
`MASTER` varchar(200) DEFAULT NULL,
`SLAVE` varchar(200) DEFAULT NULL,
`DESCRIPTION` varchar(200) DEFAULT NULL,
`GMT_CREATE` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`GMT_MODIFIED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`),
KEY `GROUPKEY` (`GROUP_KEY`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `meta_history` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
`gmt_create` datetime NOT NULL COMMENT '创建时间',
`gmt_modified` datetime NOT NULL COMMENT '修改时间',
`destination` varchar(128) DEFAULT NULL COMMENT '通道名称',
`binlog_file` varchar(64) DEFAULT NULL COMMENT 'binlog文件名',
`binlog_offest` bigint(20) DEFAULT NULL COMMENT 'binlog偏移量',
`binlog_master_id` varchar(64) DEFAULT NULL COMMENT 'binlog节点id',
`binlog_timestamp` bigint(20) DEFAULT NULL COMMENT 'binlog应用的时间戳',
`use_schema` varchar(1024) DEFAULT NULL COMMENT '执行sql时对应的schema',
`sql_schema` varchar(1024) DEFAULT NULL COMMENT '对应的schema',
`sql_table` varchar(1024) DEFAULT NULL COMMENT '对应的table',
`sql_text` longtext DEFAULT NULL COMMENT '执行的sql',
`sql_type` varchar(256) DEFAULT NULL COMMENT 'sql类型',
`extra` text DEFAULT NULL COMMENT '额外的扩展信息',
PRIMARY KEY (`id`),
UNIQUE KEY binlog_file_offest(`destination`,`binlog_master_id`,`binlog_file`,`binlog_offest`),
KEY `destination` (`destination`),
KEY `destination_timestamp` (`destination`,`binlog_timestamp`),
KEY `gmt_modified` (`gmt_modified`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='表结构变化明细表';
CREATE TABLE IF NOT EXISTS `meta_snapshot` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
`gmt_create` datetime NOT NULL COMMENT '创建时间',
`gmt_modified` datetime NOT NULL COMMENT '修改时间',
`destination` varchar(128) DEFAULT NULL COMMENT '通道名称',
`binlog_file` varchar(64) DEFAULT NULL COMMENT 'binlog文件名',
`binlog_offest` bigint(20) DEFAULT NULL COMMENT 'binlog偏移量',
`binlog_master_id` varchar(64) DEFAULT NULL COMMENT 'binlog节点id',
`binlog_timestamp` bigint(20) DEFAULT NULL COMMENT 'binlog应用的时间戳',
`data` longtext DEFAULT NULL COMMENT '表结构数据',
`extra` text DEFAULT NULL COMMENT '额外的扩展信息',
PRIMARY KEY (`id`),
UNIQUE KEY binlog_file_offest(`destination`,`binlog_master_id`,`binlog_file`,`binlog_offest`),
KEY `destination` (`destination`),
KEY `destination_timestamp` (`destination`,`binlog_timestamp`),
KEY `gmt_modified` (`gmt_modified`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='表结构记录表快照表';
insert into USER(ID,USERNAME,PASSWORD,AUTHORIZETYPE,DEPARTMENT,REALNAME,GMT_CREATE,GMT_MODIFIED) values(null,'admin','801fc357a5a74743894a','ADMIN','admin','admin',now(),now());
insert into USER(ID,USERNAME,PASSWORD,AUTHORIZETYPE,DEPARTMENT,REALNAME,GMT_CREATE,GMT_MODIFIED) values(null,'guest','471e02a154a2121dc577','OPERATOR','guest','guest',now(),now());

otter-system-ddl-mysql.sql

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
/*
供 otter 使用， otter 需要对 retl.* 的读写权限，以及对业务表的读写权限
1. 创建database retl
*/
CREATE DATABASE retl;
/* 2. 用户授权 给同步用户授权 */
CREATE USER retl@'%' IDENTIFIED BY 'retl';
GRANT USAGE ON *.* TO `retl`@'%';
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO `retl`@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE ON `retl`.* TO `retl`@'%';
/* 业务表授权，这里可以限定只授权同步业务的表 */
GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO `retl`@'%';
/* 3. 创建系统表 */
USE retl;
DROP TABLE IF EXISTS retl.retl_buffer;
DROP TABLE IF EXISTS retl.retl_mark;
DROP TABLE IF EXISTS retl.xdual;
CREATE TABLE retl_buffer
(
ID BIGINT(20) AUTO_INCREMENT,
TABLE_ID INT(11) NOT NULL,
FULL_NAME varchar(512),
TYPE CHAR(1) NOT NULL,
PK_DATA VARCHAR(256) NOT NULL,
GMT_CREATE TIMESTAMP NOT NULL,
GMT_MODIFIED TIMESTAMP NOT NULL,
CONSTRAINT RETL_BUFFER_ID PRIMARY KEY (ID)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE retl_mark
(
ID BIGINT AUTO_INCREMENT,
CHANNEL_ID INT(11),
CHANNEL_INFO varchar(128),
CONSTRAINT RETL_MARK_ID PRIMARY KEY (ID)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE xdual (
ID BIGINT(20) NOT NULL AUTO_INCREMENT,
X timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (ID)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
/* 4. 插入初始化数据 */
INSERT INTO retl.xdual(id, x) VALUES (1,now()) ON DUPLICATE KEY UPDATE x = now();

其他

​

最后

以上就是文静百褶裙最近收集整理的关于数据库-工具-otter部署otter环境部署&数据同步1. otter部署要求2. 部署步骤附录的全部内容，更多相关数据库-工具-otter部署otter环境部署&数据同步1.内容请搜索靠谱客的其他文章。

本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
点赞(54)

相关文章

Otter单向同步配置
Otter单向同步配置
CanalParseException: column size is not match for table:xm_search.user,5 vs 4理解canal tsdb（时序表结构方案设计）的功能需要先看懂官方对tsdb的介绍和实现https://github.com/alibaba/canal/wiki/TableMetaTSDB
CanalParseException: column size is not match for table:xm_search.user,5 vs 4理解canal tsdb（时序表结构方案设计）的功能需要先看懂官方对tsdb的介绍和实现https://github.com/alibaba/canal/wiki/TableMetaTSDB
【问题解决】canal column size is not match for table
【问题解决】canal column size is not match for table
Java实现读取canal中binlog数据
Java实现读取canal中binlog数据
数据库-工具-otter部署otter环境部署&数据同步1. otter部署要求2. 部署步骤附录
数据库-工具-otter部署otter环境部署&数据同步1. otter部署要求2. 部署步骤附录
20211123-CanalParseException: column size is not match for table:test
20211123-CanalParseException: column size is not match for table:test
canal报错:CanalParseException: column size is not match for table
canal报错:CanalParseException: column size is not match for table
canal踩坑之路
canal踩坑之路

评论列表共有 0 条评论

立即
投稿
返回
顶部