Mysql 企業級備份與恢復(學習筆記七)

隨著業務的發展，公司業務和規模不斷擴大，網站積累了大量的使用者資訊和資料，對於一家網際網路公司來說，使用者和業務資料是根基。一旦公司的資料錯亂或者丟失，對於網際網路公司而言就等於說是滅頂之災，為防止系統出現操作失誤或系統故障導致資料丟失，公司要求加強使用者資料的可靠性，要求全面加強資料層面備份，並能在故障發生時第一時間恢復。

資料備份形式

檔案備份：

通過Linux的備份命令把檔案統一打個包存起來，可存在本地和遠端伺服器，等到要恢復時，再用這些檔案恢復到指定位置。

資料庫資料備份：

在一些對資料可靠性要求很高的行業如銀行、證券、電信等，如果發生意外停機或資料丟失其損失會十分慘重。為此資料庫管理員應針對具體的業務要求制定詳細的資料庫備份與災難恢復策略，並通過模擬故障對每

種可能的情況進行嚴格測試，只有這樣才能保證資料的高可用性。資料庫的備份是一個長期的過程，而恢復只在發生事故後進行，恢復可以看作是備份的逆過程，恢復的程度的好壞很大程度上依賴於備份的情況。此外，

資料庫管理員在恢復時採取的步驟正確與否也直接影響最終的恢復結果。

資料備份型別

按業務劃分：可分為完全備份、增量備份、差異備份

1、完全備份：就是對整個資料庫的資料和資料結構進行備份

優點：直觀，容易被人理解

缺點：1.備份的資料有大量的資料都是重複的，佔用了大量的空間，增加成本

2.備份的資料量大，所需時間較長

（Full Backup）所謂全備份就是對整個資料庫的資料和資料結構進行備份。這種備份方式的好處就是很直觀，容易被人理解。而且當發生資料丟失的災難時，只要用災難之前的備份檔案，就可以恢復丟失的資料。

然而它也有不足之處：首先由於每天都對系統進行完全備份,因此在備份資料中有大量是重複的。這些重複的資料佔用了大量的空間，這對使用者來說就意味著增加成本；其次，由於需要備份的資料量相當大，因此備份所需時間較長。對於那些業務繁忙，備份視窗時間有限的單位來說，選擇這種備份策略無疑是不明智的。

2、增量備份（Incremental Backup）：每次備份的資料只是相當於上次備份後增加和修改過的資料。

優點：沒有重複備份的資料，節省空間

缺點：恢復資料比較麻煩，其中任何一個備份資料出了問題都會導致資料丟失

就是每次備份的資料只是相當於上一次備份後增加的和修改過的資料。這種備份的優點很明顯：沒有重複的備份資料，即節省空間，又縮短了備份時間。但它的缺點在於當發生災難時，恢復資料比較麻煩。舉例來說，如

果系統在星期四的早晨發生故障，丟失大批資料，那麼現在就需要將系統恢復到星期三晚上的狀態。

這時管理員需要首先找出星期一的那份完全備份資料進行系統恢復，然後再找出星期二的資料來恢復星期二的資料，然後在找出星期三的資料來恢復星期三的資料。很明顯這比第一種策略要麻煩得多。另外這種備份可靠

性也差。在這種備份下，各備份資料間的關係就象鏈子一樣，一環套一環，其中任何一個備份資料出了問題都會導致整條鏈子脫節。

3、差異備份（Differential Backup）：每次備份的資料相當於上一次全備份之後新增加和修改過的資料。

就是每次備份的資料是相對於上一次全備份之後新增加的和修改過的資料。管理員先在星期一進行一次系統完全備份；然後在接下來的幾天裡，管理員再將當天所有與星期一不同的資料（新的或經改動的）備份到磁帶上。舉例來說，在星期一，網路管理員按慣例進行系統完全備份；在星期二，假設系統內只多了一個資產清單，於是管理員只需將這份資產清單一併備份下來即可；在星期三，系統內又多了一份產品目錄，於是管理員

不僅要將這份目錄，還要連同星期二的那份資產清單一並備份下來。

