Day13-数据库服务架构集群

1、数据库高可用应用（MHA）
2、数据库读写分离应用（mysql-proxy）
3、数据库高可用/读写分离（MIC）
4、数据库分布式存储（Mycat）

MGR集群构建（主从群组搭建）
单主模式构建

• 进行主机的配置（2N+1个主机-最少三台实例主机）

loose-group_replication_group_name="eb8441e9-8aef-4a86-a4bc-5beea315f04f"
loose-group_replication_start_on_boot=OFF
loose-group_replication_local_address="10.0.0.51:33061"
loose-group_replication_group_seeds="10.0.0.51:33061,10.0.0.52:33062,10.0.0.53:33063"
loose-group_replication_bootstrap_group=OFF

• 激活构建MGR群组功能

主节点进行激活

change master to master_user='repl',master_password='123' for channel 'group_replication_recovery';
set global group_replication_bootstrap_group=ON;
start group_replication;
set global group_replication_bootstrap_group=OFF;

从节点进行激活

change master to master_user='repl',master_password='123' for channel 'group_replication_recovery';
start group_replication;

检查确认

select * from performance_schema.replication_group_members;
-- 查看集群节点状态信息，以及集群成员信息

# 遇到集群构建异常，可以进行重置操作
stop group_replication;
reset master;
set sql_log_bin=0;
change master to master_user='repl',master_password='123' for channel 'group_replication_recovery';
start group_replication;

多主模式构建

group_replication_single_primary_mode=0
-- 设置参数表示关闭掉单master模式
group_replication_enforce_update_everywhere_checks=1
-- 这个参数设置表示多主模式下，各个节点进行严格一致性检查

1、数据库高可用应用（MHA）

MHA原主节点修复过程
第一步：修复原主节点故障/并重新启动原主节点

systemctl start mysqld

第二步：将数据信息进行恢复
通过备份/通过克隆

第三步：重新构建主从关系

change master to
master_host='10.0.0.52',
master_user='repl',
master_password='123456',
master_auto_position=1;

第四步：重新加入到MHA集群中
方式一：重新编写配置文件

vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.52
port=3306

方式二：利用命令脚本将故障节点加入到mha集群中

[root@xiaoQ-03 ~]# masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --hostname=10.0.0.51 --block=server1 --params="port=3306"

补充：恢复额外补偿功能

mysql -e "show slave status\G"|grep "Master_Log"
cd /data/binlog_server
nohup mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000007 &

第五步：重新运行mha服务

