优化服务器设置
操作系统状态
CPU密集型的机器
CPU密集型服务器的vmstat输出通常在us列会有一个很高的值，报告了花费在非内核代码上的CPU时钟;也可能在sy列有很高的值，表示系统CPU利用率，超过20%就足以令人不安了。在大部分情况下，也会有进程队列排队时间(在r列报告的)。如图所示。注意，这里也可能有合理数量的上下文切换(cs列)，除非每秒超过100 000次或更多，一般都不用担心上下文切换。当操作系统停止一个进程转而运行另一个进程时，就会产生上下文切换。例如，一查询语句在MyISAM上执行了一个非覆盖索引扫描，就会先从索引中读取元素，然后根据索引再从磁盘上读取页面。如果页面不在操作系统缓存中，就需要从磁盘进行物理读取，着就会导致上下文切换中断进程处理，直到IO完成。这样一个查询可以导致大量的上下文切换。
如果我们在同一台机器观察iostat的输出(再次剔除显示启动以来平均值的第一行)，可以发现磁盘利用率可能低于50%,如图所示。
这台机器不是IO密集型的，但是依然有相当数量的IO发生，在数据库服务器中这种情况很少见。另一方面，传统的Web服务器会消耗大量CPU资源，但是很少发生IO,所以Web服务器的输出不会像这个例子。
IO密集型的机器
在IO密集型工作负载下，CPU花费大量时间在等待IO请求完成。这意味着vmstat会显示很多处理器在非中断休眠(b列)状态，并且在wa这一列的值很高,如果你查询这台机器的iostat输出显示硬盘一直很忙。%util的值可能因为四舍五入的错误超过100%.什么迹象意味着机器是IO密集的呢？只要有足够的缓冲来服务写请求，即使机器正在做大量的写操作，也可能满足，但是却通常意味着可能会无法满足读请求。这听起来好像违反直觉，但是如果思考读和写的本质，就不会这儿认为了:
- 1.写请求能够缓冲或同步操作。它们可以被任意一层缓冲:操作系统层、RAID控制器层，等等
- 2.读请求就其本身而言都是同步的。当然程序可以猜测可能需要某些数据，并异步地提前读取(预读)。无论如何，通常程序在继续工作前得到它们需要的数据。这就强制读请求为同步操作:程序必须被阻塞直到请求完成。
想想这种方式:你可以发出一个写请求到缓冲区的某个地方，然后过一会儿完成。甚至可以每秒发出很多这样的请求。如果缓冲区正确工作，并且有足够的空间，每个请求都可以很快地完成，并且实际上写到物理硬盘是被重新排序后更有效地批量操作的。然而，没有办法对读操作这么做——不管多小或多少的请求，都不可能让硬盘响应说"这是你的数据，我等一会儿读它"。这就是为什么读需要IO等待是可以理解的原因
发生内存交换的机器
一台正在发生内存交换的机器可能在swapd列有一个很高的值，也可能不高。但是可以看到si和so列有很高的值，这是我们不希望看到的
空闲的机器
为完整期间，下面也给出一台空闲机器上的vmstat输出。注意，没有在运行或或被阻塞的进程，idle列显示CPU是100%空闲，st列展示了从"虚拟机"偷来的时间
复制
概述
MySQL内建的复制功能是构建基于MySQL的大规模、高性能应用的基础，这类应用使用所谓的"水平扩展"的架构。我们可以通过为服务器配置一个或多个备库(可能有的地方将会复制备库(replica)称为从库(slave))的方式来进行数据同步。复制功能不仅有利于构建高性能的应用，同时也是提高可用性、可扩展性、灾难恢复、备份以及数据仓库等工作的基础。事实上，可扩展性和高可用性通常是相关联的话题。
复制解决的基本问题是让一台服务器的数据与其他服务器保持同步。一台主库的数据可以同步到堕胎备库上，备库背身也可以被配置成另外一台服务器的主库。主库和备库之间可以有多种不同的组合方式。MySQL支持两种复制方式:基于行的复制和基于语句的复制。基于语句的复制(也称逻辑复制)早在MySQL3.23版本中就存在，而基于行的复制方式在5.1版本中才被加进来，这两种方式都是通过在主库上记录二进制日志,在备库重放日志的方式来实现异步的数据复制。这意味着，在同一时间点备库上的数据可能与主库存在不一致，并且无法保证主备之间的延迟。一些大的语句可能导致备库产生几秒、几分钟甚至几个小时的延迟。MySQL复制大部分是向后兼容的，新版本的服务器可以作为老版本服务器的备库，但反过来，将老版本作为新版本服务器的备库通常是不可行的，因为他可能无法解析新版本所采用的新的特性或语法，另外所使用的二进制文件的格式也可能不相同。例如，不能从MySQL5.1复制到MySQL4.0。在进行大的版本升级前，例如从4.1升级到5.0，或从5.1升级到5.5，最好先对复制的设置进行测试。但对于小版本号升级，如从5.151升级到5.1.58，则通常是兼容的。通过阅读每次版本更新的ChangeLog可以找到不同版本间做了什么修改。
复制通常不会增加主库的开销，主要是启用二进制日志带来的开销，但出于备份或及时从崩溃中恢复的目的，这点开销也是必要的。除此之外，每个备库也会对主库增加一些负载(例如网络IO开销)，尤其当备库请求从主库读取旧的二进制日志文件时，可能会造成更高的IO开销。另外锁竞争也可能阻碍事务的提交。最后，如果时从一个高吞吐量(例如5 000或更高的TPS)的主库上复制到多个备库，唤醒多个复制线程发送时间的开销将会累加。
通过复制可以将读操作指向备库来获得更好的读扩展，但对于写操作，除非设计得当，否则并不适合通过复制来扩展写操作。在一主库多备库的架构中，写操作会被执行多次，这时候整个系统的性能取决于写入最慢的那部分。
当使用一主库多备库的架构时，可能会造成一些浪费，因为本质上它会复制大量不必要的重复数据。例如，对于一台主库和10台备库，会有11份数据拷贝，并且这11台服务器的缓存中存储了大部分相同的数据。这和在服务器上有11路RAID 1类似，这不是一种经济的硬件使用方式，但这种复制架构却很常见
复制解决的问题
下面是复制常见的用途。
- 1.数据分布
MySQL复制通常不会对贷款造成很大的压力，但在5.1版本引入的基于行的复制会比传统的基于语句的复制模式的带宽压力大，你可以随意地停止或开始复制，并在不同的地理位置来分布数据备份，例如不同的数据中心。即使在不稳定的网络环境下，远程复制也可以工作。但如果为了保持很低的复制延迟，最好有一个稳定的低延迟连接 - 2.负载均衡
通过MySQL复制可以将读操作分布到多个服务器上，实现对读密集型应用的优化，并且实现很方便，通过简单的代码修改就能实现基本的负载均衡。对于小规模的应用，可以简单地对机器名做硬编码或使用DNS轮询(将一个机器指向多个IP地址)。当然也可以使用更复杂的方法，例如网络负载均衡这一类的标准负载均衡解决方案，能够很好地将负载分配到不同的MySQL服务器上。Linux虚拟服务器(Linux Virtual Server，LVS)也能很好地工作， - 3.备份
对于备份来说，复制是一项很有意义的技术补充，但复制既不是备份也不能够取代备份 - 4.高可用性和故障切换
复制能够帮助应用程序避免MySQL单点失败，一个包含复制的设计良好的故障切换系统能够显著地缩短宕机时间 - 5.MySQL升级测试
这种做法比较普遍，使用一个更高版本的MySQL作为备库，保证在升级全部实例前，查询能够在备库按照预期执行。
复制如何工作
在详细介绍如何设置复制之前，让我们先看看MySQL实际上是如何复制数据的。总的来说，复制有三个步骤:
- 1.在主库上把数据更改记录到二进制日志(Binary Log)中(这些记录被称为二进制日志事件)
- 2.备库将主库上的日志复制到自己的中继日志(Relay Log)中
- 3.备库读取中继日志中的事件，将其重放到备库数据之上
以上只是概述，实际上每一步都很复杂，如图所示
第一步是在主库上记录二进制日志.在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引擎可以提交事务了。
下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个共组哦县城，称为IO线程，IO线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转储(binlog dump)线程(该线程没有对应的SQL命令)，这个二进制转储线程会读取主库上二进制日中的事件。它不会对事件进行轮询。如果该线程追赶上了主库，它将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会被幻行，贝克IO线程会将接收到的事件记录到中继日志中。
MySQL4.0之前的复制与之后的版本相比改变很大，例如MySLQ最初的复制功能没有使用中继日志，所以复制只用到了两个线程，而不是现在的三个线程。目前大部分人都是使用的最新版本。
备库的SQL线程执行最后异步，该线程从中继日志中读取事件并在备库执行，从而实现备库数据的更新。当SQL线程追赶上IO线程时，终极日志通常已经在系统缓存中，所以中继日志的开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写入其自己的二进制日志中。
上图显示了在备库有两个运行的线程，在主库上也有一个运行的线程:和其他普通连接一样，由备库发起的连接，在主库上同样拥有一个线程。
这种复制架构实现了获取事件和重放事件的解耦，允许这两个过程异步进行。也就是说IO线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要的一点时在主库上并发运行的查询在备库只能串行化执行，因为只有一个SQL线程来重放中继日志中的事件。后面我们将会看到，这是很多工作负载的性能瓶颈所在，虽然有一些针对该问题的解决方案，但大多数用户仍然会受制于单线程