本文主要給大家介紹XtraBackup備份原理及優(yōu)勢，希望可以給大家補(bǔ)充和更新些知識，如有其它問題需要了解的可以持續(xù)在創(chuàng)新互聯(lián)行業(yè)資訊里面關(guān)注我的更新文章的。

10年積累的成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站策劃后付款的網(wǎng)站建設(shè)流程，更有青浦免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

MySQL主從同步原理
MySQL主從同步是在MySQL主從復(fù)制(Master-Slave Replication)基礎(chǔ)上實(shí)現(xiàn)的，通過設(shè)置在Master MySQL上的binlog(使其處于打開狀態(tài))，Slave MySQL上通過一個I/O線程從Master MySQL上讀取binlog，然后傳輸?shù)絊lave MySQL的中繼日志中，然后Slave MySQL的SQL線程從中繼日志中讀取中繼日志，然后應(yīng)用到Slave MySQL的數(shù)據(jù)庫中。這樣實(shí)現(xiàn)了主從數(shù)據(jù)同步功能。
XtraBackup備份原理
innobackupex在后臺線程不斷追蹤InnoDB的日志文件，然后復(fù)制InnoDB的數(shù)據(jù)文件。數(shù)據(jù)文件復(fù)制完成之后，日志的復(fù)制線程也會結(jié)束。這樣就得到了不在同一時間點(diǎn)的數(shù)據(jù)副本和開始備份以后的事務(wù)日志。完成上面的步驟之后，就可以使用InnoDB崩潰恢復(fù)代碼執(zhí)行事務(wù)日志（redo log），以達(dá)到數(shù)據(jù)的一致性。

XtraBackup優(yōu)勢 ：

1. 無需停止數(shù)據(jù)庫進(jìn)行InnoDB熱備
2. 增量備份MySQL
3. 流壓縮到傳輸?shù)狡渌品?wù)器
4. 能比較容易地創(chuàng)建主從同步
5. 備份MySQL時不會增大服務(wù)器負(fù)載

備份分為兩個過程：

1. backup，備份階段，追蹤事務(wù)日志和復(fù)制數(shù)據(jù)文件（物理備份）。
2. preparing，重放事務(wù)日志，使所有的數(shù)據(jù)處于同一個時間點(diǎn)，達(dá)到一致性狀態(tài)

   為什么要做主從復(fù)制？
   我想這是要在實(shí)施以前要想清楚的問題。是為了實(shí)現(xiàn)讀寫分離，減輕主庫負(fù)載或數(shù)據(jù)分析？ 為了數(shù)據(jù)安全，做備份恢復(fù)？主從切換做高可用？
   大部分場景下，以上三個問號一主一從都能夠解決，而且任何生產(chǎn)環(huán)境都建議你至少要有一個從庫，假如你的讀操作壓力特別大，甚至要做一主多從，還可以不同的slave扮演不同的角色，例如使用不同的索引，或者不同的存儲引擎，或使用一個小內(nèi)存server做slave只用于備份。（當(dāng)然slave太多也會對master的負(fù)載和網(wǎng)絡(luò)帶寬造成壓力，此時可以考慮級聯(lián)復(fù)制，即 A->B->C ）
   mysql支持的復(fù)制類型：
   ?。ǎ保夯谡Z句的復(fù)制：  在主服務(wù)器上執(zhí)行的SQL語句，在從服務(wù)器上執(zhí)行同樣的語句。MySQL默認(rèn)采用基于語句的復(fù)制，效率比較高。  
   一旦發(fā)現(xiàn)沒法精確復(fù)制時，  會自動選著基于行的復(fù)制。   
   ?。ǎ玻夯谛械膹?fù)制：把改變的內(nèi)容復(fù)制過去，而不是把命令在從服務(wù)器上執(zhí)行一遍. 從mysql5.0開始支持
   　（３）：混合類型的復(fù)制: 默認(rèn)采用基于語句的復(fù)制，一旦發(fā)現(xiàn)基于語句的無法精確的復(fù)制時，就會采用基于行的復(fù)制。
   復(fù)制類型還可以分為 異步復(fù)制和半同步復(fù)制。
   通常沒說明指的都是異步，即主庫執(zhí)行完Commit后，在主庫寫入Binlog日志后即可成功返回客戶端，無需等等Binlog日志傳送給從庫，一旦主庫宕機(jī)，有可能會丟失日志。而半同步復(fù)制，是等待其中一個從庫也接收到Binlog事務(wù)并成功寫入Relay Log之后，才返回Commit操作成功給客戶端；如此半同步就保證了事務(wù)成功提交后至少有兩份日志記錄，一份在主庫Binlog上，另一份在從庫的Relay Log上，從而進(jìn)一步保證數(shù)據(jù)完整性；半同步復(fù)制很大程度取決于主從網(wǎng)絡(luò)RTT（往返時延），以插件 semisync_master/semisync_slave 形式存在。
   補(bǔ)充：

   • mysql 5.7開始加入了多源復(fù)制，這個特性對同時有很多個mysql實(shí)例是很有用的，阿里云RDS（遷移）實(shí)現(xiàn)了類似的方式。
   • 從MySQL 5.6.2開始，mysql binlog支持checksum校驗(yàn)，并且5.6.6默認(rèn)啟用（CRC32），這對自己模擬實(shí)現(xiàn)mysql復(fù)制的場景有影響。

