MySQL 性能调优——高可用架构设计

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/smartbetter/article/details/93502395

高可用性(High Availability)指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间,以提高系统和应用的可用性。常见的高可用衡量指标有 5 个 9、4 个 9、3 个 9,例如 5 个 9 即 99.999%,意味着每年只能有 (365 * 24 * 60) * (1 - 0.99999) = 5.256 分钟不可用。高可用的指标需要结合业务和成本来选择。

如何实现高可用?

  • 避免导致系统不可用的因素(服务器磁盘空间耗尽、性能糟糕的SQL、表结构和索引没有优化、主从数据不一致、人为的操作失误等等),减少系统不可用的时间;
    • 建立完善的监控及报警系统;
    • 定时的对备份数据进行恢复测试;
    • 正确配置数据库环境;
    • 从服务器一定要配置成只读的,这样能减少很多因为主从不一致而出现的故障;
    • 对不需要的数据进行归档和清理;
  • 增加系统的冗余,保证发生系统不可用时可以尽快恢复;
    • 避免存储单点故障(单纯的主从复制架构并不能解决主库的单点问题);
    • 主从切换及故障转移;

如何避免 MySQL 单点故障?

  • 利用MySQL的主从复制来解决MySQL的单点问题;

如何解决 MySQL 库的单点故障?

  • 主库切换后,如何通知新的主服务器的IP地址?
  • 如何检查 MySQL 主库是否可用?
  • 如何处理从服务器和新主服务器之间的那种复制关系?

下面来看一下这些问题。

1.复制功能

复制功能解决来什么问题?

  • 实现了在不同服务器上的数据分布;
    • MySQL 的复制是利用二进制日志的增量进行的,不需要太多的带宽;
    • 如果是使用基于行的复制在进行大批量的更改时,会对带宽带来一定的压力;
  • 实现数据读取的负载均衡;
    • 需要其他组件配合完成,例如利用DNS轮询的方式把程序的读连接到不同的备份数据库;
  • 增加了数据的安全性;
    • 利用备库的备份来减少主库负载;
    • 复制并不能代替备份;
    • 备份的另一个作用是方便进行数据库高可用架构的部署,避免 MySQL 单点失败;
  • 实现数据库高可用和故障切换;
  • 实现数据库在线升级。

MySQL 复制功能提供分担读负载;

我们可以使用复制功能对数据库服务器进行水平扩展,为数据库增加一个或多个备库,用于分担主数据库的读负载,复制功能也为高可用、灾难恢复、备份提供来更多的选择。

MySQL 的复制是基于主库上的二进制日志,然后在备库上存放这些日志的方式来完成的。所以 MySQL 的复制是异步的。这也表明同一时间点,备库上的数据可能与主库存在不一致的问题。且无法保证主备之间的延迟。

附一:MySQL二进制日志

MySQL二进制日志
MySQL服务层日志
二进制日志
慢查日志
通用日志
记录了所有对MySQL数据库的修改事件,
包含增删改查事件和对表结构的修改事件
MySQL存储引擎层日志
Innodb
重做日志
回滚日志

MySQL 复制功能根据主库二进制数据格式可以分为:

MySQL复制
基于SQL语句的复制
二进制日志格式使用的是statement格式
基于行的复制
二进制日志格式使用的是基于行的日志格式
混合模式
根据实际内容在以上两种切换
复制 优点 缺点
基于SQL语句的复制 1、生成的日志量少,节约网络传输IO;
2、并不强制要求主从数据库的表定义完全相同;
3、相比于基于行的复制方式更为灵活;
1、对于非确定性事件,无法保证主从复制数据的一致性;
2、对于存储过程、触发器、自定义函数进行的修改也能造成数据不一致;
3、相比于基于行的复制方式在从库上执行时需要更多的行锁;
基于行的复制 1、可以应用于任何SQL的复制,包括非确定性函数、存储过程等;
2、可以减少从库上锁的使用;
1、要求主从数据库的表结构相同,否则可能会中断复制;
2、无法在从库上单独执行触发器;

综合考虑,建议大家使用基于行的复制,这种复制对主从数据库的一致性更加有保证。

MySQL 复制最容易出现性能的问题就是主从延迟的问题。影响主从延迟的因素有:

因素 解决方案
主库写入二进制日志的时间 控制主库的事务大小,分割大事务
二进制日志传输时间 (主->从) 可以使用MiXED日志格式
默认情况下从库只有一个SQL线程,主库上并发的修改在从库上变成了串行,最常见的因素 使用多线程复制 (MySQL 5.6及以上) ,在MySQL 5.7中可以按照逻辑时钟的方式来分配SQL线程

2.MMM架构

MMM(Multi-Master Replication Manager)是 MySQL 多组复制的简称,它是由 Perl 语言开发的用于管理 MySQL 主主同步架构的工具集。主要作用就是监控和管理 MySQL 的主主复制拓扑,并在当前的主服务器失效时,进行主和主备服务器之间的主从切换和故障转移等工作。

MMM 提供了什么功能?

  • 监控 MySQL 主从复制健康情况(MMM 架构同一时间只有一台主服务器对外提供服务,另外的主备服务器只能用于查询);
  • 在主库出现宕机时进行故障转移并自动配置其他从对新主的复制。
    • 如何找到从库对应的新的主库日志点的日志同步点?如果存在多个从库出现数据不一致的情况如何处理?MMM 对这一块的处理并不安全。MMM 只是简单粗暴的找到新的主库当前的日志点,然后使从库对这个日志点进行同步。在一个繁忙的系统中使用 MMM 很有可能造成数据丢失的情况。
  • 提供了一个写虚拟 IP 和多个读虚拟 IP,写虚拟 IP 只能在主数据库之间进行切换,读虚拟 IP 则可以在服务器所有主从节点进行切换。在主从服务器出现问题时可以自动迁移虚拟 IP。

