day09-高可用+读写分离

高可用与读写分离

什么是高可用
企业高可用标准:全年无故障时间
无故障时间           故障时间      
99.9%                0.1%     = 525.6  min        KA+双主                 :人为干预 
99.99%               0.01%    = 52.56  min        MHA+增强半同步+GTID     :半自动化
99.999%              0.001%   = 5.256  min        PXC 、 MGR 、MGC        : 多活
99.9999%             0.0001%  = 0.5256 min        自动化、云化、平台化    : 
MHA的软件结构
` manager 组件
masterha_manger             启动MHA                  ## 启动命令
masterha_check_ssh      	检查MHA的SSH配置状况 
masterha_check_repl         检查MySQL复制状况 
masterha_master_monitor     检测master是否宕机        ## 监控脚本 每隔ping_interval检测主库心跳,一共检测四次
masterha_check_status       检测当前MHA运行状态 
masterha_master_switch  	控制故障转移(自动或者手动)
masterha_conf_host      	添加或删除配置的server信息



2.2 node 组件
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志(不会阻塞SQL线程)
站位不同
在产品经理人的位置

3.1 监控 
3.2 选主
3.3 数据补偿
3.4 故障转移
3.5 应用透明
3.6 自动提醒
3.7 自愈(待开发)
MHA FailOver(故障转移)原理
1. 启动manager 程序: masterha_manger
2. 监控: masterha_master_monitor 每隔ping_interval检测主库心跳,一共检测四次.
3. 如果出现多次检查没有心跳,进入切换流程
4. 选主:  
           'alive   数组: 存活的从节点的编号.
           'lastest数组: 日志最新的从节点编号.  Master_Log_File ,Read_Master_Log_Pos(看的是从库接收到的日志,只要中继日志中能接收到,就肯定有一天可以回放到)
           'pref    数组: 备选从节点的编号. candidate_master>=0(只要大于等于0,就认为你是pref,不管你设置的是多大)
           'bad    数组 : 不应该被选择的从节点编号.
                      'binlog没开,no_master=1,日志差异100000000 pos
                      
          `0       手工切换时,人为指定的节点,被作为新主
          `① if    lastest &&  pref !& bad,被选择为新主 
          `elif  lastest !& bad ,被选择为新主
          `③ elif  pref !& bad  ,被选择为新主
          `elif     alive   !& bad
          `⑤ 报错
           `说明: 如果结果多个节点都满足,按照[serverN]中的N值来选主.
5.  数据补偿 
          `a. 主库SSH能连
              'save_binary_logs 远程保存缺失部分日志到从节点的/var/tmp/xxx,进行补偿.
              ## 其实也就是scp过来,然后source一下
          `b. ssh不能连
               '从节点直接通过apply_diff_relay_logs,计算之间的差异并恢复
			##主节点进行失联之后,就只能两从节点选主之后,进行他们之间的数据互补。 
				
6.  切换主从关系masterha_master_switch
           `解除老的主从关系 stop slave  ;reset slave;
           `构建新的主从 change master to; start slave;
7.  VIP 应用透明 master_ip_failover
8.  故障通知 send_report
9.  将配置文件中的故障节点删掉masterha_conf_host
10. "自杀".
搭建使用
0. MHA高可用架构介绍及搭建过程

0.1 规划:
主库:
51       node 
从库: 
52       node
53       node    manager

0.2 准备环境
3台独立的主机节点,----- (不能再一台主机上使用多实例来做高可用)
1主2从  ----- GTID


0.3 配置关键程序软连接
	## 因为脚本中输出命令的方式使用的是绝对路径,所以必须做软链接
ln -s /usr/local/mysql/bin/mysqlbinlog          /usr/bin/mysqlbinlog
ln -s /usr/local/mysql/bin/mysql                /usr/bin/mysql



0.4 配置各节点互信(各节点之间无密码SSH)
# db01:
rm -rf /root/.ssh 
ssh-keygen 
cd /root/.ssh 
mv id_rsa.pub authorized_keys
scp  -r  /root/.ssh  10.0.0.52:/root 
scp  -r  /root/.ssh  10.0.0.53:/root 

--------------------------------------------------------------

