1. Otter数据同步系统概述
Otter是阿里巴巴开源的一款分布式数据库同步系统,专门用于解决异地机房之间的数据同步问题。这个纯Java开发的系统在阿里巴巴B2B内部已经稳定运行多年,目前管理着200多个数据库实例、80多台机器的集群规模,日均同步数据量高达6亿条记录,文件同步量达到1.5TB。
提示:Otter名称来源于英文单词"Otter"(水獭),寓意数据搬运工的角色,非常形象地描述了它的核心功能。
作为基于数据库增量日志解析的准实时同步系统,Otter主要支持MySQL和Oracle数据库之间的同步。它采用典型的分布式架构,由Manager(管理节点)和Node(工作节点)组成,通过Zookeeper实现分布式状态调度,确保多节点协同工作的高可靠性。
2. 核心架构与工作原理
2.1 系统组件解析
Otter的系统架构主要包含以下几个关键组件:
-
Manager节点:提供Web管理界面,负责同步任务的配置、监控和调度。它会将配置信息推送到各个Node节点,并接收节点反馈的同步状态。
-
Node节点:实际执行数据同步的工作节点,每个节点可以处理多个同步任务。节点会定期向Manager汇报工作状态和进度。
-
Zookeeper:用于分布式协调服务,管理节点注册、任务分配和故障转移等分布式场景下的协同工作。
-
Canal组件:阿里巴巴开源的MySQL数据库增量日志解析工具,Otter依赖它来获取数据库的binlog变更。
2.2 同步流程详解
Otter的数据同步过程可以分为以下几个阶段:
- 日志抓取阶段:通过Canal伪装成MySQL从库,从主库获取binlog日志。
- 日志解析阶段:将获取的binlog解析为可理解的数据变更事件。
- 数据转换阶段:根据配置的映射规则,对数据进行必要的转换处理。
- 数据加载阶段:将转换后的数据应用到目标数据库。
- 状态反馈阶段:将同步进度和状态反馈给Manager节点。
这个流程确保了数据从源库到目标库的准实时同步,典型延迟在秒级别。
3. 环境搭建与部署
3.1 前置条件准备
在部署Otter之前,需要确保以下环境已经就绪:
- Java环境:JDK 1.8或以上版本
- 数据库:MySQL 5.6+/Oracle 10g+作为源库和目标库
- Zookeeper:3.4.6或以上版本
- Manager节点:至少2核CPU,4GB内存
- Node节点:根据同步任务量配置,建议4核CPU,8GB内存起
3.2 安装步骤详解
-
获取安装包:
bash复制git clone https://github.com/alibaba/otter.git cd otter -
安装依赖:
bash复制cd lib bash install.sh -
编译打包:
bash复制cd .. mvn clean install -Dmaven.test.skip -Denv=release -
部署Manager:
- 解压target目录下的manager.deployer-${version}.tar.gz
- 修改conf/otter.properties配置数据库和Zookeeper连接信息
- 启动脚本:bin/startup.sh
-
部署Node:
- 解压target目录下的node.deployer-${version}.tar.gz
- 修改conf/otter.properties配置Zookeeper连接信息
- 启动脚本:bin/startup.sh
注意:生产环境建议将Manager和Node部署在不同的服务器上,Zookeeper建议使用3节点集群保证高可用。
4. 同步任务配置实战
4.1 数据源配置
- 登录Manager的Web界面(默认端口8080)
- 进入"数据源配置"菜单
- 添加源库和目标库的连接信息:
- 数据源类型(MySQL/Oracle)
- 连接地址和端口
- 用户名和密码
- 字符集设置(建议UTF-8)
4.2 通道与管道配置
-
创建通道:
- 通道是同步任务的基本单位,一个通道可以包含多个管道
- 设置通道名称、同步模式(单向/双向)等基本信息
-
配置管道:
- 选择源库和目标库
- 设置同步表映射关系
- 配置高级参数:
- 批处理大小(建议500-1000)
- 并发线程数(根据服务器性能调整)
- 是否同步DDL操作
4.3 表映射规则
Otter支持灵活的表和字段映射:
- 表名映射:可以设置源表和目标表的不同名称
- 字段映射:支持字段名转换和字段过滤
- 数据转换:支持简单的数据转换函数,如日期格式转换、字符串处理等
5. 高级功能与优化技巧
5.1 双A架构实现
Otter支持双向同步,可以实现双活数据中心架构:
- 冲突检测:基于时间戳或版本号解决数据冲突
- 环路控制:防止同步的数据再次被同步回去
- 事务一致性:确保双向同步的事务完整性
5.2 性能优化建议
-
批处理优化:
- 适当增大批处理大小(但不宜过大)
- 建议值:500-1000条/批
-
并发控制:
- 根据服务器CPU核心数设置合适的并发线程
- 建议值:CPU核心数×2
-
网络优化:
- 跨机房同步建议开启数据压缩
- 调整TCP缓冲区大小
-
内存配置:
bash复制# 修改bin/startup.sh中的JVM参数 JAVA_OPTS="-Xms4g -Xmx4g -XX:+UseG1GC"
5.3 监控与告警
-
内置监控:
- Manager界面提供同步延迟、吞吐量等监控指标
- 支持查看详细的同步日志
-
外部集成:
- 支持通过JMX暴露监控指标
- 可以对接Prometheus等监控系统
-
告警配置:
- 设置延迟阈值告警
- 配置同步失败告警
6. 常见问题排查
6.1 同步延迟问题
现象:同步延迟持续增大
排查步骤:
- 检查源库的binlog生成速度
- 检查网络带宽和延迟
- 检查Node节点的CPU和内存使用情况
- 适当调整批处理大小和并发数
6.2 数据不一致问题
现象:目标库数据与源库不一致
解决方案:
- 启用Otter的数据一致性检查功能
- 配置定期全量校验任务
- 对于不一致数据,可以通过Otter的修复工具进行修复
6.3 常见错误代码
| 错误代码 | 含义 | 解决方案 |
|---|---|---|
| 1001 | 连接源库失败 | 检查网络和数据库连接信息 |
| 1003 | 权限不足 | 确保数据库用户有足够权限 |
| 2005 | 目标表不存在 | 检查表映射配置或手动创建目标表 |
| 3008 | 数据冲突 | 配置合适的冲突解决策略 |
7. 生产环境最佳实践
7.1 高可用部署方案
-
Manager高可用:
- 部署多个Manager实例
- 使用Nginx做负载均衡
-
Node高可用:
- 每个同步通道配置多个Node节点
- 通过Zookeeper实现故障自动转移
-
Zookeeper集群:
- 至少3个节点
- 分布在不同的物理服务器上
7.2 灾备方案设计
-
多级同步:
- 主中心->备中心->灾备中心的多级同步架构
- 设置不同的同步优先级
-
数据校验:
- 定期执行全量数据校验
- 配置自动修复机制
-
容灾演练:
- 定期模拟故障场景
- 测试故障切换和数据恢复流程
7.3 版本升级策略
-
测试环境验证:
- 先在测试环境验证新版本
- 运行完整的回归测试
-
滚动升级:
- 逐个节点升级,确保服务不中断
- 先升级Node,再升级Manager
-
回滚方案:
- 保留旧版本安装包
- 准备快速回滚脚本
在实际生产环境中使用Otter时,我发现合理配置批处理大小和并发数是性能优化的关键。对于跨机房的同步场景,网络带宽往往成为瓶颈,此时可以考虑在业务低峰期同步大表数据,高峰期只同步关键业务表。另外,定期检查Zookeeper的健康状态也非常重要,因为它是整个系统协调工作的核心组件。