如果在星期四系統內有多了一張工資表，那麼星期四需要備份的內容就是：工資表+產品目錄+資產清單。由此可以看出，全備份所需時間最長，但恢復時間最短，操作最方便，當系統中資料量不大時，採用全備份最可靠；差異備份可避免另外兩種策略缺陷，但不同備份型別可以存在一定組合不同備份型別可以存在一定組合不同備份型別可以存在一定組合不同備份型別可以存在一定組合。

不同備份型別組合應用的示例

完全備份和差異備份

在星期一進行完全備份，在星期二至星期五進行差異備份。如果在星期五資料被破壞了，則你只需要還原星期一完全的備份和星期四的差異備份。這種策略備份資料需要較多的時間，但還原資料使用較少的時間。

完全備份和增量備份

在星期一進行完全備份，在星期二至星期五進行增量備份。如果在星期五資料被破壞了，則你需要還原星期一正常的備份和從星期二至星期五的所有增量備份。這種策略備份資料需要較少的時間，但還原資料使用較多的時間。

按方式劃分：可分為熱備、溫備、冷備

熱備份（Hot Backup）是指在資料庫執行中直接備份，對正在執行的資料庫沒有任何影響。

冷備份（Cold Backup）是指在資料庫停止的情況下進行備份，這種備份最為簡單，一般只需要拷貝相關的資料庫物理檔案即可。

溫備份（Warm Backup）備份同樣是在資料庫執行時進行，但是會對當前資料庫的操作有所影響，例如加一個全域性讀鎖以保證備份資料的一致性。（當你備份資料庫中的一個表時，先把這個表鎖起來，不讓別人來增查刪改表中的資料，這樣你在備份的時候，該表中的資料就不會發生變化，保證了備份資料的一致性）

物理備份：直接複製資料檔案進行的備份（直接複製備份的資料檔案是二進位制格式的）

優點：無需額外工具，直接copy即可，恢復直接複製備份檔案即可

缺點：與儲存引擎有關，跨平臺能力較弱

邏輯備份：從資料庫中"匯出"資料另存而進行的備份（將sql語句給匯出到一個文字中，比二進位制格式的檔案大）

優點：能使用編輯器處理，恢復簡單，能基於網路恢復，有助於避免資料損壞

缺點：備份檔案較大，備份較慢，無法保證浮點數的精度，使用邏輯備份資料恢復後，還需手動重建索引，十分消耗CPU資源

備份流程圖

Mysql日誌介紹

MySQL日誌：

主要包含：錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進位制日誌等；

日誌是mysql資料庫的重要組成部分。日誌檔案中記錄著mysql資料庫執行期間發生的變化；也就是說用來記

錄mysql資料庫的客戶端連線狀況、SQL語句的執行情況和錯誤資訊等。當資料庫遭到意外的損壞時，可以通

過日誌檢視檔案出錯的原因，並且可以通過日誌檔案進行資料恢復。

Mysql錯誤日誌

在mysql資料庫中，錯誤日誌功能是預設開啟的。並且，錯誤日誌無法被禁止。預設情況下，錯誤日誌儲存在mysql資料庫的資料檔案中。錯誤日誌檔案通常的名稱為hostname.err。其中，hostname表示伺服器主機名。

錯誤日誌資訊可以自己進行配置的，錯誤日誌所記錄的資訊是可以通過logerror和log-warnings來定義的，其中log-err是定義是否啟用錯誤日誌的功能和錯誤日誌的儲存位置，log-warnings是定義是否將警告資訊也定義至錯誤日誌中。預設情況下錯誤日誌大概記錄以下幾個方面的資訊：伺服器啟動和關閉過程中的資訊（未必是錯誤資訊，如mysql如何啟動InnoDB的表空間檔案的、如何初始化自己的儲存引擎的等等）、伺服器執行過程中的錯誤資訊、事件排程器執行一個事件時產生的資訊、在從伺服器上啟動伺服器程式時產生的資訊。

mysql -uroot -p

select globle variables like '%log%';

可以通過配置檔案來修改log_error

vim /etc/my.cnf //如下圖：我將錯誤日誌的路徑改為/var/log/mariadb/mariadb.err

log-error=/var/log/mariadb/mariadb.err

然後重啟資料庫服務連線資料庫檢視全域性日誌，修改成功

檢視錯誤日誌的內容

