MySQL之高可用性(三)

高可用性

MySQL同步复制

当使用同步复制时，主库上的事务只有在至少一个备库上提交后才能认为其执行完成。这实现了两个目标:当服务器崩溃时没有提交的事务会丢失，并且至少有一个备库拥有实时的数据副本。大多数同步复制架构运行在主动——主动模式。这意味着每个服务器在任何时候都是故障转移的候选者，这使得通过冗余关于获得高可用性更加容易，早期版本的MySQL不支持同步复制(MySQL5.5支持半同步复制)，还有两个基于MySQL的集群解决方案支持同步复制。

1.MySQL Cluster

MySQL中的同步复制首先出现在MySQL Cluster(NDB Cluster)。它在所有节点上进行同步的主——主复制。这意味着可以在任何节点上写入;这些节点拥有等同的读写能力。每一行都是冗余存储的，这样即使丢失了一个节点，也不会丢失数据，并且集群仍然能提供服务。尽管MySQL Cluster还不是是哟个与所有应用的完美解决方案，但正如我们在前面提到的，在最近的版本中它做了非常快速的改进，现在已经拥有了大量的新特性和功能:非索引数据的磁盘存储、增加数据节点能够在线扩展、使用ndbinfo表来管理集群、配置和管理集群的脚本、多线程操作、下推(push-down)的关联操作(现在称为自适应查询本地化)、能够处理BLOB列和很多列的表、集中式的用户管理，以及通过像memcached协议一样的NDB API来实现NoSQL访问。在下一个版本中将包含最终一致运行模式，包括为跨数据中心的主动-主动复制提供事务冲突检测和跨WAN解决方案。简而言之，MySQL Cluster是一项引人注目的技术。
现在至少有两个为简化集群部署和管理提供附加产品的供应商:Oracle针对MySQL Cluster的服务支持包含了MySQL Cluster Manager工具;Severalnines提供了Cluster Control工具，该工具还能够帮助部署和管理复制集群

2.Percona XtraDB Cluster

Percona XtraDB Cluster是一个相对比较新的技术，基于已有的XtraDB(InnoDB)存储引擎增加了同步复制和集群特性，而不是通过一个新的存储引擎或外部服务器来实现。它是基于Galera(支持在集群中跨节点复制写操作)实现的(Galera技术由Codership Oy开发，可以作为一个补丁在标准的MySQL和InnoDB中使用。Percona XtraDB Cluster除了其他特性和功能外，还包含这组补丁的修改版本，Percona XtraDB Cluster是一个可以直接使用的基于Galera的解决方案。)这是在一个集群中不同节点复制写操作的库。跟MySQL Cluster类似，Percona XtraDB Cluster提供同步多主库复制(你可以通过配置主备只写入其中一个节点来实现，但在集群配置中，对于这种模式的操作没有什么不同)支持真正的任意节点写入能力，能够在节点失效时保证数据零丢失(持久性，ACID中的D),另外还提供高可用性，在整个集群没有失效的情况下，就算单个节点失效也没有关系。
Galera作为底层技术，使用一种被称为写入集合(write-set)复制的技术。写入集合实际上被作为基于行的二进制日志时间进行编码，目的是在集群中的节点间传输并进行更新，但是这不要求二进制日志是打开的。
Percona XtraDB Cluster的速度很快。跨节点复制实际上比没有集群还要快，因为在完全持久性模式下，写入远程RAM比写入本地磁盘要快。如果你源异，可以选择通过降低每个节点的持久性来获得更好的性能，并且可以依赖于多个节点上的数据副本来获得持久性。NDB也是基于同样的原理实现的。集群在整体上的持久性并没有降低;仅仅是降低了本地节点的持久性。除此之外，还支持行级别的并发(多线程)复制，这样就可以利用多个CPU核心来执行写入集合。这些特性结合起来是的Percona XtraDB Cluster非常适合云计算环境，因为云计算环境中的CPU和磁盘通常比较慢。
在集群中通过设置auto_increment_offset和auto_increment_increment来实现自增键，以使节点间不会生成冲突的主键值。锁机制和标准InnoDB完全相同，使用的是乐观并发控制。当事务提交时，所有的更新是序列化的，并在节点间传输，同时还有一个检测过程，以保证一旦发生更新冲突，其中一些更新操作需要丢弃。这样如果许多节点同时修改同样的数据，可能产生大量的死锁和回滚。
Percona XtraDB Cluster只要集群内在线的节点数不少于"法定人数(quorum)“就能保证服务的高可用性。如果发现某个节点不属于"法定人数"中的医院，就会从集群中将其踢出。被踢出的节点在再次加入集群前必需重新同步。因此集群也无法处理"脑裂综合征”；如果出现脑裂则集群会停止服务。在一个只有两个节点的集群中，如果其中一个节点失效，剩下的一个节点达不到"法定认数"。集群将停止服务，所以实际上最少需要三个节点才能实现高可用的集群。

