返回IT运维网
  • |
  • 文章EID:
  • |
  • 账号:
  • 密码:
数据库跨机房问题解决方案基础解析
2012-05-10  chuanhui / 转载

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

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

相关评论 [查看所有评论]
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
心情:
  • 支持
  • 高兴
  • 枪稿
  • 不解
  • 搞笑
  • 愤怒
  • 谎言
账号: 密码:
验证码 看不清?点击更换
相关阅读