臨時修改：

Mysql錯誤日誌中，log_error可以直接定義為檔案路徑，也可以為ON|OFF；

log_warings只能使用1|0來定義開關啟動。

永久修改：

更改錯誤日誌位置可以使用log_error來設定形式如下：

[root@stu18 data]# vim /etc/my.cnf

[mysqld]

Log_error=DIR/[filename]

解析：其中，DIR引數指定錯誤日誌的路徑filename引數是錯誤日誌的名稱，沒有指定該引數時預設為主機名。修改配置檔案重啟mysql伺服器即可生效。

注意：在mysql5.5.7之前：資料庫管理員可以刪除很長時間之前的錯誤日誌，以保證mysql伺服器上的硬碟空間。mysql資料庫中，可以使用mysqladmin命令開啟新的錯誤日誌。

mysqladmin命令的語法如下：

mysqladmin –u root –pflush-logs也可以使用登入mysql資料庫中使用FLUSHLOGS語句來開啟新的錯誤日誌。

Mysql查詢日誌

預設情況下查詢日誌是關閉的。由於查詢日誌會記錄使用者的所有操作，其中還包含增刪查改等資訊，在併發操作大的環境下會產生大量的資訊從而導致不必要的磁碟IO，會影響mysql的效能的。如若不是為了除錯資料庫的目的建議不要開啟查詢日誌。

mysql

show global variables like '%log%';

Mysql慢查詢日誌

慢查詢日誌是用來記錄執行時間超過指定時間的查詢語句。通過慢查詢日誌，可以查詢出哪些查詢語句的執行效率很低(有些查詢語句的執行時間比較長，要把這些查詢語句找出清除，來優化伺服器效能)，以便進行優化。強烈建議開啟，它對伺服器效能的影響微乎其微，但是可以記錄mysql伺服器上執行了很長時間的查詢語句。可以幫助我們定位效能問題的。

啟動和設定慢查詢日誌：

1、通過配置檔案my.cnf中的log-slow-queries選項可以開啟慢查詢日誌；

形式如下：

vim /etc/my.cnf

[mysqld]

slow-query-log = ON

slow-query-log-file = /var/log/mariadb/slow.log

long-query-time = 0.01

其中，DIR引數指定慢查詢日誌的儲存路徑；filename引數指定日誌的檔名，生成日誌檔案的完成名稱為filename-slow.log。如果不指定儲存路徑，慢查詢日誌預設儲存到mysql資料庫的資料檔案下，如果不指定檔名，預設檔名為hostname-slow.log

2、通過登入mysql伺服器直接定義

方式如下：

首先要有全域性許可權；然後執行mysql>set global slow_query_log=1;（臨時生效，sql語句執行時間超過1s就被成為慢查詢日誌）

時間預設超過多少的稱為慢查詢日誌？

一般都是通過long_query_time選項來設定這個時間值，時間以秒為單位，可以精確到微秒。如果查詢時間超過了這個時間值（預設為10秒），這個查詢語句將被記錄到慢查詢日誌中。檢視伺服器預設時間值方式如下：

註釋：其中這個慢查詢時間並不是只表示語句自身執行超過10秒還包含由於其他資源被徵用造成阻塞的查詢執行時間或其他原因等都被記錄到慢查詢中。所以這個慢查的時長表示從查詢開始到查詢結束中間包含可能的任何原因所經歷的所有時間。

檢視慢查詢日誌內容

Mysql事務日誌

事務：事務就是一系列操作的集合，一系列操作之後需要提交，提交之後，這一系列操作才能被稱為事務。(要麼操作都執行，要麼都不執行)

事務日誌（InnoDB特有的日誌）可以幫助提高事務的效率。使用事務日誌，儲存引擎在修改表的資料時只需要修改其記憶體拷貝，再把改修改行為記錄到持久在硬碟上的事務日誌中，而不用每次都將修改的資料本身持久到磁碟。事務日誌採用追加的方式，因此寫日誌的操作是磁碟上一小塊區域內的順序I/O，而不像隨機I/O需要在磁碟的多個地方移動磁頭，所以採用事務日誌的方式相對來說要快得多。事務日誌持久以後，記憶體中被修改的資料在後臺可以慢慢的刷回到磁碟。目前大多數的儲存引擎都是這樣實現的，我們通常稱之為預寫式日誌，修改資料需要寫兩次磁碟。

