這裏寫目錄標題

mysqldump + binlog 故障恢復案例

按照這個順序去讀取

一、備份工具

設計備份、容災策略

備份策略：備份工具選擇、備份週期設計、備份監控方法

5.1 mysqldump (MDP)

優點：
1.不需要下載安裝
2.備份出來的是SQL，文本格式，可讀性高,便於備份處理
3.壓縮比較高，節省備份的磁盤空間

缺點：
4.依賴於數據庫引擎，需要從磁盤把數據讀出
然後轉換成SQL進行轉儲，比較耗費資源，數據量大的話效率較低
建議：
100G以內的數據量級，可以使用mysqldump
超過TB以上，我們也可能選擇的是mysqldump，配合分佈式的系統
1EB  =1024 PB =1000000 TB

5.2 xtrabackup(XBK)

優點：
1.類似於直接cp數據文件，不需要管邏輯結構，相對來說性能較高
缺點：
2.可讀性差
3.壓縮比低，需要更多磁盤空間
建議：
>100G<TB

5.3 備份策略

備份方式：
全備:全庫備份，備份所有數據
增量:備份變化的數據
邏輯備份=mysqldump+mysqlbinlog
物理備份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog
備份週期:
根據數據量設計備份週期
比如：週日全備，周1-周6增量

二、mysqldump

mysqldump (邏輯備份的客戶端工具)
mysqldump --help

邏輯備份工具。備份的是SQL語句

InnoDB可以採取快照備份的方式。
備份方式：開啓一個獨立的事務，獲取當前最新的一致性快照
將快照數據，放在臨時表中，轉換成SQL（Create database，Create table，insert），保存到sql文件中。

非InnoDB表
需要鎖表備份、觸發FTWRL，全局鎖表。轉換成SQL（Create database，Create table，insert），保存到sql文件中。

2.1 客戶端通用參數

連接參數：
-u  -p   -S   -h  -P    
本地備份:
mysqldump -uroot -p  -S /tmp/mysql.sock      這個 -S 不寫就默認在tmp位置
遠程備份:
mysqldump -uroot -p  -h 10.0.0.51 -P3306

2.2 備份專用基本參數
-A 全備參數，整個備份

例子1:
[root@db01 ~]# mkdir -p /data/backup
mysqldump -uroot -p -A >/data/backup/full.sql
Enter password: 

mysqldump: [Warning] Using a password on the command line interface can be insecure.
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events. 

# 補充:
# 1.常規備份是要加 --set-gtid-purged=OFF,解決備份時的警告
# [root@db01 ~]# mysqldump -uroot -p123 -A  --set-gtid-purged=OFF  >/backup/full.sql
# 2.構建主從時,做的備份,不需要加這個參數
# [root@db01 ~]# mysqldump -uroot -p123 -A    --set-gtid-purged=ON >/backup/full.sql

-B db1 db2 db3 備份多個單庫

說明：生產中需要備份，生產相關的庫和MySQL庫
例子2 :
mysqldump -B mysql gtid --set-gtid-purged=OFF >/data/backup/b.sql

不加參數，備份單個或多個表

例子3 world數據庫下的city,country表
mysqldump -uroot -p world city country >/backup/bak1.sql
以上備份恢復時:必須庫事先存在,並且ues才能source恢復

三、高級參數

每週日 23:00全備，周1-6 binlog備份。所有備份是完整的。
週三時，有一個核心運維人員進行了刪庫操作。
思路：恢復全備 + 所有需要binlog恢復
痛點：binlog的截取
起點：起點查找比較困難
方法一：備份開始時，切割日誌。 -F
方法二：備份開始時，自動記錄日誌文件信息 --master-data=2
終點：drop之前的位置點

–master-data=2

以註釋的形式,保存備份開始時間點的binlog的狀態信息

mysqldump -uroot -p  -A  -R --triggers --master-data=2   >/back/world.sql
[root@db01 ~]# grep 'CHANGE' /backup/world.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000035', MASTER_LOG_POS=194;

