首页 > 数据库 > MySQL中间件的一些思考

MySQL中间件的一些思考

2013年1月30日 6,933 views 发表评论 阅读评论

MySQL中间件的一些思考

下午特地花2个多小时 做了一些思考. 本着分享的精神,摘录了工作邮件的部分内容发这里. 希望能帮到有同样需求的人.  我说的中间件是代理所有的请求访问,  相对于应用路由,会有一些性能上的损耗,适合流量大点的业务.

=====================
1.需以集群的思路去设计,部署和维护,所有模块的安装,部署,启动,关闭,监控,收集信息,都在一个统一的平台(界面)完成;举一些例子: 可以直观得看到某个应用的TPS,以及response time,需要关注资源的使用情况,报警…..略….
2.关于mha里日本老外实现的日志补齐功能: 要看应用是否能接受丢失少量记录,其实大部分公司大部分应用可以接受的.这个开发成本较高,而且需要权限能访问到二进制日志.  5.5的半同步复制,5.6的全局事务日志 都可以让以后的日志更安全可靠,高可用变得更简单 ,还是让MySQL来做更专业的事吧.
3. 中间件的方案引入了一定开销,相对比应用直接判断路由,效率会低些,但这个不太重要. 主要的缺陷是引入了单点, 所以中间件(Proxy)自身需要实现冗余.还需要客户端/应用程序 支持,做到无单点高可用. LVS类似的方案也是可以的,但你需要构建一个LVS的管理平台。
4. 关于MySQL一主多从切换  一般此类架构是为了实现读写分离,中间件实现难度大 ,目前应用层支持读写分离的技术是成熟可靠的,没有必要在中间件上做.  要做到监控主从延时,在从库延时超过一定阀值后,摘掉这个从节点,在从节点滞后小于阀值,又加入这个节点.   读写分离,对于从库可能还需要负载均衡算法.目前已知的的算法有:随机,轮询,最少连接,最快响应,哈希,权重,相对来说,随机,轮询(权重)等算法 实现成本更小,  由于数据库的缓存对于应用的性能影响很大,高并发的业务预热数据是需要一定时间的,那么新加入的节点如何慢慢接受应用请求需要考量具体采用什么算法,主要还是取决于应用负载的类型, 如果有多种算法可供选择,那么就更有针对性.同时,一个健康的监控策略需要确保多台从库的架构宕机一台,仍然可以正常提供服务,这中间是需要一个容量规划的算法的。Proxy的同理,也需要一个容量规划和预警,以免出现瓶颈。

5.支持MySQL互为主从切换   如果中间件可以友好的断开连接,确保任何时刻,只写其中一个库, 那么我们倾向于以后都是用master-master架构,为了避免万无一失, 所以有必要给予mha super权限,设置当前非活动的数据库为readonly状态,切换的时候才设置为可读写 .
6,7,8略

 

9. 关于更高级的特性:支持队列, 就是可以缓存用户的请求,当DB server变得可用后,再把这部分请求给DB.

10. 中间件面对的是专业的DBA,所以不需要有太多的限制,但需要有充分的各种视图辅助DBA做决策。

 

 » 转载保留版权:老陈 » 《MySQL中间件的一些思考》
 » 如果喜欢可以: 点此订阅本站
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.