mysql基於事務的操作，會直接把對應記憶體中的資料給改掉，改完之後，去檢視，都已經生效，但是並沒有網磁碟上去寫，他是先寫到事務日誌裡面，然後再定期的往磁碟上去刷（事務日誌採用追加的方式，往磁碟上寫，是按照順序來寫的，大大提高了事務的效率）

如果資料的修改已經記錄到事務日誌並持久化，但資料本身還沒有寫回磁碟，此時系統崩潰，儲存引擎在重啟時能夠自動恢復這部分修改的資料。具有的恢復方式則視儲存引擎而定。

innodb引擎是支援事務的引擎

檢視事務日誌的定義

show global variables like '%log%';

Mysql二進位制日誌

二進位制日誌也叫作變更日誌，主要用於記錄修改資料或有可能引起資料改變的mysql語句，並且記錄了語句發生時間、執行時長、操作的資料等等。所以說通過二進位制日誌可以查詢mysql資料庫中進行了哪些變化。一般大小體積上限為1G

show global variables like '%log%';

sql_log_bin ={ON|OFF} #用於控制會話級別（連上mysql執行一個操作語句，這就是會話級別的，比如說直接用一個檔案匯入mysql，這就不算會話級別的）二進位制日誌功能的開啟或關閉。預設為ON，表示啟用記錄功能。使用者可以在會話級別修改此變數的值，但其必須具有SUPER許可權。

binlog_cache_size =32768 #預設值32768 Binlog Cache用於在開啟了二進位制日誌（binlog）記錄功能的環境，是MySQL 用來提高binlog的記錄效率而設計的一個用於短時間內臨時快取binlog資料的記憶體區域。一般來說，如果我們的資料庫中沒有什麼大事務，寫入也不是特別頻繁，2MB～4MB是一個合適的選擇。但是如果我們的資料庫大事務較多，寫入量比較大，可與適當調高binlog_cache_size。同時，我們可以通過binlog_cache_use 以及binlog_cache_disk_use來分析設定的binlog_cache_size是否足夠，是否有大量的binlog_cache由於記憶體大小不夠而使用臨時檔案（binlog_cache_disk_use）來快取了。

log_bin = mysql-bin #指定binlog的位置，預設在資料目錄下。

binlog-format= {ROW|STATEMENT|MIXED} #指定二進位制日誌的型別，建議為MIXED。如果設定了二進位制日誌的格式，卻沒有啟用二進位制日誌，則MySQL啟動時會產生警告日誌資訊並記錄於錯誤日誌中。

row:不記錄每條sql語句的上下文關係，而僅僅記錄每條資料被修改了

statement：每一條會修改資料的sql語句都會被記錄

mixed：表示前兩者混合

sync_binlog = 10 #設定多久同步一次二進位制日誌至磁碟檔案中，0表示不同步，任何正數值都表示對二進位制每多少次寫操作之後同步一次。當autocommit的值為1時，每條語句的執行都會引起二進位制日誌同步，否則，每個事務的提交會引起二進位制日誌同步

通過編輯my.cnf中的log-bin選項可以開啟二進位制日誌；形式如下：

其中，DIR引數指定二進位制檔案的儲存路徑；filename引數指定二級制檔案的檔名，其形式為filename.number，number的形式為000001、000002等。每次重啟mysql服務或執行mysql> flush logs;都會生成一個新的二進位制日誌檔案，這些日誌檔案的number會不斷地遞增。除了生成上述的檔案外還會生成一個名為filename.index的檔案。這個檔案中儲存所有二進位制日誌檔案的清單又稱為二進位制檔案的索引。

每重啟一次資料庫服務，就會生成一個二進位制日誌檔案

檢視二進位制日誌：

二進位制日誌的定義方式為二進位制格式；使用此格式可以儲存更多的資訊，並且可以使寫入二進位制日誌的效率更高。但是不能直接使用檢視命令開啟並檢視二進位制日誌。

