一、MYSQL 主从复制
主从复制作用：
(1)处理数据库的物理损坏
(2)架构演变的基础（高可用，读写分离，分布式等）
1、主从复制搭建前提
(1)至少两台以上的mysql实例，（并定义主从，不同的server_id，主库开启二进制日志）
(2)主库需要开启专门的复制用户
(3)从库提前进行数据补偿
(4)告知从库，主库的：ip port,user,passwd 复制的起点（change master to）
2、搭建主从复制
2.1、准备两个数据库节点(我准备了 db01,db02两个节点)
保证主库的server_id 小于从库
保证数据库开启二进制日志
2.2 在主库创建复制用户（权限：replication slave）
[root@db01 ~]# mysql -uroot -p123456 -e "grant replication slave on . to repl@'10.0.0.%' identified by '123456';"
2.3备份主库数据恢复到从库：
[root@db01 ~]# mysqldump -uroot -p123456 -A -E -R --triggers --master-data=2 --single-transaction >/tmp/date +%F.sql 2>/dev/null
[root@db01 /tmp]# scp 2019-09-02.sql 10.0.0.52:/tmp
[root@db02 /tmp]# mysql -uroot -p123456
2.4在从库指明主库的ip port,user,passwd 复制的起点（change master to）
在恢复到从库的数据日志中找到位置点： CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=154;
help change master to
CHANGE MASTER TO
MASTER_HOST='master2.example.com',
MASTER_USER='replication',
MASTER_PASSWORD='password',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;
在从库下执行：
[root@db02 /tmp]# mysql -uroot -p123456
mysql> CHANGE MASTER TO
-> MASTER_HOST='10.0.0.51',
-> MASTER_USER='repl',
-> MASTER_PASSWORD='123456',
-> MASTER_PORT=3306,
-> MASTER_LOG_FILE='mysql-bin.000015',
-> MASTER_LOG_POS=154,
-> MASTER_CONNECT_RETRY=10;
Query OK, 0 rows affected, 2 warnings (0.39 sec)
2.5在从库启动复制的专用线程
[root@db02 /tmp]# mysql -uroot -p123456 -e "start slave;"
2.6 判断主从复制是否成功
[root@db02 /tmp]# mysql -uroot -p123456 -e "show slave status\G" |grep Running
排错:
遇见此情况不要慌乱，首先查看日志，看看是什么报错
[root@db02 /tmp]# mysql -uroot -p123456 -e "show slave status\G" |grep Running
mysql: [Warning] Using a password on the command line interface can be insecure.
Slave_IO_Running: No
Slave_SQL_Running: Yes
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
mysql主从配置uuid相同错误解决
配置mysql主从时，由于是拷贝的mysql目录，导致主从mysql uuid相同， Slave_IO无法启动，报错信息如下：
The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
解决办法:修改mysql data 目录下auto.cnf 文件中uuid的值，使两台mysql不同即可，修改后重启mysql服务。
3、主从复制原理
3.1主从复制涉及到的文件
主库
二进制日志
从库
relaylog ：存放主库发送的二进制日志
master.info :存放主库的信息
relaylog.info :relaylog 信息，记录了已经执行（回放）的relaylog的位置点
3.2 涉及到的线程
主库
使用mysql> show processlist;查看
Binlog Dump thread
从库
IO线程 Slave_IO_Running: Yes
SQL线程 Slave_SQL_Running: Yes
4、主从复制监控
(1) 主库相关信息(master.info)
Master_Host: 10.0.0.51
Master_User: repl
Master_Port: 3306
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 154
(2) 从库中继日志信息(relay.info)
Relay_Log_File: db01-relay-bin.000005
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 154
(3) 从库的线程状态,异常信息
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
(4) 过滤复制相关信息
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
(5) 主从延时的判定（落后于主库的时间）
Seconds_Behind_Master: 0
(6) 延时从库（主动延迟）
SQL_Delay: 0
SQL_Remaining_Delay: NULL
(7) GTID复制信息
Retrieved_Gtid_Set:
Executed_Gtid_Set:
5、主从故障
5.1 如何监控
mysql -uroot -p123456 -e "show slave status \G" |egrep " Last|Running"
5.2 原因
5.2.1 IO 故障
(1) 连接主库
ip port user passwd
网络
主库宕机
防火墙
主库连接数上限
[root@db01 ~]# mysql -urepl -p123 -h 10.0.0.58 -P 3307
(2) 请求日志
主库二进制日志
如果是二进制日志无法同步按照一下方法执行即可。
stop slave;
reset slave all;
mysql -S /data/3308/mysql.sock -e "CHANGE MASTER TO MASTER_HOST='10.0.0.51',MASTER_USER='repl',MASTER_PASSWORD='123',MASTER_PORT=3307,MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154;"
start slave
(3) 接收日志
I/O 线程down掉，一般时有人stop slave; 重启即可 。
(4) 写入日志
主库或从库的relaylog 文件损坏
解决方法1：最稳妥的做法是重新做主从.
如果数据量大可以使用第2种方法：pt-table-checksum校验、pt-table-sync修复数据
5.2.2 SQL 故障
回放relaylog
(1) relaylog损坏
(2) 回放语句失败(执行SQL为什么会失败)
一般是因为主从库数据不一致，一般有一下几个方面的问题：
创建的对象已存在
修改的对象不存在
约束性的冲突
5.3 传统主从复制的一些缺点
人为的写入 --解决办法--只读从库,中间件
只读库设置方法：在配置文件添加以下两个参数改为on 即可。
read_only=on #控制普通用户只读
super_read_only=on #控制超级管理员只读。
mysql> show variables like '%read_only%';
| Variable_name | Value |
+-----------------------+-------+
| read_only | OFF |
| super_read_only | OFF |
+-----------------------+-------+
主从本身就是有可能出现数据不一致--解决方案--半同步,增强半同步,无损复制. MGR PXC MGC
5.4 主从修复的方法
5.4.1
pt-table-checksum校验
pt-table-sync修复数据
5.4.2
重新构建主从
++++++++++++++++++++++++++++++++++++++++++++++
6、主从延迟
6.1 主库:
(1) 二进制日志书写不及时--解决办法--sync_binlog=1
sync_binlog=1 #值为1时，表示每次事务提交后立即写入磁盘
(2) dump线程串行--解决办法--GTID
6.2 从库 :
（1）SQL 串行的问题--解决办法--MySQL 5.7版本 GTID 逻辑时钟 Logical_clock
（2） 大事务--解决办法--将一个大事务化成多个小事务执行，执行多次
6.3 定位到SQL延时的位置点。
Relay_Log_File: db01--bin.000005
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 154
7、延时从库
其实时在从库的SQL线程上控制执行时间
7.1 延时从库配置（在从库执行一下操作）
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY=300;
mysql>start slave;
mysql> show slave status \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
7.2 延时从库演练
场景 db01(主) db02(延时从库)
大型互联网公司,数据量10T左右
每周全备,其他时间备份日志,1主多从,有延时从库3小时
故障场景: 核心业务库被恶意损坏 (drop database)
恢复思路:
1. 停从库SQL线程 stop slave sql_thread;
2. 挂维护页
3. 截取从库的relaylog
起点: sql线程停止时的relay位置点
Relay_Log_File: db01-relay-bin.000004
Relay_Log_Pos: 367
终点: drop
恢复操作
第一步：模拟主库数据及删除操作
create database relay charset utf8;
use relay
create table t1 (id int);
insert into t1 values(1);
drop database relay;
第二步：停止从库SQL线程
mysql>stop slave sql_thread;
第三步：找relaylog的起点和终点并截取日志
起点:
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 320
Relay_Log_File: db02-relay-bin.000006
Relay_Log_Pos: 367
终点:
mysql>show relaylog events in 'db02-relay-bin.000006';
| db02-relay-bin.000006 | 1027 | Query | 1 | 909 | drop database relay |
[root@db02 /tmp]# mysqlbinlog --start-position=367 --stop-position=1027 /data/mysql/data/db02-relay-bin.000006> /tmp/relay.sql
第四步：从库恢复relaylog
mysql>source /tmp/relay.sql
第五步：从库身份解除
mysql>stop slave;
mysql>reset slave all
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
8、过滤复制
在从库的SQL线程上作过滤回放
8.1 主库方面
Binlog_Ignore_DB #黑名单，不记录 那个库的
Binlog_Do_DB #白名单，记录那个库的
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000004 | 1209 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
8.2 从库方面
将以下参数选择加入配置文件，重启mysql 即可。
replicate_do_db=库名 #记录那个库
replicate_ignore_db=库名 #忽略那个库
replicate_do_table=库名.表名 #记录那个表
replicate_ignore_table=库名.表名 #忽略那个表
查看：
mysql>show slave status\G
Replicate_Do_DB: test1
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
9、GTID 复制
介绍：GTID(Global Transaction ID)是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。
它的官方定义如下：
GTID = server_uuid ：transaction_id #保存在auto.cnf 文件中
7E11FA47-31CA-19E1-9E56-C43AA21293967:1-10
什么是sever_uuid，和Server-id 区别？
核心特性: 全局唯一,具备幂等性
9.1 GTID核心参数（编写进配置文件中即可）
gtid-mode=on #启用gtid模式，否则就是普通的复制架构
enforce-gtid-consistency=true #强制GTID的一致性
log-slave-updates=1 #slave更新是否记入日志
9.2 执行change master to 时不用指定position号，自动查找即可。
change master to
master_host='10.0.0.52',
master_user='repl',
master_password='123456' ,
MASTER_AUTO_POSITION=1;
start slave;
9.3 搭建GTID主从复制
背景 ：一个主库，两个从库（没有原始数据的库不用执行一下操作）
第一步：清空源数据目录数据信息和配置文件（三个库）
/etc/init.d/mysqld stop
rm -rf /data/mysql/*
rm -rf /data/mysql/*
rm -rf /etc/my.cnf
第二步：初始化数据（三个库）
mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data
第三步：编写配置文件（server_id 不能相同）
cat >/etc/my.cnf <第四步：创建错误日志文件授权并重启（三个库都执行）
touch /data/mysql/error.log
chown -R mysql.mysql /data/
/etc/init.d/mysqld start
第五步:主库添加授权目录（仅主库执行）
mysql -e "grant replication slave on *.* to repl@'10.0.0.%' identified by '123456';"
第六步：执行从库配置（两个从库）
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123456' ,
MASTER_AUTO_POSITION=1;
start slave;
show slave status\G
9.4 查看GTID
主库
mysql> show master status;
+------------------+----------+--------------+------------------+----------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+----------------------------------------+
| mysql-bin.000001 | 444 | | | d30a33a0-d086-11e9-8bc0-000c291fc150:1 |
+------------------+----------+--------------+------------------+----------------------------------------+
1 row in set (0.00 sec)
从库
mysql> show slave status\G
Retrieved_Gtid_Set: d30a33a0-d086-11e9-8bc0-000c291fc150:1
Executed_Gtid_Set: d30a33a0-d086-11e9-8bc0-000c291fc150:1
二、 MHA 高可用
介绍：MHA初始版本必须有3个数据库节点（一主两从，数据库节点必须是三台独立的主机），还必须有一个manager 端，来管理3个独立的物理节点的数据库，三个数据库节点，都叫做node节点，管理主机叫做manager，
简单来说，要想完成一个MHA的高可用，并且各节点都是互相独立的主机，那么就需要 1主+2从+1manager=4台主机，
MHA 软件结构
Manager工具包主要包括以下几个工具：
masterha_manger 启动MHA
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_master_monitor 检测master是否宕机
masterha_check_status 检测当前MHA运行状态
masterha_master_switch 控制故障转移（自动或者手动）
masterha_conf_host 添加或删除配置的server信息
Node工具包主要包括以下几个工具：
这些工具通常由MHA Manager的脚本触发，无需人为操作。
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
1、 MHA 搭建过程：
第一步：配置各节点互信（四个节点互信）
[root@db03 ~]# ssh-keygen -t rsa
[root@m01 /server/scripts]# cat ssh_fenfa.sh
#!/bin/bash
for ip in {51,52,53}
do
echo "=====Issued pub_key with 172.16.1.$ip====="
sshpass -p123456 ssh-copy-id -i /root/.ssh/id_rsa.pub 172.16.1.$ip -o StrictHostKeyChecking=no &>/dev/null
if [ $? -eq 0 ]
then
echo "公钥信息分发成功 [ok]"
echo ""
else
echo "公钥信息分发失败 [failed]"
echo ""
fi
done
[root@m01 /server/scripts]#
验证：
ssh 10.0.0.51 hostname
ssh 10.0.0.52 hostname
ssh 10.0.0.61 hostname
第二步：创建软件调用时需要用到的软连接（三个数据节点都要做）
ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
第三步：上传安装MHA软件并安装依赖包（所有节点）
yum install perl-DBD-MySQL -y
yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm
第四步骤：manager节点安装
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm
10.3配置和启动
(1) 主库创建管理用户
db01:
mysql -e "grant all privileges on . to mha@'10.0.0.%' identified by 'mha';"
(2) 主备配置文件(manager节点)
mkdir -p /etc/mha
mkdir -p /var/log/mha/app1
cat > /etc/mha/mng.cnf <
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123456
repl_user=repl
ssh_user=root
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
candidate_master=1
check_repl_delay=0
[server3]
hostname=10.0.0.53
port=3306
EOF
(3) 启动前检查
[root@m01 /]# masterha_check_ssh --conf=/etc/mha/mng.cnf
[root@m01 /]# masterha_check_repl --conf=/etc/mha/mng.cnf
(4) 启动MHA的manager进程
nohup masterha_manager --conf=/etc/mha/mng.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
[root@m01 /]# masterha_check_status --conf=/etc/mha/mng.cnf#查看启动状态
(5) 主库宕机测试
/etc/init.d/mysqld stop
(6) 恢复MHA
注意：在MHA的环境下，主库一旦宕机，主从关系就会发生变化，想要恢复宕机的主库，需要重新建立主从关系
使用change master to 在down机节点上重新构建主从关系，因为是GTID复制，所以可以不用找Position号
change master to
master_host='10.0.0.52',
master_user='repl',
master_password='123456' ,
MASTER_AUTO_POSITION=1;
start slave;
show slave status\G
回到manager 节点配置文件中重新添加消失的主机节点，然后重启manager进程即可恢复，恢复后注意监测
2、MHA工作原理
2.1 主库宕机后，从库选主问题
(1) 当主库宕机后，MHA会根据配置文件内的权重进行选主（最优先）;candidate_master=1
如果被选主，和宕机主库的日志数量相差超过100M时，也不会进行自动选主，加上check_repl_delay=0参数，强制选主。
(2) 当主库宕机后，如果配置文件内没有设置权重，会根据两个从库的日志量级进行选主（次之）根据日志量(position或者GTID)
(3) 当主库宕机后，MHA配置文件内没有设置权重，同时两个从库的数据量级相同，接根据配置文件的书写顺序进行选主（最后）
2.2 数据补偿
(1) 主库SSH能连,会在选主之前,立即在各个节点保存(save_binary_logs) 缺失部分日志到/var/tmp
(2) SSH不能连,通过apply_diff_relay_logs,计算两个从节点的relaylog差异,进行补偿
11.3 当主库故障后，MHA自动选主发生的事件（不需要人工干预）
（1）被选主库：清理自身的从库关系
stop slave;
reset slave all;
（2）所有从库和新主库确认新的主从关系
change master to
start slave
2.3 应用透明（VIP）
(1) 脚本准备
[root@m01 /server/tools]# chmod +x master_ip_failover.txt
[root@m01 /server/tools]# dos2unix master_ip_failover dos2unix master_ip_failover
[root@m01 /server/tools]# cp master_ip_failover.txt /usr/local/bin/master_ip_failover
修改文件内容:
my key = '1';
my key ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
(2) 修改MHA配置文件
添加脚本的完整路径
master_ip_failover_script=/usr/local/bin/master_ip_failover
(3) 手工添加主库vip
ifconfig eth0:1 10.0.0.55/24
(4) 重启MHA
`
masterha_stop --conf=/etc/mha/mng.cnf
nohup masterha_manager --conf=/etc/mha/mng.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/mng.cnf#查看启动状态
2.4 故障切换通知
邮件提醒send_report
- 参数：在配置文件中添加以下
report_script=/usr/local/bin/send - 准备邮件脚本
send_report
(1)准备发邮件的脚本(上传 email_2019-最新.zip中的脚本，到/usr/local/bin/中)
(2)将准备好的脚本添加到mha配置文件中,让其调用
(3)重启MHA
masterha_stop --conf=/etc/mha/mng.cnf
nohup masterha_manager --conf=/etc/mha/mng.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/mng.cnf#查看启动状态
2.5 binlog_server数据补偿功能
binlogserver配置：
找一台额外的机器，必须要有5.6以上的数据库版本，支持gtid并开启
vim /etc/mha/mng.cnf
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
创建必要目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
修改完成后，将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）
拉取主库binlog日志（日志拉取时一定要cd 到日志目录下）
cd /data/mysql/binlog
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
注意：
拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点
(3)重启MHA
masterha_stop --conf=/etc/mha/mng.cnf
nohup masterha_manager --conf=/etc/mha/mng.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/mng.cnf#查看启动状态
恢复基于MHA的高可用思路：
a、恢复故障节点
b、重新确认主从关系 change master to
c、在MHA配置文件中将故障节点添加回去
d、binlog 拉取时指向新的主库
mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
e、重启MHA
三、 MHA 配合Atlas 实现数据库的读写分离
1、atlas 配置
1.1 上传 Atlas软件包后 直接安装即可，没有依赖关系
1.2 安装后Atlas配置文件存放在/usr/local/mysql-proxy/conf
1.3 备份并重新生成新的配置文件
cd /usr/local/mysql-proxy/conf
mv test.cnf test.cnf.bak
cat > /usr/local/mysql-proxy/conf/test.cnf <1.4 启动配置文件
/usr/local/mysql-proxy/bin/mysql-proxyd test start
1.5 测试
注意这里-h 对应的ip 是Atlas 安装节点的IP, -u -p 信息必须和数据库内的一致（后端数据库拥有的用户名和密码）
[root@m01 /usr/local/mysql-proxy/bin]# mysql -umha -pmha -h10.0.0.61 -P33060
MySQL [(none)]> select @@server_id; #测试结果可以看到两个从库的server_id
MySQL [(none)]> begin; select @@server_id commit; 可以看到主库的数据库节点
2、 Atlas的管理
这里的 -u -p Atlas配置文件中的用户名和密码，-h 是Atlas安装节点的地址
mysql -uuser -ppwd -h10.0.0.61 -P2345
2.1 开用户
(1) 后端节点添加用户
db01 [(none)]>grant all on . to root@'10.0.0.%' identified by '123';
(2) 密码加密
/usr/local/mysql-proxy/bin/encrypt 123
(3) 修改配置
pwds = repl:3yb5jEku5h4=,mha:O2jBXONX098=,root:3yb5jEku5h4=
(4) 重启
/usr/local/mysql-proxy/bin/mysql-proxyd test restart
2.2 内部管理操作
(0) 获取帮助
select * from help
| 使用方法 | 说明 |
|---|---|
| SELECT * FROM help | shows this help |
| SELECT * FROM backends | lists the backends and their state |
| SET OFFLINE $backend_id | offline backend server, $backend_id is backend_ndx's id |
| SET ONLINE $backend_id | online backend server, ... |
| ADD MASTER $backend | example: "add master 127.0.0.1:3306", ... |
| ADD SLAVE $backend | example: "add slave 127.0.0.1:3306", ... |
| REMOVE BACKEND $backend_id | example: "remove backend 1", ... |
| SELECT * FROM clients | lists the clients |
| ADD CLIENT $client | example: "add client 192.168.1.2", ... |
| REMOVE CLIENT $client | example: "remove client 192.168.1.2", ... |
| SELECT * FROM pwds | lists the pwds |
| ADD PWD $pwd | example: "add pwd user:raw_password", ... |
| ADD ENPWD $pwd | example: "add enpwd user:encrypted_password", ... |
| REMOVE PWD $pwd | example: "remove pwd user", ... |
| SAVE CONFIG | save the backends to config file |
| SELECT VERSION | display the version of Atlas |
(1) 查看后端节点
db03 [(none)]>SELECT * FROM backends;
(2) 上线和下线节点
SET OFFLINE $backend_id
SET ONLINE $backend_id
(3) 添加或删除从节点
db03 [(none)]>REMOVE BACKEND 3;
db03 [(none)]> ADD SLAVE 10.0.0.53:3306;
(4) 查看和添加删除用户
db03 [(none)]> SELECT * FROM pwds;
db03 [(none)]>REMOVE PWD repl;
db03 [(none)]>ADD PWD repl:123;
(5) 保存配置
db03 [(none)]>save config;