Linux数据库管理——day8——MHA集群、MySQL

perl语言编写的安装包
1. 解压包
2. 解决配置依赖，配置

perl  Makefile.PL

如果出现报错信息，根据报错 Can't locate 后面的名字，用yum search 查找相关包，并安装，解决依赖
然后再配置，循环直到配置成功
配置成功的标志是每个包后面都有括号，显示相应的版本号
3. 编译安装

make && make install

MHA
简介： MHA是一套优秀的实现MySQL高可用软件，其能确保故障切换过程中保持数据的一致性，达到真正意义上的高可用

环境准备：
1. 准备设备一个管理服务器、一个主库、至少一台待选主库、至少一台从库
2. 所有库都安装好perl基本软件包(资源中MHA压缩包中有)
3. 主库要配置主库配置也要开启从库的功能，不过可以先不开启slave功能，然后所有其他从库都指该主库的IP
4. 待选主库，和主库配置相似，只不过要指定slave主库为上面配置的主库IP
5. 从库配置成主库的从库，实现主从同步
6. 预先设定一个给客户端连接的VIP，然后把VIP绑定到主库的网卡上

原理：
主库和待选主库、从库形成一主多从的结构，管理服务器就是安装 MHA软件用来管理整个主从集群
当主库出现问题，管理服务器会自动根据主库中的二进制日志，识别所有待选主库中数据最新的更新日志，最接近的那个待选库就升级成为新的主库，自动其他所有库的都指向该库，做该库的从库，当原主库修复后，配置修改后，需要将其配置成为当前主库的从库
举例解释：假设当前有主库m0 ，待选库ms1、ms2，从库s1、s2，现在ms1、ms2、s1、s2都是m0的从库，现在m0出故障量，管理服务器检测到后会将m0的二进制日志读取出来，并检测ms1和ms2的更新日志，最接近的假如是ms1，那么ms1就会成为集群的主库，ms2、s1、s2都是他的从库，进行工作，当m0修复完成量，他加入集群后，就会成为一个待选主库，必须配置成为ms1的一个从库，在ms1出故障的时候再和，ms2一起竞争主库。
而客户端的访问的是一个预设定的VIP，虚拟IP地址，谁做主库，这IP就被 MHA管理服务器绑定在网卡上，那么客户端访问的是这个VIP，那么就一定访问的是当前担任主库的那个服务器

相关命令(每个命令后面必须跟上 --conf=配置文件的绝对路径)

masterha_check_ssh	检查MHA的SSH配置状况
masterha_check_repl	检查MySQL主从同步情况
masterha_manager	启动MHA
masterha_check_status	检测MHA运行状态

配置：
1. 在管理服务器上创建管理命令
拿源码包解压，然后进入目录中，进行编译安装，然后进去寻找一些配置文件和管理命令
把perl编译安装的包中bin下有很多命令，将其拷贝到PATH下任意一个位置即可(例如：/usr/local/bin)
2. 创建主配置
源码编译的文件夹中 samples/conf/ 有个app1.cnf ，将其拷贝到自己规划的 MHA工作目录，编辑配置文件

[server default]
manager_workdir=/MHA工作目录
manager_log=/MHA工作目录/日志名称

# 当检测主库出现故障，会自动将主库切换给被选库中数据最接近的那个库
master_ip_failover_script=/MHA工作目录/master_ip_failover(MHA错误转移脚本)

# ssh远程的用户和端口号
ssh_user=root
ssh_port=22

# 主从同步使用的用户名和密码
repl_user=repluser
repl_password=密码

# 管理、检测 数据库集群的用户名和密码
user=root
password=密码

[server1]
hostname=主库的IP
candidate_master=1

[server2]
hostname=待选主库的IP
candidate_master=1

[server3]
hostname=从库的IP
no_master=1

修改脚本master_ip_failover(可以直接用tar包中的，也可以自己修改编译安装后，程序中的samples/scripts/的脚本)

my $vip = '预定义的VIP/24';
my $key = "1";
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";

3. 启动服务(必须确保把相关命令拷贝到PATH下，如果没有只能在命令前面加上命令所在的绝对路径)
3.1 检查ssh连接

[root@mha ~]# masterha_check_ssh --conf=/配置文件所在位置/app1.cnf
# 如果返回信息如下则代表成功，否则根据报错信息进行修正
[info] All SSH connection tests passed successfully.

3.2 检查主从同步配置

[root@mha ~]# masterha_check_repl --conf=/配置文件所在位置/app1.cnf
# 如果返回信息如下则代表成功，否则根据报错信息进行修正
MySQL Replication Health is OK.

3.3 启动管理服务

# 启动服务后，终端会宕死，这是正常的，再开一个终端检查服务状态(当然也可以放入后台，不过会出现提示信息，最好还是不要用这个终端了)
masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover
# --remove_dead_master_conf 代表当服务器出现故障，将其在配置文件中的内容删除
# --ignore_last_failover 短时间内频繁出现问题，就不工作

4. 查看状态

masterha_check_status --conf=/etc/mha/app1.cnf
# 如果显示如下，代表服务启动失败
app1 is stopped(2:NOT_RUNNING).
# 如果显示如下，代表服务启动成功
app1 (pid:2298) is running(0:PING_OK), master:
# 如果显示如下，代表正在启动，等一会再查看即可
app1 monitoring program is now on initialization phase(10:INITIALIZING_MONITOR). Wait for a while and try checking again.

附：如何判断管理服务器如何判断主库服务应该给哪个待选库：
计算机是根据，待选库中的中继日志的修改时间，时间较为新的那个待选库将成为主库
如果有新的从库加入集群，那么他们的日志修改时间就是加入集群的时间，当然如果后来还有数据添加进来，那时间就会一起被覆盖

注意点：
1. 服务MHA是一次性的，他检测到一次问题并调度解决后就不会继续检测了，服务也会立刻停止
2. 如果有 --remove_dead_master_conf 选项，那么可以在服务停止后随即人工再次开启监控服务，不过这时候，集群中不再有那个出现问题的服务器，配置文件中也没有与之相关的信息
3. 如果需要将出现问题的服务器重新假如集群必须，手动把这个服务器配置成为当前集群中主库的从库，如果原先的MHA服务添加了选项(--remove_dead_master_conf)，那么就需要修改配置文件，将这个服务器添加进去，最后手动重新启动 MHA服务。

Linux数据库管理——day8——MHA集群、MySQL

猜你喜欢