可扩展性

负载均衡

一主多备间的负载均衡

最常见的复制拓扑结构就是一个主库加多个备库。我们很难绕开这个架构，许多应用都假设只有一个目标机器用于所有的写操作，或者所有的数据都可以从单个服务器上获得。尽管这个架构不太具有很好的可扩展性，但可以通过一些办法结合负载均衡来获得很好的效果。

• 1.功能分区
  对于特定的目的可以通过配置备库或一组备库来极大地阔扎脑容量。一些比较常见的功能包括报表、分析、数据仓库，以及全文检索
• 2.过滤和数据分区
  可以适用适用复制过滤技术在相似的备库上对数据进行分区。只要数据在主库上已经被隔离到不同的数据库或表中，这种方法就可以奏效。不幸的是，没有内建的八幡在行级别上进行复制过滤。你需要适用一些独创性的技术来实现这一点，例如适用触发器和一组不同的表。即使不把数据分区到各个备库上，也可以通过对读进行分区而不是随机分配来提高缓存效率。例如，可以把对以字母A-M开头的用户的读操作分配给一个给定的备库，把N-Z开头的分配给另外一个。这能够更好地利用每台机器的缓存，因为分离读更可能在缓存中找到相关的数据。最好的情况下，当没有写操作时，这样适用的缓存相当于两台服务器缓存的综合。相比之下，如果随机地在备库上分配读操作，每个机器的缓存本质上还是重复的数据，而总的有效缓存效率和一个备库缓存一样，不管你有多少台备库。
• 3.将部分写操作转移到备库
  主库并不总是需要处理写操作中的所有工作。你可以分解写擦汗寻，并在备库上执行其中的一部分，从而显著减少主库的工作量
• 4.保证备库跟上主库
  如果要在备库执行某种操作，他需要即使知道数据处于哪个时间点——哪怕需要等待一会儿才能到达这个点——可以适用函数MASTER_POS_WAIT()阻塞直到备库赶上了设置的主库同步点。另一种替代方案是复制复制心跳来检查延迟情况
• 5.同步写操作
  也可以使用MASTER_POS_WAIT()函数来确保写操作已经被同步到一个或多个备库上。如果应用需要模拟同步复制来确保数据安全性，就可以在多个备库上轮流执行MASTER_POS_WAIT()函数。这就类似创建了一个"同步屏障"，但任意一个备库出现复制延迟时，都可能花费很长时间完成，所以最好在确实需要的时候才适用这种方法(如果你的目的只是确保某些备库拥有时间，可以只等待一台备库接收到时间，MySQL5.5增加了半同步复制，能够支持这项技术)

高可用性

概述

接下来分析提到的复制、可扩展性以及高可用性三个主题中的第三个。归根结底，高可用性实际上意味着"更少的宕机时间"。然而糟糕的是，高可用性经常和其他的概念混淆，例如冗余、保障数据不丢失，以及负载均衡。
高可用性实际上优点像神秘的野兽。它通常以百分比表示，这本身也是一种按时:高可用性不是绝对的，只有相对更高的可用性。100%的可用性是不可能达到的。可用性的"9"规则是表示可用性目标最普遍的方法，你可能也知道"5个9"表示99.999%的正常可用时间。换句话说，每年只允许5分钟的宕机时间。对于大多数应用这已经是令人惊叹的数字，尽管还有一些人视图获得更多的"9".
每个应用对可用性的需求各不相同。在设定一个可用时间的目标之前，先问问自己，是不是确实需要达到这个目标。可用性每提高一点，所花费的成本都会远超之前;可用性的效果和开销的比例并不是线性的。需要保证多少可用时间，取决于能够承担多少成本。高可用性实际上是在宕机造成的损失与降低宕机时间所花费的成本之间取一个平衡。换句话说，如果需要花大量金钱去获得更好的可用时间，但所带来的收益却很低，可能就不值得做。总地来说，应用在超过一定的点以后追求更高的可用性是非常困难的。成本也会很高，因此我们建议设定一个更现实的目标并且避免过度设计。幸运的是，建立2个9或3个9的可用时间的目标可能并不困难，具体情况取决于应用。
有时候人们将可用性定义成服务正在运行的时间段。我们认为可用性的定义还应该包括应用是否能以足够好的性能处理请求。有许多方法可以让一个服务器保持运行，但服务并不是真正可用。对一个很大的服务器而言，重启MySQL之后，可能需要几个消失才能充分预热以保证查询请求的响应时间是可以接受的，即使服务器只接收了正常流量的一小部分也是如此。
另一个需要考虑的问题是，即使应用并没有停止服务，但是否可能丢失了数据。如果服务器遭遇灾难性故障，可能多少都会丢失一些数据，例如最近已经写入(最新丢失的)二进制日志但尚未传递到备库的中继日志中的事务。你能够容忍吗？大多数应用能够容忍；因为替代方案大多非常昂贵且复杂，或者有一些性能开销。例如，可以使用同步复制，或是将二进制日志档到一个通过DRBD进行复制的设备上，这样就算服务器完全失效也不用担心丢失数据(但是整个数据中心也有可能会掉电)。
一个良好的应用架构通常可以降低可用性方面的需求，至少对部分系统而言是这样的，良好的架构也更容易做到高可用。将应用中重要和不重要的部分进行分离可以节约不少工作量和金钱，因为对于一个更小的系统改进可用性会更容易。可以通过计算"风险敞口(risk exposure)"，将失效概率与失效代价相乘来确认高优先级的风险，画一个简单的风险计算表，以概率、代价和风险敞口作为列，这样很容易找到需要优先处理的享目。
在前面讨论如何避免导致糟糕的可扩展性的原因，来退出如何获得更好的可扩展性。这里也会使用相似的方法来讨论可用性，因为我们相信，理解可用性最好的方法就是研究它的反面——宕机时间。

