码迷,mamicode.com
首页 > 其他好文 > 详细

[转]跨机房问题

时间:2015-08-03 22:21:16      阅读:118      评论:0      收藏:0      [点我收藏+]

标签:

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

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宕机时(比如一分钟不通)将服务切换到备机房并报警。

本文转自日照博客:http://www.nosqlnotes.net/archives/232

[转]跨机房问题

标签:

原文地址:http://www.cnblogs.com/cobbliu/p/4700441.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!