1. 什么是高可用性
- 通常情况下人们将可用性定义为服务正在运行的时间，但最好还包括应用是否能以足够好的性能处理请求。
2. 导致宕机的原因
- 导致宕机的原因一般有：运行环境、性能问题、复制、数据丢失与损坏等。
- 在运行环境中，最普遍的问题是磁盘空间耗尽。
- 在性能问题中，最普遍的确实是运行很糟糕的 SQL。
- 糟糕的 Schema 和索引设计是第二大影响性能的问题
- 复制问题通常由于主备数据不一致导致
- 数据丢失问题通常由于
DROP TABLE的误操作导致，并总是伴随着缺少可用备份的问题
3. 如何实现高可用性
- 可以通过两步来获得高可用性。第一尝试避免导致宕机的原因来减小宕机时间，称之为提高平均失效时间(MTBF)。第二可以尽量保证在发生宕机时能够快速恢复，我们称之为降低平均恢复时间(MTTR)。
4. 避免单点失效
- 找到并消除系统中可能失效的单点，并结合切换到备用组件的机制，这是一种通过减小恢复时间(MTTR)来改善可用性的办法。可以通过增加空余容量和重复组件两种方法为系统增加冗余。
共享存储和磁盘复制
-
共享存储
- 共享存储能够为数据库服务器和存储解耦，通常使用 SAN。
- 共享存储有两个优点：可以避免除存储外的其他任何组件失效所引起的数据丢失，并为非存储组件建立冗余提供可能。
- 强烈建议在使用共享存储策略时选择 InnoDB 存储引擎或其他文档的 ACID 存储引擎，也强烈建议使用日志型文件系统。
-
磁盘复制技术
- MySQL 中最普遍使用的磁盘复制工具是DBRB。DBRBs 是一个以 Linux 内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另一个服务器的块设备上，并在主设备提交块之前记录下来。由于在备用 DRDB 设备上的写入必须要在主设备上的写入完成之前，因此备用设备的性能至少要和主设备一样，否则就会限制主设备的写入性能。带电池写缓存的的 RAID 控制器对 DRBD 而言几乎是必需的，否则性能将会很差。
- DRBD 是复制存储而不是共享存储，所以使用 DRBD 获得的是一份冗余的数据。
- DRBD 可以避免"脑裂综合征"，即两个节点同时提示自己为主服务器。但是 DRBD 也有一部分缺点：DRBD 的故障转移无法做到秒级以内、代价比较昂贵、无法替代备份、增加写操作负担等。
- 倾向于只使用 DRBD 复制存放二进制日志的设备。
MySQL 同步复制
- 当使用同步复制时，主库的事务只有在至少一个备库上提交后才能认为其执行完成。大多数同步架构运行在主动-主动模式。
- MySQL 本身不支持同步复制，但是有两个基于 MySQL 的集群解决方案支持同步复制，分别为：MySQL Cluster和Percona XtraDB Cluster。他们都提供同步多主库复制，支持在任意节点写入，每一行都是冗余存储，能够在节点失效时保证数据零丢失。
基于复制的冗余
- 复制管理器是使用标准 MySQL 复制来创建冗余的工具。它通常监控和管理三件事：应用和 MySQL 间的通信、MySQL 服务器的健康度以及 MySQL 服务器间的复制关系。
5. 故障转移和故障恢复
提升备库或切换角色
- 提升一台备库为主库，或者在一个主-主复制结构中调换主动和被动角色，是许多 MySQL 故障转移策略很重要的部分。
虚拟 IP 地址或 IP 接管
- 可以为需要提供服务的 MySQL 服务器指定一个逻辑 IP 地址。当 MySQL 实例失效时，将 IP 地址转移到另一台 MySQL 服务器上去。
中间件解决方案
- 可以使用代理、端口转发、网络地址转换(NAT)或者硬件负载均衡来实现故障转移和故障恢复。但是这些措施自身也引入了单点失效，需要准备冗余来避免单点问题。