mysql到底如何備份

數(shù)據(jù)備份是數(shù)據(jù)容災(zāi)的最后一道防線，即便有著兩地三中心的架構(gòu)，備份也依然重要。如果備份出問題，備份時(shí)影響了交易業(yè)務(wù)，備份數(shù)據(jù)無法恢復(fù)，這些也是企業(yè)難以承受的。所以選擇合適的備份工具尤為重要。

創(chuàng)新互聯(lián)建站專注于鄂托克前企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),成都商城網(wǎng)站開發(fā)。鄂托克前網(wǎng)站建設(shè)公司,為鄂托克前等地區(qū)提供建站服務(wù)。全流程按需規(guī)劃網(wǎng)站，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)

每個(gè)企業(yè)級(jí)數(shù)據(jù)庫都會(huì)有配套的備份工具，MEB(MySQL Enterprise Backup)就是MySQL企業(yè)版中非常重要的工具之一，是為企業(yè)級(jí)客戶提供的數(shù)據(jù)備份方案。

Xtrabackup一直作為MEB 開源版?zhèn)涮ザ嬖?，從MySQL 8.0開始情況可能會(huì)變得有所不同。

在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB備份/恢復(fù)體驗(yàn)會(huì)更好，目前xtrabackup還不支持這些特性。

MySQL 企業(yè)版還有哪些功能？

特性1：Backup Lock

8.0之前使用xtrabackup或MEB做物理備份，為了保證備份時(shí)InnoDB引擎表與其他引擎數(shù)據(jù)文件、及binlog日志的一致性會(huì)上全局讀鎖，再拷貝非InnoDB文件，這期間MySQL會(huì)變成只讀，數(shù)據(jù)無法寫入。表數(shù)量越多，可能加上時(shí)間越長(zhǎng)，如果使用的xtrabackup 不小心沒加rsync參數(shù)，逐個(gè)拷貝frm文件，鎖定時(shí)間會(huì)更長(zhǎng)，對(duì)業(yè)務(wù)影響較大。

我曾遇到過部署在虛擬機(jī)的實(shí)例有12000多張表，當(dāng)時(shí)使用的xtrabackup，備份腳本中沒加rsync參數(shù)，結(jié)果鎖了十幾分鐘，而MEB就沒有這樣的問題。

MySQL 8.0支持輕量級(jí)備份鎖 LOCK INSTANCE FOR BACKUP，數(shù)據(jù)字典也重構(gòu)了由InnoDB存儲(chǔ)。若不創(chuàng)建非InnoDB表，MEB默認(rèn)使用備份鎖獲取binlog日志一致性位置，并阻止DDL操作，但不影響DML操作。

只有InnoDB表，僅上備份鎖

請(qǐng)點(diǎn)擊輸入圖片描述

若有非InnoDB表，上全局鎖

請(qǐng)點(diǎn)擊輸入圖片描述

特性2：Redo Log Archiving

MEB能做到在線熱備，備份時(shí)不影響數(shù)據(jù)庫讀寫，這是利用了InnoDB事務(wù)日志，在備份期間持續(xù)監(jiān)視r(shí)edo log的變化，讀取增量變化，寫入到ibbackup_logfile，也就不需要上鎖來保障備份一致性。(對(duì)非InnoDB的文件需要上讀鎖拷貝)

如果備份期間數(shù)據(jù)庫寫入負(fù)載特別大，而寫入ibbackup_logfile速度較慢，redo log size也不大，很可能會(huì)出現(xiàn)ibbackup_logfile的寫入速度跟不上redo log記錄生成速度，redo log 空間不夠時(shí)需要覆寫日志文件，那么來不及寫入ibbackup_logfile的記錄會(huì)丟失，導(dǎo)致備份失敗。

MEB 4.1對(duì)此做了優(yōu)化，將redo log處理線程拆分成多線程分工合作，提高處理redo log的效率，降低了redo log覆寫造成備份失敗的概率，但redo log新增速度和ibbackup_logfile寫入速度懸殊太大，問題依然會(huì)發(fā)生。