小擴充套件：二進位制日誌的記錄位置,通常為上一個事件執行結束時間的位置，每一個日誌檔案本身也有自己的後設資料所以說對於當前版本的mysql來說二進位制的開始位置通常為107；

連線mysql，輸入幾條可以修改資料的sql語句，從而生成二進位制日誌

檢視指定二進位制日誌資訊

命令列下檢視二進位制日誌：

由於無法使用cat等方式直接開啟並檢視二進位制日誌；所以必須使用mysqlbinlog命令。但是當正在執行mysql讀寫操作時建議不要使用此開啟正在使用的二進位制日誌檔案；若非要開啟可flushlogs。mysqlbinlog命令的使用方式：

匯出此資料庫的資訊：

[root@stu18 data]#mysqlbinlog mysql-bin.000017 > /tmp/a.sql

匯入此資料庫的資訊：

[root@stu18 data]#mysql < a.sql

刪除二進位制日誌資訊：

二進位制日誌會記錄大量的資訊（其中包含一些無用的資訊）。如果很長時間不清理二進位制日誌，將會浪費很多的磁碟空間。但是，刪除之後可能導致資料庫崩潰時無法進行恢復，所以若要刪除二進位制日誌首先將其和資料庫備份一份，其中也只能刪除備份前的二進位制日誌，新產生的日誌資訊不可刪(可以做即時點還原)。也不可在關閉mysql伺服器之後直接刪除因為這樣可能會給資料庫帶來錯誤的。若非要刪除二進位制日誌需要做如下操作：匯出備份資料庫和二進位制日誌檔案進行壓縮歸檔儲存。刪除二進位制檔案的方法如下：

使用RESET MASTER語句可以刪除所有的二進位制日誌。該語句的形式如下：

mysql> reset master;

Query OK, 0 rowsaffected (0.17 sec)

mysql> show binary logs;

Mysql備份工具

mysqldump: 邏輯備份工具，適用於所有儲存引擎，可用於溫備，能實現完全備份，部分備份；對InnoDB儲存引擎

支援熱備；

cp, tar等檔案系統工具：物理備份工具，適用於所有儲存引擎；用於冷備，能實現完全備份，部分備份；

lvm2的快照：幾乎熱備；藉助於檔案系統工具實現物理備份；

mysqlhotcopy: 幾乎冷備；僅適用於MyISAM儲存引擎；

Mysql備份方案①mysqldump+binlog: （推薦）

完全備份，通過備份二進位制日誌實現增量備份

②xtrabackup:

對InnoDB：熱備，支援完全備份和增量備份

對MyISAM：溫備，只支援完全備份

③lvm2快照+binlog：

幾乎熱備，物理備份

mysqldump+binlog命令的語法格式

mysqldump [OPTIONS] database [tables]：備份單個庫，或庫指定的一個或多個表

mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2DB3...]：備份一個或多個庫

mysqldump [OPTIONS] --all-databases [OPTIONS]：備份所有庫

其他選項

-x, --lock-all-tables：鎖定所有表

-l, --lock-tables：鎖定備份的表

--single-transaction：啟動一個大的單一事務實現備份

-C, --compress：壓縮傳輸

-E, --events：備份指定庫的事件排程器

-R, --routines：備份儲存過程和儲存函式

--triggers：備份觸發器

--master-data={0|1|2}

0：不記錄

1：記錄CHANGE MASTER TO語句；此語句未被註釋

2：記錄為註釋語句

-F，--flush-logs：鎖定表之後執行flush logs命令

mysqldump+binlog備份與恢復1.修改mysql配置檔案，開啟二進位制日誌

vim /etc/my.cnf

log-bin = master-log

然後重啟mysql

systemctl restart mariadb

在進入mysql檢視是否生成二進位制日誌

2、準備備份目錄

3、準備備份資料庫及表

mysql

create database test;

use magedu;

create table m(id int,name char(20));

4、進行完整備份

mysqldump --all-databases --lock-all-tables --flush-log --master-data=2 > /backup/`date +%F_%T`-all.sql

5、向表中插入資料

mysql

use magedu;

show master status;

insert into m26 (id,name) values(1,'fuming'),(2,'zhangmeng');

6、進行增量備份，備份二進位制日誌