功能：
（1）在備份時，會自動記錄，二進制日誌文件名和位置號
0  默認值
1  以change master to命令形式，可以用作主從複製
2  以註釋的形式記錄，備份時刻的文件名+postion號
（2）自動鎖表
（3）如果配合--single-transaction，只對非InnoDB表進行鎖表備份，InnoDB表進行“熱“”備，實際上是實現快照備份。

–single-transaction

對於innodb 存儲引擎開啓熱備(快照備份)功能  ———— 開啓一個獨立事務，獲取一致性快照，進行備份     
master-data可以自動加鎖
（1）在不加--single-transaction ，啓動所有表的溫備份，所有表都鎖定
（1）加上--single-transaction ,對innodb進行快照備份,對非innodb表可以實現自動鎖表功能

❤例子6: 備份必加參數
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql

–set-gtid-purged=auto

auto , on
off 
使用場景:
1. --set-gtid-purged=OFF,可以使用在日常備份參數中.
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql
2. auto , on:在構建主從複製環境時需要的參數配置
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=ON >/data/backup/full.sql

–max-allowed-packet=#

mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF --max-allowed-packet=256M >/data/backup/full.sql

 --max-allowed-packet=# 
The maximum packet length to send to or receive from server.

數據包大小默認是4M。超過4M就會拒絕。因此要利用參數 --max-allowed-packet=#

補充（瞭解）：

-R            備份存儲過程及函數
--triggers    備份觸發器
-E            備份事件

例子4:
[root@db01 backup]# mysqldump -uroot -p -A -R -E --triggers >/data/backup/full.sql
(5) 特殊參數2使用

-F 在備份開始時,刷新一個新binlog日誌

例子5:
mysqldump -uroot -p  -A  -R --triggers -F >/bak/full.sql

mysqldump + binlog 故障恢復案例

案例場景：

基礎環境：Centos 7.6 + MySQL 5.7.28，LNMT 網站業務，數據量100G，每天5-10M數據增長。
備份策略：mysqldump 每天全備，binlog定時備份。
故障說明：週三上午10點數據故障，例如：核心業務庫被誤刪除

恢復思路：

1.掛維護頁。
2.找測試庫。
3.恢復週二全備。
4.截取週二全備——》週三上午10點誤刪除之前的binlog，並恢復
5.測試業務功能正常
6.恢復業務：
方案1：故障庫導回到原生產
方案2：直接用測試庫稱當生產，先跑着。

模擬數據損壞及恢復：
1.模擬原始數據

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

2.模擬週二晚上全備

mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M > /data/back/full_`date +%F`.sql

出現錯誤Binlogging on server not active

vim /etc/my.cnf 
去掉mysqld下的log_bin前面的註釋 並且改成
log_bin=mysql-bin

3.模擬週三白天的數據變化

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

4.搞破壞

drop database mdp;

5.開始恢復

5.1 檢查全備
在備份好的sql文件找到這句話
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

5.2 恢復全備
在5.7之後，默認備份的sql文件就已經包含sql_log_bin=0，這裏只是爲了嚴謹

mysql> set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)

mysql> source /data/back/full_2020-06-03.sql

5.3 截取binlog
起點：grep “-- CHANGE MASTER TO” /data/back/full_2020-06-03.sql

– CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000001’, MASTER_LOG_POS=154;

終點：
show master status;
show binlog events in ‘musql-bin.000001’;

position截取

mysqlbinlog --skip-gtids --start-position=648 --stop-position=729 /data/binlog/mysql-bin.000001 > /tmp/binlog.sql

GTID截取：

5.4 恢復binlog

mysql> set sql_log_bin=0;
mysql> source /tmp/binlog.sql
mysql> set sql_log_bin=1;

mysqldump小結：

參數：-u -p -S -h -p
     -A -B --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64
選擇場景： 數據流較少

四、小練習

1.實現所有表的單獨備份

提示：
information_schema.tables
mysqldump -uroot -p123 world city >/backup/world_city.sql

