?
3.开始对静态slave做数据, 一拆为二
?
4.回放增量写入,直到追上的所有增量,与原cluster基本保持同步
?
5.写入切换由原3 cluster 切换为6cluster?
?
有没有类似飞机空中加油的感觉这是一个脏活累活容易出问题的活为了避免这个我们一般在最开始的时候设计足够多的sharding cluster来防止可能的cluster扩容这件事情
?
?
云计算现在是各大IT公司内部作为节约成本的一个突破口对于数据存储的
mysql来说如何让其成为一个saasSoftware as a Service是关键点。在MS的官方文档中把构建一个足够成熟的SAAS(MS简单列出了SAAS应用的4级成熟度)所面临的3个主要挑战可配置性可扩展性多用户存储结构设计称为"three headed monster". 可配置性和多用户存储结构设计在Mysql saas这个问题中并不是特别难办的一件事情所以这里重点说一下可扩展性。
?
Mysql作为一个saas服务在架构演变为V4.0之后依赖良好的sharding key设计, 已经不再存在扩展性问题只是他在面对扩容缩容时有一些脏活需要干而作为saas,并不能避免扩容缩容这个问题所以只要能把V4.0的脏活变成 1. 扩容缩容对前端APP透明(业务代码不需要任何改动) ?2.扩容缩容全自动化且对在线服务无影响 那么他就拿到了作为Saas的门票.
对于架构实现的关键点需要满足对业务透明扩容缩容对业务不需要任何改动 那么就必须eat our own dog food在你mysql saas内部解决这个问题一般的做法是我们需要引入一个Proxy,Proxy来解析sql协议按sharding key 来寻找cluster, 判断是读操作还是写操作来请求主 或者 从这一切内部的细节都由proxy来屏蔽。
这里借淘宝的图来列举一下proxy需要干哪些事情
百度公开的技术方案中也有类似的解决方案见文章最后资料部分链接
?
对于架构实现的关键点扩容缩容全自动化且对在线服务无影响 扩容缩容对应到的数据操作即为数据拆分和数据合并要做到完全自动化有非常多不同的实现方式总体思路和V4.0介绍的瓶颈部分有关目前来看这个问题比 较好的方案就是实现一个伪装slave的sync slave, 解析mysql同步协议然后实现数据拆分逻辑把全量数据进行拆分。具体架构见下图
其中Sync slave对于Original Master来说和一个普通的Mysql Slave没有任何区别也不需要任何额外的区分对待。需要扩容/缩容时挂上一个Sync slave,开始全量同步+增量同步等待一段时间追数据。以扩容为例若扩容后的服务和扩容前数据已经基本同步了这时候如何做到切换对业务无影响 其实关键点还是在引入的proxy,这个问题转换为了如何让proxy做热切换后端的问题。这已经变成一个非常好处理的问题了.
?
另外值得关注的是2014年5月28日——为了满足当下对Web及云应用需求甲骨文宣布推出MySQL Fabric在对应的资料部分我也放了很多Fabric的资料有兴趣的可以看看说不定会是以后的一个解决云
数据库扩容缩容的手段
