基于keepalived配置数据库主从实现高可用[亲测有效]

基于keepalived配置数据库主从实现高可用

使用keepalived来监听端口，实现数据库的高可用。实现效果，其中一台数据库服务器突然出故障或关机时，应该不影响应用正常运行，等待服务器启动之后，数据能够自动同步，保持数据一致性。

主从配置

架构图及原理

1. 主从状态下，必须保证业务数据实际写入Master数据库，Slave数据库只承担读的作用；
2. Master 数据库只要发生变化，立马记录到Binary log日志文件中；
3. Slave数据库启动一个I/O thread连接Master数据库，请求Master变化的二进制日志；
4. Slave I/O获取到的二进制日志，保存到自己的Relay log 日志文件中；
5. Slave 有一个 SQL thread定时检查Realy log是否变化，变化那么就更新数据。

数据库资源

配置步骤

主master配置

1. 修改配置文件，添加以下内容（gs.cnf）

server-id=1
log-bin=gbase-log #开启binlog日志
binlog_fromat=row

代码100分

重启数据库 2. 重启数据库并登陆数据库 #创建同步用的账号

代码100分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库

1. 修改配置文件，添加以下内容（gs.cnf）

server-id=2
log-bin=gbase-log   #开启binlog日志
binlog_fromat=row # 设置binlog日志格式

重启数据库 2. 登陆数据库，根据主master库的binlog文件名和POS进行同步配置

代码100分#先停止同步
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 statusG;

基于keepalived实现高可用

1. 下载安装包
2. 解压到指定目录 tar -zxvf keepalived-1.2.2.tar.gz
3. 执行安装检测

./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

验证结果

1. 首先启动两台服务器的数据库、keepalived服务。
2. 连接指定虚拟 ip 访问数据库，此时应该先跳转到优先级高的 master 服务器。
3. 此时关闭优先级高的数据库服务器，通过虚拟ip访问数据库，此时应该跳转到 Slave 服务器。
4. 再次开启主数据库服务器，通过虚拟 ip 访问数据库，此时再次跳转到 master 服务器。

配置过程中遇到的问题及解决方法

shell脚本一直不行

执行shell脚本一直运行不了，提示结束符错误，后面将里面内容只保留了几行，还是有错，

解决2

最后解决办法，将脚本内容copy，然后新建一个脚本。才能够正常执行。 原因：由于开始的脚本是从windows机器拷贝进去的，可能由于中间编码存在一些问题，所以一直报错。

keepalived监听脚本一直执行不了

解决方法

1. 需要确定该脚本能够正常执行，所以需要手动执行一下看脚本是否有错。
2. 查看系统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 命令。不然真的要删库跑路了。