云平台中的MySQL

     此文主要翻译高性能MySQL v3

     对于MySQL在云中的使用，大致分为两类：
IaaS:基础设施即服务，
IaaS 为你的MySQL server提供基础服务，你可以购买虚拟server资源来安装MySQL server 实例。你可以按照自己的要求设置os 和MySQL server,但是你不能与之相关的硬件设施。
DbaaS (Database as a Server)
MySQL 本身是云所管理的资源，你只有一个访问MySQL 的凭证，你只能对MySQL 进行设置，但是不能看到os和虚拟的资源。Amazon 的RDS就是这样一个例子，他们提供的服务不是真正的MySQL,只是和MySQL和查询语言兼容。

    我们大部分集中在第一类。(我们的目标是帮助您避免您可能会遇到的一些缺陷，如果你不是一个MySQL在云端的专家。)

优点，缺陷，对云的误解
云计算有很多好处，其中一些是使用MySQL的时候特定的。
优点：
1、所有的基础设施都外包出去，不用未管理而费心，您不必购买硬件和开发供应链关系。不用替换坏掉的硬件等等
2、付费是按照自己的需求来说，可以将前期资本投入转换为当前项目运营上。
3、云服务器提供的价值随着时间而增加，因为他们会提供新的服务并降低成本。你不必做向升级服务事就能从他们的价值中获益。
4、对硬件资源管理方便，可随时增加或退订任何资源，省去处理或回收的成本。
5、云带来了对基础设施的重新思考与定位，资源可以通过API来展现，并且更加自动化。同样你也能搭建自己的私有云。

缺点：
1、资源是共享的并且不固定。我们获得的资源不能像我们付费那样公平的使用，并且云服务器也不能给出满意的答案
2、对于业务容量和可靠性是无法保证的。并不能完全按照自己业务需求来购买新的资源，可能会收到供应商资源限制或者“超额并购”
3、虚拟、共享的资源是不好进行故障排除。尤其是不能看到相关硬件设施并得知他们的状态。举例：当我们查看系统时，iostat 显示IO正常，vmstat显示CPU正常，当我们真正测试发现问题的时候是因为系统上的其他程序导致系统负载高。当出现问题的真的不好判断。

对云的一点误解：
1、云计算本质上更具扩展性
应用程序，它们的架构和组织管理，是可扩展的（或者不是）。云计算本质上不是可扩展的，只是因为它是一个云，选择一个可扩展平台不会使你的应用能够扩展。如果云平台供应商没有对购买资源作出限制，那么我们购买资源只是可扩展的一方面。
2、云会自动改善，甚至保证正常运行时间
一般情况下，个人云托管的服务器实际上更可能比精心设计的专用基础设施失败或出现停电，然而很多人没有认识到这一点，例如，一个人写道：“我们正在改善我们的基础设施基于云计算的系统给我们100％的正常运行时间和可扩展性。这是AWS已经历了两次巨大的停电之后，受影响较大的部分用户基地。一个好的架构师可能设计可靠的系统不可靠的部件。从另一方面来讲，如果你使用那些专家构建的云平台服务，对于一个新手来说是非常有帮助的。
3、云计算是唯一能够提供。。。。
事实上，许多云计算的好处，所采用的技术都继承自构建云平台和可以得到的带或不带云。如果你在任何平台下都游刃有余。那么你不需要云。
4、云是一个银弹
这可能似乎是荒谬的，怎么会有人居然说这.

