otter

#Otter-入门篇1(阿里开源项目Otter介绍)# ##前言## 呜啦啦啦啦!今天笔者又来开坑了,这次开坑的对象呢是阿里的一个开源项目Otter,Otter它是一个数据同步解决方案,可以解决本地跨网络跨机房跨地域的数据同步问题,并且拥有可观的效率,web管理工具等特点,而且背景也很优秀,据说阿里B2B内部的本地/异地机房的同步需求基本全上了otter。 附上: 喵了个咪的博客: w-blog.cn Otter项目地址: https://github.com/alibaba/otter Otter文档地址: https://github.com/alibaba/otter/wiki ##1. Otter是什么## Ottter是由阿里 爸爸 开源的一个数据同步产品,它的最初的目的是为了解决跨国异地机房双A架构,两边可写的场景,开发时间从2011年7月份一直持续到现在，目前阿里巴巴B2B内部的本地/异地机房的同步需求基本全上了Otter。 Otter基于数据库增量日志解析，支持mysql/oracle数据库进行同步,在最新的v4.2.13已经支持mysql5.7以及阿里云提供的RDS数据库(使用RDS童鞋的福音) ###工作原理 下图是关于Otter运行原理图: 更具上图里面关键几个元素进行介绍 db : 数据源以及需要同步到的库 Canal : 用户获取数据库增量日志

数据同步工具otter（一）谈谈binlog和canal 之前因为懒，没有针对otter做更多的解释和说明，在使用过程中，也发现了一些问题，此次补上一个完整的文档，方便大家使用。 Otter是基于cannal开源的，canal又是基于mysql binlog的产品。我们就从binlog说起 binlog mysql的binlog日志是被设计用来作主从备份或者数据恢复用的。binlog是The Binary Log的简称，意思就是二进制的日志文件（可以点击https://dev.mysql.com/doc/refman/5.6/en/binary-log.html了解）。binlog中以二进制的形式记录了数据库的"events（事件）"即数据库结构及表数据发生的变化。以下这张图就反应了主从库之间使用binlog进行同步的过程： mysql提供了三种不同的binlog记录形式： STATEMENT 语句模式（默认）：日志中记录了所有的执行的sql语句，从库在执行的时候，重新执行相应sql即可。但是因为不记录语句执行的上下文，在从库执行某些语句（比如存储过程）的时候，有些语句不一定能成功执行导致丢失数据 ROW 行模式：日志中记录每一行每个字段的变化，能清楚记录每行数据的变化历史，主从丢失数据的情况大大降低，但是缺点是会产生大量的binlog占用存储空间 MIX 混合模式：在 Mixed

cannal+otter ：mysql数据库同步组件，阿里出品 https://github.com/alibaba/canal https://github.com/alibaba/otter 来源： https://www.cnblogs.com/clarino/p/11794279.html

一、otter简介 otter是阿里开源的一个分布式数据库同步系统，尤其是在跨机房数据库同步方面，有很强大的功能。它是基于数据库增量日志解析，实时将数据同步到本机房或跨机房的mysql/oracle数据库。 二、安装配置JDK 因为zookeeper和Otter-manager都依赖与java环境 注：将Centos的yum源更换为国内的阿里云源 1、首先安装wget yum install wget 2、备份原有源 mv /etc/yum.repos.d /etc/yum.repos.d.backup mkdir /etc/yum.repos.d 注：不同Linux版本，不同源 CentOS 5 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-5.repo CentOS 6 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo CentOS 7 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo 3、清除缓存、生成缓存并更新 yum

本文根据洪斌10月27日在「3306π」技术 Meetup - 武汉站现场演讲内容整理而成。 主要内容： 本次分享将介绍目前数据迁移、数据同步、数据消费，多IDC架构中数据复制技术所面临问题及现有的产品和方案，并分享新开源的能在异构数据存储之间提供高性能和强大复制功能的DTLE相关技术内容。 提纲： 1. MySQL Replication 2. DTLE核心场景 3. DTLE设计原则 4. DTLE相关介绍（架构/集群机制/拓扑结构/技术栈/功能/限制） 5. Demo演示 6. 云间同步案例 大家好，我今天分享的主题是关于爱可生在前不久开源的数据传输中间件DTLE，也可简称为DTS。爱可生作为一家以MySQL为主的技术服务公司，在我们服务企业客户过程中，经常会遇到各种数据同步的需求，能做数据同步的软件很多，但未能找到满足我们所有需求的软件，所以我们决定自研一款数据传输软件，结合我们客户的需求场景做了DTLE，并选择在10月24号“程序员节”向社区开源。 今天主要是对DTLE的一些技术架构，跟大家分享。 1. MySQL Replication MySQL如此受欢迎，其原因和MySQL原生支持了 Replication密不可分。基于replication能力社区也是玩出了各种拓扑架构。 1.1 MySQL Replication架构 这张图对DBA们应该并不陌生

Canal入门（四） 实际上，在实际应用开发中，单体架构的很少存在，我们要为其做一个HA高可用的架构，保障其中一台宕机后，不影响正常使用。 Canal的HA模式配置 1、机器准备 a. 运行canal的机器： 10.20.144.22 , 10.20.144.51. b. zookeeper地址为10.20.144.51:2181 c. mysql地址：10.20.144.15:3306 2、 按照部署和配置，在单台机器上各自完成配置，演示时instance name为example 修改canal.properties，加上zookeeper配置 canal.zkServers=10.20.144.51:2181 canal.instance.global.spring.xml = classpath:spring/default-instance.xml 创建example目录，并修改instance.properties canal.instance.mysql.slaveId = 1234 ##另外一台机器改成1235，保证slaveId不重复即可 canal.instance.master.address = 10.20.144.15:3306 注意： 两台机器上的instance目录的名字需要保证完全一致，HA模式是依赖于instance name进行管理