Percona XtraDB Cluster优缺点

优点

• 1.提供基于InnoDB的透明集群，所以无须转换到另外的技术，例如NDB这样完全不同的技术需要很多学习成本和管理
• 2.提供了真正的高可用性，所有节点等效，并在任何时候提供读写服务。相比较而言，MySQL内建的异步复制和半同步复制必须要有一个主库，并且不能保证数据被复制道备库，也无法保证备库数据是最新的并能够随时提升为族库
• 3.节点失效时保证数据不丢失。实际上，由于所有的节点都拥有全部数据，因此可以丢失任一个节点而不会丢失数据(即使集群出现脑裂并停止工作)。这和NDB不同，NDB通过节点组进行分区，当在一个节点组中的所有服务器失效时就可能丢失数据。
• 4.备库不会延迟，因为在事务提交前，写入集合已经在集群的所有节点上传播并被确认了
• 5.因为是使用基于行的日志事件在备库上进行更新，所以执行写入集合比直接执行更新的开销要小很多，就和使用基于行的复制差不多。当结合多线程应用的写入集合时，可以使其比MySQL本身的复制更具备可扩展性。

当然Percona XtraDB Cluster也有一些缺点:

• 1.它很新，因此还没有足够的经验来证明其优点和缺点，也缺乏合适的使用案例
• 2.整个集群的写入速度由最差的节点决定。因此所有的节点最好拥有相同的硬件配置，如果一个节点慢下来(例如,RAID卡做了一次battery-learn循环)，所有的节点都会慢下来。如果一个节点接收写入操作变慢的可能性为P,那么3个节点的集群变慢的可能性为3P
• 3.没有NDB那样节省空间，因为每个节点都需要保存全部数据，而不仅仅是一部分。但另一方面，它基于Percona XtraDB(InnoDB的增强版本)，也就没有NDB关于磁盘数据限制的担忧
• 4.当前不支持一些在异步复制中可以做的操作，例如在备库上离线修改schema，然后将其提升为主库，然后在其他节点上重复离线修改操作。当前可替代的选择时使用诸如Percona Toolkit中的在线schema修复工具。不过滚动式schema升级(rolling schema upgrade)也即将发布
• 5.当向集群中增加一个新节点时，需要复制所有的数据，还需要跟上不断进行的写入操作，所以一个拥有大量写入的大型集群很难进行扩容。这实际上限制了集群的数据大小。我们无法确定具体的数据。但悲观地估计可能低至100GB或更小，也可能会大得多。这一点需要时间和经验来证明
• 6.复制协议在写入时对网络波动比较敏感，这可能导致节点停止并从集群中踢出。所以我们推荐使用高性能网络，另外还需要很好的冗余。如果没有可靠的网络，可能会导致需要频繁地将节点加入到集群中，这需要重新同步数据。还有一个几乎接近可用的特性即通过增量状态传输来避免完全复制数据集，因此未来这并不是一个问题。还可以配置Galera以容忍更大的网络延迟(以延迟故障检测为代价)
• 7.如果没有仔细关注，集群可能会增长得太大，以至于无法重启失效节点，就像在一个合理的时间范围内，如果在日常工作中没有定期做恢复演练，备份也会变得太过庞大而无法用于恢复。我们需要更多的实践经验来了解它事实上是如何工作的
• 8.由于事务提交时需要进行跨节点通信，写入会更慢，随者集群增加的节点越来越多，死锁和回滚也会更加频繁
  Percona XtraDB Cluster和Galera都处于生命周期的早期，正在被快速地修改和改进。现在正在进行或即将进行地改进包括群体行为、安全性、同步性、内存管理、状态转移等。未来还可以为离线节点执行诸如滚动式schema变更的操作