select concat("mysqldump -uroot -p123 ",table_schema," ",table_name," --master-data=2 --single-transaction --set-gtid-purged=0  -R -E --triggers>/backup/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema');

2.模擬故障案例並恢復

（1）每天全備
（2）binlog日誌是完整
（3）模擬白天的數據變化
（4）模擬下午兩點誤刪除數據庫

需求： 利用全備+binlog回覆數據庫誤刪除之前。
故障模擬及恢復：
1. 模擬週一23:00的全備
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql
2. 模擬白天的數據變化
Master [(none)]>create database day1 charset utf8;
Master [(none)]>use day1
Master [day1]>create table t1(id int);
Master [day1]>insert into t1 values(1),(2),(3);
Master [day1]>commit;
Master [world]>update city set countrycode='CHN';
Master [world]>commit;
模擬磁盤損壞：
[root@db01 data]# \rm -rf /data/mysql/data/*
3. 恢復故障
[root@db01 data]# pkill mysqld
[root@db01 data]# \rm -rf /data/mysql/data/*

4. 恢復思路
1.檢查備份可用性
2.從備份中獲取二進制日誌位置
3.根據日誌位置截取需要的二進制日誌
4.初始化數據庫,並啓動
5.恢復全備
6.恢復二進制日誌

3.壓縮備份並添加時間戳

例子：
mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz
mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F-%T).sql.gz

mysqldump備份的恢復方式（在生產中恢復要謹慎，恢復會刪除重複的表）
set sql_log_bin=0;
source /backup/full_2018-06-28.sql

注意：
1、mysqldump在備份和恢復時都需要mysql實例啓動爲前提。
2、一般數據量級100G以內，大約15-45分鐘可以恢復，數據量級很大很大的時候（PB、EB）
3、mysqldump是覆蓋形式恢復的方法。

一般我們認爲，在同數據量級，物理備份要比邏輯備份速度快.
邏輯備份的優勢:
1、可讀性強
2、壓縮比很高

4.從mysqldump 全備中獲取庫和表的備份

1、獲得表結構
# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `city`/!d;q'  full.sql>createtable.sql

2、獲得INSERT INTO 語句，用於數據的恢復
# grep -i 'INSERT INTO `city`'  full.sqll >data.sql &

3.獲取單庫的備份
# sed -n '/^-- Current Database: `world`/,/^-- Current Database: `/p' all.sql >world.sql

五、MySQL物理備份工具-xtrabackup(XBK、Xbackup)

安裝依賴包

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

https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

備份方式——物理備份

（1）對於非Innodb表（比如 myisam）是，鎖表cp數據文件，屬於一種溫備份。
（2）對於Innodb的表（支持事務的），不鎖表，拷貝數據頁，最終以數據文件的方式保存下來，把一部分redo和undo一併備走，屬於熱備方式。

面試題： xbk 在innodb表備份恢復的流程

  0、xbk備份執行的瞬間,立即觸發ckpt,已提交的數據髒頁,從內存刷寫到磁盤,並記錄此時的LSN號
  1、備份時，拷貝磁盤數據頁，並且記錄備份過程中產生的redo和undo一起拷貝走,也就是checkpoint LSN之後的日誌
  2、在恢復之前，模擬Innodb“自動故障恢復”的過程，將redo（前滾）與undo（回滾）進行應用
  3、恢復過程是cp 備份到原來數據目錄下

MySQL day6 備份恢復

這裏寫目錄標題

一、備份工具

二、mysqldump

三、高級參數

mysqldump + binlog 故障恢復案例

四、小練習

五、MySQL物理備份工具-xtrabackup(XBK、Xbackup)

如何使用 JS 判斷用戶是否處於活躍狀態

通過HPA+CronHPA組合應對業務複雜彈性伸縮場景

❤️‍🔥 Solon Cloud Event 新的事務特性與應用

Ansible基礎 day01 快速入門

基於LAMP架構搭建BBS論壇或者博客

自動化運維工具 ansible

Zabbix 4.0企業級分佈式監控 day02 第四章安裝zabbix agent

防火牆入侵與檢測 day04 防火牆雙機熱備

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

linux以太網驅動總結