Chinaunix首页 | 论坛 | 博客
  • 博客访问: 859071
  • 博文数量: 186
  • 博客积分: 4939
  • 博客等级: 上校
  • 技术积分: 2075
  • 用 户 组: 普通用户
  • 注册时间: 2010-04-08 17:15
文章分类

全部博文(186)

文章存档

2018年(1)

2017年(3)

2016年(11)

2015年(42)

2014年(21)

2013年(9)

2012年(18)

2011年(46)

2010年(35)

分类: Mysql/postgreSQL

2011-08-13 17:54:26

    相比oracle,MySQL在高可用方面做的实在太差了,可能就因为免费的缘故吧,oracle 有RAC(real application cluster),多个instance连接磁盘阵列或存储,即使其中某个机器instance异常,也不存在传统HA的监控检查和切换时间的空白期,真正做到了高可用,更别说data guard容灾机制了。
 
    我看不少文章用lvs+keepalived,后边挂2个master做master--master 复制,切不论mm复制的主键重复问题,光这个就存在问题,假如只让一个mysql起作用另外一个standby,keepalived只起自动切换作用,完全浪费了一台机器,实质和ms复制没什么区别。假如2个都由VIP分配写数据,那么slave到底连接那一台呢?
何况复制延时问题会导致2个mysql数据都不一致,切不论主主复制给web程序设计带来的潜在风险。
 
   我个人倾向性的办法是主从MS复制,一主多从,主库负责写数据,然后丛库前边放lvs来做读的负载均衡提供读的load balance ,当然复制肯定有延时问题,可以加memcache,把即时写的数据缓存一会,前端读memcache,直到复制完成,根据show slave status来观察。这样不至于出现诡异问题。当然一个主肯定是单点问题,但没办法可以通过前端web放一个测试脚本实时连接做query操作,假如几秒内出现故障,马上启用一台slave,重写php的config(这个可以用dns来做,但dns有cache,还是写hosts好一点)重写另外2个slave的master让复制继续,这一切完全可以由脚本完成。
   假如master挂了,现在服务器起码都是做raid5/10,数据丢失的可能性不大,只是会导致slave上的数据和挂了的master不一致,加上binlog应该可以恢复的95%(看你的备份策略)了,另外主从复制对于现在的服务器设备性能而言,延迟不是太大问题了。
   假如你说写太繁忙了,复制延迟太大,此时可以把不相干的数据表给拆出来单独用一台服务器,然后再做主从复制。这个就是常见的垂直拆分吧,当然要在程序里避免和这个表有关的联合查询,至于为什么,可以看联合查询的东西。
  实际上,我所在的公司基本上都是这种架构,甚至据我了解baidu部分业务都这样来做,虽然切换会影响部分业务,但也是无奈之举,实在不行,考虑oracle吧。
 
    又询问了一个朋友,heartbeat + drbd ,貌似是个不错的方案,2个mysql服务器跑了hearbeat,drbd,数据实时同步类似网络raid1,对外提供VIP,假如某个mysql挂了,vip自动切换到另外一个上,这样对前端web和slave而言,都是透明的,不影响业务。
阅读(978) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~