MySQL 8.0.17支持了redo log archiving 徹底解決了此問題，備份前設(shè)置innodb_redo_log_archive_dirs，指定redo log歸檔目錄。MEB備份時(shí)自動(dòng)開啟日志歸檔，當(dāng)checkpoint時(shí)會(huì)將舊記錄歸檔到此目錄，后續(xù)從歸檔文件中讀取redo日志記錄，避免了覆寫可能導(dǎo)致的redo記錄丟失。

請(qǐng)點(diǎn)擊輸入圖片描述

注意：innodb_redo_log_archive_dirs 不能在數(shù)據(jù)目錄下，目錄權(quán)限要求是700

特性3：Page Tracking

Page Tracking 是為優(yōu)化增量備份效率，減少不必要的數(shù)據(jù)頁掃描。

增量備份當(dāng)前有3種掃描模式：

page-track：利用LSN精確跟蹤上次備份之后被修改頁面，僅復(fù)制這些頁面，效率最快。

optimistic：掃描上次備份之后被修改的InnoDB 數(shù)據(jù)文件中，找出并拷貝修改的頁面。依賴系統(tǒng)時(shí)間，使用存在限制。

full-scan：掃描所有InnoDB數(shù)據(jù)文件，找出并拷貝自上次備份之后修改的頁面，效率最慢

1、利用page-track增量備份，需先安裝備份組件

mysql INSTALL COMPONENT "";

2、在全備前開啟page-track

SELECT mysqlbackup_page_track_set(true);

3、全備之后，做增量備份時(shí)指定若滿足page tracking條件，默認(rèn)會(huì)使用page-track模式，否則會(huì)使用full-scan模式，也可以指定--incremental=page-track。

mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup

incremental-base有3種選擇

last_backup：基于前一次備份做增備，前一次備份可能是增備，也可能是全備。這種方式全備之間可能會(huì)有多個(gè)增備，每次增量可能比較小，但恢復(fù)時(shí)需要逐個(gè)合并。

last_full_backup：基于前一次全備做增備。這種方式增備會(huì)越往后體積可能越大，但恢復(fù)時(shí)只需要合并最后一次增量備份。

dir：基于前一次的備份目錄，前一次備份可能是增備，也可能是全備。

測(cè)試對(duì)比full-scan 和page-track ，在變更頁小于總體50%的情況下 ，備份效率至少能有1倍的速度提升。

page-track 模式 磁盤讀寫均衡，說明讀寫的都是修改頁面。

請(qǐng)點(diǎn)擊輸入圖片描述

full-scan模式 磁盤讀寫差別很大，說明讀了很多未修改的頁面。

請(qǐng)點(diǎn)擊輸入圖片描述

請(qǐng)問mysql怎么自動(dòng)備份數(shù)據(jù)庫?

數(shù)據(jù)庫的自動(dòng)備份，可以減輕維護(hù)者的工作量也便于系統(tǒng)恢復(fù)，對(duì)于比較重要的數(shù)據(jù)庫，最好還是設(shè)置下自動(dòng)備份。

工具/原料

navicat for mysql

mysql 5.5

方法/步驟

打開navicat客戶端，連上mysql后，雙擊左邊你想要備份的數(shù)據(jù)庫。點(diǎn)擊“計(jì)劃”，再點(diǎn)擊“新建批處理作業(yè)”。

雙擊上面的可用任務(wù)，它就會(huì)到下面的列表里去，代表你選擇了這個(gè)任務(wù)。

點(diǎn)擊保存，彈出個(gè)命名對(duì)話框，給這個(gè)任務(wù)取個(gè)名字，點(diǎn)擊“確定”

點(diǎn)擊“設(shè)置”計(jì)劃任務(wù)。

彈出的對(duì)話框，選擇“計(jì)劃”，再點(diǎn)擊“新建”。

這里設(shè)置為從2014年1月24號(hào)起每天早上九點(diǎn)備份該數(shù)據(jù)庫。如果想提高備份頻率、或者設(shè)置備份截止日期，請(qǐng)點(diǎn)擊“高級(jí)”。