mysqlbinlog --start-position=245 --stop-position=479 /var/lib/mysql/master-log.000002 > /backup/binlog/binlog-`date +%F_%T`.sql

判斷position的start和stop

show master logs;

show binlog events in 'master-log.000002';

結束要包含commit提交。

7、繼續插入資料，在沒備份的情況下刪除資料庫，模擬誤操作

8、資料恢復，由於最後我們沒有備份就刪除了資料庫，所以我們首先需要保護最後的二進位制日誌,如果這些二進位制丟了，那就真的恢復不了了，檢視刪除操作之前的position值mysqlbinlog /var/lib/mysql/master-log.000002

9、將最後操作的二進位制日誌備份

mysqlbinlog --start-position=467 --stop-position=677 /var/lib/mysql/master-log.000002 > /backup/binlog/binlog-`date +%F_%T`.sql

ls /backup/binlog/

10.匯入之前的所有備份

mysql < /backup/2017-12-07_20\:20\:04-all.sql 匯入完整備份

mysql < /backup/binlog/binlog-2017-12-07_20\:45\:17.sql 匯入增量備份

mysql < /backup/binlog/binlog-2017-12-07_21\:05\:42.sql 匯入刪掉資料庫之前的增量備份

11.檢視資料庫及資料

xtrabackup

Xtrabackup是由percona提供的mysql資料庫備份工具，據官方介紹，是一款開源能夠對innodb和xtradb資料庫進行熱備的工具。

特點：

(1)備份過程快速、可靠

(2)備份過程不會打斷正在執行的事務

(3)能夠基於壓縮等功能節約磁碟空間和流量

(4)自動實現備份檢驗

(5)還原速度快

實驗步驟：（1）xtrabackup的安裝

yum install percona-xtrabackup -y

（2）完全備份

innobackupex --user=root /backup

（3）新增資料

mysql -uroot

create database magedu;

use magedu

create table m26 (id int,name char(20));

insert into m26 values (007,'fuming'),(008,'zhangmeng')

（4）增量備份

innobackupex --incremental /backup/ --incremental-basedir=/backup/2017-11-16_16-53-4

（5）資料恢復準備

1.執行操作（完全備份）：

innobackupex --apply-log --redo-only BASE-DIR（BASE-DIR是完全備份的目錄）

例如：innobackupex --apply-log --redo-only BASE-DIR --incrementaldir=/backup/2017-11-16_17-17-52/

2.接著執行（增量）：

innobackupex --apply-log --redo-only BASE-DIR --incrementaldir=INCREMENTAL-DIR-1（INCREMENTAL-DIR-1是增量備份的目錄）

例如：innobackupex --apply-log --redo-only /backup/2017-11-16_16-53-43 --incrementaldir=/backup/2017-11-16_17-17-52/

（6）恢復階段，還原資料

mv /var/lib/mysql /var/lib/mysql.bak 模擬刪除資料庫

mkdir /var/lib/mysql

cd /var/lib/mysql

innobackupex --copy-back /backup/2017-11-16_16-53-43 恢復完全備份

lvm2快照+binlog

做實驗之前我們先回顧一下lvm2-snapshot的知識

LVM快照簡單來說就是將所快照源分割槽一個時間點所有檔案的後設資料進行儲存，如果原始檔沒有改變，那麼訪問快照卷的相應檔案則直接指向源分割槽的原始檔，如果原始檔發生改變，則快照卷中與之對應的檔案不會發生改變。快照卷主要用於輔助備份檔案。

實驗步驟：

1、新增硬碟，並劃分磁碟型別為lvm型別

echo '- - -' > /sys/class/scsi_host/host2/scan

2.分割槽

t 8e 就是lvm

partx -a /dev/sdb 使核心識別新磁碟

3.pvcreate /dev/sdb1 新增物理卷

4.vgcreate myvg /dev/sdb1 新增捲組

5.lvcreate -n mydata -L 5G myvg 新增邏輯卷

6、mkfs.ext4 /dev/mapper/myvg-mydata 格式化邏輯卷

7、掛載mount /dev/mapper/myvg-mydata /lvm_data 使用

8、修改Mysql配置，使得資料檔案在邏輯捲上 datadir=/lvm_data

9、service mysqld restart 啟動Mysql服務

10、建立資料庫，進行操作