或者: ## 做到互信
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.0.51
scp -rp ./.ssh/*   10.0.0.52:/root/.ssh/
scp -rp ./.ssh/*   10.0.0.53:/root/.ssh/

-------------------------------------------------------------

cat >> ansible_ssh.sh <<EOF
#!/bin/bash
yum install sshpass -y  
rm -fr ~/.ssh/id_rsa
ssh-keygen -f ~/.ssh/id_rsa  -P '' -q
for ip in  51 52 53
do
  sshpass -p123456 ssh-copy-id -f -i ~/.ssh/id_rsa.pub "-o StrictHostKeyChecking=no" 10.0.0.\$ip
done
EOF

-------------------------------------------------------------

各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date



0.5 安装软件
0.5.1 下载mha软件
mha官网:https://code.google.com/archive/p/mysql-master-ha/
github下载地址:https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

0.5.2 所有节点安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node*.rpm


0.5.3 在db01主库中创建mha需要的用户
create user mha@'10.0.0.%' identified with mysql_native_password by 'mha';
grant all privileges on *.* to mha@'10.0.0.%' ;


0.5.4  Manager软件安装(db03)
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
yum install -y  mha4mysql-manager*.rpm




0.6  配置文件准备(db03)

0.6.1 创建配置文件目录
mkdir -p /etc/mha
 
0.6.2 创建日志目录
 mkdir -p /var/log/mha/app1
 
0.6.3 编辑mha配置文件
vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager        
manager_workdir=/var/log/mha/app1            
master_binlog_dir=/data/3306/binlog/      
user=mha                                   
password=mha                               
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root 

                              
[server1]                                   
hostname=10.0.0.51
port=3306                                  
[server2]            
hostname=10.0.0.52
candidate_master=1    ## 当主库宕机之后,可以自动切换到一个从库,然后两个之间在做成一主一从
port=3306
[server3]
hostname=10.0.0.53
port=3306


0.7 状态检查
### 互信检查
masterha_check_ssh  --conf=/etc/mha/app1.cnf 

### 主从状态检查
masterha_check_repl --conf=/etc/mha/app1.cnf 




0.8 开启MHA(db03)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 &


0.9 查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf




  ## 故障测试和修复
宕掉主库,查看现象.
` db01 
	` /etc/init.d/mysql stop	
修复过程:
a. 检查三个节点的状态
	'show slave status;  发现现在52为主,53是从   51是一个没有加入高可用的单独节点   
b. 修复1主2从
	` /etc/init.d/mysql start  先将db01起来
	` db01  mysql
	change master to 
    master_host='10.0.0.153', 
    master_user='repl',
    master_password='123' ,
    MASTER_AUTO_POSITION=1;
    
    	start slave;
    ` show slave status\G;
    在51检查,是否加入到了52.

c. 修复配置文件
	vim /etc/mha/app1.cnf
	[server2]
	hostname=10.0.0.52
	port=3306

	[server3]
	hostname=10.0.0.53
	port=3306

	[server1]
	hostname=10.0.0.51
	port=3306


d. 启动前检测 
	### 互信检查
masterha_check_ssh  --conf=/etc/mha/app1.cnf 

	### 主从状态检查
masterha_check_repl --conf=/etc/mha/app1.cnf 

e. 启动
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 &

f. 查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
应用透明—VIP
` 其实也就是自动地址漂移
vip :   10.0.0.55/24

6.1 vip 故障转移脚本
上传脚本文件到/usr/local/bin 解压

[root@db03 mha_script]# cp -a /opt/mha_script/*  /usr/local/bin

6.2 修改权限 
[root@db03 bin]# chmod +x /usr/local/bin/*

6.3 修改内容
[root@db03 bin]# cp master_ip_failover master_ip_failover.bak

my $vip = '10.0.0.55/24';
my $key = '1';
my $if  = 'eth0';
my $ssh_start_vip = "/sbin/ifconfig $if:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig  $if:$key down";
my $ssh_Bcast_arp= "/sbin/arping -I $if -c 3 -A 10.0.0.55";

6.4 修改Manager 配置文件
vim /etc/mha/app1.cnf 

master_ip_failover_script=/usr/local/bin/master_ip_failover


6.5 重启MHA (只需要重启MHA,不需要重启数据库)
[root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
[root@db03 bin]# 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 &


6.6 手工在主库添加VIP 
[root@db03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf
[root@db02 ~]# ifconfig eth0:1 10.0.0.55/24


6.7 效果测试 
使用navicat 连接测试MHA vip功能。
故障提醒功能
7.1 准备脚本 
[root@db03 bin]# cp send_report send_report.bak1

my $smtp='smtp.qq.com';             # smtp服务器
my $mail_from='xxx@qq.com';    # 发件箱
my $mail_user='xx';           # 用户名 QQ号
my $mail_pass='xx';   # 授权码
my $mail_to=['xxx@qq.com'];    # 收件箱

#my $mail_to=['to1@qq.com','to2@qq.com'];

7.2 修改配置文件 
vim /etc/mha/app1.cnf 
# 添加一行: 
report_script=/usr/local/bin/send_report

7.3 重启MHA
[root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
[root@db03 bin]# 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 &



7.4 模拟主库宕机  
7.4.1 确认主库 
[root@db03 bin]# masterha_check_status  --conf=/etc/mha/app1.cnf 
app1 (pid:27096) is running(0:PING_OK), master:10.0.0.52

7.4.2 宕主库 
[root@db02 ~]# /etc/init.d/mysqld stop 
Shutting down MySQL............ SUCCESS! 

7.4.3 观察 vip 漂移  

7.4.4 观察 邮件


7.5  修复MHA 架构1主2从
日志补偿的冗余方案–binlog_server(异步机制)
8.1 创建必要目录(db03)
mkdir -p /data/binlog_server/
chown -R mysql.mysql /data/*
cd  /data/binlog_server/

				## 查询到当前主库在哪个文件
[root@db03 ~]# mysql -e "show slave status \G"|grep "Master_Log"
              Master_Log_File: mysql-bin.000008
          Read_Master_Log_Pos: 194
        Relay_Master_Log_File: mysql-bin.000008
          Exec_Master_Log_Pos: 194
	
				## 查询到当前谁是主库
[root@db03 binlog_server]# masterha_check_status --conf=/etc/mha/app1.cnf 
app1 (pid:7057) is running(0:PING_OK), master:10.0.0.51

mysqlbinlog  -R --host=10.0.0.52 --user=mha --password=mha --raw  --stop-never  mysql-bin.000005 &
		## 文件的位置,是查看当前主库正在使用的文件名。在这一时刻,开始拉取。


注意:
拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点

8.2 配置文件设置 

vim /etc/mha/app1.cnf 
[binlog1]
no_master=1     `不做选主,只要备份
hostname=10.0.0.53     
master_binlog_dir=/data/binlog_server/

8.3 重启MHA 
[root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
[root@db03 bin]# 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 &




8.4 故障演练及修复

额外修复binlog server 
## 因为你是主库已经坏了,那么日志还是拉取的是主库的,这个时候就只能手动的进行修复切换到一个新的主库上)
[root@db03 binlog_server]# cd /data/binlog_server/
[root@db03 binlog_server]# 
[root@db03 binlog_server]# ll
total 4
-rw-r----- 1 root root 485 Jul 15 12:09 mysql-bin.000004
[root@db03 binlog_server]# rm -rf *
[root@db03 binlog_server]#  mysql -e "show slave status \G"|grep "Master_Log"
              Master_Log_File: mysql-bin.000004
          Read_Master_Log_Pos: 234
        Relay_Master_Log_File: mysql-bin.000004
          Exec_Master_Log_Pos: 234

[root@db03 binlog_server]# mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000006 &


[root@db03 binlog_server]# 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 &
[2] 8375
[root@db03 binlog_server]# masterha_check_status --conf=/etc/mha/app1.cnf 
app1 (pid:8375) is running(0:PING_OK), master:10.0.0.51



8.5 MHA 故障修复大法.

a. 检查修复故障节点(硬件 OS  网络).
b. 检查修复数据库实例 
c. 检查和修复1主2从.
db01  <---->  db02 
stop slave  ; 
reset slave;
db01  ---->  db02 
d. 检查和修复配置文件
e. 检查和修复VIP 
f. 检查和修复binlog server 
g. 使用检查脚本最后确认
h.  启动MHA 
MHA的维护操作 - 在线切换功能
9.1 只切换角色(在db03)

masterha_master_switch  --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.52 --orig_master_is_new_slave --running_updates_limit=10000
		## 查看状态,如果是51,就切到52.如果52是主,就切51 。默认超时时间10s

-------------------------------------------------------------------------
------------------------------------------------------------------------
	## 执行上述语句,出现的报错
	1. `Sun Jan  3 17:24:24 2021 - [error][/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm, ln143] Getting advisory lock failed on the current master. MHA Monitor runs on the current master. Stop MHA Manager/Monitor and try again`
	'提示说,需要先停止mha。停止mha是不会影响数据库的,只是主从不能自动切换
		[root@db03 /usr/local/bin]= masterha_stop  --conf=/etc/mha/app1.cnf
		
	2.`It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 10.0.0.52(10.0.0.52:3306)?(YES/no)`	
    '提示说:在原主库中执行FLUSH NO_WRITE_TO_BINLOG TABLES这个语句。就可以禁止binlog的跟新,不让binlog,往日志文件中刷新了。(必须要做的)做完这个之后,稍等几秒,在yes
    	db02 [(none)]>FLUSH NO_WRITE_TO_BINLOG TABLES;
	 
	3.`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
	'提示说:你是需要通过一个脚本,来禁止主库的写入的话。因为手动切换vip时,vip是不会自动漂移的(因为脚本中定义的是只有主库出现了故障才会漂移,但是现在没有出现故障),所以vip还是原主库,而应用也还会往原主库写,这个时候不就冲突了'
	1. 此种方法 切换,要注意将原主库,FTWRL,否则会造成主从不一致。 flush table with read lock,手动加锁
	2. 手工切换vip
	## 生产中,最佳的做法是下边的方式:



9.2 master_ip_online_change_script功能实现

功能: 在线切换时,自动锁原主库,VIP自动切换

9.2.1 准备切换脚本

vim /usr/local/bin/master_ip_online_change
my $vip = "10.0.0.55/24";
my $key = "1";
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key $vip down";
my $ssh_Bcast_arp= "/sbin/arping -I ens33 -c 3 -A 10.0.0.55";


9.2.2 修改MHA配置文件 
vim /etc/mha/app1.cnf
master_ip_online_change_script=/usr/local/bin/master_ip_online_change

===============
9.2.3 停 MHA
[root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 

9.2.4 检查repl
[root@db03 bin]# masterha_check_repl   --conf=/etc/mha/app1.cnf 
====================


9.2.5 在线切换 
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

9.2.6 重构binlogserver
[root@db03 bin]# ps -ef |grep mysqlbinlog
[root@db03 bin]# kill -9 28144
[root@db03 bin]# cd /data/binlog_server/
[root@db03 binlog_server]# ll
total 4
-rw-r----- 1 root root 194 Apr  1 17:50 mysql-bin.000005
[root@db03 binlog_server]# rm -rf *
[root@db03 binlog_server]# mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000004 &
[1] 28534

9.2.7 启动MHA 
[root@db03 bin]# 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@db03 binlog_server]# masterha_check_status   --conf=/etc/mha/app1.cnf 
app1 (pid:28535) is running(0:PING_OK), master:10.0.0.51
读写分离(proxysql中间件)
ProxySQL是基于MySQL的一款开源的中间件的产品,是一个灵活的MySQL代理层,可以实现读写分离,支持 Query路由功能,支持动态指定某个SQL进行缓存,支持动态加载配置信息(无需重启 ProxySQL 服务),支持故障切换和SQL的过滤功能。 
相关 ProxySQL 的网站:
https://www.proxysql.com/
https://github.com/sysown/proxysql/wiki
安装ProxySQL
# 下载proxySQL
https://proxysql.com/
https://github.com/sysown/proxysql/releases

# 安装proxySQL 
[root@db03 ~]# rpm -ivh proxysql-2.0.10-1-centos7.x86_64.rpm 
[root@db03 ~]# systemctl start proxysql
[root@db03 ~]# netstat -tulnp
tcp        0      0 0.0.0.0:6032            0.0.0.0:*               LISTEN      2115/proxysql       
tcp        0      0 0.0.0.0:6033            0.0.0.0:*               LISTEN      2115/proxysql   

6033  是连接应用节点
6032  是用户管理连接端口 
 
[root@db03 ~]# mysql -uadmin -padmin -h127.0.0.1 -P6032
ProxySQL中管理结构自带系统库
## 在ProxySQL,6032端口共五个库: main、disk、stats 、monitor、stats_history 
`main: 
	'main 库中有如下信息:
	'mysql_servers: 后端可以连接 MySQL 服务器的列表 
	'mysql_users:   配置后端数据库的账号和监控的账号。 
	'mysql_query_rules: 指定 Query 路由到后端不同服务器的规则列表。
	'mysql_replication_hostgroups : 节点分组配置信息
注: 表名以 runtime_开头的表示ProxySQL 当前运行的配置内容,不能直接修改。不带runtime_是下文图中Mem相关的配置。
`disk :
	持久化的磁盘的配置 
`stats: 
	统计信息的汇总 
`monitor:
	监控的收集信息,比如数据库的健康状态等 
`stats_history: 
	ProxySQL 收集的有关其内部功能的历史指标
ProxySQL管理接口的多层配置关系
## 整套配置系统分为三层:
`顶层   RUNTIME 
`中间层 MEMORY  (主要修改的配置表)
`持久层 DISK 和 CFG FILE 

`RUNTIME : 
	代表 ProxySQL 当前正在使用的配置,无法直接修改此配置,必须要从下一层 (MEM层)“load” 进来。 
`MEMORY: 
	MEMORY 层上面连接 RUNTIME 层,下面disk持久层。这层可以在线操作 ProxySQL 配置,随便修改,不会影响生产环境。确认正常之后在加载达到RUNTIME和持久化的磁盘上。修改方法: insert、update、delete、select。
`DISK和CONFIG FILE:
	持久化配置信息。重启时,可以从磁盘快速加载回来。
在不同层次间移动配置
LOAD xxxx  TO RUNTIME;
SAVE xxxx  TO DISK;


## CFG 到 MEM
LOAD MYSQL SERVERS FROM CONFIG
===============================
 ` mysql query rules配置 
##  MEM 加载到runtime
LOAD MYSQL QUERY RULES TO RUNTIME;

##  runtime 保存至 MEM
SAVE MYSQL QUERY RULES TO MEMORY;

## disk 加载到 MEM
LOAD MYSQL QUERY RULES FROM DISK;

## MEM  到 disk 
SAVE MYSQL QUERY RULES TO DISK;

## CFG 到 MEM
LOAD MYSQL QUERY RULES FROM CONFIG

=================================
` MySQL variables配置
##  MEM 加载到runtime
LOAD MYSQL VARIABLES TO RUNTIME;

##  runtime 保存至 MEM
SAVE MYSQL VARIABLES TO MEMORY;

## disk 加载到 MEM
LOAD MYSQL VARIABLES FROM DISK;

## MEM  到 disk 
SAVE MYSQL VARIABLES TO DISK;

## CFG 到 MEM
LOAD MYSQL VARIABLES FROM CONFIG


'总结: 
日常配置其实大部分时间在MEM配置,然后load到RUNTIME,然后SAVE到DIsk。cfg很少使用。
例如 : 
load xxx to runtime;
save xxx to disk;

'注意:
	只有load到 runtime 状态时才会验证配置。在保MEM或disk时,都不会发生任何警告或错误。当load到 runtime 时,如果出现错误,将恢复为之前保存得状态,这时可以去检查错误日志。
ProxySQL应用——基于SQL的读写分离
		## 因为读写分离是基于是否节点里有read_only参数来判定的,然后根据这个参数,来自动识别和加载节点到对应的读或写组
		
0. 从库设定read_only参数
set global read_only=1;
set global super_read_only=1;

1. 在mysql_replication_hostgroup表中,配置读写组编号
		## 一套proxysql是可以管理多个架构组的,而不只是一个。
[root@db03 ~]# mysql -uadmin -padmin -h127.0.0.1 -P6032
insert into 
mysql_replication_hostgroups 
(writer_hostgroup, reader_hostgroup, comment) 
values (10,20,'proxy');

load mysql servers to runtime;
save mysql servers to disk;


db03 [main]>select * from mysql_replication_hostgroups\G
*************************** 1. row ***************************
	writer_hostgroup: 10
	reader_hostgroup: 20
      	check_type: read_only
         	comment: proxy
	1 row in set (0.00 sec)
'说明:
	ProxySQL 会根据server 的read_only 的取值将服务器进行分组。 read_only=0 的server,master被分到编号为10的写组,read_only=1 的server,slave则被分到编号20的读组。所以需要将从库设置:set global read_only=1;


2. 创建监控用户,并开启监控
# 主库创建监控用户
create user monitor@'%' identified with mysql_native_password  by '123';
grant replication client on *.* to monitor@'%';

# proxySQL修改variables表
set mysql-monitor_username='monitor';
set mysql-monitor_password='123';

或者 : 
UPDATE global_variables SET variable_value='monitor'
WHERE variable_name='mysql-monitor_username';
UPDATE global_variables SET variable_value='123'
WHERE variable_name='mysql-monitor_password';
 
 
load mysql variables to runtime;
save mysql variables to disk;


3. 添加主机到ProxySQL
insert into mysql_servers(hostgroup_id,hostname,port) values (10,'10.0.0.51',3306);
insert into mysql_servers(hostgroup_id,hostname,port) values (20,'10.0.0.52',3306);
insert into mysql_servers(hostgroup_id,hostname,port) values (20,'10.0.0.53',3306);

load mysql servers to runtime;
save mysql servers to disk;

# 查询监控日志
db03 [(none)]>select * from mysql_server_connect_log;
db03 [(none)]>select * from mysql_server_ping_log; 
db03 [(none)]>select * from mysql_server_read_only_log;
db03 [(none)]>select * from mysql_server_replication_lag_log;


4. 配置应用用户 

# 主库
create user root@'%' identified with mysql_native_password  by '123';
grant all on *.* to root@'%';

# proxysql 
insert into mysql_users(username,password,default_hostgroup) values('root','123',10);

load mysql users to runtime;
save mysql users to disk;

早期版本,需要开启事务持续化。
	## 如果不开启这个事务持久化,那么它会把一个数据拆分成多个语句,然后进行存放,但是加入之后,会把一个事务当成一个整体。
	## 早期版本,需要手动添加,现在的是默认开启的
update mysql_users set transaction_persistent=1 where username='root';
load mysql users to runtime;
save mysql users to disk;


5.  实用的读写规则
insert into mysql_query_rules(rule_id,active,match_pattern,destination_hostgroup,apply) values (1,1,'^select.*for update$',10,1);
insert into mysql_query_rules(rule_id,active,match_pattern,destination_hostgroup,apply) values (2,1,'^select',20,1);
insert into mysql_query_rules(rule_id,active,match_pattern,destination_hostgroup,apply) values (3,1,'^drop',30,1);


load mysql query rules to runtime;
save mysql query rules to disk;

注: selectfor update规则的rule_id必须要小于普通的select规则的rule_id,ProxySQL是根据rule_id的顺序进行规则匹配。  

6.  测试读写分离
[root@db03 ~]#  mysql -uroot -p123  -P 6033 -h 127.0.0.1 -e "begin;select @@server_id;commit"

[root@db03 ~]#  mysql -uroot -p123  -P 6033 -h 127.0.0.1 -e "select @@server_id;"
db03 [(none)]>select * from stats_mysql_query_digest\G

## 通过定义没有真实存在的组,来屏蔽一些不需要的操作,比如drop,进行屏蔽。
ProxySQL应用扩展——花式路由规则(了解)
1. 基于端口的路由
## 修改ProxySQL监听SQL流量的端口号,监听多端口上。
set mysql-interfaces='0.0.0.0:6033;0.0.0.0:6034';
save mysql variables to disk;
## 重启生效
systemctl restart proxysql

## 设定路由规则
delete from mysql_query_rules;      # 为了测试,先清空已有规则

insert into mysql_query_rules(rule_id,active,proxy_port,destination_hostgroup,apply) 
values(1,1,6033,10,1), (2,1,6034,20,1);

load mysql query rules to runtime;
save mysql query rules to disk;

说明:
	除了基于端口进行分离,还可以基于监听地址(修改字段proxy_addr即可),也可以基于客户端地址(修改字段client_addr字段即可)。
	
2. 基于用户的路由
nsert into mysql_users(username,password,default_hostgroup) 
values('writer','123',10),('reader','123',20);
load mysql users to runtime;
save mysql users to disk;

delete from mysql_query_rules;      # 为了测试,先清空已有规则

insert into mysql_query_rules(rule_id,active,username,destination_hostgroup,apply) 
values(1,1,'writer',10,1),(2,1,'reader',20,1);

load mysql query rules to runtime;
save mysql query rules to disk;
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值