1. 可扩展的Mysql
可扩展性: 通过增加资源提升容量的能力
1.1 考虑负载
容量可以简单地认为是处理负载的能力,考虑负载可从以下几个角度
- 数据量: 很多应用从不物理删除任何数据,应用所积累的数据量是可扩展的普遍挑战
- 用户量: 更多的用户意味着更多的事务,更多的复杂查询
- 用户活跃度
- 相关数据集的大小
1.2 规划可扩展性
- 估算需要承担的负载到底有多少
- 大致正确地估计日程表
- 应用的功能完成多少
- 预期的最大负载是多少
- 如果依赖系统的每个部分分担负载,某个部分失效时会发生什么
1.3 向上扩展(垂直扩展)
- 单台服务器增加各种高性能硬件
- 烧钱有效的方法
- 不应该无限制向上扩展
1.4 向外扩展
- 策略: 复制,拆分,数据分片
- 按功能拆分: 常见做法,根据功能将应用部署在不同服务器,并使用专用的数据库服务器
1.4.1 数据分片
数据分片是目前扩展大型MySQL最通用且最成功的方法
- 应用设计初期考虑到,后期实现就比较容易,否则很难将应用从单一数据存储转换为分片架构
- 文中举例: 通过用户id来对文章和评论进行分片,而将用户的信息保留在单个节点上
- 数据库访问抽象层,降低应用和分片数据之间通信的复杂度
- 如非必要尽量不分片
- 数据分片最大的挑战就是查找和获取数据
- 类似于表分区,选择分区键和数据分片方式是关键,具体请细查
1.5 通过集群扩展
- 可以使用集群或数据库分布式技术根据场景适当解决一些问题
- 书中提到技术: NDB Cluster, Clustrix等技术
1.6 向内扩展
- 对不再需要的数据进行归档和清理
- 需要考虑对应用的影响
- 需要考虑数据逻辑的一致性,例如清理A表历史数据时需要考虑所有关联数据的处理
- 冷热数据分离
1.7 负载均衡
1.7.1 目的
- 可扩展性: 如读写分离时从备库读数据
- 高效性: 把更多工作分配给更好的机器
- 可用性: 使用时刻保持可用的服务器
- 透明性: 客户端无需知道服务器
- 一致性: 如果应用是有状态的,负载均衡器就应该将相关的查询指向同一个服务器
1.7.2 直接连接
1.7.2.1 复制上的读写分离
- 基于查询分离: 将不能容忍脏数据的查询分配到主库,其他分配到备库
- 基于脏数据分离: 让应用检查复制延迟,许多报表类应用使用这个策略
- 基于会话分离: 可以在会话层做一个标记,如果用户修改了数据,则一段时间内总是指向主库
- 基于版本分离: 给用户的操作增加版本号,检查版本号决定从主库还是备库读取数据
1.7.2.3 修改DNS名
- 通过变更DNS名指定的服务器实现
- 缺点很多,不建议
1.7.2.4 转移IP地址
- 在服务器之间转移虚拟地址
- 给服务器分配固定的ip地址,为每个逻辑上的服务使用一个虚拟ip地址
1.7.3 引入中间件
- 负载均衡器,如HAproxy
- 负载均衡算法: 随机, 轮询,最少连接数,最快响应,哈希,权重
- 服务器池中增加或移除服务器: 在配置连接池中的服务器时,要保证有足够多未使用的容量
2. 高可用性
2.2 高可用性实现
- 衡量指标: 平均失效时间(MTBF), 平均恢复时间(MTTR)
- 避免问题: 适当的配置,监控和规范
- 保证在宕机时能快速恢复,系统制造冗余,具备故障转移能力
2.2.1 避免单点失效
- 通过增加冗余避免
- 共享存储或磁盘复制,如果服务器挂了,备用服务器可以挂载相同的文件系统执行需要的恢复操作
- MySQL同步复制
2.2.2 故障转移和故障恢复
- 提升备库或切换角色
- 虚拟IP地址或IP接管: 当MySQL实例失效时可以将IP地址转移到另一台MySQL服务器上
- 使用中间件解决方案
3. 备份与恢复
3.1 设计MySQL备份方案考虑点
- 在线备份还是离线备份
- 逻辑备份还是物理备份
- 非显著数据: 如二进制日志和InnoDB事务日志
- 代码: 存储过程,触发器
- 服务器配置和复制配置
- 外部配置,管理脚本
- 增量备份和差异备份
- 存储引擎和数据一致性
3.2 备份数据方式
- 文件系统中或SAN快照中直接复制数据文件
- Percona XtraBackup 做热备份
3.3 InnoDB崩溃恢复
- 二级索引损坏: 使用OPTIMIZE TABLE修复损坏的二级索引,此外可以通过构建一个新表重建受影响的索引
- 聚簇索引损坏: innodb_force_recovery导出表
- 损坏系统结构: 系统结构包括事务日志等,可能需要做整个数据库的导出和还原,因为InnoDB内部绝大部分的工作可能受影响
4. MySQL用户工具
工欲善其事,必先利其器
4.1 接口工具
- MySQL Workbench: 一站式的工具
- SQLyog: 可视化工具之一
4.2 命令行工具集
- Percona Toolkit
- MySQL Workbench 工具集
4.3 SQL实用集
- common_schema
- MySQL Forge
4.4 监测工具
- Nagios
- Zabbix: 同时支持监控和指标收集的完整系统
- Zenoss: Python写的
- Hyperic HQ: 基于Java
4.5 Innotop命令行监控
主要包括以下功能
- 事务列表
- 当前运行的查询
- 当前锁和锁等待列表
- 服务器状态和变量汇总信息
- InnoDB内部信息
- 复制监控