mysql【週三】day16

備份恢復

關於備份恢復方面的職責
1、備份、恢復策略的設計
備份週期 備份工具 備份方式 恢復方式全部流程化
2、日常備份檢查
日誌 備份內容
3、定期的恢復演練
4、數據故障時，利用現有的資源，快速恢復
5、數據遷移、升級

備份工具介紹
1、邏輯備份
mysqldump / source *****
mysqlbinlog /source
mydumper / myloader
select into outfile / load data infile
binlog2sql
myflashback
2、物理備份
Percona Xtrabackup (PXB,XBK) *****
遷移表空間
Mysql Enterpise backup（MEB，企業版）
8.0 clone plugin (8.0.17)
3、選型
100G 以內 邏輯備份
100G 以上 物理備份
超大型 分佈式邏輯備份

mysqldump工具使用 屬於邏輯備份工具
介紹：
mysql數據邏輯備份工具 （Create database\ create table \ insert）
mysql 自帶的客戶端命令，可以實現遠程和本地備份
參數：
-u 指定用戶
-p 指定登錄密碼
-S 指定本地登錄socket文件
-h 指定是localhost 還是網絡ip
-P 指定端口號碼
備份參數：
-A 全備

[root@db01 ~]# mkdir -p /data/backup
[root@db01 ~]# mysqldump -uroot -p123  -A >/data/backup/full.sql

-B 單庫或多庫

[root@db01 ~]# mysqldump -uroot -p123  -B world gtdb test >/data/backup/db.sql

備份單表或多表

[root@db01 ~]# mysqldump -uroot -p123  world t1 country >/data/backup/tab.sql

–master-data=2
功能：
1.自動記錄備份時的binlog信息（註釋）
2.自動鎖定所有表，自動解鎖（global read lock）。最好配合–single-transaction 參數，減少鎖表時間。

[root@db01 ~]# mysqldump -uroot -p123  -A  --master-data=2  >/data/backup/full.sql

–single-transaction
功能：

1. 對於InnoDB表，開啓獨立事務，通過快照備份表數據，不鎖表備份，可以理解爲熱備。
   通過照片查人數。

[root@db01 ~]# mysqldump -uroot -p123  -A  --master-data=2  --single-transaction  >/data/backup/full.sql

–max_allowed_packet=64M 最大允許的數據包大小

[root@db01 ~]# mysqldump -uroot -p123  -A  --master-data=2  --single-transaction  --max_allowed_packet=64M  >/data/backup/full.sql

小故障
學員問題： 備份時超出最大數據包大小。
1153 - Got a packet bigger than ‘max_allowed_packet’ bytes

-R -E --triggers 備份特殊對象使用

[root@db01 ~]# mysqldump -uroot -p123  -A  --master-data=2  --single-transaction  --max_allowed_packet=64M  -R -E  --triggers >/data/backup/full.sql

格式化備份文件

[root@db01 ~]# mysqldump -uroot -p  -A  --master-data=2  --single-transaction  --max_allowed_packet=64M  -R -E  --triggers >/data/backup/full_`date +%F`.sql

故障恢復演練(mdp+binlog,每天全備)

模擬環境

