基于keepalived配置数据库主从实现高可用
使用keepalived来监听端口,实现数据库的高可用。实现效果,其中一台数据库服务器突然出故障或关机时,应该不影响应用正常运行,等待服务器启动之后,数据能够自动同步,保持数据一致性。
主从配置
架构图及原理
- 主从状态下,必须保证业务数据实际写入Master数据库,Slave数据库只承担读的作用;
- Master 数据库只要发生变化,立马记录到Binary log日志文件中;
- Slave数据库启动一个I/O thread连接Master数据库,请求Master变化的二进制日志;
- Slave I/O获取到的二进制日志,保存到自己的Relay log 日志文件中;
- Slave 有一个 SQL thread定时检查Realy log是否变化,变化那么就更新数据。
数据库资源
数据库 | 数据库IP | 节点 |
---|---|---|
Gbase1 | 192.168.0.52 | Master |
Gbase2 | 192.168.0.53 | Slave |
配置步骤
主master配置
- 修改配置文件,添加以下内容(gs.cnf)
server-id=1
log-bin=gbase-log #开启binlog日志
binlog_fromat=row
重启数据库 2. 重启数据库并登陆数据库 #创建同步用的账号
set SQL_LOG_BIN=0;
CREATE USER 'save'@'%' IDENTIFIED WITH gbase_native_password BY '123456';
#添加权限
grant replication slave on *.* to 'save'@'%' ;
#刷新权限(使立即生效)
flush privileges;
set SQL_LOG_BIN=1;
3、获取binlog文件名和POS
SHOW MASTER STATUS;
配置从slave库
- 修改配置文件,添加以下内容(gs.cnf)
server-id=2
log-bin=gbase-log #开启binlog日志
binlog_fromat=row # 设置binlog日志格式
重启数据库 2. 登陆数据库,根据主master库的binlog文件名和POS进行同步配置
#先停止同步
stop slave;
#同步信息配置
CHANGE MASTER TO
MASTER_HOST='192.168.1.101',
MASTER_USER='save',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='bin-log.000003',
MASTER_LOG_POS=817;
#启动slave同步
start slave;
#查看同步状态
show slave status\G;
基于keepalived实现高可用
- 下载安装包
- 解压到指定目录 tar -zxvf keepalived-1.2.2.tar.gz
- 执行安装检测
./configure --prefix=/usr/local/keepalived
错误代码
configure: error:
OpenSSL is not properly installed on your system. !!!
Can not include OpenSSL headers files.
解决方法
正常如果能够连网络执行一下命令即可,但是由于是内网,通过yum直接安装缺少的包是安装不了的
yum install -y openssl openssl-devel
所以这种环境下只能通过下载离线的相关包。下载地址如下,这个网站rpm包比较齐全,可以收藏一下
[[linux内核相关包下载]
分别下载并安装:
keepalived-1.3.5-1.ns7_4.mips64el.rpm
net-snmp-5.7.2-28.ns7_4.2.mips64el.rpm
net-snmp-agent-libs-5.7.2-28.ns7_4.2.mips64el.rpm
net-snmp-libs-5.7.2-28.ns7_4.2.mips64el.rpm
openssl-1.0.2k-12.ns7_4.2.mips64el.rpm
openssl-devel-1.0.2k-12.ns7_4.2.mips64el.rpm
openssl-libs-1.0.2k-12.ns7_4.2.mips64el.rpm
rpm -ivh example.rpm
配置keepalived
实现原理,主从服务器都设置同一个虚拟ip,如果两台服务器都开启了了数据库服务,则会根据keepalived的priority设置的优先级跳转到优先级高的服务器,keepalived服务通过监听数据库端口,如果监听发现该端口已经关闭,则需要关闭keepalived服务,此时ip自动漂移到备用服务器。
keepalived 相关操作
systemctl start keepalived #启动服务
systemctl stop keepalived #停止服务
systemctl status keepalived # 查看keepalived状态
systemctl restart keepalived # 重启服务
修改默认keepalived.conf
vim /etc/keepalived/keepalived.conf
vrrp_script check_port {#创建一个vrrp_script脚本,检查配置
script "/etc/keepalived/check_port.sh 5258" #配置监听的端口
interval 3 #检查脚本的频率,单位(秒)
}
vrrp_instance VI_1 {
state MASTER #配置为BACKUP节点,一般有三个配置可选MASTER(主机)、BACKUP(备机)
interface ens33 #ifconfig确定
virtual_router_id 51 #路由器标识,MASTER和BACKUP必须是一致的
priority 100 #定义优先级,数字越大,优先级越高,在同一个vrrp_instance下,MASTER的优先级必须大于BACKUP的优先级。这样MASTER故障恢复后,就可以将VIP资源再次抢回来
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.11.25 # 虚拟ip
}
track_script {
check_port #执行指定vrrp_script脚本
}
}
check_port.sh脚本
#!/bin/bash
#keepalived 监控端口脚本
CHK_PORT=$1
echo $CHK_PORT
if [ "$CHK_PORT" != "" ];then
PORT_PROCESS=`lsof -i:$CHK_PORT|grep LISTEN|wc -l`
if [ $PORT_PROCESS -eq 0 ];then
echo "Port $CHK_PORT Is Not Used,End."
sleep 2
PORT_PROCESS=`lsof -i:$CHK_PORT|grep LISTEN|wc -l`
if [ $PORT_PROCESS -eq 0 ];then
#停止keepalived服务
systemctl stop keepalived.service
fi
fi
else
echo "Check Port Cant Be Empty!"
fi
验证结果
- 首先启动两台服务器的数据库、keepalived服务。
- 连接指定虚拟 ip 访问数据库,此时应该先跳转到优先级高的 master 服务器。
- 此时关闭优先级高的数据库服务器,通过虚拟ip访问数据库,此时应该跳转到 Slave 服务器。
- 再次开启主数据库服务器,通过虚拟 ip 访问数据库,此时再次跳转到 master 服务器。
配置过程中遇到的问题及解决方法
shell脚本一直不行
执行shell脚本一直运行不了,提示结束符错误,后面将里面内容只保留了几行,还是有错,
解决2
最后解决办法,将脚本内容copy,然后新建一个脚本。才能够正常执行。 原因:由于开始的脚本是从windows机器拷贝进去的,可能由于中间编码存在一些问题,所以一直报错。
keepalived监听脚本一直执行不了
解决方法
- 需要确定该脚本能够正常执行,所以需要手动执行一下看脚本是否有错。
- 查看系统tail -f /var/log/messages 监控主机日志。 /etc/keepalived/check_port.sh exited due to signal 15 3.vrrp_script{}中的interval时间需大于脚本中的sleep时间,开始两个时间设置成一样大小了。
数据库突然主从同步不了
show slave status /G; 查看slave状态
Slave_IO_Running: Yes
Slave_SQL_Running: No
而且出现了1062错误,还提示
Last_SQL_Error: Error 'Duplicate entry '1020202' for key 'PRIMARY'' on query. Default database: 'bug'. Query: 'insert into testtable (id,mid,pid) values (1020202,1001,0)'
很显然,由于主库重启导致 从库数据不同步而且主键冲突。查看error 日志发现error日志文件变得好大,比以前大了将近好几倍, tail -f gbase_error.log 最开始查看到的是这条信息。 此时由于我在测试时两边数据不一致导致。后面用新建的一个库来测试正常。 如查出现错误,会导造主从复制破坏,此时将不能同步数据,需要手工处理,把两边数据保持一致后,再重新设置同步节点。并针对于一些错误代码,可以选中跳过,否则主从同步容易停止。 修改gs.cnf slave-skip-errors = 1062 (忽略所有的1062错误) 并需要对从库进行数据恢复,保持主从数据库一致性。
总结
这一次设置的主从数据库是用的国产数据库gbase的,但是他是基于mysql的,所以主从的原来和mysql是一模一样的。我们只要掌握了mysql的基础,就能够用同样的方式配置出来gbase的主从。操作数据库时一定要注意备份。慎用rm -rf /xxx 命令。不然真的要删库跑路了。
来源:oschina
链接:https://my.oschina.net/u/1581846/blog/4328115