[转]跨机房数据库同步问题解决方案

转载：http://blog.sina.com.cn/s/blog_73b41ab20102uy10.html

近期正在考虑多或问题，所有将相关文章收集下，自己思考的方案类似于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协议就能够保证不停写服务。

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

[转]跨机房数据库同步问题解决方案相关推荐

干货 | 五大实例详解，携程 Redis 跨机房双向同步实践
作者简介 Nick,携程软件技术专家,关注分布式数据存储以及操作系统内核. 前言在<携程 Redis 跨 IDC 多向同步实践>一文曾和大家分享过携程在 Redis 双向同步方面的心得, ...
跨系统实时同步数据解决方案
数据量太大,单存储节点存不下,就只能把数据分片存储. 数据分片后,对数据的查询就没那么自由.如订单表按用户ID作为Sharding Key,就只能按用户维度查询.我是商家,我想查我店铺的订单,做不到. ...
mysql同步数据到另一张表_mysql:Otter跨机房数据同步(单向)
重要说明:需要同步的表必须要有主键主键主键 otter是一款基于Java且免费.开源基于数据库增量日志解析,准实时同步到本机房或异地机房的mysql/oracle数据库的解决方案. Otter目前 ...
通过SQL Server 2008数据库复制实现数据库同步备份
通过SQL Server 2008数据库复制实现数据库同步备份原文通过SQL Server 2008数据库复制实现数据库同步备份 SQL Server 2008数据库复制是通过发布/订阅的机制进行 ...
SQL Server主从数据库同步方式及同步问题解决方案总结
SQL Server主从数据库同步方式及同步问题解决方案总结参考文章: (1)SQL Server主从数据库同步方式及同步问题解决方案总结 (2)https://www.cnblogs.com/zh ...
mysql跨服务器数据增量同步的解决方案
说明:由于本人的实际情况是不能修改线上对数据引擎的支持,并且只是为了同步部分表,因此没必要将两个库做主从,因此采用以下的方式进行解决对于跨服务器同步增量导数据的问题, 本可以使用: select * ...
sqlserver数据库同步软件_sqlserver同步工具_ 数据库同步解决方案
SyncNavigator v8.6.2 SyncNavigator是一款功能强大的数据库同步软件,适用于SQL SERVER, MySQL,具有自动/定时同步数据.无人值守.故障自动恢复.同构/异构 ...
pi数据库同步解决方案_MySQL数据库主主同步配置实战
最近云服务器大减价,趁机买了几台,博客就放在其中一台上,为了不让剩下的两台服务器闲置,打算都利用起来,对博客网站进行负载均衡.使用两台数据库进行主主同步配置,扩展网站数据库架构,提高数据库的读写性能. ...
SQL Server 跨网段（跨机房）复制
一.本文所涉及的内容(Contents) 本文所涉及的内容(Contents) 背景(Contexts) 解决方案(Solution) 搭建过程(Process) 注意事项(Attention) 参考 ...

[转]跨机房数据库同步问题解决方案

[转]跨机房数据库同步问题解决方案相关推荐

最新文章

热门文章