相比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而言，都是透明的，不影响业务。
阅读(1065) | 评论(0) | 转发(0) |
