什么是高可用性
- 高可用性是相对的没有100%的高可用只有尽可能接近100%。
- 可用性每提高一点，所花费的成本都会远超之前，可用性的效果和开销的比例并不是线性的。
宕(dang)机的原因
-
运行环境问题，最普遍的是磁盘空间耗尽。
-
性能问题，最普遍的是运行糟糕的SQL，或服务器BUG或错误的行为。
-
表和索引设计有问题。
-
复制问题通常由于主备数据不一致导致。
-
数据丢失通常由于DROP TABLE的误操作导致，并总是伴随着缺少可用备份的问题。
如何实现高可用性
-
避免导致宕机的原因来减少宕机时间
-
尽量保证在发生宕机时能够快速恢复
1.提升平均失效时间（MTBF）
- 测试恢复工具和流程包括从备份中恢复数据。
- 遵从最小权限原则。
- 保持系统干净、整洁。
- 用好的命名和组织约定来避免产生混乱,例如服务器是用于开发还是用于生产环境。
- 安排升级数据库服务器。在升级前,使用诸如PerconaToolkit中的pt-upgrade之类的工具仔细检查。
- 系统使用INNODB并进行适当的配置,确保INNODB是默认存储引擎。如果存储引擎被禁止,服务器就无法启动。
- 确认基本的服务器配置是正确的。
- 通过skip_name_resolve禁止DNS。
- 除非能证明有效,否则禁用查询缓存。
- 避免使用复杂的特性,例如复制过滤和触发器,除非确实需要。
- 监控重要的组件和功能,特别是像磁盘空间和RAID卷状态这样的关键项目,但也要避免误报,只有当确实发生问题时才发送告警。
- 尽量记录服务器的状态和性能指数,如果可能就尽量久地保存。
- 定期检查复制完整性。
- 将备库设置为只读,不要让复制自动启动。
- 定期进行查询语句审查。归档并清理不需要的数据。
- 为文件系统保留一些空间。在GNU/Linx中,可以使用-m选项来为文件系统本身保留空间。还可以在LVM卷组中留下一些空闲空间。或者,更简单的方法,仅仅创建一个巨大的空文件,在文件系统快满时,直接将其删除。
- 养成习惯,评估和管理系统的改变、状态以及性能信息。
2.降低平均恢复时间（MTTR）
- 所有的宕机事件都是由多方面的失效联合在一起导致的，可以通过利用合适的方法比如主备结构确保单点的安全。
避免单点失效
找到并消除系统中可能失效的单点，并结合切换到备用组件的机制，这是一种通过减少恢复时间来改善可用性的方法。
- 共享存储或磁盘复制
共享存储能够为数据库服务器和存储解耦合，通常使用的是SAN。使用共享存储时，服务器能够正常挂载文件系统并进行操作。如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，并在失效服务器的数据上启动MySQL。这个过程在逻辑上跟修复那台故障的服务器没什么两样，不过更快速，因为备用服务器已经启动，随时可以运行。当开始故障转移时，检查文件系统、恢复InnoDB以及预热是最有可能遇到延迟的地方，但检测失效本身在许多设置中也会花费很长时间。
磁盘复制技术是另外一个获得跟SAN类型效果的方法。MySQL中最普遍使用的磁盘复制技术是DRBD，并结合Linux-HA项目中的工具使用。
- 同步复制
当使用同步复制时，主库上的事务只有在至少一个备库上提交后才能认为其执行完成。这实现了两个目标：当服务器崩溃时没有提交的事务会丢失，并且至少有一个备库拥有实时的数据副本。大多数同步复制架构运行在主动-主动模式。这意味着每个服务器在任何时候都是故障转移的候选者，这使得通过冗余获得高可用性更加容易。
- 基于复制的冗余
复制管理器是使用标准MySQL复制来创建冗余的工具。尽管可以通过复制来改善可用性，但也有一些“玻璃天花板”当前版本的异步复制和半同步复制获得和真正的同步复制相同的结果。复制无法保证实时的故障转移和数据零丢失，也无法将所有节点等同对待。
故障转移和故障恢复
在故障转移的过程中，高可用性是建立在冗余的基础上。当有一个组件失效，但存在冗余时，可以停止使用发生故障的组件，而使用冗余组件。冗余和故障转移结合可以帮助更快的恢复。
- 提升备库或切换角色
提升一台备库作为主库，或者在一个主-主结构中调换主动或被动角色。 - 虚拟IP地址或IP接管
可以为需要提供特定服务的MySQL实例指定一个逻辑IP地址。当MySQL实例失效时，可以将IP地址转移到另一台MySQL服务器上。这和负载均衡类似。 - 中间件解决方案
可以使用代理、端口转发、网络地址转换或者硬件负载均衡来实现故障转移和故障恢复。这些都是很好的解决方案，不像其他方法可能会引入一些不确定性，它们是控制应用和服务器间连接的中枢。但是，它们自身也引入了单点失效，需要准备冗余来避免这个问题。 - 在应用中处理
当应用判断mysql失效自动转到另一台。