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