学习
实践
活动
工具
TVP
写文章

干货 | 携程异地活-MySQL实时双向(多向)复制实践

一、前言 携程内部MySQL部署采用机房部署,机房A部署一主一从,机房B部署一从,作为DR(Disaster Recovery)切换使用。 为了做到真正的数据异地活,实现MySQL同机房就近读写,机房故障时无需进行数据库DR操作,只进行流量切换,就需要引入数据实时双向(多向)复制组件。 ? )战略的背景下,服务于异地活项目,赋予了业务全球化的部署能力。 4.2.1 低复制延迟 为了降低复制延迟,就要求复制链路中每一环都尽可能高效。 循环复制 单向复制时,经过DRC复制到对端的SQL在执行后,同样会落到MySQL的Binlog中,这样在双向(多向)复制结构中,对端的Replicator Instance在拉取到该条Binlog后如果继续复制

1.4K21

异地活架构

只读类业务 例如谷歌的搜索,不管用户在哪个国家搜索,得到的结果基本相同,对用户来说,跨国异地的几秒延迟,对搜索结果没什么影响。 跨城异地活设计技巧 1. 保证核心业务的异地活 思维误区:要保证所有业务都能异地活。 解决的方法就是:优先实现核心业务的异地活。 只保证绝大部分用户的异地活 思维误区:要保证业务 100% 可用。 物理规律决定了异地活无法保证100%的业务可用。 所以,无法做到实时转账的异地活,需要通过特殊业务受到实现。