高級(jí)選項(xiàng)可以把備份設(shè)置的更精細(xì)，比如這里設(shè)置的是在24小時(shí)內(nèi)每隔2小時(shí)就備份一次。加上前面的基本設(shè)置，任務(wù)計(jì)劃就是：從2014年1月24號(hào)開始，每天九點(diǎn)，每隔2小時(shí)備份一次，每天的備份都持續(xù)24小時(shí)。

最后，輸入電腦密碼就大功告成。

mysql如何快速備份

來源：知乎

河南-老宋(志強(qiáng))

問題描述的不是非常的清晰

使用mysqldump備份時(shí)一般會(huì)會(huì)加上--single-transaction參數(shù)，這里假設(shè)你是加了這個(gè)參數(shù)。

一 加速備份

1 加了single-transaction參數(shù) 備份時(shí) 需要先flush table with read lock 這個(gè)過程中會(huì)有一個(gè)鎖表的過程，如果有事務(wù)或語句正在執(zhí)行，沒有結(jié)束，那么備份進(jìn)程會(huì)一直等待，并且阻塞別的事務(wù)，那么也會(huì)影響業(yè)務(wù)。所以要先確認(rèn)備份的時(shí)候沒有大的事務(wù)在運(yùn)行。

具體 single-transaction的加鎖可以參考 我的博客：mysqldump備份時(shí)加single-transaction會(huì)不會(huì)加鎖

2 mysqldump是單進(jìn)程的，沒有辦法并行，但現(xiàn)在機(jī)器的瓶頸多是出現(xiàn)在IO方面，可以使用更了的IO設(shè)備加快速度

3 mysqldump時(shí)如果空間夠的話，不要邊壓縮邊備份

二 加速恢復(fù)

1 關(guān)閉binlog:不寫入Binlog會(huì)大大的加快數(shù)據(jù)導(dǎo)入的速度

2 innodb_flush_log_at_trx_commit=0

3 更好的配置

建議：

一 如果非要使用邏輯備份，可以考慮mysqldumper, mysqlpump(5.7)這兩個(gè)工具去備份，這兩個(gè)在備份的時(shí)候支持并行操作，mysqldumper還可以對(duì)單表進(jìn)行恢復(fù)，在只需要恢復(fù)單表的情況下，恢復(fù)速度會(huì)大大加快

二 使用物理備份 xtrabackup (open source),MEB(oracle提供，收費(fèi))： 他們的備份原理是基于mysql crash recover， 備份速度 是和邏輯備份的相差不太大。但是恢復(fù)速度卻有很大的提升。

邏輯備份 備出來的是sql語句文件，恢復(fù)時(shí)需要一條一條的執(zhí)行sql,所以恢復(fù)很慢。

而物理備份和還原的速度 相當(dāng)于直接copy文件，所以恢復(fù)的時(shí)候性能有很大的提升

并且這兩個(gè)軟件還支持并行，效果更好。

邏輯備份最大的優(yōu)點(diǎn)是 備份好的文件經(jīng)壓縮后占用空間較小，最大缺點(diǎn)恢復(fù)太慢

物理備份可以很快的恢復(fù)，但是備份好的文件壓縮后占用空間比邏輯備份要大。

使用云，你做為用戶可以不用考慮這些事情。

附：xtrabackup的并行參數(shù)

Parallel local backups

Parallel compression

Parallel encryption

Parallel apply-log

Gary Chen

《MySQL DBA修煉之道》作者。從事數(shù)據(jù)庫領(lǐng)域10多年。

1.一般來說,你只有靠更好的硬件. 軟件沒有大的變動(dòng)的情況下不可能突破硬件瓶頸;

2. mysqldump默認(rèn)的導(dǎo)出選項(xiàng)已經(jīng)可以了,單進(jìn)程的工具不要期望太多,TommyChiu介紹的工具可試試.;

3. 導(dǎo)出的時(shí)候觀察下系統(tǒng),如果是cpu瓶頸,你基本無解.如果是swap問題,看是否是因?yàn)閮?nèi)存不夠;