MMM 架构图:

MMM 架构图

MMM 部署所需资源:

资源名称 数量 说明
主DB服务器 2 用于主备模式的主主复制配置
从DB服务器 0-N 可以配置0台或多台服务器,但不建议太多
监控服务器 1 用于监控MySQL复制集群
IP地址 2 * (N+1) N为MySQL服务器的数量
监控用户 1 用于监控数据库状态的MySQL用户(replication client)
代理用户 1 用于MMM代理的MySQL用户(super, replication client, process)
复制用户 1 用于配置MySQL复制的MySQL用户(replication slave)

MMM 架构优点:

  • 使用Perl脚本语言开发及完全开源;
  • 提供了读写 VIP (虚拟IP),使服务器角色的变更对前端应用透明;
  • 提供了对从服务器的延迟监控;
  • 提供了主数据库故障转移后,从服务器对新主服务器的重新同步功能;
  • 很容易对发生故障的主数据库重新上线;

MMM 架构缺点:

  • 发布时间比较早,不支持 MySQL 新的复制功能;
  • 在进行主从切换时,容易造成数据丢失;
  • MMM监控服务存在单点故障;
  • 没有读负载均衡的功能。

3.MHA架构

MHA(Master High Availability)也是由 Perl 语言开发的,在 MySQL 高可用方面是一个相对成熟的解决方案。

MHA 完成主从切换超高效,基本上在 30 秒内完成主从切换,并且在切换过程中最大程度的保证数据一致性。达到真正意义上的高可用。

MHA 提供了什么功能?

  • 监控主数据库服务器是否可用;
  • 当主DB不可用时,MHA可以从多个从服务器中选举出一个新的主数据库服务器;
  • 提供了主从切换和故障转移功能;

MHA 是如何进行主从切换的?

  1. 尝试从出现故障的主数据库中保存二进制日志(与MMM最大的不同,这一步不是总能成功的,当主数据库硬件本身无法访问时,则不能成功保存二进制日志);
  2. 从多个可用的从服务器中识别出含有最新更新的那个从服务器,并把这个从服务器作为新的备选主服务器;
  3. 在备选主服务器和其他从服务器之间同步差异二进制数据;
  4. 新的备选主服务器会存放从原主服务器上保存下来的二进制日志(前提是保存下来了,这一步如果出现错误,例如重复的主键等,会使MHA停止进行故障转移);
  5. 提升备选主服务器作为新的主服务器;
  6. 迁移集群中其他的从服务器作为新的主服务器的从服务器。

MHA 架构图:

MHA 架构图

MHA 支持 GTID 的复制,而 MMM 不支持,GTID 也是安全性比较高的一种复制模式,配合 MHA 使用也是更加的合理。

MHA 配置步骤:

  1. 配置集群内所有主机的 SSH 免认证登陆(比如故障转移过程中保存原主服务器二进制日志,配置虚拟IP地址等);
  2. 所有 DB 服务器安装 MHA-node软件包,监控服务器安装 MHA-manager 软件包;
  3. 建立主从复制集群(MHA支持基于日志点的复制和基于GTID的复制,这里推荐使用基于GTID的复制);
  4. 配置 MHA 管理节点;
  5. 使用 masterha_check_ssh 和 masterha_check_repl 对配置进行检验;
  6. 启动并测试 MHA 服务。

MHA 架构优点:

  • 使用Perl脚本语言开发及完全开源;
  • 可以支持基于 GTID 的复制模式;
  • MHA 在进行故障转移时更不易产生数据丢失;
  • 同一个监控节点可以监控多个集群;

MHA 架构缺点:

  • MHA 的配置中没有主从 VIP 的配置,需要编写脚本或利用第三方工具来实现 VIP 的配置;
  • MHA 启动后只会对主数据库进行监控,无法发现复制链路中的问题(例如主从延迟增大,复制链路中断等);
  • 需要基于 SSH 免认证配置,存在一定的安全隐患;
  • 没有读负载均衡的功能。

4.读写分离和负载均衡

为什么要读写分离?

写负载是不能够分担的,而且只能在主库上进行写操作。读操作主从上都可以。为了分担主库的读负载,就需要进行读写分离,写操作只能在主库上进行,而读操作尽量的在从库上完成。

读写分离
而完成读写分离后,对于读操作,如何分配多个服务器的读操作,这就需要我们进行读的负载均衡了。

目前实现读写分离有两种方式:

  • 由程序实现读写分离;
  • 由中间件实现读写分离,例如 mysql-proxy(高并发下存在一定的问题)、maxScale(相对来说性能损耗小);
- 优点 缺点
由程序实现读写分离 1、由开发人员控制什么样的查询在从库中执行,比较灵活;
2、由程序直接连接数据,性能损耗比较少;
3、架构简单;
1、增加了开发的工作量,使程序代码更加复杂;
2、人为控制,容易出现错误;
由中间件实现读写分离 1、由中间件根据查询语法分析,自动完成读写分离;
2、对程序透明,对于已有程序不用做任何调整;
1、由于增加了中间层,所以对查询性能有损耗(经测试,QPS可能降低50%-70%);
2、对于延迟敏感的业务,无法自动在主库执行,不灵活;
展开阅读全文

没有更多推荐了,返回首页