饿了么异地双活数据库实战
- -本文根据 GOPS2017·上海站演讲《饿了么异地双活数据库实战》整理发布. 虢国飞，饿了么 DBA负责人. 从事数据库行业10+年，专注于MySQL、PgSQL、MSSQL等数据库领域的管理、研究和平台的研发等工作，目前负责饿了么数据库团队的管理和数据库维护方面的工作. 我今天分享是饿了么在数据库和多活数据库这块的实战经历，供大家参考.
再谈异地双活容灾部署(6.24)
标签：
IT咨询
| 发表时间：2019-06-24 09:49 | 作者：人月神话
出处：http://blog.sina.com.cn/cmmi
对于数据库异地双活容灾部署在前面博客上也有文章谈到过，这篇文章做一些进一步的分析，对于异地双活容灾推荐阅读下网上的一篇文章，这篇文章介绍的比较全面，可以重点参考，本文配图也来源于该文。
数据库的双活设计
对于异地双活，前面我很多文章都已经谈到过，实际上最难的就是数据库如何保证双活，大部分的异地容灾方案数据库本身都是单活的，一个做为备份库。根据这篇文章我们可以看到，实际上在数据库层面分为三个层面。
1. 数据库单活：一个做为备份库，平时不工作，在出现问题再动态切换
2. 数据库写单活，读双活：只有主库可以写，但是两个数据中心的数据库都可以作为读库同时工作
3. 数据库双活：即表格里面谈到的Oracle ASM Extended
RAC方案，这个原来没怎么接触过
对于应用服务器的Cluster集群，实际要做到双活就比较简单，由于不存在数据持久化的问题，因此只需要搭配上层的全局负载均衡往往就容易实现上层应用服务器集群的双活配置。
而对于ESB服务总线中间件来说，和传统的业务系统本身有两点关键的区别，具体说明为
1. App Server应用服务器层，存在JMS消息中间件，这个存在在临时和持久化存储问题
2.
对于数据库层面，一个是ESB引擎数据库本身对ESB运行无大影响，一个ESB管控数据库仅存储日志信息
在原来我们谈SOA整体部署架构的时候，为了保证整个ESB总线的运行稳定性，实际上我们做了相应的验证，即对于ESB引擎数据库停机，实际上不影响到App
Server和ESB服务正常运行；或者对管控数据库停机，也不影响到服务正常运行，只是会出现日志数据出现丢失。
其次，对于ESB总线而言本身数据库压力不大，完全没有必要在数据库层面采用读写双活的设计方式，而对于管控平台而言，实际上使用最多的就是日志查询，异常查询几个功能，这几个功能可以单独定制为支撑读双活往往就能够满足需求。在数据库层面，最初我们的方案仍是采用类似GoldenGate进行单向的数据同步，确保在另外一个数据中心有一个完整的备库，以用于在数据中心出现问题后的数据库迁移。
那么接下来我们再看，如果不采用类似GG的数据库同步复制产品和技术，我们如何来做异地双活设计。初步考虑有如下几种方案可以选择。
方案1：在两个数据中心进行重复操作
即对于ESB服务的部署，服务授权，服务配置等操作，同时在两个数据中心操作，确保实际的服务部署，服务配置元数据能够同时入库到两个数据中心不同的数据库。即实际上两个数据中心最终提供的ESB服务完全是一致的和相同的，服务部署情况，服务授权情况也是完全相同的。
在这种方案里面涉及到我们流程申请和订购功能，涉及到服务运行实例功能无法重复操作，因此这些功能对应后的后台日志表，就需要我们晚上进行定时同步到备份数据中心。由于日志，流程实例非核心内数据，是可以容忍一天内的丢失情况。
方案2：后台每天进行定时数据复制
对于ESB服务的部署，实际上我们很难去做定时的数据复制来解决问题，因此服务部署仍然需要手工操作。而对于其他所有的管控配置操作等全部通过每天定时后台数据库表复制即可。该方案不使用类似GG进行实时同步复制，允许数据出现1天内丢失，但是不影响到实际的服务运行。
应用服务器集群的双活
当我们谈双活数据中心的时候，前面更多谈的数据库的部署和同步方案，既然是双活，那么APP
Server应用服务器就必须要做到能够同时工作。而对于应用服务器集群我们考虑的时候要注意，实际上在我们配置的时候，数据中心A和数据中心B两个集群都是操作数据中心A的数据库，否则就会出现数据库双向同步复制问题。
要做到应用集群双活，在前面文章方案已经谈到，必须在数据库中心A和B上面还有一个全局的负载均衡设备进行全局负载均衡，同时全局负载均衡设备本身还需要HA配置确保无单点故障。
而实际上双活架构部署的时候，对于数据中心B我们完全可以单独进行ESB中间件和管控软件的安装，同时将数据库中心A的数据库导出再导入恢复到数据中心B，确保初始一致性。在完成数据中心B本身的服务调用正常，管控访问正常后，我们在进行操作，将数据中心B的ESB服务集群，管控数据库连接配置修改为对应到数据中心A。
这个时候可以确保应用服务器全部处于工作状态，但是数据中心A出现故障后数据库连接需要手工切换。
那么这个时候更好的做法是在两个数据中心的数据库上层还有一个轻量的DaaS数据库服务提供层，即在DaaS层来提供可用的数据库服务连接，当发现数据中心A的数据库无法访问的时候，可以自动切换到数据中心B的数据库。同时DaaS层作为独立的应用也在两个数据中心进行部署，接入到上层的全局复制，确保没有单点故障。
如果没有DaaS层，那么出现故障手工切换，预计也就在5到10分钟能够完成数据中心的切换操作。
临时记录-待进一步思考
在数据中心单独安装一个ESB
Cluster集群，配置到数据中心B的ESB数据库，数据中心B的ESB库完全从A中心进行同步拷贝。然后对ESB集群的服务部署信息进行导出，导出后再数据中心B进行服务部署。完成后将数据中心B的集群数据库连接切换到数据中心A。
或者直接在数据中心B进行Cluster集群的扩展，即数据中心B不再有Admin管理节点，这种模式实际上涉及到Admin管理节点需要在两个数据中心做HA架构配置，暂时无法验证其可行性。
相关 [双活] 推荐：
异地多活（异地双活）实践经验 - CSDN博客
- -异地多活（异地双活）是最近业界讨论比较多的话题，特别是前一阵子支付宝机房光纤故障和携程网数据库丢失之后，更加唤起了技术人员们对异地容灾的考虑. 而异地多活比异地容灾更高一级，因为异地容灾仅仅是一个冷备的概念，而异地多活却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步.
异地双活的四个误区 - 旁观者 - 博客园
- -郑昀（老兵笔记） 20190305. 阿里云华北二机房2019年3月3日凌晨服务中断长达三小时，我在微博上喊出了：工程师赶紧起床，切多活流量啊. 多年前，大家往往做成了灾备机房，一主一备. 结果是，真正灾难发生的时候，最高领导人下不了决心切机房，因为无法预料切换后果（灾难总是不期而遇，切过去就可能切不回来了）.
再谈异地双活容灾部署(6.24)
- - 人月神话的BLOG对于数据库异地双活容灾部署在前面博客上也有文章谈到过，这篇文章做一些进一步的分析，对于异地双活容灾推荐阅读下网上的一篇文章，这篇文章介绍的比较全面，可以重点参考，本文配图也来源于该文. 文章链接： https://dbaplus.cn/news-21-646-1.html. 对于异地双活，前面我很多文章都已经谈到过，实际上最难的就是数据库如何保证双活，大部分的异地容灾方案数据库本身都是单活的，一个做为备份库.
配置双活网络切换技术 - ericnie - 博客园
- -因配置多数据中心的时候遇到如何进行生产以及备份的切换，阅读此文受益匪浅，转载保留. 应用级灾备要求提供冗余的网络线路和设备. 正常情况下，客户端通过生产中心的业务网络访问生产中心的应用服务器；在发生灾难时，通过网络切换，客户端能够访问到灾备中心的备用服务器. 目前，网络切换技术主要有以下三种：. 生产中心和灾备中心主备应用服务器的IP地址空间相同，客户端通过唯一的IP地址访问应用服务器.
oracle ogg goldengate 双活复制避免循环复制参数_ITPUB博客
- -我简单的简绍一下goldengate的一些实用的、常用的参数. 一、双向复制避免数据循环复制的参数. 首先说明一下循环复制，官网上的描述：. 意译：主端对数据的修改，被应用到了备端. 但是备端在执行这个主端传递过来的数据改变时，又被备端的extract 进程. 扑获到，并且又反给主端. 然后主端又给备端，这样形成了循环复制，会一直循环下去.
历经16年猪八戒网如何成功实现双活流量架构
- - DockOne.io猪八戒网随着业务访问量的直线增长，用户增长达到一定规模后，同时面临着高并发业务和海量数据的挑战，传统单机房在服务器容量上存在瓶颈，而且在一些不可预知场景下，导致整个网站出现故障，例如机房断电、火灾等这些不可抗拒因素都会导致所有服务器出现宕机从而导致业务瘫痪，即使有备份，恢复业务花费的时间也比较长. 所以公司根据实际业务情况选择了同城双活流量高可用架构，当然还有两地三中心、异地多活等方案.
Apache APISIX 在雪球双活架构演进中的生产与实践
- - 掘金 架构本文整理自雪球基础组件团队在 Apache APISIX Summit ASIA 2022 上的分享. 雪球的愿景是做「中国人首选的在线财富管理平台」，为投资者提供优质内容、实时行情、交易工具、财富管理等多种服务. 其中实时行情服务对接了多种上游数据源，通过数据流式计算、存储、分发，为投资者提供稳定的数据服务.
携程：上万坐席呼叫中心异地双活架构及系统设计
- - 运维派携程旅行网 通信技术中心高级经理. 拥有十几年的呼叫中心系统建设和运维管理经验，经历了携程呼叫中心系统架构的多次转型设计，使之从单一系统逐步演进到异地冗灾、异地双活，从单品牌到多平台的融合架构设计. 目前负责携程上万座席呼叫中心的产品管理和架构设计工作. 之前，我先拜读了《Google SRE》 这本书的几个章节，我对这些章节中的内容非常认同，特别是基于自动化运维以及故障响应时间的阐述，感同身受.
MySQL 双活同步复制的四种方案_咸鱼的梦想专栏-CSDN博客_mysql双机同步复制
- -对于数据实时同步，其核心是需要基于日志来实现，是可以实现准实时的数据同步，基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束. 基于MySQL原生复制主主同步方案 . 这是常见的方案，一般来说，中小型规模的时候，采用这种架构是最省事的. 两个节点可以采用简单的双主模式，并且使用专线连接，在master_A节点发生故障后，应用连接快速切换到master_B节点，反之也亦然.