4. 恢復(fù)的時(shí)候主要是一個(gè)參數(shù):innodb_flush_log_at_trx_commit=2

TommyChiu

mk-parallel-dump 試試

MySQL 常用備份工具流程解析

下面我們就看一下常見的備份工具，以及目前最流行的 Percona XtraBackup 的備份流程。

MySQL 常見的備份工具主要分為三種：

這里先說一下 binlog 備份，它只是把 binlog 又復(fù)制了一份，并且需要在邏輯備份或者物理備份的基礎(chǔ)上才能進(jìn)行數(shù)據(jù)恢復(fù)，無法單獨(dú)進(jìn)行數(shù)據(jù)恢復(fù)。

mysqldump 備份出的文件就是 sql 文件，其核心就是對(duì)每個(gè)表執(zhí)行 select ，然后轉(zhuǎn)化成相應(yīng)的 insert 語句。mysqldump 的備份流程大致如下：

從上面可以看出在 mysqldump 備份期間，備份到某個(gè)數(shù)據(jù)庫時(shí)，該數(shù)據(jù)庫下的表都會(huì)處于只讀狀態(tài)，無法對(duì)表進(jìn)行任何變更，直到該庫下的表備份完畢，這對(duì)于線上環(huán)境一般是無法接受的。若是指定了--master-data或者 --dump-slave 則會(huì)在備份開始時(shí)加全局讀鎖（FLUSH TABLES WITH READ LOCK），直到備份結(jié)束。當(dāng)然我們可以選一個(gè)從庫進(jìn)行備份，這樣就不會(huì)影響線上業(yè)務(wù)。另外使用 mysqldump 備份還有一個(gè)最大的好處，因?yàn)閭浞莩鰜淼氖?sql 語句，所以它支持跨平臺(tái)和跨版本的數(shù)據(jù)遷移或者恢復(fù)，這是物理備份無法做到的。

但是也正是因?yàn)?mysqldump 備份出來的是 sql 語句，在使用時(shí)要更加注意，否則可能會(huì)釀成大禍。例如，使用 mysqldump 常見的問題有：

所以使用 mysqldump 時(shí)一定要了解各個(gè)選項(xiàng)的作用，以及確認(rèn)備份出來的 sql 文件里會(huì)有什么操作，會(huì)對(duì)現(xiàn)有數(shù)據(jù)造成什么影響。

Mydumper 原理與 Mysqldump 原理類似，最大的區(qū)別是引入了多線程備份，每個(gè)備份線程備份一部分表，當(dāng)然并發(fā)粒度可以到行級(jí)，達(dá)到多線程備份的目的。這里不再單獨(dú)介紹。

Percona XtraBackup 是 Percona 公司開發(fā)的一個(gè)用于 MySQL 數(shù)據(jù)庫物理熱備的備份工具，是基于 InnoDB 的崩潰恢復(fù)功能來實(shí)現(xiàn)的。它的基本工作原理如下：

Percona XtraBackup 在進(jìn)行恢復(fù)時(shí)會(huì)應(yīng)用拷貝的 redo log ，應(yīng)用已提交的事務(wù)，回滾未提交的事物，將數(shù)據(jù)庫恢復(fù)到一致性狀態(tài)。因?yàn)?Percona XtraBackup 備份出來的是物理文件，所以在使用備份出的文件進(jìn)行恢復(fù)或者遷移時(shí)，不會(huì)像 mysqldump 那樣會(huì)存在很多問題。

使用 XtraBackup 備份時(shí)根據(jù)備份參數(shù)設(shè)置不同，對(duì)數(shù)據(jù)庫的變更會(huì)造成不同程度的影響，具體影響會(huì)在下文分析。

通過對(duì)比發(fā)現(xiàn)，XtraBackup 具有對(duì)數(shù)據(jù)庫影響小，且能快速恢復(fù)的優(yōu)點(diǎn)，在日常備份中是首選；mysqldump 使用相對(duì)更加靈活，但是使用是要注意對(duì)數(shù)據(jù)庫原有數(shù)據(jù)的影響。

