MySQL两地三中心方案初步设计【转】
整体内容会按照如下的方式来进行设计:
首先说下方案的背景,我参考了一些资料(参见附件)。
方案背景
随着互联网业务快速发展,多IDC的业务支撑能力和要求也逐步提升,行业内的“两地三中心”方案较为流行。
其中两地是指同城、异地;三中心是指生产中心、同城容灾中心、异地容灾中心。
在早期,比较典型的是国内外银行多采用“两地三中心”建设方案。这种模式下,多个数据中心是主备关系,即存在主次,业务部署优先级存在差别,针对灾难的响应与切换周期非常长,RTO与RPO目标无法实现业务零中断,资源利用率低下,投资回报无法达到预期。两地三中心本质上是一种通过简单资源堆砌提高可用性的模式,对高可用的提高、业务连续性的保证仍然只是量变,业务连续性及容灾备份一直没有实质性的跨越。
目前,以银行为代表的、包括政府、公共交通、能源电力等诸多行业用户,开始将关注点转向“分布式多活数据中心”
通过双活的方案,具有两类特点。一是多IDC中心之间地位均等,在正常模式下协同工作,并行的为业务访问提供服务,实现了对资源的充分利用,避免一个或两个备份中心处于闲置状态,造成资源与投资浪费,通过资源整合,多活数据中心的服务能力往往双倍甚至数倍于主备数据中心模式;二是在一个数据中心发生故障或灾难的情况下,其他数据中心可以正常运行并对关键业务或全部业务实现接管,达到互为备份的效果,实现用户的“故障无感知”。
结合公司目前的业务运营情况,IDC机房主要在xxxx,xxx,同时在xxxx区域部署有一些IDC机房,其中数据中心主要以xxx为主,所以在两地三中心方案中,同城双活较为符合发展的趋势。
而两地三中心方案的设计,不光需要数据库层基于分布式进行改造,同时在业务层,系统层,网络层都需要相关的方案适配。
目标和计划:
ü 两地三中心的设计原则为同城双活,异地容灾,其中同城暂定为HB30,HB21,异地容灾暂定为华中或华东的IDC节点
ü 改造设计需要和业务端进行密切配合,从业务场景出发选择合适的方案
ü 考虑跨机房的支持,需要引入consul方案,实现service_name的高可用管理
ü 同城双活的数据要求为最终一致性,异地容灾暂不对业务开放,在30分钟内可以快速恢复业务
ü 可以设定短期目标和长期目标,短期目标可以充分借助开源红利和业务场景进行落地,在落地过程中不断的迭代改进;长期目标可以选择更为通用,技术挑战较大,业务效果好的方案(如异地多活)。
ü 为了确保方案的有效,需要定期进行演练
方案简介
两地三中心方案中,基于设定的短期目标可以明确同城双活和异地容灾的方案组合。
则设计重点为同城双活,即在同城的数据中心之间,一般通过高速光纤相连,在网络带宽有保障的前提下,网络延迟一般在可接受范围内,两个机房之间可以认为在同一个局域网内。
在设计上可以和应用层结合起来,有两种部署模式:分为应用层双活和数据库双活,应用层双活和数据库单活。
1)
.应用层双活和数据库单活方案:
应用层双活,数据库单活:两个机房的应用程序同时对外提供服务,但是只有一个机房的数据库提供读写,另外一个机房的应用程序需要跨机房访问数据库,数据库之间单向复制。该模式在网络延迟相对低的同城环境下表现良好,但是如果距离超过100 公里,机房之间的网络延迟就会超过2ms(或者更高),此时对于跨机房访问的数据库请求,性能有较大影响。
针对同城网络延迟低,可以看作是同一个局域网的特点,对于应用双活+数据库单活的方案,应用跨机房访问数据库,一旦某个机房故障,则将另外一个机房的应用访问请求切换到本机房的数据库,从而实现同城任何一个数据中心出现故障,都不会影响到整体业务的运行。
由于同城之间网络条件相对较好,MySQL 数据库原生的复制模式能够满足大部分业务场景,MySQL 5.7 推出的并行复制可以有效解决容灾机房日志回放慢的问题,在5.7.17推出的MGR/InnoDB Cluster则可以实现数据的强一致需求。
方案一:MGR集群多活架构
整个架构是基于分布式方案来设计,节点通信基于协议Paxos,MGR作为InnoDB Cluster的核心组件,目前支持单主模式和多主模式,本方案优先采用单主模式,节点数至少2-9个节点。
基于MGR的多活的设计方案如下,在数据库层通过优先在本机房的实例节点设置权重,优先切换到同机房,在同机房出现故障的情况下,切换到同城异机房。
以上方案的实施成本较低,对业务的侵入较少,适用于跨机房容灾的初级阶段的用户。
2) 应用层双活,数据库双活方案
应用层双活和数据库双活:两个机房的应用程序同时对外提供服务,两个机房的数据库也同时提供读写,每个机房的应用程序读写同一个机房内的数据库,两个数据库之间双向复制,通过一致性协议解决双向写冲突问题,该模式理论上实现了数据库多点写入,但是在实际跨机房场景中,尤其是在写冲突密集的业务场景下,性能下降非常大,不适用于跨机房的OLTP 系统。
而对于应用双活+数据库多活的方案,需要重点考虑数据延迟和数据同步的问题。首先需要在业务上做隔离,数据目标为最终一致性,目前存在如下的五类方案。
方案一:MGR集群多活架构
可以基于MGR的多活特性,数据的写入可以在多个节点之间进行复制,实现数据强一致性需求,并且在节点间通信出现延迟的情况下,会自动实现服务降级。
对于此类方案,我们可以采用同机房多写,同城异机房只读的方案。
方案二:分布式数据同步
基于分布式设计方案,可以引入数据组件syncer和writer,实现机房多活的业务需求,syncer和writer为数据的发布者和消费者,基于分布式协议进行处理。
在处理过程中有三类关键技术:
1)数据的处理基于分布式ID,能够唯一定位数据处理操作,并且该操作具备递增趋势。
2)同步组件的稳定性,同步组件可以理解为一种通用服务,需要考虑不同机房间的数据延迟和数据冲突处理机制,保证同步组件服务的稳定,高效。
3)同步组件的高可用,对于同步组件需要根据业务特点做权重处理,考虑不通IDC的业务情况,并重点考虑同步组件的数据冗余设计,保证发生异常时能够及时恢复数据。
此种方案短期内难以实现,但是长期来看,可以支持机房多活,业务价值更高。
方案三:双主模式的多活
对于数据库原生的双主模式,两个节点均可以写入数据,可以实现跨机房的数据复制,延迟较低,在业务层需要做隔离,在故障发生时能够快速切换到同机房的Slave节点。
此方案对于两个IDC机房的场景中较为实用,但是机房多活的场景不适合。
方案四:业务交叉的双活方案
此种方案是双活技术的变通实现,即存在两类业务A和B,数据存储在database级别(schema层级),分别在不通的IDC节点完成数据写入,比如业务A在IDC1完成写入,业务B在IDC2完成写入,两个节点之间存在跨机房的复制节点,在出现问题时,能够通过域名的方式切换到指定的IDC节点。
此种方案对于业务的依赖性较高,不适合机房多活的场景。
方案五:基于NewSQL的改造方案
可以参考行业内的NewSQL开源解决方案,原生支持MySQL协议。
比如PolarDB,Sequoia,TiDB等。
转自
杨建荣的学习笔记(jianrong-notes)
MySQL两地三中心方案初步设计 https://www.toutiao.com/i6720970848284443149/
MySQL两地三中心方案初步设计【转】的更多相关文章
- DTS搭载全新自研内核,突破两地三中心架构的关键技术|腾讯云数据库
随着企业规模的扩大,对数据库可用性要求越来越高,更多企业采用两地三中心.异地多活的架构,以提高数据库的异常事件应对能力. 在数据库领域,我们常听的"两地三中心"."异地多 ...
- MySQL冗余数据的三种方案
一,为什么要冗余数据 互联网数据量很大的业务场景,往往数据库需要进行水平切分来降低单库数据量. 水平切分会有一个patition key,通过patition key的查询能够直接定位到库,但是非pa ...
- .NET程序迁移到Mysql的极简方案——让GGTalk同时支持Sqlserver与mysql全程记录!
园子里的这个GGTalk,咱们前前后后用它移花接木做的IM项目也不下三四个了.初次入手的时候,洋洋代码,多少感觉有些难以把握.不过一来二去,理清了头绪,也就一览无余了.相信跟我们一样想要利用GGTal ...
- mysql cluster 安装配置方案
mysql cluster (mysql 集群)安装配置方案 一.准备 1.准备服务器 计划建立有5个节点的MySQL CLuster体系,需要用到5台服务器,但是我们做实验时没有这么多机器,可以 ...
- MySQL (三)-- 字段属性、索引、关系、范式、逆规范化
1 字段属性 主键.唯一键和自增长. 1.1 主键 主键:primary key,一张表中只能有一个字段可以使用对应的键,用来唯一的约束该字段里面的数据,不能重复. 一张表只能有最多一个主键. 1.1 ...
- SpringCloud(9)---mysql实现配置中心
mysql实现配置中心 本公司配置数据的管理是通过mysql进行配置管理,因为已经搭建好了,所以自己动手重新搭建一遍,熟悉整个流程.有关项目源码后期会补上github地址 微服务要实现集中管理微服务配 ...
- 优秀后端架构师必会知识:史上最全MySQL大表优化方案总结
本文原作者“ manong”,原创发表于segmentfault,原文链接:segmentfault.com/a/1190000006158186 1.引言 MySQL作为开源技术的代表作之一,是 ...
- mysql 分库分表 ~ 方案选择浅谈
一 简介:分库分表的理解二 具体: 1 当由于单台DB业务增长导致的服务器压力时,就必须横向进行扩展 2 本文仅从中间层观点进行分析三 现有方案 方案1 sharding家 ...
- MySQL 大表优化方案(长文)
当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型 ...
随机推荐
- php 加密
PHP 自带的加密解密函数 目前经常使用的加密函数有:md5(), sha1(), crypt(), base64_encode(), urlencode() .其中 md5(), sha1(), c ...
- QtCreator常用快捷键
1)帮助文件:F1 (光标在函数名字或类名上,按 F1 即可跳转到对应帮助文档,查看其详细用法) 2).h 文件和对应.cpp 文件切换:F4 3)编译并运行:Ctrl + R 4)函数声明和定义(函 ...
- 微博MySQL优化之路
数据库是所有架构中不可缺少的一环,一旦数据库出现性能问题,那对整个系统都回来带灾难性的后果.并且数据库一旦出现问题,由于数据库天生有状态(分主从)带数据(一般还不小),所以出问题之后的恢复时间一般不太 ...
- docker 基本常用操作做
docker 基本常用操作做(只列举入门常用的命令) 容器生命周期管理 docker run :创建一个新的容器并运行一个命令 -a stdin: 指定标准输入输出内容类型,可选 STDIN/STDO ...
- 小程序框架之视图层 View~事件系统~WXS响应事件
WXS响应事件 基础库 2.4.4 开始支持,低版本需做兼容处理. 背景 有频繁用户交互的效果在小程序上表现是比较卡顿的,例如页面有 2 个元素 A 和 B,用户在 A 上做 touchmove 手势 ...
- 2019-2020-1 20199301《Linux内核原理与分析》第五周作业
第四章·系统调用的三层机制(上) 本章的重点在于用户态程序如何触发系统调用? 一.用户.内核.中断 IntelX86有四种不同的执行级别.Linux操作系统中只采用了其中的0和3两个特权级别,分别对应 ...
- LG2664 树上游戏
树上游戏 题目描述 lrb有一棵树,树的每个节点有个颜色.给一个长度为n的颜色序列,定义s(i,j) 为i 到j 的颜色数量.以及 $$sum_i=\sum_{j=1}^ns(i,j)$$ 现在他想让 ...
- JS基础篇之作用域、执行上下文、this、闭包
前言:JS 的作用域.执行上下文.this.闭包是老生常谈的话题,也是新手比较懵懂的知识点.当然即便你作为老手,也未必真的能理解透彻这些概念. 一.作用域和执行上下文 作用域: js中的作用域是词法作 ...
- Oracle NVL 函数 nvl nvl2
Oracle中函数以前介绍的字符串处理,日期函数,数学函数,以及转换函数等等,还有一类函数是通用函数.主要有:NVL,NVL2,NULLIF,COALESCE,这几个函数用在各个类型上都可以. 下面简 ...
- 10分钟用Python爬取最近很火的复联4影评
欲直接下载代码文件,关注我们的公众号哦!查看历史消息即可! <复仇者联盟4:终局之战>已经上映快三个星期了,全球票房破24亿美元,国内票房破40亿人民币. 虽然现在热度逐渐下降,但是我们还 ...