九、操作系统和硬件优化
A.什么限制了MySQL的性能
1.当数据可以放在内存中或者可以从磁盘中以足够快的速度读取时，CPU可能出现瓶颈，把大量的数据集完全放到大容量的内存中，以现在的硬件条件完全是可行的
2.I/O瓶颈，一般发生在工作所需的数据远远超过有效内存容量的时候，如果应用程序是分布在网络上的，或者如果有大量的查询和低延迟的要求，瓶颈可能转移到网络上
B.如何为MySQL选择CPU
1.可以通过检查CPU利用率来判断是否是CPU密集型的工作负载，还需要看看CPU使用率和大多数重要的查询的I/O之间的平衡，并注意CPU负载是否分配均匀
2.当遇到CPU密集型的工作时，MySQL通常可以从更快的CPU中获益，但还依赖于负载情况和CPU数量
3.MySQL复制也能在高速CPU下工作得非常好，而多CPU对复制的帮助却不大
4.多CPU在联机事务处理（OLTP）系统的场景中非常有用，在这样的环境中，并发可能成为瓶颈
C.平衡内存和磁盘资源
1.配置大量内存最终目的是避免磁盘I/O，最关键的是平衡磁盘的大小、速度、成本和其他因素，以便为工作负载提供高性能的表现
2.设计良好的数据库缓存（如InnoDB缓冲池），其效率通常超过操作系统的缓存，因为操作系统缓存是为通用任务设计的
3.数据库服务器同时使用顺序和随机I/O，随机I/O从缓存从受益最多
4.每个应用程序都有一个数据的“工作集”——就是这个工作确实需要用到的数据
5.工作集包括数据和索引，所以应该采用缓存单位来计数，一个缓存单位是存储引擎工作的数据最小单位
6.找到一个良好的内存/磁盘比例最好的方式是通过试验和基准测试
7.硬盘选择考虑因素：存储容量、传输速度、访问时间、主轴转速、物理尺寸
8.MySQL如何扩展到多个磁盘上取决于存储引擎和工作负载，InnoDB能很好地扩展到多个硬盘驱动器，然而，MyISAM的表锁限制其写的可扩展性，因此写繁重的工作加在MyISAM上，可能无法从多个驱动器中收益
D.固态存储
1.高质量闪存设备具备：
* 相比硬盘有更好的随机读写性能
* 相比硬盘有更好的顺序读写性能
* 相比硬盘能更好地支持并发
* 提升随机I/O和并发性
2.闪存的最重要特征是可以迅速完成多次小单位读取，但是写入更有挑战性。闪存不能在没有做擦除操作前改写一个单元（Cell），并且一次必须擦除一个大块。擦除周期是缓慢的，并且最终会磨损整个块
3.垃圾收集对理解闪存很重要。为了保持一些块是干净的并且可以被写入，设备需要回收脏块。这需要设备上有一些空闲空间
4.许多设备被填满后会开始变慢，速度下降是由于没有空闲块时必须等待擦写完成所造成的
5.固态存储最适合使用在任何有着大量随机I/O工作负载的场景下，随机I/O通常是由于数据大于服务器的内存导致的，闪存设备可能大大缓解这种问题
6.单线程工作负载也是另一个闪存的潜在应用场景
7.闪存也可以为服务器整合提供巨大的帮助
8.Flashcache，磁盘和内存技术的结合，适合以读为主的I/O密集型负载，并且工作集太大，用内存优化并不经济的情况
9.优化固态存储上的MySQL
* 增加InnoDB的I/O容量
* 让InnoDB日志文件更大
* 把一些文件从闪存转移到RAID
* 禁用预读
* 配置InnoDB刷新算法
* 禁用双写缓冲的可能
* 限制插入缓冲大小，插入缓冲设计来用于减少当更新行时不在内存中的非唯一索引引起的随机I/O
* InnoDB的页大小
* 优化InnoDB页面校验（Checksum）的替代算法
E.为备库选择硬件
1.通常需要跟主库差不多的配置
F.RAID性能优化
1.RAID可以帮助做冗余、扩展存储容量、缓存，以及加速
2.RAID 0：如果只是简单的评估成本和性能，是成本最低和性能最高的RAID配置
3.RAID 1：在很多情况下提供很好的读性能，并且在不同的磁盘间冗余数据，所以有很好的冗余性，非常适合用来存放日志或者类似的工作
4.RAID 5：通过分布奇偶校验把数据分散到多个磁盘，如果任何一个盘的数据失效，都可以从奇偶校验块中重建，但如果有两个磁盘失效了，则整个卷的数据无法恢复，最经济的冗余配置。随机写是昂贵的，存放数据或者日志是一种可接受的选择，或者是以读为主的业务
5.RAID 10：对数据存储是个非常好的选择，由分片的镜像组成，对读和写都有良好的扩展性
6.RAID 50：由条带化的RAID 5组成
G.SAN和NAS
1.SAN（Storage Area Network）和NAS（Network-Attached Storage）是两个外部文件存储设备加载到服务器的方法，访问SAN设备时通过块接口，NAS设备通过基于文件的协议来访问
2.SAN允许服务器访问非常大量的硬盘驱动器，并且通常配置大容量智能高速缓存来缓冲写入
3.哪些工作放在SAN上不合适：执行大量的随机I/O的单线程任务
4.SAN的应用：
* 备份，可以只备份SAN
* 简化容量规划
* 存储整合还是服务器整合
* 高可用
* 服务器之间的交互
* 成本
H.使用多磁盘卷
1.二进制日志和数据文件分离的真正的优势，是减少事故中同时丢失数据和日志文件的可能性
2.如果有很多磁盘，投入一些给事务日志可能会从中受益
I.网络配置
1.在生产服务器上启用skip_name_resolve是个好主意，损坏或缓慢的DNS解析对许多应用程序都是个问题，对MySQL尤严重，如果启用skip_name_resolve选项，MySQL将不会做任何DNS查找的工作
2.可以通过MySQL的back_log选项控制MySQL的传入TCP连接队列的大小，在每秒有很多连接创建和销毁的环境中，默认值50是不够的
3.网络物理隔离也是很重要的因素，尽可能避免实时的跨数据中心的操作是明智的
J.选择操作系统
1.一般企业级的MySQL部署在Windows上，但一般的企业级MySQL更多的还是部署在类UNIX操作系统上
K.选择文件系统
1.如果可能，最好使用日志文件系统，如ext3、ext4、XFS、ZFS或者JFS
2.可以调整文件系统的预读行为，因为这可能也是多余的
L.选择磁盘队列调度策略
1.在GUN/Linux上，队列调度决定了到块设备的请求实际上发送到底层设备的顺序，默认情况下使用cfq（Completely Fair Queueing，完全公平排队）策略，在MySQL的工作负载类型下，cfq会导致很差的响应时间，因为会在队列中延迟一些不必要的请求
2.cfq之外的两个选项都适合服务器级的硬件，noop调度适合没有自己的调度算法的设备，deadline则对RAID控制器和直接使用的磁盘都工作良好
M.线程
1.MySQL每个连接使用一个线程，另外还有内部处理线程、特殊用途的线程，以及所有存储引擎创建的线程
2.MySQL确实需要内核级线程的支持，而不只是用户级线程，这样才能更有效地使用多个CPU，另外也需要有效的同步原子
N.内存交换区
1.内存交换对MySQL性能影响是很糟糕的，它破坏了缓存在内存的目的，并且相对于使用很小的内存做缓存，使用交换区的性能更差
2.在GNU/Linux上，可以用vmstat来监控内存交换，最好查看si和so列报告的内存交换I/O活动，这比看swpd列报告的交换区利用率更重要，最佳为0
3.设置/proc/sys/vm/swappiness为一个很小的值
4.修改存储引擎怎么读取和写入数据，使用innodb_flush_method=0_DIRECT减轻I/O压力
5.使用MySQL的memlock配置项，可以把MySQL锁定在内存
O.操作系统状态
1.vmstat
* vmstat 5，每隔5秒刷新一次
* procs，r列显示多少进程正在等待CPU，b列显示多少进程正在不可中断地休眠
* memory，swpd列显示多少块被换出到了磁盘，剩下的三个列显示了多少块是空闲的、多少块正在被用作缓冲，以及多少正在被用作操作系统的缓存
* swap，显示页面交换活动
* io，显示有多少块从块设备读取（ bi）和写出（bo）
* system，显示了每秒中断（in）和上下文切换（cs）的数量
* cpu，显示所有的CPU时间花费在各类操作的百分比
2.iostat
* iostats -dx 5，每5秒刷新
* rrqm/s和wrqm/s，每秒合并的读和写请求，意味着操作系统从队列中拿出多个逻辑请求合并为一个请求到实际磁盘
* r/s和w/s，每秒发送到设备的读和写请求
* rsec/s和wsec/s，每秒读和写的扇区数
* avgrq-sz，请求的扇区数
* avgqu-sz，在设备队列中等待的请求数
* await，磁盘排除上花费的毫秒数
* svctm，服务请求花费的毫秒数，不包括排除时间
* %util，至少有一个活跃请求所占时间的百分比
3.CPU密集型的机器，vmstat输出通常在us列会有一个很高的值，也可能在sy列有很高的值
4.I/O密集型工作负载下，vmstat会显示很多处理器在非中断休眠（b列）状态，并且wa这一列的值很高
5.发生内存交换的机器可能在swpd列有一个很高的值
十、复制
A.复制概述
1.MySQL支持两种复制方式：基于行的复制和基于语句的复制，都是通过在主库上记录二进制日志、在备库重放日志的方式来实现异步的数据复制
2.复制通常不会增加主库的开销，主要是启用二进制日志带来的开销，但出于备份或及时从崩溃中恢复的目的，这点开销也是必要的
3.通过复制可以将读操作指向备库来获得更好的读扩展，但对于写操作，除非设计得当，否则并不适合通过写复制来扩展写操作
4.复制解决的问题：
* 数据分布
* 负载均衡
* 备份
* 高可用性和故障切换
* MySQL升级测试
5.复制如何工作
* 在主库上把数据更新记录到二进制日志（Binary Log）中
* 备库将主库上的日志复制到自己的中继日志（Relay Log）中
* 备库读取中继日志中的事件，将其重放到备库数据之上
B.配置复制
1.在每台服务器上创建复制帐号
* 用来监控和管理复制的帐号需要REPLICATION CLIENT权限，并且针对这两种目的使用同一个帐号更加容易
* 如果在主库上建立了帐号，然后从主库将数据克隆到备库时，备库也就设置好了——变成主库所需要的配置
2.配置主库和备库
* 必须明确地指定一个唯一的服务器ID
* 有时候只开启了二进制日志，但却没有开启log_slave_updates，可能会踫到一些奇怪的现象
* 如果可能的话，最好使用read_only配置选项，会阻止任何没有特权权限的线程修改数据
3.通知备库连接到主库并从主库复制数据
4.推荐的复制配置
* sync_binlog =1，在提交事务前会将二进制日志同步到磁盘上，保证在服务器崩溃时不会丢失事件
* 如果无法容忍服务器崩溃导致表损坏，推荐使用InnoDB
* 推荐明确指定二进制日志的名字，log_bin=/var/lib/mysql/mysql-bin
* 在备库上为中继日志指定绝对路径，relay_log
* 如果正在使用5.5并且不介意额外的fsync()导致的性能开销，最好设置：sync_master_info，sync_relay_log，sync_relay_log_info
C.复制的原理
1.基于语句的复制
* 5.0之前只支持基于语句的复制（也称为逻辑复制），主库会记录那些造成数据更改的查询，当备库读取并重放这些事件时，实际上只是把主库上执行过的SQL再执行一遍
* 好处是实现相当简单，日志更加紧凑，不会占用太多带宽
* 问题是基于语句的方式可能并不如其看起来那么便利，还存在一些无法被正确复制的SQL，更新必须是串行的这需要更多的锁
2.基于行的复制
* 5.1开始支持，会将实际数据记录在二进制日志中，跟其他数据库的实现比较想像
* 好处是可以正确地复制每一行，一些语句可以被更加有效地复制
* 如果使用全表更新，则开销会很大，因为每一行的数据都会被记录到二进制日志中，这使得二进制日志事件非常庞大，并且会给主库上记录日志和复制增加额外的负载，更慢的日志记录则会降低并发度
3.基于行或基于语句：哪种更优
* 基于语句的复制模式的优点：当主备的模式不同时，逻辑复制能够在多种情况下工作；基于语句的方式执行复制的过程基本上就是执行SQL语句
* 基于语句的复制模式的缺点：很多情况下通过基于语句的模式无法正确复制，如果正在使用触发器或者存储过程，就不要使用基于语句的复制模式，除非能够清楚地确定不会踫到复制的问题
* 基于行的复制模式的优点：几乎没有基于行的复制模式无法处理的场景；可能减少锁的使用，并不要求这种强串行化是可重复的；会记录数据变更；占用更少的CPU；能够帮助更快地找到并解决数据不致的情况
* 基于行的复制模式的缺点：无法判断执行了哪些SQL；无法知道服务器在做什么；在某些情况下，例如找不到要修改的行时，基于行的复制可能会导致复制停止
4.复制文件
* mysql-bin.index，二进制日志文件
* mysql-relay-bin-index，中继日志的索引文件
*
http://master.info，保存备库连接到主库所需要的信息*
http://relay-log.info，包含了当前备库复制的二进制日志和中继日志坐标
5.发送复制事件到其他备库：log_slave_updates，可以让备库变成其他服务器的主库
6.复制过滤选项
* 在主库上过滤记录到二进制日志中的事件
* 在备库上过滤记录到中继日志的事件
D.复制拓扑
1.基本原则：
* 一个MySQL备库实例只能有一个主库
* 每个备库都必须有一个唯一的服务器ID
* 一个主库可以有多个备库
* 如果打开了log_slave_updates选项，一个备库可以把其主库上的数据变化传播到其他备库
2.一主库多备库
3.主动-主动模式下的主主复制：auto_increment_increment和auto_increment_offset可以让MySQL自动为INSERT语句选择不互相冲突的值
4.主动-被动模式下的主主复制：其中一台服务器是只读的被动服务器
5.拥有备库的主主结构：增加了冗余，能够消除站点单点失效的问题
6.环形复制：每个服务器都是在它之前的服务器的备库，是在它之后的服务器的主库
7.分发主库事实上也是一个备库，提取和提供主库的二进制日志
8.树或金字塔形：减轻了主库的负担，但中间层出现的任何错误都会影响到多个服务器
9.定制的复制方案
* 选择性复制：配置replicate_wild_do_table
* 分离功能：OLTP、OLAP
* 数据归档：在备库上保留主库上删除过的数据
* 将备库用作全文检索
* 只读备库：read_only选项
* 模拟多主库复制
* 创建日志服务器：创建没有数据的日志服务器，更加容易重放并且/或者过滤二进制日志事件
E.复制和容量规划
1.写操作通常是复制的瓶颈，并且很难使用复制来扩展写操作
2.在构建一个大型应用时，有意让服务器不被充分使用，这应该是一种聪明并且蔓延的方式，尤其在使用复制的时候，有多余容量的服务器可以更好地处理负载尖峰，也有更多能力处理慢速查询和维护工作，并且能够更好地跟上复制
F.复制管理和维护
1.在主库上，可以使用SHOW MASTER STATUS命令来查看当前主库的二进制日志位置和配置
2.从库上，使用SHOW SLAVE STATUS
十一、可扩展的MySQL
A.什么是可扩展性
1.可扩展性表明了当需要增加资源以执行更多工作时系统能够获得划算的等同提升（equal bang for the buck）的能力，缺乏扩展能力的系统在达到收益递减的转折点后，将无法进一步增长
2.可扩展性就是能够通过增加资源来提升容量的能力
B.扩展MySQL
1.规划可扩展性最困难的部分是估算需要承担的负载到底有多少，还需要大致正确地估计日程表，需要知道底线在哪里
2.可以做的准备工作：优化性能、购买性能更强的硬件
3.向上扩展（垂直扩展）意味着购买更多性能强悍的硬件
4.向外扩展（横向扩展、水平扩展）：复制、拆分、数据分片
* 按功能拆分（按职责拆分），不同的节点执行不同的任务
* 数据分片，把数据分割成一小片，或者一小块，然后存储到不同的节点中
* 选择分区键（partitioning key）
* 多个分区键
* 跨分片查询，使用C或Java编写一个辅助应用来执行查询并聚合结果集，也可以借助汇总表来执行
* 分配数据、分片和节点
5.通过多实例扩展
6.通过集群扩展
* MySQL Cluster（NDB Cluster）
* Clustrix
* ScaleBase
* GenieDB
* Akiban
7.向内扩展，对不再需要的数据进行归档和清理
8.保持活跃数据独立
C.负载均衡
1.在一个服务器集群中尽可能地平均负载量，通常在服务器前端设置一个负载均衡器
十二、高可用性
A.什么是高可用性
1.高可用性不是绝对的，只有相对更高的可用性，100%的可用性是不可能达到的
2.可用性每提高一点，所花费的成本都会远超之前，可用性的效果和开销的比例并不是线性的
B.导致宕机的原因
1.运行环境问题，最普遍的问题是磁盘空间耗尽
2.性能问题，最普遍的原因是运行很糟糕的SQL，或服务器BUG或错误的行为
3.糟糕的Schema和索引设计
4.复制问题通常由于主备数据不一致导致
5.数据丢失通常由于DROP TABLE的误操作导致，并总是伴随着缺少可用备份的问题
C.如何实现高可用性
1.可以通过同时进行以下两步来获得高可用性
* 可以尝试避免导致宕机的原因来减少宕机时间
* 尽量保证在发生宕机时能够快速恢复
2.提升平均失效时间（MTBF）
* 对系统变更管理的缺失是所有导致宕机的事件中最普遍的原因
* 缺少严格的评估
* 没有正确地监控MySQL的相关信息
3.降低平均恢复时间（MTTR）
* 所有的宕机事件都是由多方面的失效联合在一起导致的，可以通过利用合适的方法确保单点的安全来避免
D.避免单点失效
1.系统中任何不冗余的部分都是一个可能失效的单点
2.可以采用两种方法来为系统增加冗余：增加空余容量和重复组件
3.共享存储或磁盘复制
* 能够为数据库服务器和存储解耦合，通常使用的是SAN
* 两个优点：可以避免除存储外的其他任何组件失效所引起的数据丢失，并为非存储组件建立冗余提供可能
4.MySQL同步复制
* 当使用同步复制时，主库上的事务只有在至少一个备库上提交后才能认为其执行完成
* 完成了两个目标：当服务器崩溃时没有提交的事务会丢失，并且至少有一个备库拥有实时的数据副本
* MySQL Cluster
* Percona XtraDB Cluster
5.基于复制的冗余
* 复制管理器是使用标准MySQL复制来创建冗余的工具
E.故障转移和故障恢复
1.冗余一点也不会增加可用性或减少宕机，和故障转移结合可以帮助更快地恢复，故障转移最重要的部分就是故障恢复
2.提升备库或切换角色
3.虚拟IP地址或IP接管
4.中间件解决方案，可以使用代理、端口转发、网络地址转换或者硬件负载均衡来实现故障转移和故障恢复
5.在应用中处理故障转移
十三、云端的MySQL
A.云的优点、缺点和相关误解
1.优点：
* 云是一种将基础设施外包出去无须自己管理的方法
* 云一般是按照即用即付的方式支付
* 随着供应商发布新的服务和成本降低，云提供的价值越来越大
* 云能够帮助你轻松地准备好服务器和其他资源
* 云代表了对基础设施的另一种思考方式——作为通过API来定义和控制的资源——支持更多的自动化操作
2.缺点：
* 资源是共享并且不可预测的
* 无法保证容量和可用性
* 虚拟的共享资源导致排查故障更加困难
B.MySQL在云端的经济价值
1.云托管比较适合尚处于初级阶段的企业，或者那些持续接触新概念并且本质上是以适用为主的企业
2.大量使用的策略是尽可能又快又便宜地开发和发布应用
3.运行不是很重要的基础设施
C.云中的MySQL的可扩展性和高可用性
1.数据库通常是一个应用系统中主要或唯一的有状态并且持久化的组件
2.MySQL并不具备在一个无共享集群中的对等角色服务器之间迁移的能力
D.四种基础资源
1.CPU通常少且慢
2.内在大小受限制
3.I/O的吞吐量、延迟以及一致性受到限制
4.网络性能还比较好
E.MySQL在云主机上的性能
1.需要高并发的工作负载并不是非常适合云计算
2.那些需要大量I/O的工作负载在云中并不总是表现很好
F.MySQL数据库即服务（DBaaS）
1.将数据库本身作为云资源
十四、应用层优化
A.常见问题
1.什么东西在消耗系统中每台主机的CPU、磁盘、网络，以及内存资源？这些值是否合理？如果不合理，对应用程序做基本的检查，看什么占用了资源
2.应用真是需要所有获取到的数据吗？
3.应用在处理本应由数据库处理的事情吗，或者反过来？
4.应用执行了太多的查询？
5.应用执行的查询太少了？
6.应用创建了没必要的MySQL连接吗？
7.应用对一个MySQL实例创建连接的次数太多了吗？
8.应用做了太多的“垃圾”查询？
9.应用使用了连接池吗？这既可能是好事，也可能是坏事
10.应用是否使用长连接？
11.应用是否在不使用的时候还保持连接撕开？
B.Web服务器问题
1.最常见的问题是保持它的进程的存活（alive）时间过长，或者在各种不同的用途下混合使用，而不是分别对不同类型的工作进行优化
2.如果用一个通用目的的Apache配置直接用于Web服务，最后很可能产生很多重量级的Apache进程
3.不要使用Apache来做静态内容服务，或者至少和动态服务使用不同的Apache实例
4.进程存活时间变短策略：
* 不要让Apache填鸭式地服务客户端
* 打开gzip压缩
* 不要为用于长距离连接的Apache配置启用Keep-Alive选项
C.缓存
1.被动缓存除了存储和返回数据外不做任何事情；主动缓存在访问未命中时做一些额外工作
2.应用可以缓存部分计算结果，所以应用层缓存可能比更低层次的缓存更有效，可以节省两方面的工作：获取数据以及基于这些数据进行计算，重点是缓存命中率可能更低，并且可能使用较多的内存
3.应用层缓存：
* 本地缓存
* 本地共享内存缓存
* 分布式内存缓存
* 磁盘上的缓存
4.缓存控制策略
* TTL（time to live，存活时间）
* 显式失效，如果不能接受脏数据，那么进程在更新原始数据时需要同时使缓存失效
* 读时失效，在更改旧数据时，为了避免要同时失效派生出来的脏数据，可以在缓存中保存一些信息，当从缓存中读数据时可以利用这些信息判断数据是否已经失效
5.可以在后台预先请求一些页面，并将结果存为静态页面，好处：
* 应用代码没有复杂的命中和未命中处理路径
* 当未命中的处理路径慢得不可接受时，这种方案可以很好地工作
* 预生成内容可以避免在缓存未命中时导致的雪崩效应
D.MySQL的替代品
1.搜索：Lucene和Sphinx
2.简单的键值存储：Redis
3.结构化数据：Hadoop
十五、备份与恢复
A.为什么要备份
1.灾难恢复
2.人们改变想法
3.审计
4.测试
B.定义恢复需求
1.规划备份和恢复策略时，有两个重要的需求：恢复点目标（PRO）和恢复时间目标（RTO）
C.设计MySQL备份方案
1.建议
* 在生产实践中，对于大数据库来说，物理备份是必需的：逻辑备份太慢并受到资源限制，从逻辑备份中恢复需要很长时间
* 保留多个备份集
* 定期从逻辑备份（或者物理备份）中抽取数据进行恢复测试
* 保存二进制日志以用于基于故障时间点的恢复
* 完全不借助备份工具本身来监控备份和备份的过程
* 通过演练整个恢复过程来测试备份和恢复
* 对安全性要仔细考虑
2.如果可能，关闭MySQL做备份是最简单最安全的，需要考虑：锁时间、备份时间、备份负载、恢复时间
3.逻辑备份优点：
* 可以用编辑器或像grep和sed之类的命令查看和操作的普通文件
* 恢复非常简单
* 可能通过网络来备份和恢复
* 可以在类似Amazon RDS这样不能访问底层文件系统的系统中使用
* 非常灵活
* 与存储引擎无关
* 有助于避免数据损坏
4.逻辑备份的缺点：
* 必须由数据库服务器完成生成逻辑备份的工作
* 逻辑备份在某些场景下比数据库文件本身更大
* 无法保证导出后再还原出来的一定是同样的数据
* 从逻辑备份中还原需要MySQL加载和解释语句
5.物理备份优点：
* 基于文件的备份，只需要将需要的文件复制到其他地方即可
* 恢复简单
* InnoDB和MyISAM的物理备份非常容易跨平台
6.物理备份缺点：
* InnoDB的原始文件通常比相应的逻辑备份要大得多
* 物理备份不总是可以跨平台
7.除非经过测试，不要假定备份是正常的
8.建议混合使用物理和逻辑两种方式来做备份
9.MySQL备份需要考虑的几点：
* 非显著数据
* 代码
* 复制配置
* 服务器配置
* 选定的操作系统
10.差异备份是对自上次全备份后所有改变的部分做备份，而增量备份则是自从任意类型的上次备份后所有修改做的备份
11.差异、增量备份的建议：
* 使用Percona XtraBackup和MySQL Enterprise Backup中的增量备份特性
* 备份二进制日志，每次备份后FLUSH LOGS
* 不要备份没有改变的表
* 不要备份没有改变的行
* 某些数据根本不需要备份
* 备份所有的数据，然后发送到一个有去重特性的目的地
12.数据一致性：当备份时，应该考虑是否需要数据在指定时间点一致
13.文件一致性：每个文件的内部一致性
14.从备库中备份最大的好处是可以不干扰主库，故意将一个备库延时一段时间对于某些灾难场景非常有用
D.管理和备份二进制日志
1.expire_log_days变量MySQL定期清理日志
E.备份数据
1.生成逻辑备份
* SQL导出：mysqldump方式
* 符号分隔文件备份：使用SELECT INTO OUTFILE以符号分隔文件格式创建数据的逻辑备份
2.文件系统快照
* 支持快照的文件系统和设备包括FreeBSD的文件系统、ZFS文件系统、GNU/Linux的逻辑卷管理（LVM），以及许多的SAN系统和文件存储解决方案
F.从备份中恢复
1.恢复步骤：
* 停止MySQL服务器
* 记录服务器的配置和文件权限
* 将数据从备份中移到MySQL数据目录
* 改变配置
* 改变文件权限
* 以限制访问模式重启服务器，等待完成启动
* 载入逻辑备份文件
* 检查和重放二进制日志
* 检测已经还原的数据
* 以完全权限重启服务器
G.备份和恢复工具
1.MySQL Enterprise Backup
2.Percona XtraBackup
3.mylvmbackup
4.Zmanda Recovery Manager
5.mydunper
6.mysqldump
十六、MySQL用户工具
A.接口工具
1.MySQL Workbench
2.SQLyog
3.phpMyAdmin
4.Adminer
B.命令行工具集
1.Percona Toolkit
2.Maatkit and Aspersa
3.The openark kit
4.MySql workbench
C.SQL实用集
1.common_schema
2.mysql-sr-lib
3.MySQL UDF仓库
4.MySQL Forge
D.监测工具
1.开源的监控工具
* Nagios
* Zabbix
* Zenoss
* OpenNMS
* Groundwork Open Source
* MRTG
* Cacti
* Ganglia
* Munin
2.商业监控系统
* MySQL Enterprise Monitor
* MONyog
* New Relic
* Circonus
* Monitis
* Splunk
* Pingdom
3.Innotop的命令行监控
