数据库跨机房问题解决措施
发布时间：2021-06-26 17:13:22 所属栏目：大数据 来源：互联网
导读：跨机房问题一直都是一个老大难的问题，先看传统 数据库 的跨机房方案。 Master/Slave方案 这是最常用的方案，适用于大多数需求。Master将操作日志实时地发送到Slave，Slave当成Master的一个Hot Backup。Master宕机时，服务切换到Slave，需要修改客户端逻辑使
|
跨机房问题一直都是一个老大难的问题，先看传统数据库的跨机房方案。 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协议就能够保证不停写服务。 （编辑：宿州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