2.1K21
  • 广告
    关闭

    对象存储COS专场特惠,新用户专享存储包低至1元

    一站式解决数据备份、共享、大数据处理、线上数据托管的云端存储服务

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    谈谈异地活架构

    单纯从异地活的描述来看,异地活很强大,能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务,我们都要去实现异地活架构呢? 例如,MySQL的主备复制、Redis的Cluster功能、Elasticsearch的集群功能。 以MySQL为例,MySQL 5.1版本的复制是单线程的复制,在网络抖动或者大量数据同步时,经常发生延迟较长的问题,短则延迟十几秒,长则可能达到十几分钟。 Redis又是另外一个问题,Redis 3.0之前没有Cluster功能,只有主从复制功能,而为了设计上的简单,Redis 2.8之前的版本,主从复制有一个比较大的隐患:从机宕机或者和主机断开连接都需要重新连接主机 ,重新连接主机都会触发全量的主从复制

    2.5K41

    京东JDHBase异地活实践

    为了保障业务稳定不间断运行,我们构建了JDHBase集群的异地活系统。主要介绍在我们在异地活系统的实践。 因为是后台线程异步的读取WAL并复制到备集群,所以这种Replication方式叫做异步Replication,正常情况下备集群收到最新写入数据的延迟在秒级别。 JDHBase异地活架构 JDHBase服务端与客户端交互主要包含三个组件:Client、JDHBase集群、Fox Manager。 我们对可靠性要求比较高的业务做了异地活备份。 ? Active Cluster:正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster,同时保证数据不丢失,但是会有延迟。 实际生产中,我们根据两个建群间的Replication,构建了集群间的Replication拓扑,使得集群互为主备。

    74041

    从 单体架构 到 异地

    异地活到底是什么?为什么需要异地活?它到底解决了什么问题?究竟是怎么解决的? ---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双活 两地三中心 异地双活 异地活 系统可用性 让我们从最基础的开始往上垒。 我很喜欢的一句话和大家分享一下:很多模式是不能直接复制的。当数量级直线上升的时候,其背后的难度是几何增长的。 图中小数点后的一个9,对系统的要求那绝对是更上一层楼了。 ---- 主从复制 但是呢,作为商业型公司要获利就要开源节流嘛,平白整个数据库在那边是不是要利用起来,这时候考虑到主库既要读又要写,压力有点大,从库闲着也是闲着,那就让它分担掉绝大部分读的压力吧。 == ---- 异地活 理解了异地双活,那「异地活」顾名思义,就是在异地双活的基础上,部署多个机房即可。

    14530

    再讲Mysql主从延迟(外赠MySQL异地活的数据双向复制经验.pdf)

    数据库的集群架构都不陌生了,最熟悉也是应用最广泛的就是咱们熟知的主从,今天大概的回味下: 主从复制 MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。 因此,要进行复制,必须在主服务器上启用二进制日志。 每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新,以便从服务器可以对其数据拷贝执行相同的更新。 从架构图中我们可以分析,在大并发量较大的情况下,会出现主从复制延迟这种问题,如何解决?目前已经有了比较成熟的方案。 主从复制原理图: ? 步骤1: 所有数据更新都会被主库记录到主库的二进制日志。 DDL(data definition language): DDL比DML要,主要的命令有CREATE、ALTER、DROP等,DDL主要是用在定义或改变表(TABLE)的结构,数据类型,表之间的链接和约束等初始化工作上 设置为0或者关闭binlog,innodb_flushlog也可以设置为0来提高sql的执行效率 3、使用比主库更好的硬件设备作为slave 4、使用mysql5.7 参看 《MySQL 5.7 并行复制实现原理与调优

    74820

    COS结合SCF的数据复制实践

    我们在使用使用COS上传数据后,会遇到如下场景。 1.上传的数据目录不合适,但是现有代码调整需要发布,临时处理方法可以将A目录的数据复制一份到B目录。 information from COS, and downloads it to the local temporary disk 'tmp' of SCF. # SCF配置COS触发,从COS获取文件上传信息 (2)我们复制对象使用的方法是COS API的objectcopy接口https://cloud.tencent.com/document/product/436/10881 (3)client.copy 配置好函数后,我们设置触发事件 注意:如果是相同桶内资源复制,触发事件一定要带上前缀,否则会导致循环触发复制。造成生成大量无用文件。 如果是跨桶复制资源,触发时可以选择根目录触发。 4.png 看到在根目录同时复制了一个相同文件,耗时大约为1秒。 5.png 验证成功。

    60351

    拆解交易系统--异地

    或者基于高可用 / 高性能的需求,需要做异地活。 架构层次上看是Master-Master,在用户数据纬度看是Master-Slave模式,每条数据只能在用户归属的数据中心写入,再通过异步复制方式写到其他数据中心中。 ? 多数据中心通过数据复制方式实现了数据最终一致性。如何在业务逻辑纬度处理这种数据弱一致性带来的问题呢? 异地活容灾 很多巨型互联网产品发展到一定规模之后,其可用性往往造成很大经济损失,比如微信,支付宝这些用户规模巨大的产品,如果可用性有一点的降级,都会对大规模的用户影响,所以微信,支付宝这些产品早已做了异地活 传统灾备方案 传统数据中心的灾备方案,一般是同城两个互备数据中心,异地建设一个灾备中心,三个数据中心平时只能一个提供在线服务,故障时将业务流量切到其他数据中心。

    40420

    详解:淘宝高可用异地活架构

    可以说,异地活是互联网公司业务规模扩大后所必然要经历的阶段。那么如何解决高可用异地活呢? 有状态服务 后台服务可以划分为两类,有状态和无状态。 高可用的一些解决方案 高可用,从发展来看,大致经过了这几个过程: 冷备 双机热备 同城双活 异地双活 异地活 在聊异地活的时候,还是先看一些其他的方案,这有利于我们理解很多设计的缘由。 简而言之,冷备,就是复制粘贴,在 Linux 上通过 cp 命令就可以很快完成。可以通过人为操作,或者定时脚本进行。 有如下好处: 简单 快速备份(相对于其他备份方式) 快速恢复。 偏软件层面的,比如 MySQL 的 master/slave 方式,通过同步 binlog 的方式;sqlserver 的订阅复制方式。 异地活 ? 图 4:异地活的示意图 根据异地双活的思路,我们可以画出异地活的一种示意图。每个节点的出度和入度都是 4,在这种情况下,任何节点下线都不会对业务有影响。

    63011

    搞懂异地活,看这篇就够了

    在软件开发领域,「异地活」是分布式系统架构设计的一座高峰,很多人经常听过它,但很少人理解其中的原理。 异地活到底是什么?为什么需要异地活?它到底解决了什么问题?究竟是怎么解决的? 这些疑问,想必是每个程序看到异地活这个名词时,都想要搞明白的问题。 有幸,我曾经深度参与过一个中等互联网公司,建设异地活系统的设计与实施过程。所以今天,我就来和你聊一聊异地活背后的的实现原理。 如果你对 MySQL 有所了解,MySQL 本身就提供了双主架构,它支持双向复制数据,但平时用的并不多。 11 异地活 理解了异地双活,那「异地活」顾名思义,就是在异地双活的基础上,部署多个机房即可。 在写这篇文章时,我又仔细阅读了阿里、饿了么、微博等公司,关于异地活架构设计的相关资料,如果你想更深入地学习异地活架构,可以在我的公众号后台回复「异地活」获取。

    52430

    分布式系统架构-----异地活架构

    分布式系统架构-----异地活架构 背景 最近公司在搞异地活,特来写篇文章来学习和回顾一下。 异地活看字面意思 :不通的地方部署服务。 异地活架构 1. 什么是异地活架构? 异地:不同的地理位置,活:不同的地理位置的服务都能独立提供服务。 异地活的目的也就是容灾,容灾的话我们也可以理解为某个地方服务出现了灾难性故障,而服务仍然能正常提供服务。 2. 系统性能,因为异地活会部署在不同的城市,所以距离就会带来延迟(距离越远,耗时越久)。 3. 常用的几种活方案 同城异区 同城异区指的是将业务部署在同一个城市不同区的多个机房。 像我们现在比较流行的夸奖电商的那些服务,岂不是都是这种跨国异地机构呢? 应用 在背景也讲了我们公司也做了异地活,活的方式数据跨城异区。一个集群部署在广州南沙,一个部署在广东佛山。

    13210

    同城双活与异地活架构分析

    例如,企业内部的 IT 系统、管理系统、博客站点等,如果无法承受异地活带来的复杂度和成本,是可以不做异地活的,而对于重要的业务例如核心金融、支付、交易等有必要做活。 四、异地异地活指分布在异地的多个站点同时对外提供服务的业务场景。异地活是高可用架构设计的一种,与传统的灾备设计的最主要区别在于“活”,即所有站点都是同时在对外提供服务的。 1、异地活挑战 (1)应用要走向异地,首先要面对的便是物理距离带来的延时。 这类数据部署情况像下面这样 6、方案评估 优势 容灾能力大幅度提高,服务异地活,数据异地活。 理论上系统服务可以水平扩展,异地机房突破大幅度提升整体容量,理论上不会有性能担忧。 由于篇幅限制本文并未详细介绍各种储存(例如Redis、MySQL)在活下数据同步复制以及高可用方案,有兴趣的同学可以去深入了解这方面知识。

    4.3K61

    分布式系统技术难题--异地

    什么是异地活? 为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对机房场景下的技术挑战。 事实上,异地活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。 ? ? 异地活常见的解决方案有哪些? 请求如何路由,如何实现会话保持? 对于请求路由问题,其设计目标在于,让特定用户访问特定的机房,并且可以实现流量分发策略控制,根据IP会话保持。 在常见的解决方案中有机房单集群,和机房集群部署两种.数据的同步可以分为,数据库,缓存,消息队列,session等。在机房单集群中如何部署? 对于强一致数据,应建立机房单集群的部署模式,使用双读策略。机房集群模式,采用双写策略。 7.

    82950

    MySQL复制复制过滤

    在上一篇文章《深入了解MySQL复制》中,介绍了MySQL复制的相关内容,本文将继续讲解MySQL复制,主要内容是过滤复制以及在已有复制过滤配置中新增复制对象; 首先,来看一下MySQL 复制复制过滤器 区别就在于,在复制的情况,可以为单独的复制通道配置复制过滤,而在8.0之前的版本是无法做到的 如果是在5.7环境中执行下面的语法 CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE ,就需要在把多个源需要过滤的库表进行进行配置;这样是不是就不如8.0支持FOR CHANNEL channel更方便一些了呢; 上面说完了复制中的复制过滤的相关内容,那么在实际的生产中有如下的需求: 如果是对其中一个或多个实例进行过滤复制,并且运行一段时间后,想在这个源上再增加一个或多个库或表复制,该怎么实现呢? 使用mysqldump 导出 db2(记录pos1),并导入源从库。 2. 停止源从库的sql线程(STOP SLAVE SQL_THREAD ),并记录此刻同步到主1的位置pos2。 3.

    47740

    异地活场景下的数据同步之道

    作者:田守枝 来源:田守枝的技术博客订阅号(ID:tianshouzhi_blog) 在当今互联网行业,大多数人互联网从业者对"单元化"、"异地活"这些词汇已经耳熟能详。 而数据同步是异地活的基础,所有具备数据存储能力的组件如:数据库、缓存、MQ等,数据都可以进行同步,形成一个庞大而复杂的数据同步拓扑。 本文将先从概念上介绍单元化、异地活、就近访问等基本概念。 不同单元的之间数据实时进行同步,相互备份对方的数据,才能做到真正意义上"异地活”。 1、基础知识 为了了解如何对不同MySQL的数据相互进行同步,我们先了解一下MySQL主从复制的基本架构,如下图所示: ? 通常一个MySQL集群有一主从构成。 下图红色框中展示了MySQL主从复制的相关协议: ?

    71730

    异地活场景下的数据同步之道

    在当今互联网行业,大多数人互联网从业者对"单元化"、"异地活"这些词汇已经耳熟能详。 而数据同步是异地活的基础,所有具备数据存储能力的组件如:数据库、缓存、MQ等,数据都可以进行同步,形成一个庞大而复杂的数据同步拓扑。 本文将先从概念上介绍单元化、异地活、就近访问等基本概念。 不同单元的之间数据实时进行同步,相互备份对方的数据,才能做到真正意义上"异地活”。 2.1 基础知识 为了了解如何对不同mysql的数据相互进行同步,我们先了解一下mysql主从复制的基本架构,如下图所示: ? 通常一个mysql集群有一主从构成。 下图红色框中展示了Mysql主从复制的相关协议: ?

    1.8K41

    简述异地活方案以及腾讯云实践

    attachmentid=68288undefined(https://km.woa.com/gkm/api/img/cos-file-url? 2F1661740963-7135-630c27a3ae350-387876.png&is_redirect=1优点: 部署简单,将同一套架构完全复制到另外机房即可,数据做单向同步,对业务的改造极少。 缺点: 业务系统需要能够接受一定的跨机房网络延;业务需要进行一定程度的改造, 将操作分位读操作和写操作两类;容灾距离依然受到非常大的限制(主要受限于跨机房写)异地双()活异地双活可以接受两个机房之间的距离大于 云上容灾架构分析案例一腾讯云上云基础架构云上基础容灾架构如下(数据层采取同城双活):图片主要产品:CDN 加速WAF应用防火墙+DDOS防护CLB 负载均衡(可用区)可用区云主机数据库(可用区主备 +异地灾备)

    36080

    复制下处理写冲突(4)-复制拓扑

    复制的拓扑结构描述了写请求从一个节点传播到另一个节点的通信路径。若有两个主节点,如图-7,只有一个合理拓扑结构:M1必须把他所有的写同步到M2,反之亦然。当有两个以上M,各种不同拓扑都可能的。 为避免无限循环,每个节点需赋予一个唯一标识符,在复制日志中的每个写请求都标记了所有已经过的节点的标识符。当某节点收到用自己的标识符标记的数据更改时,该数据更改将被忽略,避免重复转发。 问题 若某节点故障,则可能会中断其他节点之间的复制消息流,导致它们无法通信,直到节点修复。拓扑结构可以重新配置为在发生故障的节点上工作,但在大多数部署中,这种重新配置必须手动完成。 特别当一些网络链接可能比其他网络链接更快(网络拥塞),结果一些复制消息可能“超过”其他复制消息,如图-9。 客户端A向L1的表中插入一行,B在L3更新该行。 冲突检测技术在很多主节点复制系统中实现不够完善。如PostgreSQL BDR不提供写入的因果排序,Tungsten Replicator for MySQL甚至不尝试检测冲突。

    6610

    数据库的异地活分析和方案

    前言 ---- 前文提到异地活的几种型态和基于OceanBase实现方案。这里再总结一下基于其他分布式数据库(MySQL)实现异地活时要考虑的点。 本文不讨论为什么做异地活,可以参考末尾的文章。 异地活的目标 ---- 首先引用前文的分析。 异地活的概念一直都有,只是内涵不断变化。以双机房活为例,应用通常都是无状态的,可以地部署。 MySQL的Group replication基于分布式一致性算法(Paxos协议的变体)实现了主更新复制协议,可以双写或写,对原来主从复制架构是个突破。 后面主要讨论如何基于分布式MySQL实现第4种异地活。 异地活的困难 ---- 异地活的目标很吸引人,但是技术门槛也很高。说光靠一个数据库或者一个数据传输产品就可以做异地活是很片面的。 异地活架构方案 ---- 基于分布式MySQL的异地活方案 ? 上图是阿里巴巴电商异地活技术架构。

    4.2K11

    聊聊高可用的“异地活”架构设计

    高可用 1、高可用的一些解决方案 高可用,从发展来看,大致经过了这几个过程: 冷备 双机热备 同城双活 异地双活 异地活 在聊异地活的时候,还是先看一些其他的方案,这有利于我们理解很多设计的缘由。 简而言之,冷备,就是复制粘贴,在 linux 上通过 cp 命令就可以很快完成。可以通过人为操作,或者定时脚本进行。有如下好处: 简单 快速备份(相对于其他备份方式) 快速恢复。 实际上,异地双活和异地活已经很像了,双活的结构更为简单,所以在程序架构上不用做过多的考虑,只需要做传统的限流,failover等操作即可。但其实双活只是一个临时的步骤,最终的目的是切换到活。 异地活 图4 异地活的示意图 根据异地双活的思路,我们可以画出异地活的一种示意图。每个节点的出度和入度都是4,在这种情况下,任何节点下线都不会对业务有影响。 相对而言,饿了么的活方案可能更适合大多数的企业。 本文只是通过画图的方式进行了简单的描述,其实异地活是需要很多很强大的基础能力的。

    12920

    扫码关注腾讯云开发者

    领取腾讯云代金券