之前对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机房集群上。

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 上传安装包

# 登录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。

# 连接10.19.161.232
# 执行otter-manager-schema.sql

2.2.3 启动manager

# 登录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机房集群上。

# 登录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示例

# 登录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机房待同步的数据源

# 登录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
验证连接数据源: 恭喜，数据库通过验证！

B-uc:
数据源名称: B-uc
类型: MYSQL
用户名: user
密码: passwd
URL: jdbc:mysql://10.19.104.240:3306/usercenter_0	# 注意，这里设置usercenter_0是需要已经先做一次数据全量备份恢复
编码: UTF8
验证连接数据源: 恭喜，数据库通过验证！

2.3.2 数据表配置

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

A:
schema name: usercenter_0	# 也可以用 .* 全匹配
table name: .*
数据源: A-uc
验证连接表: SELECT 未成功	# 配置单表的验证
查询Schema&Table:
# 列出usercenter_0下所有表

B:
schema name: usercenter_0	# 也可以用 .* 全匹配
table name: .*
数据源: B-uc
验证连接表: SELECT 未成功	# 配置单表的验证
查询Schema&Table:
# 列出usercenter_0下所有表

2.3.3 Canal配置

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

# 连接对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

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配置介绍

# 登录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调度模型

# 登录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
# 级联同步

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同步映射

参数参考:映射规则配置

# 点击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

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配置介绍

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

2.4.5 开启同步

# 同步管理/Channel管理
# 启动

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

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

附录

otter-manager-schema.sql

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

/*
供 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.内容请搜索靠谱客的其他文章。