导致宕机的原因

我们经常听到导致数据库宕机最主要的原因是编写的SQL查询性能很差，真的是这样吗？2009年我们决定分析我们客户的数据库所遇到的问题，以找出那些真正引起宕机的问题，以及如何避免这些问题。结果正是了一些已有的猜想，但也否定了一些(错误的)认识，并从中学到了很多。
我们首先对宕机时间按表现方式而非导致的原因进行分类。一般来说，"运行环境"是排名第一的宕机类别，大于35%的时间属于这一类。运行环境可以看作是支持数据库服务器运行的系统和资源集合，包括操作系统、硬盘以及网络等。性能问题紧随其后，也是约占35%;然后是复制，占20%，最后剩下的10%包含各种类型的数据丢失或损坏以及其他问题。我们对时间按类型进行分类后，确定了导致这些时间的原因。以下是一些需要足以的地方:

• 1.在运行环境的问题中，最普遍的是磁盘空间耗尽
• 2.在性能问题中，最普遍的宕机原因确实是运行很糟糕的SQL，但也不一定都是这个原因，比如也有很多问题是由于服务器Bug或错误的行为导致的
• 3.糟糕的Schema和索引设计是第二大影响性能的问题
• 4.复制问题通常由于主备数据不一致导致
• 5.数据丢失问题通常由于DROP TABLE的误操作导致，并总是伴随着缺少可用备份的问题。

复制虽然常被人们用来改善可用时间，但却也可能导致宕机。这主要是由于不正确的使用导致的，即便如此，它也阐明了一个普遍的情况:许多高可用性策略可能会产生反作用

如何实现高可用性

可以通过同时进行以下两步来获得高可用性。首先，可以尝试避免导致宕机的原因来减少宕机时间。许多问题其实很容易避免，例如通过适当的配置、监控，以及规范或安全保障措施来避免认为错误。第二，金狼保证在发生宕机时能够快速恢复。最常见的策略时在系统中制造冗余，并且具备故障转移的能力。这两个维度的高可用性可以通过两个相关的度量来确定:平均失效时间(MTBF)和平均恢复时间(MTTR)。一些阻止会非常仔细地追踪这些度量值.
第二步——通过冗余快速恢复——很不幸，这里时应该最注意的地方，但预防措施的投资回报率会很高。

提升平均失效时间(MTBF)

其实只要尽职尽责地做好一些应做的事情，就可以避免很多宕机。在分类整理宕机事件并追查导致宕机的根源时，还发现，很多宕机本来是有一些方法可以避免的。我们发现大部分宕机事件都可以通过全面的常识性系统管理办法来避免。以下是做一些指导性的建议:

• 1.测试恢复工具和流程，包括从备份中恢复数据
• 2.遵从最小权限原则
• 3.保持系统干净、整洁
• 4.使用好的命名和组织约定来避免产生混乱，例如服务器是用于开发还是用于生产环境
• 5.谨慎安排升级数据库服务器
• 6.在升级前，使用诸如Percona Toolkit中的pt-upgrade之类的工具仔细检查系统
• 7.使用InnoDB并进行适当的配置，确保InnoDB是默认存储引擎。如果存储引擎被禁止，服务器就无法启动
• 8.确认基本的服务器配置是正确的
• 9.通过skip_name_resolve禁止DNS
• 10.除非能证明有效，否则禁用查询缓存
• 11.避免使用复杂的特性，例如复制过滤和触发器，除非确实需要
• 12.监控重要的组建和功能，特别是像磁盘空间和RAID卷状态这样的关键享目，但也要避免误报，只有当确实发生问题时才发送告警
• 13.定期检查复制完整性
• 14.讲备库设置为只读，不要让复制自动启动
• 15.定期进行查询语句审查
• 16.归档并清理不需要的数据
• 17.为文件系统保留一些空间。在GNU/Linux中，可以使用-m选项来为文件系统本身保留空间。还可以在LVM卷组中留下一些空闲空间。或者，更简单的方法，仅仅创建一个巨大的空文件，在文件系统快满时，直接将其删除(这是100%跨平台兼容的)
• 18.养成习惯，评估和管理系统的改变、状态以及性能信息

我们发现对系统变更管理的缺失时所有导致宕机的实践中最扑鼻那的原因。典型的错误包括粗心的升级导致升级失败并遭遇一些Bug，或是尚未测试就将Schema或查询语句的更改直接运行到线上，或者没有为一些失败的情况制定计划，例如达到了磁盘容量限制。另外一个导致问题的主要原因是缺少严格的评估，例如因为疏忽没有确认备份是否是可以恢复的。最后，可能没有正确地监控MySQL的相关信息。例如缓存命中率报警并不能说明问题，并且可能产生大量的误报，这会使监控系统被认为不太有用，于是一些人就会忽略报警。有时候监控系统失效了，甚至没人会注意到，直至你的老板质问你，“为什么Nagios没有告诉我们磁盘已经满了?”

降低平均恢复时间(MTTR)

之前提到，可以通过减少恢复时间来获得高可用性。事实上，一些人走的更远，只专注于减少恢复时间的某个方面:通过在系统中建立冗余来避免系统完全失效，并避免单点失效问题。在降低恢复时间上进行投资非常虫咬，一个能够提供冗余和故障转移能力的系统架构则是降低恢复时间的关键环节。但实现高可用性不单单是技术问题，还有许多个人和组织的因素。组织和个人在避免宕机和从宕机事件中恢复的成熟度和能力层次各不相同。
团队成员是最重要的高可用性资产，所以为恢复制定一个好的流程非常重要。拥有熟练技能、应变能力、训练有素的雇员，以及处理紧急事件的详细文档和经过仔细测试的流程，对从宕机中恢复有巨大的作用。但也不能完全依赖工具和系统，因为它们并不能理解实际情况的细微差别，有时候它们的行为在一般情况下是正确的，但在某些场景下却会是个灾难
对宕机事件进行评估有助于提升组织学习能力，可以帮助避免未来发生相似的错误，但是不要对"事后反思"或"事后的调查分析"期待太高。后见之明被严重曲解，并且一味想找到导致问题的唯一根源，这可能会影响你的判断力。许多流行的方法，例如"五个为什么"，可能会被过度使用，导致一些人将他们的经历集中在找到唯一的替罪羊。很难去回顾我们解决的问题当时所处的状况，也很难理解真正的原因，因为原因通常是多方面的。因此，尽管事后反思可能是有用的，但也应该对结论有所保留。即使是这里给出的建议，也是基于长期研究导致宕机事件的原因以及如何预防它们所得，并且只是这里的观点而已。
这里要反复提醒:所有的宕机事件都是由多方面的失效联合在一起导致的。因此可以通过利用合适的方法确保单点的安全来避免。整个链条必须要打断，而不仅仅是单个环节。例如，那些问我们求助恢复数据的人不仅遭受数据丢失(存储失效，DBA误操作等)。同时还缺少一个可用的备份。
这样说来，当开始调查并尝试阻止失效或加速恢复时，大多数人和组织不应太过于内疚，而是要专注于技术上的一些措施——特别是那些很酷的方法，例如集群系统和冗余架构。这些是有用的，但要记住这些系统依然会失效。事实上，前面提到的MMM复制管理，已经对它失去了型取，因为它被证明可能导致更多的宕机事件。你应该不会奇怪一组Perl脚本会陷入混乱，但即使是特别昂贵并精密设计的系统也会出现灾难性的失效——是的，即使是花费了大量金钱的SAN也是如此。已经见过太多的SAN失效