目前公司有一套核心交易数据库配置了 AlWaysON,SQL 2012 版本, 1 主 4 从, 其从库 (8,14, 8.15) 这 2 台只读的从数据库服务器, 后台程序和 wms 等很多程序, 都是直接配置 IP 连接这个 2 个机器, 而且这 2 台机器已经过保, 如果其中一天机器出现故障, 不能使用, 怎么处理?
怎么解决?
先谈谈后果:
这 2 台机器都有很多程序只读查询操作, 一旦一台挂了, 起不来 (虽然概率很低), 连故障服务器的程序, IP 要改, 同时程序要重启, 这些程序和服务, 还很多, 很容易漏. 一旦出现故障, 至少按小时算业务才能恢复, 波及的面很广, 肯定一级事故, 其他最大的老板肯定会知道.
怎么处理:
自己咨询了其他同行他们的做法:
1, 用域名替换 IP, 当 IP 的服务器有问题, 修改 DNS 服务器就可以
2, 使用类似的 MyCAT 中间件, 目的读库有故障漂移到其他读库中
3, 使用硬件, 如携程他们的 A10, 可以做相关的分发
4, 可以使用 SQL AlwaysON 的只读路由, 让程序连主库, 在主库做只读路由分发到读库
的确这些方法都能解决前面提到的读库故障转移:
1, 用域名替换 IP, 同行能用, 但是和他们这边的开发和运维聊了后, 说这个域名替换 IP 的方案不可靠, 因为现在我们程序用域名, 有时就出现莫名其妙的延迟问题, 现在运维的技术只能哈哈, 无法保证. 这个方案不行
2, 使用中间件来做故障转移, 和相关的框架开发, 领导聊了, 结论: 没人没时间, 不稳定, 而且需要大量的测试, 做不了. 这个方案不行
3, 购买 A10 这样的硬件, 贵, 我们提也会被公司否. 这个方案不行
4, 利用 AlwaysON 的只读路由, 自己也想了, 现在因为主库的压力大查读库的, 变成了先要到主库做一次路由分发, 主库压力会更大, 而且路由无法指定到那个机器, 不能做流量控制. 这个方案不行
这一看市面上通用的方法一个也不适合我们, 只能祈祷这 2 台服务器不出故障, 即使出故障, 也能重启后就好了. 真的只有这样的吗? 还有其他办法解决这个难题:
这个问题一直困扰, 怎么解决, 没有其他办法了, 看起来所有的办法都不是很好的, 只能留下一个笨办法
比较好方案: 找到全部连这 2 台的程序配置文件和需要重启的服务, 预先找到全部, 一旦有故障起不来, 立即批量修改和重启. 这样就可以了
但是这个方案我一直想找开发和测试聊, 看看能否做出个 "故障预案", 一直没有去做.
公司一部分的数据库有 MySQL, 在配置 keepalived,MHA, 和 MMM, 大量的使用了虚 IP, 在 CentOS 里配置虚 IP 结合这些开源的组件, 的确很方便, 在 Windows 里是否也可以利用这虚 IP, 如果哪天 8.15 这个数据库服务器挂了, 是否也可以虚 IP
自己想了想, Windows 里加虚 IP, 就是直接加个 IP 就可以了. 如果真的 8.15 挂了, 我把 8.15 的 IP 加到 8.14 服务器, 是否可行?
又出现问题:
Windows 的故障转移集群和 AlwaysON , 连的是 8.15, 把 IP 加到 8.14 是对现有的集群有影响.
后来想了想:
如果真的是 8.15 集群出故障, 启动不来, 不是可以把 8.15 踢出故障转移集群和 AlwaysON, 再添加 IP 到 8.14 不就好了.
这几天测试了一下这个流程, 的确是可以的.
最终的解决方案:
(8.15, 8.14) 这 2 台读库服务器, 出现故障, 无法起来时, 把故障的服务器踢出故障转移集群和 AlwaysON, 再添加新 IP 到其他读服务器上, 同时前提在各读库服务器加上统一的账户和密码. 这样, 虽然不能做到无缝切换,
但也能最大程度上减少故障时间, 等后面条件成熟了, 可以用其他办法.
目前 8.15 和 8.14 因为服务器过保, 目前也准备用这个方案来做服务器替换, 用这个加虚 IP 的方法下架旧服务器和上架新服务器. 目前正在测试, 等切换完后, 再介绍一下切换过程.
总结:
希望对大家解决问题思路上有些启发, 天无绝人之路, 只要你用心, 会有收获, 有时收获还很多!!
来源: https://www.cnblogs.com/zping/p/11278581.html