随着生产环境用户访问的与日俱增,数据库访问压力也随之增大,近期准备对生产环境中的单一数据库进行扩容,增加多台slave数据库,进行读写分离操作,经过若干测试,最终选择使用Haproxy方案,在haproxy版本选型时,选择了1.4的版本,因为在1.4.9开始,haproxy 增加了option mysql-check 健康检查功能,其工作原理是建立对应的Mysql连接,然后断开来判断数据库当前的健康状况。而实际生产环境中对数据一致性要求较高,不仅需要对mysql进行健康检查,也需要的slave节点的repliation状态
(Slave_IO_Running,Slave_SQL_Running,Seconds_Behind_Master)进行检查,故现阶段的haproxy健康检查功能无法满足需求,需自己进行定制.
其检查流程为:
(1) 检查时指定需要检查的主机,端口,用户名,密码(可为空),同时需要指定检查的数据库类型(对于master类型数据库,则只需连接进去然后通过”select version()”来检查健康状态,对于slave类型的数据库,则需要增加”show slave status” replication 状态检查)
(2)结果采用HTTP方式返回,指定不同的状态码对应不同的检查状态,如下所示:
· 200 为服务器端健康检查OK(健康)
———————————————————————-
·401 为检查段MySQLdb python模块没有安装(此程序采用python开发)
·405 为当前检查程序不支持该版本的mysqld (其主要原因是因为在不同的mysqld版本中,其”show slave status”的输出格式不同)
·400 为其他检查端未知异常
———————————————————————-
·501 为服务端(被检查端)连接失败 (其原理是捕捉错误码为2003的mysql报错)
·502 为服务端(被检查端)认证失败(其原理是捕捉错误码为1045的mysql报错)
·503 为服务端(被检查端)连接成功,但是执行查询失败(如无权限等情况)
·504 为服务端(被检查端)连接成功,且该服务端为slave类型,此时replication状态无法查询(如没有启动slave)
·505 为服务端(被检查端)连接成功,且该服务端为slave类型,此时检查replication 状态,显示”Slave_IO_Running”不等于”Yes”
·506 为服务端(被检查端)连接成功,且该服务端为slave类型,此时检查replication 状态,显示”Slave_SQL_Running”不等于”Yes”