備份策略主要有：全量備份和增量備份，再加上 binlog 備份。

目前去哪兒網(wǎng)數(shù)據(jù)庫備份主要采用 XtraBackup 全量備份 +binlog 備份。數(shù)據(jù)庫的重要級(jí)別不同，全量備份的頻率不同。備份程序主要架構(gòu)如下：

說明：

Percona XtraBackup 是目前備份 MySQL 使用最廣泛的工具。在備份過程中，數(shù)據(jù)庫可以進(jìn)行正常的讀寫或者其他變更操作，但是偶爾也會(huì)遇見備份引起的元數(shù)據(jù)鎖，或提交事務(wù)時(shí)發(fā)現(xiàn)被 binlog lock 阻塞等情況。下面我們就看一下 Percona XtraBackup 的備份流程和加鎖時(shí)機(jī)。

說明：以下對(duì) Percona XtraBackup 的分析都是基于 2.4.23 的版本，其他版本會(huì)略有差別，但是關(guān)鍵步驟基本相同。

XtraBackup 在備份開始時(shí)，會(huì)創(chuàng)建一個(gè)后臺(tái)線程，專門用于拷貝數(shù)據(jù)庫的 redo log 。首先 XtraBackup 會(huì)掃描每組 redo log 的頭部，找出當(dāng)前的 checkpoint lsn ，然后從該 lsn 后順序拷貝所有的 redo log ，包括后續(xù)新產(chǎn)生的 redo log 。該線程會(huì)一直持續(xù)到將非事務(wù)表完全拷貝完成，才會(huì)安全退出。備份日志輸出中會(huì)記錄拷貝開始時(shí)的 checkpoint lsn 。日志輸出如下：

在拷貝ibd文件之前，會(huì)先掃描數(shù)據(jù)庫的數(shù)據(jù)文件目錄，獲取ibdata1，undo tablespaces及所有的ibd文件列表，并會(huì)記錄相應(yīng)的 space id，因?yàn)樵诨謴?fù)時(shí)需要這些 space id來找到對(duì)應(yīng) doublewrite buffer里頁面的內(nèi)容，以及對(duì)應(yīng)的redo log條目。然后開始循環(huán)拷貝ibdata1，undo tablespaces及所有的ibd文件。

這里可通過設(shè)置--parallel進(jìn)行多線程備份，提高物理文件的拷貝效率。不設(shè)置則默認(rèn)為1。

在所有ibd文件拷貝完成后，XtraBackup開始備份非ibd文件。這一部分的邏輯比較復(fù)雜，因?yàn)閭浞莘莍bd文件前需要加鎖，具體是否會(huì)加鎖主要受到--no-lock 參數(shù)設(shè)置的影響。

若是設(shè)置了--no-lock為TRUE，則不會(huì)使用"FLUSH TABLES WITH READ LOCK"去加全局讀鎖，但是若備份過程中對(duì)non-InnoDB表執(zhí)行了DDL或者DML操作， 這會(huì)導(dǎo)致備份的不一致，恢復(fù)出來的數(shù)據(jù)就會(huì)有問題。所以是不建議將--no-lock為TRUE，默認(rèn)值是FALSE，也就是在不指定該選項(xiàng)的情況下會(huì)在備份非ibd文件前加全局讀鎖。

下面我們結(jié)合源碼來看看判斷是否加全局鎖這部分的具體流程邏輯：

流程圖如下：

總結(jié)來看：

1）若--no-lock為FALSE（默認(rèn)值），則先施加全局讀鎖，然后再進(jìn)行拷貝文件，另外若 --safe-slave-backup 設(shè)置為TRUE ，則會(huì)在加全局鎖之前關(guān)閉SQL_THREAD線程；

2）若--no-lock為TRUE，則不會(huì)施加鎖，直接進(jìn)行拷貝文件。

加鎖的邏輯主要由lock_tables_maybe實(shí)現(xiàn),先看一下lock_tables_maybe源代碼，如下：

lock_tables_maybe 函數(shù)簡(jiǎn)化處理流程如下：