MySQL在云中的可扩展性和高可用性
正如我们前面提到的，MySQL并不会自动变的更加具有可扩展性，实际上，对于在用的不是很强大的机器迫使我们尽早的进行水平扩展。云托管中的server相比于专门的硬件是不可靠的，所以需要更多的创造力。
虽然在扩展mysql的时候，在云平台和其他地方是没有太多的区别的。但最大的区别是是否能够提供服务上的需求。在云计算中对于可扩展性和高可用有些局限性。举例：在Amazon,中，不能使用VIP来实现故障转移。这样我们只能选择其他的方式，比如代理(proxies) scalebase 比较值得期待，
另一个关于关于云计算的警告 是它的自动扩展，在需求增加的时候组织更多的实例来作出响应，当需求减少的时候关闭部分实例。这样的行为对于无状态的web server 很合适，但对于DB却不是这样，对于特殊的场景，比如读较多的应用，增加replicas 可能会在auto_scaling 受限，但这也不是适合所有的情况，在实际生产中，在每个节点都对等的集群上，MySQL是不支持的。
你可以设置一个分片的架构 来实现自动的重组分片，自动增长与缩小。但是MySQL自身是无法自动扩展的。
实际上，MySQL在应用程序中是唯一一个有状态并且持久的组件，但由于云计算的优点导致很多人把应用迁移至cloud上，所以MySQL也不得不迁移至云平台。数据库并非所有的核心，如果该应用程序的其余部分的好处大于根据需要额外的成本和所需的努力使MySQL工作.那么是否将应用迁移至云中将不是一个问题。现在回答这个问题：DB周围的资源都是可用的，这样将来对你在面对云的的额外的挑战的时候是很有帮助的。

MySQL在云中的性能
一般情况下，云中的MySQL由于较弱的的CPU，memory,I/O 导致在实体机上性能一般般。但是相对来讲，云平台的伸缩性是很强的。他和其他的虚拟机共享着资源。资源的伸缩性是很有创意的。但是对于INNODB 对这种I/O资源的性能不是很“喜欢”，I/O操作需要更多的锁锁住共享资源，这样只会产生更多long query. 产生更多的峰值，通过下面两个变量看出：Threads_runnig Threads_connected .
在实际情况下，由于不一致和变化莫测的情况，队列在这个时候是很重要的。
云中的server都是队列的一份子，如果资源正在被利用，其他的server只能进行等待。如果云中的资源变化很大的话，请求会有更多的交互，结果导致并发性不是很高，保证数据一致性的情况下会带来较低的响应时间。
现在我们可以说说OLTP的应用负载，如果对资源设置好的话，在云平台上是可以有不错的表现的。
像我们讨论的一样，工作集中需要高并发的情况下，在云中不太合适。每条语句只在一个CPU上执行，那么语句的相应时间受到CPU速度的影响。这个时候需要强并且多个CPU，我们都知道MySQL InnoDB并不会将负载分配到多个CPU上。但是有多个核心还是很有帮助的。
工作集中需要更多的I/O，在云中表现不是很好。对于CPU的资源我们是无法控制的，但I/O 可以通过添加更多的内存来降低。有了足够的内存，读取的内容可以从内存中取得，减少读和写请求的IO，多个写入操作可以利用内存来进行合并并用一次IO操作完成。但是这个时候机器的预热时间需要很长。几个小时或者几天都有可能。
你可能会想为了提高IO性能可以利用条带或者镜像的方式的磁盘 即RAID，但是这样等到达某个点的时候，我们可能会增加更多的磁盘。这样可能会增加故障率，一个部分的出现恶化，会影响到整个系统。在应用端，我们可以通过优化程序来减少IO需求，设置变量：innodb_flush_logs_at_trx_commit=2  sync_binlog=0 或者移动redolog 和 binary logs 到其他的磁盘。升级MySQL,更高版本有更好的IO性能和更少的内部瓶颈。比如Percona 能够提供更好的方便，在buffer bool中预热更短，
最后，一个增长的应用早晚会到分片的时候。但是尽量避免分片，如果实在不行的话，就从云平台上迁移下来.


MySQL Database as  a Service (DbaaS)
越来越多的公司将他们的DB作为云平台的资源，尽管在这一章我们花费大量时间来测试IaaS,但它已经很快的商业化，我们期待有更多的将重点转移至DBaaS上来，下面有家平台提供者：
Amazon  RDS
其实它就是MySQL EC2 EBS的组合。
FathomDB  (http://fathomdb.com)
Xeround (http://xeround.com)