您好,登錄后才能下訂單哦!
本文主要給大家介紹XtraBackup備份原理及優勢,希望可以給大家補充和更新些知識,如有其它問題需要了解的可以持續在億速云行業資訊里面關注我的更新文章的。
MySQL主從同步原理
MySQL主從同步是在MySQL主從復制(Master-Slave Replication)基礎上實現的,通過設置在Master MySQL上的binlog(使其處于打開狀態),Slave MySQL上通過一個I/O線程從Master MySQL上讀取binlog,然后傳輸到Slave MySQL的中繼日志中,然后Slave MySQL的SQL線程從中繼日志中讀取中繼日志,然后應用到Slave MySQL的數據庫中。這樣實現了主從數據同步功能。
XtraBackup備份原理
innobackupex在后臺線程不斷追蹤InnoDB的日志文件,然后復制InnoDB的數據文件。數據文件復制完成之后,日志的復制線程也會結束。這樣就得到了不在同一時間點的數據副本和開始備份以后的事務日志。完成上面的步驟之后,就可以使用InnoDB崩潰恢復代碼執行事務日志(redo log),以達到數據的一致性。
XtraBackup優勢 :
備份分為兩個過程:
為什么要做主從復制?
我想這是要在實施以前要想清楚的問題。是為了實現讀寫分離,減輕主庫負載或數據分析? 為了數據安全,做備份恢復?主從切換做高可用?
大部分場景下,以上三個問號一主一從都能夠解決,而且任何生產環境都建議你至少要有一個從庫,假如你的讀操作壓力特別大,甚至要做一主多從,還可以不同的slave扮演不同的角色,例如使用不同的索引,或者不同的存儲引擎,或使用一個小內存server做slave只用于備份。(當然slave太多也會對master的負載和網絡帶寬造成壓力,此時可以考慮級聯復制,即 A->B->C )
mysql支持的復制類型:
(1):基于語句的復制: 在主服務器上執行的SQL語句,在從服務器上執行同樣的語句。MySQL默認采用基于語句的復制,效率比較高。
一旦發現沒法精確復制時, 會自動選著基于行的復制。
(2):基于行的復制:把改變的內容復制過去,而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持
(3):混合類型的復制: 默認采用基于語句的復制,一旦發現基于語句的無法精確的復制時,就會采用基于行的復制。
復制類型還可以分為 異步復制和半同步復制。
通常沒說明指的都是異步,即主庫執行完Commit后,在主庫寫入Binlog日志后即可成功返回客戶端,無需等等Binlog日志傳送給從庫,一旦主庫宕機,有可能會丟失日志。而半同步復制,是等待其中一個從庫也接收到Binlog事務并成功寫入Relay Log之后,才返回Commit操作成功給客戶端;如此半同步就保證了事務成功提交后至少有兩份日志記錄,一份在主庫Binlog上,另一份在從庫的Relay Log上,從而進一步保證數據完整性;半同步復制很大程度取決于主從網絡RTT(往返時延),以插件 semisync_master/semisync_slave 形式存在。
補充:
- mysql 5.7開始加入了多源復制,這個特性對同時有很多個mysql實例是很有用的,阿里云RDS(遷移)實現了類似的方式。
- 從MySQL 5.6.2開始,mysql binlog支持checksum校驗,并且5.6.6默認啟用(CRC32),這對自己模擬實現mysql復制的場景有影響。
MySQL復制技術有以下一些特點:
(1) 數據分布 (Data distribution )
(2) 負載平衡(load balancing)
(3) 備份(Backups)
(4) 高可用性和容錯行 High availability and failover
如下開始進行XtraBackup備份操作
首先要進行說明的是:mysql主從數據同步,從mysql實時同步主mysql的數據。這里,一般要求主msyql與從mysql版本相同或主msyql不高于從mysql版本(版本查詢>select version())。一般穩健的做法都是使其版本相同,因為不同mysql版本之間的binlog(二進制日志)格式可能不一樣,有可能會導致同步異常。
主數據庫 mysql> select version(); +------------+ | version() | +------------+ | 5.6.35-log | +------------+ 1 row in set (0.00 sec) ip 地址:192.168.212.11 從數據庫: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) (在主數據庫上進行給從數據庫授權) 第二步:(如下是在主數據庫上面的操作) 說明這里只使用全量備份(恢復)不使用增量備份(恢復) [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 準備中... ################################# [100%] 正在升級/安裝... 1:percona-release-0.1-3 ################################# [100%] (首先rpm安裝yum的擴展源) [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) (在主數據庫中創建一個用戶并授權) mysql> flush privileges; Query OK, 0 rows affected (0.01 sec) (刷新mysql) [root@chy01 ~]# mkdir /data/backup (創建backup目錄,里面存放mysql備份的數據庫) [root@chy01 ~]# ls -l /data/backup/ 總用量 4 drwx------ 9 root root 4096 9月 2 18:08 2017-09-02_18-08-29 (如上是備份的數據庫) [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進行同步) 第三步(拷貝備份主數據庫的數據+恢復數據庫) [root@chy ~]# mkdir /data/backup (從數據庫上也需要創建一個目錄) [root@chy ~]# ls /data/backup/ 2017-09-02_18-08-29.tar.gz (可以看到已經同步成功) [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 (進行初始化) [root@chy ~]# /etc/init.d/mariadb stop Stopping mariadb (via systemctl): [ 確定 ] (關閉數據庫,之后進行恢復操作) [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 (在這里的時候我其實是報了一個錯誤,innobackupex version 2.3.9 based on MySQL server 5.6.24 Linux (x86_64) (revision id: fde0e3e) Error: datadir must be specified. (這里的錯誤是必須要指定新的datadir的目錄,指定后就可以恢復成功) [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 (查看已經恢復數據庫) [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): [ 確定 ]
看了以上關于XtraBackup備份原理及優勢,希望能給大家在實際運用中帶來一定的幫助。本文由于篇幅有限,難免會有不足和需要補充的地方,如有需要更加專業的解答,可在官網聯系我們的24小時售前售后,隨時幫您解答問題的。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。