1）若備份實(shí)例上已經(jīng)加鎖（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者設(shè)置lock-ddl-per-table 則直接返回；

2）若支持備份鎖，則執(zhí)行LOCK TABLES FOR BACKUP；

3）若不支持備份鎖，則執(zhí)行 FLUSH TABLES WITH READ LOCK。根據(jù)相應(yīng)選項(xiàng)設(shè)置，在執(zhí)行該操作前會(huì)判斷是否有執(zhí)行中的DDL/DML，以及等待超時(shí)時(shí)間，是否kill 對(duì)應(yīng)的未結(jié)束的事務(wù)等。

從上文中我們還看到一個(gè)參數(shù)--safe-slave-backup ，該參數(shù)的主要作用是：

若是在從庫執(zhí)行的備份操作時(shí)設(shè)置了該參數(shù)，可以防止因從庫同步主庫操作，而導(dǎo)致XtraBackup長(zhǎng)時(shí)間請(qǐng)求不到鎖而造成備份失敗。

若是設(shè)置了 --safe-slave-backup 為TRUE，那么會(huì)執(zhí)行"STOP SLAVE SQL_THREAD"，并等待Slave_open_temp_tables 為零才開始拷貝非 ibd 文件，Slave_open_temp_tables 為零說明SQL thread執(zhí)行的事務(wù)都已經(jīng)完成，這樣就能保證備份的一致性。并且此時(shí)也不會(huì)有在執(zhí)行的事務(wù)阻塞 XtraBackup 施加全局鎖。

備份完非 ibd 文件后，將會(huì)備份 slave 和 binlog 信息。

mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1

需要注意，在支持備份鎖的實(shí)例上備份，指定了 --slave-info 或--binlog-info 均會(huì)先施加 binlog 備份鎖（ LOCK BINLOG FOR BACKUP），這會(huì)阻塞任何會(huì)更改 binlog 位點(diǎn)的操作。

備份完數(shù)據(jù)庫的所有文件和binlog等相關(guān)信息，備份工作就基本完成了，之后主要執(zhí)行的操作如下：

1）執(zhí)行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",將所有的redo log刷盤；

2）停止redo log復(fù)制線程；

3）釋放全局讀鎖（備份鎖），binlog鎖；

4）開啟SQL_THREAD；

5）拷貝ib_buffer_pool和ib_lru_dump文件；

6）生成配置文件backup-my.cnf；

7）打印備份信息到xtrabackup_info文件，這些信息主要包含備份時(shí)使用的參數(shù)信息，備份起止時(shí)間，binlog位點(diǎn)信息，以及將會(huì)回到的lsn點(diǎn)。

下面是xtrabackup_info記錄的部分內(nèi)容：

加鎖對(duì)應(yīng)的函數(shù)是 mdl_lock_tables ，釋放鎖對(duì)應(yīng)的函數(shù)是 mdl_unlock_all，主要是執(zhí)行COMMIT，結(jié)束 mdl_lock_tables 中開啟的顯式事務(wù)，來釋放MDL鎖。mdl_lock_tables 流程如下：

上面參數(shù)--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之后添加的，因?yàn)?MySQL 5.7 新增了一個(gè)叫做 Sorted Index Builds 的功能，這會(huì)導(dǎo)致某些 DDL 操作不記錄重做日志而導(dǎo)致備份失敗。使用--lock-ddl或--lock-ddl-per-table 就會(huì)在備份開始時(shí)施加鎖，阻止 DDL 操作。

另外，若備份時(shí)指定了--lock-ddl或--lock-ddl-per-table，則在備份非 ibd 文件時(shí)就不是再有加鎖操作。

注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 語句只有在支持備份鎖的實(shí)例上才會(huì)執(zhí)行，Percona Server for MySQL已經(jīng)在 5.6.16-64.0 版本開始支持這種更加輕量的備份鎖。

