第9章：
MySQL需要的四种基本资源:cpu、内存、硬盘以及网络资源，倾向于很多快速的cpu
合理做法：不要超过两个插槽；内存方面 经济的服务器内存：18个DIMM槽，单条8GB（会变）
持久化存储选择：SAN、传统硬盘、固态存储设备（以提供性能的次序排序）
- 需要功能和纯粹容量时，SAN；昂贵、小的随机I/O很大延迟（慢的互联方式、工作集太大）
- 传统硬盘很大、便宜，随机读慢，best 服务器硬盘组成RAID 10卷，带有电池保护单元的RAID控制器，设置写缓存未writeBack
- 固态小且昂贵，随机I/O快 ；SSD便宜更慢缺可靠性验证：做RAID提升；PCIe昂贵容量有限，非常快且可靠不需要RAID
操作系统：存储、网络、虚拟内存管理
使用GNU/Linux，采用XFS文件系统，且为服务器页面交换倾向率 硬盘队列调度器设置恰当的值
10、复制
2种方式：通主库记录二进制日志，备库重放日志来异步复制
推荐配置：
1、明确指定二进制日志名字：保证二进制日志名在all服务器上一致 log_bin
2、备库：为中继日志指定绝对路径
11章
构建高可扩展性系统原则：
1、在系统内尽量避免串行化和交互
2、避免不同节点间的交互
2、助规划可扩展性：
应用的功能完成了多少？预期的最大负载是？某个系统失效会发生什么
数据分片最大挑战：查找和获取数据：如何查找数据取决于如何分片
负载均衡：服务器前端设置一个负载均衡器，将请求路由至最空闲的可用服务器
实现应用所明确需要的，为可能的快速增长做好预先规划
12高可用性
在宕机造成的损失与降低宕机时间所花费的成本间取一个平衡
宕机：
运行环境：裁判空间耗尽
性能：运行糟糕的SQL，服务器bug、错误行为，糟糕的schema 索引设计
复制：主备数据不一致
数据丢失或损坏：DROP TABLE误操作，缺少可用备份
其他：……
实现高可用性：
1、适当配置、监控、规范或安全保障措施避免人为失误
2、系统中造冗余，且具备故障转移能力
提升平均失效时间MTBF
使用innodb并进行适当配置、skip_name_resolve禁止DNS
备库只读，不让复制自启动、定期审查查询语句、归档清理不需要的数据
禁用查询缓存（除非能证明有效）、避免使用复杂特性（复制过滤 触发器）
监控重要组件和功能，尽量记录服务器状态和性能指数、定期检查复制完整性
为文件系统保留一些空间，养成习惯、评估管理系统的改变、状态及性能信息
测试恢复工具和流程（含从备份中恢复数据）、最小权限原则、系统干净 整洁
好的命名和组织约定、谨慎安排升级数据库服务器、升级前使用诸如Percona Toolkit的pt-upgrade类工具检查系统
降低平局恢复时间MTTR
一个能够提供冗余和故障转移能力的系统架构
团队成员是最重要的高可用性资产
14 应用层优化
缓存：
找到正确的粒度和缓存过期策略组合
决定哪些内容适合缓存，缓存在哪里
被动缓存：除了存储和返回数据不做其他事情 memcached
主动缓存：缓存未命中做额外工作，将请求转发给应用的其他办部分生成请求结果，存储并返回 squid
测量：剖析每一层问题；检查web服务器配置和缓存
15备份与恢复
还原：从备份文件获取数据
恢复：当异常发生后对一个系统或其部分的拯救
逻辑备份：导出；物理备份：复制原始文件
先使用物理复制，以此数据启动MySQL服务器实例运行mysqlcheck，周期性使用mysqldump执行逻辑备份
1、备份二进制日志：备份后使用flush logs开始新的二进制日志（只需备份新的二进制日志）
2、不备份没有改变的表，MyISAM记录每个表的最后修改时间，通过查看磁盘上的文件运行show table status查看时间，使用innodb 利用触发器记录最后修改时间
3、不备份无改变的行，某些数据不需要备份，至少一周一次全备份
数据一致性：数据指定时间点一致；文件一致性
innodb每次启动检测数据和日志文件，是否需要恢复过程：据日志文件将事务应用到数据文件，回滚未提交变更
恢复损坏的InnoDB数据：
optimize table修复损坏的二级索引；聚簇索引：innodb_force_recovery导出表；
小结：
无侵入式二进制原始数据备份：
从文件系统或SAN快照中直接复制数据文件；使用percona xtraBackup热备份
备份二进制日志，尽可能久地保存多份备份的数据和二进制文件
16、MySQL用户工具
接口工具
帮助运行查询，创建表和用户，执行其他日常任务等
命令行工具集
Percona Toolkit：日志分析、复制完整性检测、数据同步、模式和索引分析、查询建议和数据归档目的
SQL实用集
common_schema：针对服务器脚本化和管理的代码和视图
开源监控工具
nagios：问题检测和告警系统，文件：周期性检测服务器，将结果与默认 自定义阈值比较 发给联系人 难维护
zabbix：同时支持监控和指标收集的完整系统，数据库；配置简单、灵活、可扩展，图形