高性能mysql学习笔记--可扩展性

高性能mysql
十一：可扩展mysql
可扩展性就是能够通过增加资源来提升容量的能力。
11.1 规划可扩展性
考虑问题：
应用的功能完成了多少？许多建议的可扩展解决方案kennel会导致实现某些功能变得更加困难，如果应用的某些核心功能还没开始实现，就很难看出如何在一个可扩展的用用中实现他们。
预期的最大负载多少？考虑负载高峰期的负载大概多少。
如果依赖系统的每个部分来分担负载，在某个部分失效时会发生什么呢？
为扩展赢得时间
在扩展前可以做一些工作：
优化性能，购买性能更强的硬件。
向上扩展：意味着购买更多性能强悍的硬件。
向外扩展：复制，拆分，以及数据分片。
1，按功能拆分
2，数据分片

3，选择分区建
13，生成全局唯一id
多实例扩展
不要在一台性能强悍的服务器上只运行一个服务器实例，可以让数据分片足够小，以使每台机器上都能防止多个分片，
通过集群扩展
向内扩展
处理不断增长的数据和负载最简单的办法是对不再需要的数据进行归档和清理，
考虑问题：
对应用的影响，要归档的行，维护数据一致性，避免数据丢失，解除归档。
保持活跃数据独立
将表划分几个部分（分表），mysql分区
11.3 负载均衡
负载均衡的5个常见目的：可扩展性，高效性，可用性，透明性，一致性，

负载均衡有许多微妙之处，举个例子，其中一个挑战就是管理读/写策略，有些负载均衡技术本身有能够实现这一点，但其他的则需要应用自己知道哪些节点是可读或可写。
3.1 直接连接

1，常见的读写分离：
基于查询分离
最简单的分离方法是将所有不能容忍脏数据的读和写分配到主动或主库，其他的读查询分配到备库上，这种无法有效的使用备库，因为只有少数的查询能容忍脏数据。
基于脏数据分离
这是对查询分离的小改进，先让应用检查复制延迟（怎么检查，不懂），以确定备库数据是否太旧没，许多报表类应用都使用这个策略，只需要晚上加载书库复制到备库即可，并不关心100%跟上主库。
基于会话分离

基于版本分离
跟踪对象的版本号以及（或者）时间戳，通过备库读取对象的版本或时间戳来判断数据是否足够新。
基于全局版本/会话分离
这个办法是基于版本分离和基于会话分离的，当应用执行写操作时，在提交事务后，执行一次show master status操作，然后在缓存中存储主库日志坐标，作为被修改对象(会话)的版本号，当应用连接到备库时，执行show salve status 并将备库上的坐标和缓存中的版本号相对比。
大多数读写分离解决方案都需要监控复制延迟来决策读查询的分配，不管是通过复制或者负载均衡，或者一个中间系统，如果这么做，需要注意通过show slave status 得到seconds_behind_master 列的值并不能准确的用于监控延迟，有第三方工具来帮助监控延迟。
2，修改应用配置
还有一个分发负载的方法是重新配置应用，例如，你可以配置多个机器来分担生成大报表操作的负载。每台机器可以配置成连接到不同的mysql备库。
3，修改dns名

4，转移ip地址

3.2 引入中间件
1，负载均衡器
限制：
除非负载均衡器知道mysql的真实负载，否则在分发请求时可能无法做到很好的负载均衡。
mysql连接也是有状态的，但负载均衡器kennel并不知道如何把所有从单个http会话发送的链接请求固定到一个mysql服务器上
连接池和长链接可能会阻碍负载均衡器分发链接请求。
许多多用途负载均衡器只会针对http服务器做健康和负载检查。
2，负载均衡算法
常用：随机，轮询，最少连接数，最快响应，哈希，权重。
3，在服务器池中增加/移除服务器
3.3 一主多备间的负载均衡
功能分区
过滤和数据分区
将部分写操作转移到备库
保证备库跟上主库
同步写操作：在备库上执行master_pos_wait()函数