一、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 </tmp/2019-09-02.sql

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 <<EOF 
[mysqld]
user=mysql
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
log_error=/data/mysql/error.log
server_id=3
port=3306
log_bin=/data/mysql/mysql-bin
gtid-mode=on                   
enforce-gtid-consistency=true  
log-slave-updates=1                      
[mysql]
socket=/tmp/mysql.sock 
EOF

第四步：创建错误日志文件授权并重启（三个库都执行）

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 <<EOF
[server default]
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

1. 参数：在配置文件中添加以下
   report_script=/usr/local/bin/send
2. 准备邮件脚本
   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 <<EOF
[mysql-proxy]
admin-username = user
admin-password = pwd
proxy-backend-addresses = 10.0.0.55:3306  #主库配置
proxy-read-only-backend-addresses = 10.0.0.51:3306,10.0.0.53:3306  #两个从库配置
pwds = repl:3yb5jEku5h4=,mha:O2jBXONX098=
daemon = true
keepalive = true
event-threads = 8
log-level = message
log-path = /usr/local/mysql-proxy/log
sql-log=ON
proxy-address = 0.0.0.0:33060
admin-address = 0.0.0.0:2345
charset=utf8
EOF

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

(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;