首页 首页 大数据 查看内容

数据库跨机房问题解决方案

木马童年 2019-5-17 12:10 3 0

跨机房问题一直都是一个老大难的问题,先看传统数据库的跨机房方案。 Master/Slave方案 这是最常用的方案,适用于大多数需求。Master将操作日志实时地发送到Slave,Slave当成Master的一个Hot Backup。Master宕机时, ...

跨机房问题一直都是一个老大难的问题,先看传统数据库的跨机房方案。

Master/Slave方案

这是最常用的方案,适用于大多数需求。Master将操作日志实时地发送到Slave,Slave当成Master的一个Hot Backup。Master宕机时,服务切换到Slave,需要修改客户端逻辑使得Master失效时自动寻找新的Master。

这个方案有一个问题就是数据库的Master和Slave一般不是强同步的,所以,切换到Slave后可能丢失宕机前的少量更新。如果将Master和Slave做成强同步的,即:所有的数据必须同时写成功Master和Slave才成功返回客户端,这样又带来了另外一个问题:Master和Slave中任何一台机器宕机都不允许写服务,可用性太差。因此,Oracle有一种折衷的模式:正常情况下Master和Slave是强同步的,当Master检测到Slave故障,比如Slave宕机或者Master与Slave之间网络不通时,Master本地写成功就返回客户端。采用这种折衷的同步模式后,一般情况下Master和Slave之间是强同步的,Master宕机后切换到Slave是安全的。当然,为了确保数据安全后,宕机的Master重启后可以和新的Master(原有的Slave)对比最后更新的操作日志,如果发现不一致可以提醒DBA手工介入,执行数据订正过程。

Master和Slave之间强同步还有一个问题就是跨机房延时,对于关键业务,同城的机房可以部署专用光纤,在硬件层面上解决这个问题;异地的机房一般用来做备份,与主机房之间的数据同步一般是异步的,可能有秒级延时。

Bigtable跨机房方案

Bigtable跨机房部署两套集群,每个机房有各自的GFS存储和Bigtable Master。机房之间的数据同步方式为异步,类似Master/Slave方案。Bigtable Tablet Server将操作日志Flush到GFS成功后返回客户端,并生成异步任务将操作日志同步到备机房。这里的难点在于Tablet Server宕机时,某些操作日志还没有完成同步,因此,操作日志同步点也需要记录到GFS中,当其它Tablet Server加载宕机Tablet Server原先服务的tablet时,将继续发送没有同步完成的操作日志到备机房。如果主机房整体发生故障,比如机房停电,可以手工将服务切换到备机房,这时会丢失最后的一部分更新操作,需要人工执行订正操作。

Bigtable跨机房方案还有一个问题,为了提高压缩率,Bigtable跨机房的同步是按列进行的,而Bigtable保证行事务,这样就可能出现某些行的部分列同步成功,部分列同步失败,破坏行事务。早期的Google App Engine底层存储为Bigtable,这个问题没有给出自动化的解决方案。

Megastore跨机房方案(基于Paxos)

一般来说,实际中使用的方案都是Master/Slave方案,Megastore中基于Paxos的方案理论上是目前最优的,但是实现过于复杂,只有Google在工程上做了实现。Master/Slave方案的问题在于Master宕机时切换到Slave需要时间,为了保证不会同时出现两个Master的情况,这个时间一般比较长,比如30s ~ 1分钟,而且不能做到自动化。Paxos的好处在于允许多个机房同时做Master,同时提供写服务,Paxos协议将通过Quorum-Based的策略保证达成一致。一般情况下,主机房作为Paxos协议的Leader提供写服务,当Leader发生故障时,备机房的节点可以被选为新的Leader提供写服务。即使多个机房认为自己是Leader,Paxos协议也能保证同一时刻只有一个Leader的写操作被大家同意并生效,并且做到了宕机切换的自动化。只要超过一半的机房没有出现故障,Paxos协议就能够保证不停写服务。

Google App Engine目前依赖于Google Megastore,解决了机房宕机可能破坏行事务的问题。Amazon Dynamo也给出了一种Vector Clock的做法解决多点同时写入的问题,这是一种事后验证的做法,理论上很有意思,但由于弱一致性,实践上没有特别成功的案例。

需要注意的是,Megastore中的复制方案在理论上很完美,但实现过于复杂,基本没有可行性。另外,无论采用怎样的跨机房同步和切换方案,都不能解决强同步写操作延时较长的问题,一般来说,这个延时将达到几十到几百毫秒。

一种回避Paxos的切换方案

选主一般可以通过引入开源的Zookeeper做到,不过Zookeeper本身的稳定性尚待考验,有一种回避Paxos的切换方案比较有意思。机房宕机切换自动化成本太高,但是对于很多单点服务,机房内部宕机切换的自动化很有必要。Oceanbase采用Linux的一个开源方案:Pacemaker,通过heartbeat和虚IP漂移的方式实现机房内部宕机自动切换。由于主备切换本质上是一个选主问题,理论上只有Paxos或者类似协议可以解决,而Pacemaker没有采用复杂的Paxos协议,它对硬件是有依赖的,比如要求主备节点之间通过直连线保证网络不会发生故障,而这在机房内部是可以做到的。机房之间采用前面提到的Master/Slave方案,可以写一个脚本ping主机房的Master,当确认主机房Master宕机时(比如一分钟不通)将服务切换到备机房并报警。

在不久的将来,多智时代一定会彻底走入我们的生活,有兴趣入行未来前沿产业的朋友,可以收藏多智时代,及时获取人工智能、大数据、云计算和物联网的前沿资讯和基础知识,让我们一起携手,引领人工智能的未来!

数据库 数据安全 数据同步 解决方案
0
为您推荐
大数据技术改变城市的运作方式,智慧城市呼之欲出

大数据技术改变城市的运作方式,智慧城市呼

纽奥良虽像大多数城市一样有火灾侦测器安装计划,但直到最近还是要由市民主动申装。纽…...

大数据分析面临生死边缘,未来之路怎么走?

大数据分析面临生死边缘,未来之路怎么走?

大数据分析开始朝着营销落地,尤其像数果智能这类服务于企业的大数据分析供应商,不仅…...

什么是工业大数据,要通过3B和3C来理解?

什么是工业大数据,要通过3B和3C来理解?

核心提示:工业视角的转变如果说前三次工业革命分别从机械化、规模化、标准化、和自动…...

大数据普及为什么说肥了芯片厂商?

大数据普及为什么说肥了芯片厂商?

科技界默默无闻的存在,芯片行业年规模增长到了3520亿美元。半导体给无人驾驶汽车带来…...

大数据技术有哪些,为什么说云计算能力是大数据的根本!

大数据技术有哪些,为什么说云计算能力是大

历史规律告诉我们,任何一次大型技术革命,早期人们总是高估它的影响,会有一轮一轮的…...

个人征信牌照推迟落地,大数据 重新定义个人信用!!

个人征信牌照推迟落地,大数据 重新定义个

为金融学的基础正日益坚实。通过互联网大数据精准记录海量个人行为,进而形成分析结论…...