11、mysql> FLUSH TABLES WITH READ LOCK; #鎖定表

12、lvcreate -L 1G -n mydata-snap -p r -s /dev/mapper/myvgmydata

#建立快照卷 Logical volume "mydata-snap" created.

13、mysql> UNLOCK TABLES; #解鎖所有表

14、 mount /dev/myvg/mydata-snap /lvm_snap/ #掛載snap

15、tar cvf /tmp/mysqlback.tar ./* #打包物理備份

16、umount /lvm_snap/ #解除安裝snap

17、lvremove myvg mydata-snap #刪除snap

18、刪除mysql資料 rm -rf /lvm_data/*

19、解壓恢復刪除資料 tar xvf /tmp/mysqlback.tar ./

20、驗證資料庫資料是否正確恢復

總結

備份方法備份速度回覆速度便捷性性功能一般用於

Mysqldump慢慢一般，可無視儲存引擎的差異一般中小型資料量備份

Lvm2快照快快支援幾乎熱備，速度快一般中小型資料量備份

Xtrabackup較快較快實現innodb熱備，對儲存引擎要求強大較大規模的本分

cp快快一般，靈活性低很弱少量資料備份

好了，今天的內容就到這裡，我們下期再見。

以上這篇Mysql實現企業級日誌管理、備份與恢復的實戰教程就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支援指令碼之家。

mysql學習筆記之備份與恢復
2020-03-26
MySql筆記
rman資料備份恢復學習筆記
2012-10-17
筆記
INNOBACKUPEX的全備和增量備份恢復學習筆記
2015-07-28
筆記
MySQL備份與恢復
2016-06-02
MySql
MySQL備份與恢復——基於Xtrabackup物理備份恢復
2021-07-12
MySql
MYSQL 企業級備份
2016-01-25
MySql
Mysql備份與恢復(1)---物理備份
2020-01-09
MySql
Mysql的備份與恢復
2016-02-15
MySql
Mysql 備份與恢復二
2010-11-03
MySql
MySQL 非常規恢復與物理備份恢復
2019-04-30
MySql
Longhorn，企業級雲原生容器分散式儲存 - 備份與恢復
2021-08-24
分散式
MySQL：Innodb恢復的學習筆記
2018-08-27
MySql筆記
Mysql備份與恢復(2)---邏輯備份
2020-01-09
MySql
influxdb 筆記: 備份/恢復
2016-11-29
UX筆記
入門MySQL——備份與恢復
2020-07-03
MySql
《入門MySQL—備份與恢復》
2019-09-08
MySql
MySQL備份與恢復操作解析
2020-12-25
MySql
Mysql資料備份與恢復
2020-11-29
MySql
MySQL備份與恢復——實操
2020-10-05
MySql
MySQL備份與恢復簡介
2017-01-20
MySql
Effective MySQL之備份與恢復
2013-10-11
MySql
Mysql備份恢復
2019-04-18
MySql
mysql 備份恢復
2010-01-19
MySql
MySQL備份與恢復——基於MyDumper/MyLoader 邏輯備份恢復
2021-07-15
MySql
oracle備份與恢復雜記
2010-11-07
Oracle
CUUG筆記--oracle備份和恢復
2013-12-28
筆記Oracle
MySQL入門--備份與恢復（一）
2019-06-05
MySql
MySQL入門--備份與恢復（二）
2019-06-05
MySql
MySQL入門--備份與恢復（三）
2019-06-06
MySql
Mysql的幾種備份與恢復
2018-07-10
MySql
MySQL增量備份與恢復例項
2016-05-18
MySql
mysql簇備份與恢復(轉載)
2009-05-26
MySql
MySQL備份與恢復——基於OUTFILE /LOAD DATA 邏輯備份恢復
2021-07-19
MySql
學習第2章：備份與恢復選項
2008-05-26
【MySQL】MySQL備份和恢復
2018-03-12
MySql
Mysql備份和恢復
2012-03-26
MySql
備份與恢復：polardb資料庫備份與恢復
2020-11-13
資料庫
備份與恢復系列七續 catalog中的備份指令碼
2014-08-17
指令碼

Mysql 企業級備份與恢復(學習筆記七)

相關文章