MySQL读书学习笔记（十）——高可用性

10.1 概念

它通常以百分比表示：表明它不是绝对的，只有相对更高的可用性。100%的可用性是不可能达到的。可用性的“9”规则是表示可用性目标最普遍的方法。“5个9”表示99.999%的正常可用时间。换句话说，每年只允许5min的宕机时间。

10.2 宕机原因

最运行环境中，最普遍的原因是磁盘空间耗尽。

在性能问题中，最普遍的原因是运行了糟糕的SQL，但也不一定全是如此，有可能是服务器bug或错误的行为。

第二大影响性能的因素是糟糕的Schema和索引设计。

复制问题通常是因为主备数据不一致。

数据丢失问题通常是由于DROP TABLE误操作，并伴随缺少可用备份。

10.3 实现高可用性

首先，可以尝试避免导致宕机的原因来减少宕机时间。第二，尽量保证发生宕机时能尽快恢复。最常见的策略是在系统中制造冗余，并且具备故障转移能力。这两个维度的高可用性可以通过两个相关的度量来确定：平均失效时间和平均恢复时间。

10.4 避免单点失效

找到并消除系统中可能失效的单点，并结合切换到备用组件的机制，这是一种通过减少恢复时间来改善可用性的方法。

10.4.1 共享存储或磁盘复制

共享存储能够为数据库服务器和存储解耦合，通常使用的是SAN。使用共享存储时，服务器能够正常挂载文件系统并进行操作。如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，并在失效服务器的数据上启动MySQL。这个过程在逻辑上跟修复那台故障的服务器没什么两样，不过更快速，因为备用服务器已经启动，随时可以运行。当开始故障转移时，检查文件系统、恢复InnoDB以及预热是最有可能遇到延迟的地方，但检测失效本身在许多设置中也会花费很长时间。

磁盘复制技术是另外一个获得跟SAN类型效果的方法。MySQL中最普遍使用的磁盘复制技术是DRBD，并结合Linux-HA项目中的工具使用。

10.4.2 同步复制

当使用同步复制时，主库上的事务只有在至少一个备库上提交后才能认为其执行完成。这实现了两个目标：当服务器崩溃时没有提交的事务会丢失，并且至少有一个备库拥有实时的数据副本。大多数同步复制架构运行在主动-主动模式。这意味着每个服务器在任何时候都是故障转移的候选者，这使得通过冗余获得高可用性更加容易。

10.4.3 基于复制的冗余

复制管理器是使用标准MySQL复制来创建冗余的工具。尽管可以通过复制来改善可用性，但也有一些“玻璃天花板”当前版本的异步复制和半同步复制获得和真正的同步复制相同的结果。复制无法保证实时的故障转移和数据零丢失，也无法将所有节点等同对待。

10.5 故障转移和故障恢复

冗余是很好的技术，但实际上只有在遇到故障需要恢复才会用到。冗余一点也不会增加可用性和减少宕机。在故障转移的过程中，高可用性是建立在冗余的基础上。当有一个组件失效，但存在冗余时，可以停止使用发生故障的组件，而使用冗余组件。冗余和故障转移结合可以帮助更快的恢复。

10.5.1 提升备库或切换角色

提升一台备库作为主库，或者在一个主-主结构中调换主动或被动角色，这些都是许多MySQL故障转移策略很重要的一部分。

10.5.2 虚拟IP地址或IP接管

可以为需要提供特定服务的MySQL实例指定一个逻辑IP地址。当MySQL实例失效时，可以将IP地址转移到另一台MySQL服务器上。这和负载均衡类似。

10.5.3 中间件解决方案

可以使用代理、端口转发、网络地址转换或者硬件负载均衡来实现故障转移和故障恢复。这些都是很好的解决方案，不像其他方法可能会引入一些不确定性，它们是控制应用和服务器间连接的中枢。但是，它们自身也引入了单点失效，需要准备冗余来避免这个问题。

10.5.4 在应用中处理故障转移

有时候让应用来处理会更加简单和灵活。