2019-06-24 MySQL備份相關工具與命令

1 設計備份策略

全備、增量、時間、自動

1.2 日常備份檢查

備份是否存在
備份空間是否夠用

1.3 定期恢復演練(測試庫)

 一季度 或者 半年
  1. 備份類型
    2.1 熱備
    在數據庫正常業務時,備份數據,並且能夠一致性恢復(只能是innodb)
    對業務影響非常小

    2.2 溫備

    鎖表備份,只能查詢不能修改(myisam)影響到寫入操作

2.3 冷備

關閉數據庫業務,數據庫沒有任何變更的情況下,進行備份數據.
業務停止
  1. 備份方式及工具介紹
    3.1 邏輯備份工具
    基於SQL語句進行備份
    mysqldump       *****
    mysqlbinlog     *****

    3.2 物理備份工具

    基於磁盤數據文件備份
    xtrabackup(XBK) :percona 第三方   *****
    MySQL Enterprise Backup(MEB)
  2. 邏輯備份和物理備份的比較
    4.1 mysqldump (MDP)
    優點:
    1.不需要下載安裝
    2.備份出來的是SQL,文本格式,可讀性高,便於備份處理
    3.壓縮比較高,節省備份的磁盤空間
    缺點:
    4.依賴於數據庫引擎,需要從磁盤把數據讀出
    然後轉換成SQL進行轉儲,比較耗費資源,數據量大的話效率較低
    建議:
    100G以內的數據量級,可以使用mysqldump
    超過TB以上,我們也可能選擇的是mysqldump,配合分佈式的系統
    1EB  =1024 PB =1000000 TB

4.2 xtrabackup(XBK)

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

5.備份策略

備份方式:

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

6.備份工具使用-mysqldump
6.1 mysqldump (邏輯備份的客戶端工具)
6.1.1 客戶端通用參數

-u  -p   -S   -h  -P    
本地備份:
mysqldump -uroot -p  -S /tmp/mysql.sock
遠程備份:
mysqldump -uroot -p  -h 10.0.0.51 -P3306

6.1.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
以上備份恢復時:必須庫事先存在,並且use才能source恢復

6.1.3 高級參數應用

特殊參數1使用(必須要加)
-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

--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.

6.2 小練習:
6.2.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');

6.2.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.恢復二進制日誌

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、壓縮比很高

7、企業故障恢復案例
7.1 背景環境:

正在運行的網站系統,mysql-5.7.20 數據庫,數據量50G,日業務增量1-5M。

7.2 備份策略:

每天23:00點,計劃任務調用mysqldump執行全備腳本

7.3 故障時間點:

年底故障演練:模擬週三上午10點誤刪除數據庫,並進行恢復.

7.4 思路:

1、停業務,避免數據的二次傷害
2、找一個臨時庫,恢復週三23:00全備
3、截取週二23:00  --- 週三10點誤刪除之間的binlog,恢復到臨時庫
4、測試可用性和完整性
5、 
    5.1 方法一:直接使用臨時庫頂替原生產庫,前端應用割接到新庫
    5.2 方法二:將誤刪除的表導出,導入到原生產庫
6、開啓業務
處理結果:經過20分鐘的處理,最終業務恢復正常

7.5 故障模擬演練
7.5.1 準備數據