[root@xiaoQ-03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
[root@xiaoQ-03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:109463) is running(0:PING_OK), master:192.168.30.102

第六步：重新切换原主库为主节点
常见错误：

masterha_stop --conf=/etc/mha/app1.cnf
# 执行MHA手工切换
masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.51 --orig_master_is_new_slave --running_updates_limit=10000
...省略部分信息...
It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.30.102(192.168.30.102:3306)? (YES/no):
-- 以上说明信息，表示在进行切换之前，在原有主库节点执行FLUSH NO_WRITE_TO_BINLOG TABLES这个命令
-- 此命令表示，关闭所有打开的表，强制关闭所有正在使用的表，不写入binlog；
-- 因为此时VIP还没有漂移，表示禁止原主库继续写入数据信息

# 关闭原主库的写入功能
db02 [(none)]>FLUSH NO_WRITE_TO_BINLOG TABLES;
Query OK, 0 rows affected (0.01 sec)
It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.30.102(192.168.30.102:3306)? (YES/no): yes
Starting master switch from 192.168.30.102(192.168.30.102:3306) to 192.168.30.101(192.168.30.101:3306)? (yes/NO): yes
-- 进行再一次核实确认，是否进行手工切换
master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes
-- 表示master_ip_online_change_script此脚本没有定义，如果没有禁止当前主库写入的禁止，业务应用仍旧访问当前主库
-- 因为此时VIP还没有进行转移；
[info] Switching master to 192.168.30.101(192.168.30.101:3306) completed successfully.
-- 提示切换完成

显示切换成功后，做检查确认：

• 检查MHA是否启动
• 检查VIP地址是否切换

将MHA重新手动启动
将VIP地址手工漂移

# 进行MHA切换核验
[root@xiaoQ-03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
-- 重新启动MHA程序

[root@xiaoQ-03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 is stopped(2:NOT_RUNNING).
[1]+  退出 1                nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1
-- 检查状态失败，mha没有启动成功，因为vip信息并没有进行有效漂移

masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=192.168.30.102 --orig_master_is_new_slave --running_updates_limit=10000
-- 临时先切换回原有主节点，恢复MHA服务状态

[root@xiaoQ-03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
[1] 65799
[root@xiaoQ-03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:65799) is running(0:PING_OK), master:192.168.30.102
-- mha服务状态恢复

在进行MHA高可用节点在线手工切换时，有以下信息需要注意：

• 在进行MHA高可用手工切换时，无法自动调整原有主库的binlog_server，需要手工重新拉取新主库的binlog；
• 在进行MHA高可用手工切换时，无法进行触发邮件脚本功能，邮件发送功能只能在MHA产生故障转移时触发；
• 在进行MHA高可用手工切换时，需要进行架构主从关系的切换，以及可以调整转移VIP地址信息；
• 在进行MHA高可用手工切换时，需要对切换前的主库进行锁定（FTWRL flush tables with read lock)，避免数据不一致

正确切换方法：

[root@db03 ~]#  cd /usr/local/bin/
root@db03 bin]# cp master_ip_online_change master_ip_online_change.bak
[root@db03 bin]# vim master_ip_online_change
21 my $vip = "10.0.0.50";
22 my $key = "1";
23 my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
24 my $ssh_stop_vip = "/sbin/ifconfig eth0:$key $vip down";
25 my $ssh_Bcast_arp= "/sbin/arping -I eth0 -c 3 -A 10.0.0.50";

# 修改MHA服务程序配置文件：
[root@db03 bin]# vim /etc/mha/app1.cnf
master_ip_online_change_script=/usr/local/bin/master_ip_online_change

# 关闭MHA服务程序进行核查：
[root@xiaoQ-03 ~]# masterha_stop --conf=/etc/mha/app1.cnf
[root@xiaoQ-03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 is stopped(2:NOT_RUNNING).
[root@xiaoQ-03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
MySQL Replication Health is OK.

# 进行MHA服务手工在线切换：
[root@xiaoQ-03 ~]# masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.51 --orig_master_is_new_slave --running_updates_limit=10000
...省略部分信息...
It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.30.102(192.168.30.102:3306)? (YES/no): yes
-- FLUSH NO_WRITE_TO_BINLOG TABLES 命令在原有主库节点需要再执行一次；
Starting master switch from 192.168.30.102(192.168.30.102:3306) to 192.168.30.101(192.168.30.101:3306)? (yes/NO): yes
Sat Jan  7 13:48:50 2023 - [info] Switching master to 192.168.30.101(192.168.30.101:3306) completed successfully.

总结：
01 MHA高可用集群部署过程
02 MHA故障修复过程
03 MHA手动切换过程
重点：MHA工作原理机制–选主原则

2、数据库读写分离应用（mysql-proxy）

在应用数据库主从架构或者数据库冗余架构时，都可以有效保证数据库逻辑故障或物理故障对业务的影响；
但是，这两种架构进行应用时，业务访问过程只是访问主数据库节点，进行读写操作，当并发量大时无型中会对主节点造成不小压力；
因此，可以设计一种新型的业务访问架构方式，可以实现将写数据请求发送到主节点，将读数据请求发送到从节点；
最终，可以有效减少主节点的业务访问压力，这样设计的数据库架构称之为读写分离架构；

读写分离架构最终目的：实现业务写的请求到达主库，实现业务读的请求到达从库，从而减少主库的压力，实现不同请求的压力分担；
可以利用读写分离中间件实现以上的功能需求：atlas(360公司出品) proxySQL
利用读写分离中间件的设置，当业务请求有select查询时，将请求发送给从库，当业务请求有update insert等修改时，将请求发送给主库

proxySQL是基于MySQL的一款开源的中间件的产品，是一个灵活的MySQL代理层，可以实现读写分离：

• proxySQL数据库中间件支持Query路由功能；
• pxoxySQL数据库中间件支持动态指定某个SQL进行缓存；
• proxySQL数据库中间件支持动态加载配置信息（无需重启ProxySQL服务）
• proxySQL数据库中间件支持故障切换和SQL的过滤功能

ProxySQL的参考网站连接：
https://www.proxysql.com/
https://github.com/sysown/proxysql/releases

第一步：安装读写分离软件
通过官方网站或者github可以下载proxySQL软件程序，并上传到数据库服务器中进行安装；
https://repo.proxysql.com/ProxySQL/

# 上传安装软件程序
[root@db03 local]# rpm -ivh proxysql-2.4.6-1-centos7.x86_64.rpm
警告：proxysql-2.4.6-1-centos7.x86_64.rpm: 头V4 RSA/SHA512 Signature, 密钥 ID 8217c97e: NOKEY
准备中...                          ################################# [100%]
正在升级/安装...
   1:proxysql-2.4.6-1                 警告：群组proxysql 不存在 - 使用root
警告：群组proxysql 不存在 - 使用root
################################# [100%]
Created symlink from /etc/systemd/system/multi-user.target.wants/proxysql.service to /etc/systemd/system/proxysql.service