[转]跨机房数据库同步问题解决方案
[转]跨机房数据库同步问题解决⽅案
近期正在考虑多或问题，所有将相关⽂章收集下，⾃⼰思考的⽅案类似于Google的Megastore，确实过于复杂导致短时间⽆法商⽤，也不敢实际推。
北京著名景点
跨机房问题⼀直都是⼀个⽼⼤难的问题，先看传统数据库的跨机房⽅案。
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协议就能够保证不停写服务。
arctanx的图像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宕机时(⽐如⼀分钟不通)将服务切换到备机房并报警。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。