MySQL復(fù)制技術(shù)有以下一些特點(diǎn)：
(1)   數(shù)據(jù)分布 (Data distribution )
(2)   負(fù)載平衡(load balancing)
(3)   備份(Backups)
(4)   高可用性和容錯行 High availability and failover
如下開始進(jìn)行XtraBackup備份操作
首先要進(jìn)行說明的是：mysql主從數(shù)據(jù)同步，從mysql實(shí)時同步主mysql的數(shù)據(jù)。這里，一般要求主msyql與從mysql版本相同或主msyql不高于從mysql版本(版本查詢>select version()）。一般穩(wěn)健的做法都是使其版本相同，因?yàn)椴煌琺ysql版本之間的binlog(二進(jìn)制日志)格式可能不一樣，有可能會導(dǎo)致同步異常。

主數(shù)據(jù)庫 mysql> select version();
+------------+
| version()  |
+------------+
| 5.6.35-log |
+------------+
1 row in set (0.00 sec)
ip 地址：192.168.212.11 
從數(shù)據(jù)庫：MariaDB [(none)]> select version();
+----------------+
| version()    |
+----------------+
| 10.2.6-MariaDB |
+----------------+
1 row in set (0.00 sec)
ip 地址：192.168.212.10 
第一步：
mysql> grant replication slave on *.* to 'ff'@'192.168.212.10' identified by 'chylinux';
Query OK, 0 rows affected (0.09 sec)
（在主數(shù)據(jù)庫上進(jìn)行給從數(shù)據(jù)庫授權(quán)）
第二步：（如下是在主數(shù)據(jù)庫上面的操作）
說明這里只使用全量備份（恢復(fù)）不使用增量備份（恢復(fù)）
[root@chy01 ~]# rpm -ivh http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm
獲取http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm
警告：/var/tmp/rpm-tmp.tIRhy2: 頭V4 DSA/SHA1 Signature, 密鑰 ID cd2efd2a: NOKEY
準(zhǔn)備中... ################################# [100%]
正在升級/安裝...
1:percona-release-0.1-3 ################################# [100%]
(首先rpm安裝yum的擴(kuò)展源)
[root@chy01 ~]# yum list | grep percona
[root@chy01 ~]# yum install percona-xtrabackup
（安裝備份工具的包）
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'chy'@localhost identified by 'aminglinux';
Query OK, 0 rows affected (0.00 sec)
（在主數(shù)據(jù)庫中創(chuàng)建一個用戶并授權(quán)）
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)
（刷新mysql）
[root@chy01 ~]# mkdir /data/backup
(創(chuàng)建backup目錄，里面存放mysql備份的數(shù)據(jù)庫)
[root@chy01 ~]# ls -l /data/backup/
總用量 4
drwx------ 9 root root 4096 9月  2 18:08 2017-09-02_18-08-29
（如上是備份的數(shù)據(jù)庫）
[root@chy01 backup]# tar -zcvf 2017-09-02_18-08-29.tar.gz 2017-09-02_18-08-29
[root@chy01 backup]# du -sh 2017-09-02_18-08-29.tar.gz
540K   2017-09-02_18-08-29.tar.gz
[root@chy01 backup]# rsync -avP /data/backup/2017-09-02_18-08-29.tar.gz 192.168.212.10:/data/backup/
root@192.168.212.10's password:
sending incremental file list
2017-09-02_18-08-29.tar.gz
    551406 100%  40.40MB/s   0:00:00 (xfer#1, to-check=0/1)
sent 3090 bytes  received 4531 bytes  1172.46 bytes/sec
total size is 551406  speedup is 72.35
（用rsync進(jìn)行同步）
第三步（拷貝備份主數(shù)據(jù)庫的數(shù)據(jù)+恢復(fù)數(shù)據(jù)庫）
[root@chy ~]# mkdir /data/backup
（從數(shù)據(jù)庫上也需要創(chuàng)建一個目錄）
[root@chy ~]# ls /data/backup/
2017-09-02_18-08-29.tar.gz
（可以看到已經(jīng)同步成功）
[root@chy ~]# du -sh /data/backup/2017-09-02_18-08-29.tar.gz
540K   /data/backup/2017-09-02_18-08-29.tar.gz
（大小一致）
[root@chy backup]# tar -xzvf /data/backup/2017-09-02_18-08-29.tar.gz
（解壓縮）
[root@chy backup]# innobackupex --use-memory=512M --apply-log 2017-09-02_18-08-29
（進(jìn)行初始化）
[root@chy ~]# /etc/init.d/mariadb stop
Stopping mariadb (via systemctl):              [  確定  ]
（關(guān)閉數(shù)據(jù)庫，之后進(jìn)行恢復(fù)操作）
[root@chy backup]# rm -rf /data/mariadb/
[root@chy backup]# mkdir /data/mariadb
[root@chy backup]# chown mysql1:mysql1 /data/mariadb
[root@chy backup]# innobackupex --defaults-file=/etc/my.cnf --datadir=/data/mariadb/  --use-memory=512M  --copy-back 2017-09-02_18-08-29
（在這里的時候我其實(shí)是報(bào)了一個錯誤，innobackupex version 2.3.9 based on MySQL server 5.6.24 Linux (x86_64) (revision id: fde0e3e)
Error: datadir must be specified.
（這里的錯誤是必須要指定新的datadir的目錄，指定后就可以恢復(fù)成功）
[root@chy backup]# ls /data/mariadb/
db1    ib_logfile0  mysql  performance_schema  xtrabackup_binlog_pos_innodb  zhucong
ibdata1  ib_logfile1  mysql2  test         xtrabackup_info        zrlog
（查看已經(jīng)恢復(fù)數(shù)據(jù)庫）
[root@chy backup]# /etc/init.d/mariadb start
Starting mariadb (via systemctl):  Warning: mariadb.service changed on disk. Run 'systemctl daemon-reload' to reload units.
                              [  確定  ]
[root@chy backup]# systemctl daemon-reload
[root@chy backup]# /etc/init.d/mariadb start
Starting mariadb (via systemctl):              [  確定  ]
看了以上關(guān)于XtraBackup備份原理及優(yōu)勢，希望能給大家在實(shí)際運(yùn)用中帶來一定的幫助。本文由于篇幅有限，難免會有不足和需要補(bǔ)充的地方，如有需要更加專業(yè)的解答，可在官網(wǎng)聯(lián)系我們的24小時售前售后，隨時幫您解答問題的。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前題目：XtraBackup備份原理及優(yōu)勢-創(chuàng)新互聯(lián)
分享URL：http://www.rwnh.cn/article48/esgep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、服務(wù)器托管、云服務(wù)器、營銷型網(wǎng)站建設(shè)、搜索引擎優(yōu)化、品牌網(wǎng)站制作

廣告

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