mysql> create database mdp charset utf8mb4;
mysql> use mdp
mysql> create table t1(id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;

模擬 週一23:00 的全備

[root@db01 ~]# mysqldump -uroot -p  -A  --master-data=2  --single-transaction  --max_allowed_packet=64M  -R -E  --triggers >/data/backup/full_`date +%F`.sql

查看 GTID相關信息 ：GTID截取起點。

SET @@GLOBAL.GTID_PURGED='202628e9-9265-11ea-b4a0-000c29248f69:1-35';

查看pos號，備份開始時binlog位置點信息。

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000023', MASTER_LOG_POS=158999;

模擬週二白天數據變化

mysql> use mdp;
mysql> create table t2 (id int);
mysql> insert into t2 values(1),(2),(3);
mysql> commit;

週二下午2點，誤刪除了mdp核心庫

mysql> drop database mdp;

故障恢復
思路：
1、 恢復全備到週一晚上23:00
檢查全備：

vim /data/backup/full_2020-05-11.sql 

#查看 GTID相關信息 ：GTID截取起點。

SET @@GLOBAL.GTID_PURGED='202628e9-9265-11ea-b4a0-000c29248f69:1-35';

#查看pos號，備份開始時binlog位置點信息。

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000023', MASTER_LOG_POS=158999;

截取日日誌：
#起點：

mysql-bin.000023 202628e9-9265-11ea-b4a0-000c29248f69:36 或者 mysql-bin.000023 pos=158999

終點： drop

[root@db01 backup]# mysql -uroot -p123 -e "show binlog events in 'mysql-bin.000023'"|grep -B 1 "drop database mdp"
mysql-bin.000023	159421	Gtid	6	159486	SET @@SESSION.GTID_NEXT= '202628e9-9265-11ea-b4a0-000c29248f69:38'
mysql-bin.000023	159486	Query	6	159575	drop database mdp
[root@db01 backup]# 

2、截取日誌

[root@db01 backup]# mysqlbinlog --skip-gtids --include-gtids='202628e9-9265-11ea-b4a0-000c29248f69:36-37' /data/3306/logs/mysql-bin.000023 >/data/backup/bin.sql

3、恢復

mysql> set sql_log_bin=0;
mysql> source /data/backup/full_2020-05-11.sql 
mysql> source /data/backup/bin.sql
mysql> set sql_log_bin=1;

4、檢查數據

mysql> use mdp
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A


Database changed
mysql> show tables;
+---------------+
| Tables_in_mdp |
+---------------+
| t1            |
| t2            |
+---------------+
2 rows in set (0.01 sec)

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

mysql> select * from t2;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

mysqldump多種備份策略和恢復策略介紹
場景：
100G 全庫數據 全庫備份 30分鐘-40分鐘，恢復整庫需要5倍時間2.5-3小時之間
一張表 1G 被誤刪除了。

mysqldump 備份策略 ：
恢復單表數據思路：
（1） 提取full全備中的故障表數據 ，恢復數據
（2） binlog中截取全備到誤刪除t1之間對於這張表的修改
故障模擬
模擬原始數據

 create database oldboy charset utf8mb4;
 use oldboy;
 create table oldguo (id int);
 insert into oldguo values(1),(2),(3);
 commit;

週一晚上全庫備份

mysqldump -uroot -p  -A  --master-data=2  --single-transaction  --max_allowed_packet=64M  -R -E  --triggers >/data/backup/full.sql

模擬週二白天的數據變化

use oldboy ;
insert into oldguo values(11),(22),(33);
commit;
create table  oldli(id int);
insert into oldli values(1),(2),(3);
commit;
insert into oldguo values(111),(222),(333);
commit;

模擬週二下午2點，誤刪除oldguo表

drop table  oldguo;

恢復過程

1、 處理全備

[root@db01 ~]# sed -n '/CREATE TABLE `oldguo` /,/\;/p' /data/backup/full.sql >/data/backup/create.sql
[root@db01 ~]# grep -i 'INSERT INTO `oldguo`'  /data/backup/full.sql >/data/backup/insert.sql
2、binlog 的截取

範圍：
起點： 通過備份。

SET @@GLOBAL.GTID_PURGED='202628e9-9265-11ea-b4a0-000c29248f69:1-47';

終點： 通過

[root@db01 ~]#  mysql -uroot -p123 -e "show binlog events in 'mysql-bin.000023'" |grep -B 1 'DROP TABLE\ `oldguo`'
mysql-bin.000023	163044	Gtid	6	163109	SET @@SESSION.GTID_NEXT= '202628e9-9265-11ea-b4a0-000c29248f69:54'
mysql-bin.000023	163109	Query	6	163232	use `oldboy`; DROP TABLE `oldguo` /* generated by server */

[root@db01 ~]# 
[root@db01 ~]# mysqlbinlog --include-gtids='202628e9-9265-11ea-b4a0-000c29248f69:48-53' /data/3306/logs/mysql-bin.000023 |grep -B 8  '`oldboy`.`oldguo`'|grep 'GTID_NEXT'
SET @@SESSION.GTID_NEXT= '202628e9-9265-11ea-b4a0-000c29248f69:49'/*!*/;
SET @@SESSION.GTID_NEXT= '202628e9-9265-11ea-b4a0-000c29248f69:50'/*!*/;
SET @@SESSION.GTID_NEXT= '202628e9-9265-11ea-b4a0-000c29248f69:53'/*!*/;

截取：
方法1：

[root@db01 ~]# mysqlbinlog --skip-gtids --include-gtids='202628e9-9265-11ea-b4a0-000c29248f69:48-53' --exclude-gtids='202628e9-9265-11ea-b4a0-000c29248f69:51-52' /data/3306/logs/mysql-bin.000023 >/data/backup/bin.sql

方法2：

 mysqlbinlog --skip-gtids --include-gtids='202628e9-9265-11ea-b4a0-000c29248f69:48-50','202628e9-9265-11ea-b4a0-000c29248f69:53' /data/3306/logs/mysql-bin.000023 >/data/backup/bin1.sql

3、 恢復數據

use oldboy;
set sql_log_bin=0;
source /data/backup/create.sql
source /data/backup/insert.sql
commit;
source /data/backup/bin.sql
set sql_log_bin=1;

4、實現單庫單表備份

shell# mkdir -p /data/backup/single_bak
mysql> select concat("mysqldump -uroot -p123 ",table_schema," ",table_name," >/data/backup/single_bak/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema') into outfile '/tmp/single_bak.sh';
shell# sh /tmp/single_bak.sh &>/tmp/bak.log

Percona Xtrabackup（PXB\XBK） 備份工具介紹 （屬於物理備份工具介紹）

介紹
percona公司研發
xtrabackup --》C C++
innobackupex --》perl語言
8.0之前，2.4.x
8.0之後，8.0
物理備份工具，類似於cp文件。支持：全備和增量備份

安裝
安裝依賴包：

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev

下載軟件並安裝

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

全備：
介紹
拷貝，/data/3306/data/下的數據文件。
InnoDB ： 熱備。拷貝ibdataN,UNDO00N ,ibtmpN ,ibd 。通過截取變化redo。
非InnoDB： FTWRL，全局鎖。拷貝非INNODB的文件frm\myi\myd…
只能本地備份。

[client]
socket=/tmp/mysql.sock

全備實現

[root@db01 backup]# innobackupex --user=root --password=123 /data/backup/test

說明： 備份完成後，自動生成基於時間戳的目錄。
（1）xtrabackup_binlog_info
#記錄binlog位置點， 截取binlog起點位置。
（2）xtrabackup_checkpoints
#LSN號碼信息
from_lsn = 0 # 一般增量備份會關注，一般上次備份的to_lsn的位置
to_lsn = 180881595 # CKPT-LSN
last_lsn = 180881604 # xtrabackup_logfile LSN
（3）xtrabackup_info
#備份總覽信息
（4）xtrabackup_logfile
#備份期間產生的redo變化

自定義目錄備份：

[root@db01 xbk]# innobackupex --user=root --password=123 --no-timestamp /data/backup/xbk/full_`date +%F`

全備恢復應用
#故障模擬

[root@db01 xbk]# pkill mysqld 
[root@db01 xbk]# rm -rf /data/3306/data/*

使用全備恢復數據

1、prepare 準備備份階段
重用了CR ： 自動故障恢復。DWB+redo前滾和undo回滾。

[root@db01 ~]# innobackupex --apply-log /data/backup/xbk/full

2、copy-back 恢復
方法一：

  [root@db01 full]# cp -a /data/backup/xbk/full/*  /data/3306/data/
  或者： mv
  [root@db01 full]# chown -R mysql.mysql /data/*
  [root@db01 full]# /etc/init.d/mysqld start
  Starting MySQL.... SUCCESS! 

方法二：

  [root@db01 full]# innobackupex --copy-back /data/backup/xbk/full
  [root@db01 full]# innobackupex --move-back /data/backup/xbk/full

方法三：
直接指定數據路徑爲：

  vim /etc/my.cnf
  datadir=/data/backup/xbk/full

  
  chown -R mysql. /data/* 
  /etc/init.d/mysqld start

增量備份（incremental）功能
介紹
自帶的功能。
每次增量一般是將最近一次備份作爲參照物。
自動讀取參照物cat xtrabackup_checkpoints中to_lsn值，與當前CKPT的LSN對比，備份變化過page。備份期間新的數據變化，通過redo自動備份。
恢復數據時，需要把所有需要的增量合併到FULL中。無法通過增量單獨恢復數據，依賴於全備

增量備份演練（FULL(週日)+inc1(週一)+inc2(週二)+inc3(週三)）

#備份前數據準備：

mysql> create database xbk charset utf8mb4;
mysql> use xbk
mysql> create table full (id int);
mysql> insert into full values(1),(2),(3);
mysql> commit;

模擬週日 23:00全備

innobackupex --user=root --password=123 --no-timestamp /data/backup/full_`date +%F`

模擬週一白天數據變化

mysql> use xbk
mysql> create table inc1 (id int);
mysql> insert into  inc1 values(1),(2),(3);
mysql> commit;

模擬週一23:00增量備份

innobackupex --user=root --password=123  --no-timestamp   --incremental --incremental-basedir=/data/backup/full_2020-05-12  /data/backup/inc1_`date +%F`

模擬週二白天數據變化

mysql> use xbk
mysql> create table inc2 (id int);
mysql> insert into  inc2 values(1),(2),(3);
mysql> commit;

模擬週二23:00增量備份

innobackupex --user=root --password=123  --no-timestamp   --incremental --incremental-basedir=/data/backup/inc1_2020-05-12  /data/backup/inc2_`date +%F`

模擬週三白天數據變化

mysql> use xbk
mysql> create table inc3(id int);
mysql> insert into  inc3 values(1),(2),(3);
mysql> commit

模擬週三23:00增量備份

innobackupex --user=root --password=123  --no-timestamp   --incremental --incremental-basedir=/data/backup/inc2_2020-05-12  /data/backup/inc3_`date +%F`

模擬週四白天的數據變化。

mysql> use xbk
mysql> create table inc4(id int);
mysql> insert into  inc4 values(1),(2),(3);
mysql> commit;

週四下午出現數據損壞。如何恢復到誤刪除之前。

[root@db01 ~]# pkill mysqld
[root@db01 ~]# rm -rf /data/backup/xbk/full/*

;恢復思路？
（1）我們有什麼？
備份：
full+inc1+inc2+inc3
binlog:
full以來全量的binlog

（2）處理備份
需要將inc1\inc2\inc3按順序依次合併到全備，並進行prepare。
–redo-only 參數說明
從官方角度：基礎全備和合並所有增量（排除最後一個）都需要此參數
原理角度： 使所有備份合併時，LSN必須是連續的

1、 base_full

 [root@db01 ~]# innobackupex --apply-log --redo-only  /data/backup/full_2020-05-12/

2、 inc1合併到full中，並且prepare

[root@db01 ~]# cd /data/backup/
[root@db01 backup]# innobackupex --apply-log --redo-only   --incremental-dir=inc1_2020-05-12 full_2020-05-12

檢驗合併結果：

cat full_2020-05-12/xtrabackup_checkpoints  |grep "to_lsn"
cat inc1_2020-05-12/xtrabackup_checkpoints |grep "to_lsn"

3、 inc2合併到full中，並且prepare

[root@db01 ~]# cd /data/backup/
[root@db01 backup]# innobackupex --apply-log --redo-only   --incremental-dir=inc2_2020-05-12 full_2020-05-12

檢驗合併結果：

[root@db01 backup]# 
[root@db01 backup]# cat full_2020-05-12/xtrabackup_checkpoints  |grep "to_lsn"
to_lsn = 180902505
[root@db01 backup]# cat inc2_2020-05-12/xtrabackup_checkpoints |grep "to_lsn"
to_lsn = 180902505
[root@db01 backup]# 

4、inc3合併到full中，並且prepare

[root@db01 ~]# cd /data/backup/
[root@db01 backup]# innobackupex --apply-log   --incremental-dir=inc3_2020-05-12 full_2020-05-12

檢查合併結果

cat full_2020-05-12/xtrabackup_checkpoints  |grep "to_lsn"
cat inc3_2020-05-12/xtrabackup_checkpoints |grep "to_lsn"

5、 將合併後全備再次prepare

innobackupex --apply-log  /data/backup/full_2020-05-12/

（3）恢復並啓動
到這步，數據已經恢復到週三晚上備份結束後的狀態。

 vim /etc/my.cnf ----> datadir=/data/3306/data
 rm -rf /data/3306/data/* 

命令會自動讀取在my.cnf中配置的datadir路徑，將數據恢復到路徑下。

[root@db01 data]# innobackupex --copy-back /data/backup/full_2020-05-12/
[root@db01 data]# chown -R mysql. /data/*

（4） 截取週三增量備份後----》故障之前所有binlog日誌，並進行恢復。

起點 ：inc3 備份完成後的位置點

mysql-bin.000025        2069    
202628e9-9265-11ea-b4a0-000c29248f69:1-57,
88126fcb-93f6-11ea-9896-000c29248f69:1-9 

終點： binlog 結尾

[root@db01 logs]# mysqlbinlog --skip-gtids --start-position=2069  /data/3306/logs/mysql-bin.000025 >/data/backup/bin.sql

(5) 恢復binlog

mysql> set sql_log_bin=0;
mysql> source /data/backup/bin.sql
mysql> set sql_log_bin=1;

(6) xbk恢復完成後，清空所有日誌
mysql> reset master; 注意：這個一步是重新從當前環境生成新的binlog日誌 以前的binlog日誌文件會消失，也可以直接cp一份。

(7) 立即再做個全備。 因爲之前的binlog日誌被restart master後就沒有了，所以爲了防止出現問題，立即再做一個全備。

總結：
基礎備份策略：
MDP 備份 + binlog —》 全備完整恢復、部分數據損壞恢復
XBK full+inc+binlog ----> 全備完整恢復、部分數據損壞恢復
XBK full+binlog ===> 全備完整恢復、部分數據損壞恢復

容災策略：
主從
高可用

作業 ：
2T XBK 完整備份+binlog完整.誤刪除的表是 10G t1 ,drop table t1
提示：表空間遷移+t1 binlog

我感覺 獨立表空間遷移 和binlog日誌兩種方式選其中一個就可以恢復刪除的表；
如果是週三全備份 週四上午有新的數據寫入 週四下午被刪除庫
那麼應該使用全備份中的文件結合獨立表空間的技術回覆到週三全備份時的狀態 然後結合binlog日誌文件，恢復週四上午被刪除之前的數據庫，達到恢復數據的目的

主從複製
介紹
兩臺或以上的數據庫實例，通過binlog實現，數據異步同步的關係。
主從複製前提

2臺以上的MySQL實例(同版本、同平臺),具備不同的server_id,server_uuid
3307：主庫
3308：從庫
3309：從庫

[root@db01 3308]# systemctl start mysqld3307
[root@db01 3308]# systemctl start mysqld3308
[root@db01 3308]# systemctl start mysqld3309
[root@db01 3308]# mysql -S /tmp/mysql3307.sock -e "select @@server_id ;"
+-------------+
| @@server_id |
+-------------+
|           7 |
+-------------+
[root@db01 3308]# mysql -S /tmp/mysql3308.sock -e "select @@server_id ;"
+-------------+
| @@server_id |
+-------------+
|           8 |
+-------------+
[root@db01 3308]# mysql -S /tmp/mysql3309.sock -e "select @@server_id ;"
+-------------+
| @@server_id |
+-------------+
|           9 |
+-------------+

[root@db01 3308]# mysql -S /tmp/mysql3309.sock -e "select @@server_uuid ;"
+--------------------------------------+
| @@server_uuid                        |
+--------------------------------------+
| 1c920eb6-901a-11ea-a2a5-000c29248f69 |
+--------------------------------------+
[root@db01 3308]# mysql -S /tmp/mysql3308.sock -e "select @@server_uuid ;"
+--------------------------------------+
| @@server_uuid                        |
+--------------------------------------+
| 195bb724-901a-11ea-a083-000c29248f69 |
+--------------------------------------+
[root@db01 3308]# mysql -S /tmp/mysql3307.sock -e "select @@server_uuid ;"
+--------------------------------------+
| @@server_uuid                        |
+--------------------------------------+
| 15ac32d2-901a-11ea-9ee5-000c29248f69 |
+--------------------------------------+
[root@db01 3308]# 

2.2 主庫： 開啓binlog, 創建複製用戶

vim  /data/3307/my.cnf
server_id=7
log_bin=/data/3307/mysql-bin

[root@db01 3308]# systemctl restart mysqld3307
[root@db01 3308]# mysql -S /tmp/mysql3307.sock -e "select @@log_bin ;"

[root@db01 3308]# mysql -S /tmp/mysql3307.sock -e "grant replication slave on *.* to repl@'10.0.0.%' identified by '123';"
[root@db01 3308]# mysql -S /tmp/mysql3307.sock -e "select user,host ,plugin from mysql.user;"

“補課”： 備份主庫數據，恢復到從庫

[root@db01 3308]# mysqldump -S /tmp/mysql3307.sock  -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M >/data/full.sql
[root@db01 3308]# mysql -S /tmp/mysql3308.sock</data/full.sql 
[root@db01 3308]# mysql -S /tmp/mysql3309.sock</data/full.sql 

告知從庫複製的信息：change master to user,password, ip ,port, filename、pos
help change master to

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=444,
  MASTER_CONNECT_RETRY=10;

vim /data/full.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=444;

2.5 讓他幹活 ： 啓動線程

start slave;

2.6 查看複製狀態：

[root@db01 3308]# mysql -S /tmp/mysql3309.sock -e "show slave status\G"|grep "Running:"
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
[root@db01 3308]# mysql -S /tmp/mysql3308.sock -e "show slave status\G"|grep "Running:"
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
[root@db01 3308]# 

從庫執行 ：show slave status \G

中繼日誌：db01-relay-bin.000001

從庫目錄查看：

[root@db01 data]# cat  master.info

主從連接上之後步驟①②③就不需要再做了，是麼？⑦和⑧不一致，再觸發⑨

4. 如何監控主從複製

 主庫 
[root@db01 data]# mysql -S /tmp/mysql3307.sock -e "show processlist" |grep "Dump"
7 repl db01:34640 NULL Binlog Dump 5355 Master has sent all binlog to slave; waiting for more updates NULL
9 repl db01:34642 NULL Binlog Dump 687 Master has sent all binlog to slave; waiting for more updates NULL

[root@db01 data]# mysql -S /tmp/mysql3307.sock -e "show slave hosts;"
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID                           |
+-----------+------+------+-----------+--------------------------------------+
|         9 |      | 3309 |         7 | 1c920eb6-901a-11ea-a2a5-000c29248f69 |
|         8 |      | 3308 |         7 | 195bb724-901a-11ea-a083-000c29248f69 |
+-----------+------+------+-----------+--------------------------------------+

 從庫

[root@db01 data]# mysql -S /tmp/mysql3308.sock -e "show slave status \G"

主庫連接信息、binlog位置信息（master.info）

Master_Host: 
10.0.0.51
Master_User: repl
Master_Port: 3307
Connect_Retry: 10
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 444
  
 從庫中relay-log的回放信息   
Relay_Log_File: db01-relay-bin.000006
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Exec_Master_Log_Pos: 444


 線程監控信息：主要用來排查主從故障
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error: 


 過濾複製相關信息
Replicate_Do_DB: 
Replicate_Ignore_DB: 
Replicate_Do_Table: 
Replicate_Ignore_Table: 
Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
  
  
 落後於主庫的秒數
Seconds_Behind_Master: 0



 延時從庫狀態信息
SQL_Delay: 0
SQL_Remaining_Delay: NULL



 GTID複製信息
Retrieved_Gtid_Set: 
Executed_Gtid_Set: 
Auto_Position: 0