系列3-常见的高可用MySQL解决方案

高可用主要解决两个问题,如何实现数据共享和同步数据、如何处理failover,数据共享的解决方案一般是SAN,数据同步通过rsync和drbd技术来实现。

1、主从复制解决方案

这是MySQL自身的高可用解决方案,数据同步方法采用的是MySQL replication技术。是一个日志的复制过程,复制过程中,一个服务器当作主服务器,1个或多个其他服务器充当从服务器。从服务器从主服务器拉取二进制文件,将日志文件解析成sql语句在从服务器上重新执行一遍主服务器的操作,通过这个方式可以保证数据的一致性。
MySQL replication 仅提供了日志同步执行功能,而从服务器只能提供读操作,主服务器故障时,比须通过手动来处理failover,将一台从服务器改成主服务器。

2、Heartbeat/SAN、DRBD高可用解决方案

借助第三方软硬件实现,通过SAN存储共享数据,正常情况下,集群主节点将挂载存储进行数据读写,当集群发生故障时,heartbeat首先通过一个冲裁设备将主节点挂载的存储设备释放,然后在备用节点上挂载存储 ,接着启动服务,通过这种方式可以实现数据共享和数据同步。
在数据共享方面,还可以采用基于块级别的数据同步软件DRBD来实现。DRBD即Distributed Replicated Block Device,是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。和SAN网络不同,它并不共享存储,而是通过服务器之间的网络复制数据。这种方案实现起来稍微复杂,同时也存在脑裂的问题。可以实现99.900%的SLA。
在这里插入图片描述

3、PXC集群解决方案

  • Percona XtraDB Cluster提供的特性有
    同步复制,事务要么在所有节点提交要么不提交
    多主复制,可以在任意节点进行写操作
    在从服务器上并行应用事件,真正意义上的并行复制
    节点自动配置
    数据一致性,不再是异步复制
  • 优点:
    执行查询在本地节点执行,所有数据都在本地,无需远程
    无需集中管理,可以在任何时间失去任何节点,集群正常工作
    良好的读负载扩展,任意节点都可以查询
  • 缺点
    加入新节点,开销大
    不能有效的解决写缩放问题
    有多少节点就有多少重复数据
    节点之间的复制仅支持InnoDB引擎
    所有表都有主键,锁冲突,死锁问题相对较多。
    分布式系统的CAP理论。
    C—一致性,所有节点的数据一致。
    A—可用性,一个或多个节点失效,不影响服务请求。
    P—分区容忍性,节点间的连接失效,仍然可以处理请求。
    MySQL Replication: 可用性和分区容忍性
    Percona XtraDB Cluster: 一致性和可用性
    因此MySQL Replication并不保证数据的一致性,而Percona XtraDB Cluster提供数据一致性。

4、MHA高可用解决方案

  • MHA优势如下:
    故障切换快
    master故障不会导致数据不一致
    无需修改当前的MySQL设置
    无性能下降
    适用于任何存储引擎
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值