zoukankan      html  css  js  c++  java
  • [转]跨机房问题

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

    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

  • 相关阅读:
    131. Palindrome Partitioning
    130. Surrounded Regions
    129. Sum Root to Leaf Numbers
    128. Longest Consecutive Sequence
    125. Valid Palindrome
    124. Binary Tree Maximum Path Sum
    122. Best Time to Buy and Sell Stock II
    121. Best Time to Buy and Sell Stock
    120. Triangle
    119. Pascal's Triangle II
  • 原文地址:https://www.cnblogs.com/cobbliu/p/4700441.html
Copyright © 2011-2022 走看看