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
功能：

对于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

主从连接上之后步骤①②③就不需要再做了，是么？⑦和⑧不一致，再触发⑨

如何监控主从复制

 主库 
[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

mysql【周三】day16

如何使用 JS 判断用户是否处于活跃状态

通过HPA+CronHPA组合应对业务复杂弹性伸缩场景

mysql【週一】day19

mysql【週五】day18

mysql【週二】day20

mysql【週四】day17

mysql【週三】day16

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結