create database backup;
use backup
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;
rm -rf /backup/*

7.5.2 週二 23:00全備

mysqldump -uroot -p123 -A  -R  --triggers --set-gtid-purged=OFF --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz

7.5.3 模擬週二 23:00到週三 10點之間數據變化

use backup
insert into t1 values(11),(22),(33);
commit;
create table t2 (id int);
insert into t2 values(11),(22),(33);

7.5.4 模擬故障,刪除表(只是模擬,不代表生產操作)

drop database backup;

7.6 恢復過程
7.6.1 準備臨時數據庫(多實例3307)

systemctl start mysqld3307

7.6.2 準備備份
(1)準備全備:

cd /backup
gunzip full_2018-10-17.sql.gz 

(2)截取二進制日誌

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000036', MASTER_LOG_POS=793;
mysqlbinlog --skip-gtids --include-gtids='3ca79ab5-3e4d-11e9-a709-000c293b577e:6-7' /data/binlog/mysql-bin.000036 >/backup/bin.sql

7.6.3 恢復備份到臨時庫

mysql -S /data/3307/mysql.sock
set sql_log_bin=0;
source /backup/full_2018-10-17.sql
source /backup/bin.sql

7.6.4 將故障表導出並恢復到生產

mysqldump   -S /data/3307/mysql.sock backup t1 >/backup/t1.sql
mysql -uroot -p123 
set sql_log_bin=0
use backup 
source /backup/t1.sql;
  1. 課下作業:
    練習:
    1、創建一個數據庫 oldboy
    2、在oldboy下創建一張表t1
    3、插入5行任意數據
    4、全備
    5、插入兩行數據,任意修改3行數據,刪除1行數據
    6、刪除所有數據
    7、再t1中又插入5行新數據,修改3行數據
    需求,跳過第六步恢復表數據
    寫備份腳本和策略
  2. 備份時優化參數:
    
    (1) max_allowed_packet   最大的數據包大小

mysqldump -uroot -p123 -A -R --triggers --set-gtid-purged=OFF --master-data=2 max_allowedpacket=128M --single-transaction|gzip > /backup/full$(date +%F).sql.gz

(2) 增加key_buffer_size (臨時表有關)
(3) 分庫分表併發備份 (作業)
(4) 架構分離,分別備份 (架構拆分,分佈式備份)

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

10.1安裝
10.1.1 安裝依賴包:
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

10.1.2 下載軟件並安裝
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

10.2、備份命令介紹:

xtrabackup
innobackupex **

10.3 備份方式——物理備份

(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 備份到原來數據目錄下

10.4、innobackupex使用
10.4.1 全備

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

自主定製備份路徑名
[root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp /data/backup/full

備份集中多出來的文件:
-rw-r----- 1 root root 24 Jun 29 09:59 xtrabackup_binlog_info
-rw-r----- 1 root root 119 Jun 29 09:59 xtrabackup_checkpoints
-rw-r----- 1 root root 489 Jun 29 09:59 xtrabackup_info
-rw-r----- 1 root root 2560 Jun 29 09:59 xtrabackup_logfile

xtrabackup_binlog_info :(備份時刻的binlog位置)
[root@db01 full]# cat xtrabackup_binlog_info
mysql-bin.000003 536749
79de40d3-5ff3-11e9-804a-000c2928f5dd:1-7
記錄的是備份時刻,binlog的文件名字和當時的結束的position,可以用來作爲截取binlog時的起點。

xtrabackup_checkpoints :
backup_type = full-backuped
from_lsn = 0 上次所到達的LSN號(對於全備就是從0開始,對於增量有別的顯示方法)
to_lsn = 160683027 備份開始時間(ckpt)點數據頁的LSN
last_lsn = 160683036 備份結束後,redo日誌最終的LSN
compact = 0
recover_binlog_info = 0
(1)備份時刻,立即將已經commit過的,內存中的數據頁刷新到磁盤(CKPT).開始備份數據,數據文件的LSN會停留在to_lsn位置。
(2)備份時刻有可能會有其他的數據寫入,已備走的數據文件就不會再發生變化了。
(3)在備份過程中,備份軟件會一直監控着redo的undo,如果一旦有變化會將日誌也一併備走,並記錄LSN到last_lsn。
從to_lsn ----》last_lsn 就是,備份過程中產生的數據變化.

10.4.2 全備的恢復

準備備份(Prepared)

將redo進行重做,已提交的寫到數據文件,未提交的使用undo回滾掉。模擬了CSR的過程

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

恢復備份

前提:
1、被恢復的目錄是空
2、被恢復的數據庫的實例是關閉
systemctl stop mysqld

創建新目錄

[root@db01 backup]# mkdir /data/mysql1

數據授權

chown -R mysql.mysql /data/mysql1

恢復備份

[root@db01 full]# cp -a /backup/full/* /data/mysql1/

啓動數據庫

vim /etc/my.cnf
datadir=/data/mysql1
[root@db01 mysql1]# chown -R mysql.mysql /data/mysql1
systemctl start mysqld

10.4.3 innobackupex 增量備份(incremental)

(1)增量備份的方式,是基於上一次備份進行增量。
(2)增量備份無法單獨恢復。必須基於全備進行恢復。
(3)所有增量必須要按順序合併到全備中。

增量備份命令

(1)刪掉原來備份
略.
(2)全備(週日)
[root@db01 backup]# innobackupex --user=root --password --no-timestamp /backup/full >&/tmp/xbk_full.log
(3)模擬週一數據變化
db01 [(none)]>create database cs charset utf8;
db01 [(none)]>use cs
db01 [cs]>create table t1 (id int);
db01 [cs]>insert into t1 values(1),(2),(3);
db01 [cs]>commit;

(4)第一次增量備份(週一)

innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/full /backup/inc1 &>/tmp/inc1.log

(5)模擬週二數據

db01 [cs]>create table t2 (id int);
db01 [cs]>insert into t2 values(1),(2),(3);
db01 [cs]>commit;

(6)週二增量

innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/inc1 /backup/inc2 &>/tmp/inc2.log

(7)模擬週三數據變化

db01 [cs]>create table t3 (id int);
db01 [cs]>insert into t3 values(1),(2),(3);
db01 [cs]>commit;
db01 [cs]>drop database cs;

恢復到週三誤drop之前的數據狀態
恢復思路:
  1. 掛出維護頁,停止當天的自動備份腳本
  2. 檢查備份:週日full+週一inc1+週二inc2,週三的完整二進制日誌
  3. 進行備份整理(細節),截取關鍵的二進制日誌(從備份——誤刪除之前)
  4. 測試庫進行備份恢復及日誌恢復
  5. 應用進行測試無誤,開啓業務
  6. 此次工作的總結
    
    恢復過程
  7. 檢查備份
    1afe8136-601d-11e9-9022-000c2928f5dd:7-9
  8. 備份整理(apply-log)+合併備份(full+inc1+inc2)
    (1) 全備的整理
    [root@db01 one]# innobackupex --apply-log --redo-only /data/backup/full
    (2) 合併inc1到full中
    [root@db01 one]# innobackupex --apply-log --redo-only --incremental-dir=/data/backup/inc1 /data/backup/full

    (3) 合併inc2到full中

    [root@db01 one]# innobackupex --apply-log  --incremental-dir=/data/backup/inc2 /data/backup/full

    (4) 最後一次整理全備

    [root@db01 backup]#  innobackupex --apply-log  /data/backup/full
  9. 截取週二 23:00 到drop 之前的 binlog
    [root@db01 inc2]# mysqlbinlog --skip-gtids --include-gtids='1afe8136-601d-11e9-9022-000c2928f5dd:7-9' /data/binlog/mysql-bin.000009 >/data/backup/binlog.sql
  10. 進行恢復
    [root@db01 backup]# mkdir /data/mysql/data2 -p
    [root@db01 full]# cp -a * /data/mysql/data2
    [root@db01 backup]# chown -R mysql.  /data/*
    [root@db01 backup]# systemctl stop mysqld
    vim /etc/my.cnf
    datadir=/data/mysql/data2
    systemctl start mysqld
    Master [(none)]>set sql_log_bin=0;
    Master [(none)]>source /data/backup/binlog.sql

    作業1
    Xtrabackup企業級增量恢復實戰

    背景:
    某大型網站,mysql數據庫,數據量500G,每日更新量20M-30M
    備份策略:
    xtrabackup,每週日0:00進行全備,週一到週六00:00進行增量備份。
    故障場景:
    週三下午2點出現數據庫意外刪除表操作。
    如何恢復?

    作業2
    練習:mysqldump備份恢復例子

    1、創建一個數據庫 oldboy
    2、在oldboy下創建一張表t1
    3、插入5行任意數據
    4、全備
    5、插入兩行數據,任意修改3行數據,刪除1行數據
    6、刪除所有數據
    7、再t1中又插入5行新數據,修改3行數據
    需求,跳過第六步恢復表數據

    作業3

    分別寫備份腳本和策略

    作業4:備份集中單獨恢復表

思考:在之前的項目案例中,如果誤刪除的表只有10M,而備份有500G,該如何快速恢復誤刪除表?
提示:

drop table city;
create table city like city_bak;
alter table city discard tablespace;
cp /backup/full/world/city.ibd  /application/mysql/data/world/
chown -R mysql.mysql  /application/mysql/data/world/city.ibd 
alter table city import  tablespace;

作業5: 從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
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章