基于复制的冗余

复制管理器是使用标准MySQL复制来创建冗余的工具(冗余并不等同于高可用性)。尽管可以通过复制来改善可用性，但也有一些"玻璃天花板"会阻止MySQL当前版本的异步复制和半同步复制获得和真正的同步复制相同的结果。复制无法保证实时的故障转移和数据零丢失，也无法将所有节点等同对待。
复制管理器通常监控和管理三件事:应用和MySQL间的通信、MySQL服务器的健康度，以及MySQL服务器间的复制关系。它们既可以修改负载均衡的配置，也可以在必要的时候转移虚拟IP地址以使应用连接到合适的服务器上，还能够在一个伪集群中操作复制以选择一个服务器作为写入节点。大体上操作并不复杂:只需要确定写入不会发送到一个还没有准备好提供写服务的服务器上，并保证当需要提升一台备库为主库时记录下正确的复制坐标。
这听起来在理论上是可行的，但经验表明实际上并不总是能有效工作。事实上这非常糟糕，有些时候最好有一些轻量级的工具集来帮助从常见的故障中恢复并以很少的开销获得较高的可用性。不幸的是，还没有听说过任何一个好的工具及可以可靠地完成这一点。后面会介绍两个复制管理器，其中一个很新，而另外一个则有很多问题。
我们发现很多人试图去写自己的复制管理器。它们常常会陷入很多人已经遭遇过的陷阱，自己去写一个复制管理器并不是好主意。异步组件有大量的故障形式，很多你从未亲身经历过，其中一些甚至无法理解，并且程序也无法适当处理。因此从这些异步组件中得到正确的行为相当困难，并且可能遭遇数据丢失的危险。事实上，机器刚开始出现问题时，由一个经验丰富的人来解决时很快的。但如果其他人做了一些错误的修复操作则可能导致问题更严重
我们要提到的第一个复制管理器时MMM.有些人认为它在一些人工——故障转移模式下的场景下比较有用，而有些人甚至从不使用这个工具。许多人在自动——故障转移模式下使用该工具时确实遇到了许多严重的问题。它会导致健康的服务器离线，也可能将写入发送到错误的地点，并将备库移动到错误的坐标。有时混乱就接踵而至.
另外一个比较新一点的工具时Yoshinori Matsunobu 的MHA工具集，它和MMM一样时一组脚本，使用相同的通用技术来建立一个伪集群，但它不是一个完全的替换这；它不会去做太多的事情，并且依赖于Pecemaker来转移虚拟IP地址。一个主要的不同是，MHA有一个很好的测试集，可以防止一些MMM遇到过的问题。除此之外对该工具集还没有更多的认识。
基于复制的冗余最终来说好坏参半。只有在可用性的重要性远比一致性或数据零丢失保证更重要时才推荐使用。例如，一些人并不会真的从它们的网站功能重获利，而是从它的可用性重赚钱。谁会在乎是否出现了故障导致一张照片丢失了几条评论或者其他什么东西呢？只要广告收益继续滚滚而来，可能并不值得花更多成本去实现真正的高可用性。但还是可以通过复制来建立"尽可能的"高可用性，当遇到一些很难处理的严重宕机时，可能会有所帮助。这是一个大赌注，并且可能对大多数人而言太过于冒险，除非是哪些老成(或者专业)的用户。
问题时许多用户不知道如何去证明自己有资格并评估复制"轮盘赌"是否适合它们。这有两个方面的原因。第一，它们并没有看到"玻璃天花板"，错误地认为一组虚拟IP地址、复制以及管理脚本能够实现真正的高可用性。第二，它们低估了技术的复杂度，因此也低估了严重故障发生后从中恢复的难度。一些人认为它们能够使用基于复制的冗余技术，但随后它们可能会更希望选择一个有更强保障的简单系统。
其他一些类型的复制，例如DRBD或者SAN，也有他们的缺点——但也不要认为将这些技术说的无所不能而把MySQL自身的复制贬得一团糟，那不是本意。你可以为DRBD写出低质量的故障转移脚本，这很简单，就像为MySQL复制编写脚本一样。主要的区别时MySQL复制非常复杂，有很多非常细小的差别，并且不会阻止你干坏事