Q1: 使用 XtraBackup 備份的文件進(jìn)行恢復(fù)時(shí)，恢復(fù)到哪個(gè)時(shí)間點(diǎn)？ A1：恢復(fù)到執(zhí)行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的時(shí)間點(diǎn)，因?yàn)檫@時(shí)任何改變 binlog 位點(diǎn)的操作都會(huì)被阻塞，redo log和binlog 是一致的。

Q2: 在開啟 binlog 的情況下，MySQL 的奔潰恢復(fù)是同時(shí)依賴 binlog 和 redo log 這兩種日志的，為什么XtraBackup 不用備份binlog？

A2：因?yàn)樵趥浞葜杏袌?zhí)行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改變binlog位點(diǎn)的操作，這樣只需要根據(jù)redo log將有commit log 的事務(wù)提交，沒有commit log的事務(wù)進(jìn)行回滾即可。

Q3: 使用Percona XtraBackup備份完成后redo的位點(diǎn)是和binlog是一樣還是比binlog多一些？

A3：通過分析備份流程可以發(fā)現(xiàn)備份 binlog 位點(diǎn)信息（加binlog鎖）是發(fā)生在停止 redo 拷貝線程前，而釋放鎖是在停止 redo 拷貝線之后，所以 redo log 會(huì)多一些。鎖住了 binlog 保證了在該 binlog 位點(diǎn)前已經(jīng)提交的事務(wù)的 redo log 都有 commit log 的信息，未提交的事物也就沒有對(duì)應(yīng)的 commit log 的信息，即便在鎖住 binlog 后有 Innodb 表新的 DML 產(chǎn)生的 redo log ，但是事務(wù)無法提交，也就沒有 commit log 的信息的，最后在回放的過程中對(duì)沒有 commit log 的事務(wù)進(jìn)行回滾就可以了。

Q4：Percona XtraBackup什么時(shí)候會(huì)加鎖，以及影響加鎖時(shí)間長(zhǎng)度的因素有哪些？

A4：上面進(jìn)行了分析，加鎖操作只在備份非 ibd 文件時(shí)執(zhí)行，加鎖時(shí)長(zhǎng)主要和非事務(wù)表的數(shù)量和大小有關(guān)，非事務(wù)表的數(shù)量越多，體積越大，拷貝文件所用的時(shí)間越長(zhǎng)，那么加鎖時(shí)間也就越長(zhǎng)。也會(huì)和 redo log 生成的速度有關(guān)，只是 redo log 刷盤受到多個(gè)因素的影響，未及時(shí)刷盤的 redo log 一般很小。

Q5：Percona XtraBackup 和mysqldump選擇哪個(gè)更好？

A5：通過上面的的解析，若是整個(gè)實(shí)例備份，首先選擇 Percona XtraBackup ，因?yàn)閷?duì)數(shù)據(jù)庫的影響最小。若只是備份某個(gè)庫表，這個(gè)就要視數(shù)據(jù)量而定，若數(shù)據(jù)量不大可以使用 mysqldump 。注意，對(duì)數(shù)據(jù)庫做備份時(shí)最好選擇業(yè)務(wù)連接最少的從庫，因?yàn)閭浞菀矔?huì)消耗一定的資源，避免影響業(yè)務(wù)。

如何把mysql數(shù)據(jù)庫完整備份

兩種方法：①找到bin-mysql-你的數(shù)據(jù)庫名，直接壓縮備份文件夾(此處備份的是物理文件)； ②下載Mysql管理工具 我用的是navicat for mysql 里面自動(dòng)檢索你bin-mysql里面的所有數(shù)據(jù)庫。然后 右鍵數(shù)據(jù)庫名有一個(gè) 導(dǎo)出sql文件(以sql文件形式導(dǎo)出)

mysql如何備份數(shù)據(jù)庫

物理備份，可以使用開源軟件xtrabackup

邏輯備份，可以使用mysql自帶的工具mysqldump

當(dāng)前題目：mysql物理備份怎么備 mysql數(shù)據(jù)庫的備份是怎么做的
本文網(wǎng)址：http://aaarwkj.com/article14/hhhgge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、小程序開發(fā)、Google、網(wǎng)站改版、、動(dòng)態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)