高性能MySQL读书笔记 (六)

1. 可扩展的Mysql

可扩展性: 经过增长资源提高容量的能力

1.1 考虑负载

容量能够简单地认为是处理负载的能力,考虑负载可从如下几个角度

1. 数据量: 不少应用从不物理删除任何数据,应用所积累的数据量是可扩展的广泛挑战

2. 用户量: 更多的用户意味着更多的事务,更多的复杂查询

3. 用户活跃度

4. 相关数据集的大小

1.2 规划可扩展性

1. 估算须要承担的负载到底有多少

2. 大体正确地估计日程表

3. 应用的功能完成多少

4. 预期的最大负载是多少

5. 若是依赖系统的每一个部分分担负载,某个部分失效时会发生什么

1.3 向上扩展(垂直扩展)

1. 单台服务器增长各类高性能硬件

2. 烧钱有效的方法

3. 不该该无限制向上扩展

1.4 向外扩展

1. 策略: 复制,拆分,数据分片

2. 按功能拆分: 常见作法,根据功能将应用部署在不一样服务器,并使用专用的数据库服务器

1.4.1 数据分片

数据分片是目前扩展大型MySQL最通用且最成功的方法

1. 应用设计初期考虑到,后期实现就比较容易,不然很难将应用从单一数据存储转换为分片架构

2. 文中举例: 经过用户id来对文章和评论进行分片,而将用户的信息保留在单个节点上

3. 数据库访问抽象层,下降应用和分片数据之间通讯的复杂度

4. 如非必要尽可能不分片

5. 数据分片最大的挑战就是查找和获取数据

6. 相似于表分区,选择分区键和数据分片方式是关键,具体请细查

1.5 经过集群扩展

1. 可使用集群或数据库分布式技术根据场景适当解决一些问题

2. 书中提到技术: NDB Cluster, Clustrix等技术

1.6 向内扩展

1. 对再也不须要的数据进行归档和清理

2. 须要考虑对应用的影响

3. 须要考虑数据逻辑的一致性,例如清理A表历史数据时须要考虑全部关联数据的处理

4. 冷热数据分离

1.7 负载均衡

1.7.1 目的

1. 可扩展性: 如读写分离时从备库读数据

2. 高效性: 把更多工做分配给更好的机器

3. 可用性: 使用时刻保持可用的服务器

4. 透明性: 客户端无需知道服务器

5. 一致性: 若是应用是有状态的,负载均衡器就应该将相关的查询指向同一个服务器

1.7.2 直接链接

1.7.2.1 复制上的读写分离

1. 基于查询分离: 将不能容忍脏数据的查询分配到主库,其余分配到备库

2. 基于脏数据分离: 让应用检查复制延迟,许多报表类应用使用这个策略

3. 基于会话分离: 能够在会话层作一个标记,若是用户修改了数据,则一段时间内老是指向主库

4. 基于版本分离: 给用户的操做增长版本号,检查版本号决定从主库仍是备库读取数据

1.7.2.3 修改DNS名

1. 经过变动DNS名指定的服务器实现

2. 缺点不少,不建议

1.7.2.4 转移IP地址

1. 在服务器之间转移虚拟地址

2. 给服务器分配固定的ip地址,为每一个逻辑上的服务使用一个虚拟ip地址

1.7.3 引入中间件

1. 负载均衡器,如HAproxy

2. 负载均衡算法: 随机, 轮询,最少链接数,最快响应,哈希,权重

3. 服务器池中增长或移除服务器: 在配置链接池中的服务器时,要保证有足够多未使用的容量

2. 高可用性

1. 高可用性意味着更少的宕机时间

2.1 宕机缘由

1. 磁盘空间不足

2. 糟糕的sql或者服务器bug引发

3. 糟糕的表和索引设计

4. 复制问题一般因为主备数据不一致致使

2.2 高可用性实现

1. 衡量指标: 平均失效时间(MTBF), 平均恢复时间(MTTR)

2. 避免问题: 适当的配置,监控和规范

3. 保证在宕机时能快速恢复,系统制造冗余,具有故障转移能力

2.2.1 避免单点失效

1. 经过增长冗余避免

2. 共享存储或磁盘复制,若是服务器挂了,备用服务器能够挂载相同的文件系统执行须要的恢复操做

3. MySQL同步复制

2.2.2 故障转移和故障恢复

1. 提高备库或切换角色

2. 虚拟IP地址或IP接管: 当MySQL实例失效时能够将IP地址转移到另外一台MySQL服务器上

3. 使用中间件解决方案

3. 备份与恢复

3.1 设计MySQL备份方案考虑点

1. 在线备份仍是离线备份

2. 逻辑备份仍是物理备份

3. 非显著数据: 如二进制日志和InnoDB事务日志

4. 代码: 存储过程,触发器

5. 服务器配置和复制配置

6. 外部配置,管理脚本

7. 增量备份和差别备份

8. 存储引擎和数据一致性

3.2 备份数据方式

1. 文件系统中或SAN快照中直接复制数据文件

2. Percona XtraBackup 作热备份

3.3 InnoDB崩溃恢复

1. 二级索引损坏: 使用OPTIMIZE TABLE修复损坏的二级索引,此外能够经过构建一个新表重建受影响的索引

2. 聚簇索引损坏: innodb_force_recovery导出表

3. 损坏系统结构: 系统结构包括事务日志等,可能须要作整个数据库的导出和还原,由于InnoDB内部绝大部分的工做可能受影响

4. MySQL用户工具

工欲善其事,必先利其器

4.1 接口工具

1. MySQL Workbench: 一站式的工具

2. SQLyog: 可视化工具之一

4.2 命令行工具集

1. Percona Toolkit

2. MySQL Workbench 工具集

4.3 SQL实用集

1. common_schema

2. MySQL Forge

4.4 监测工具

1. Nagios

2. Zabbix: 同时支持监控和指标收集的完整系统

3. Zenoss: Python写的

4. Hyperic HQ: 基于Java

4.5 Innotop命令行监控

主要包括如下功能

1. 事务列表

2. 当前运行的查询

3. 当前锁和锁等待列表

4. 服务器状态和变量汇总信息

5. InnoDB内部信息

6. 复制监控