mysql 主備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優點 ：

1. 無需中止數據庫進行InnoDB熱備
2. 增量備份MySQL
3. 流壓縮到傳輸到其它服務器
4. 能比較容易地建立主從同步
5. 備份MySQL時不會增大服務器負載

備份分爲兩個過程：

1. backup，備份階段，追蹤事務日誌和複製數據文件（物理備份）。
2. preparing，重放事務日誌，使全部的數據處於同一個時間點，達到一致性狀態

   爲何要作主從複製？
   我想這是要在實施之前要想清楚的問題。是爲了實現讀寫分離，減輕主庫負載或數據分析？ 爲了數據安全，作備份恢復？主從切換作高可用？
   大部分場景下，以上三個問號一主一從都可以解決，並且任何生產環境都建議你至少要有一個從庫，假如你的讀操做壓力特別大，甚至要作一主多從，還能夠不一樣的slave扮演不一樣的角色，例如使用不一樣的索引，或者不一樣的存儲引擎，或使用一個小內存server作slave只用於備份。（固然slave太多也會對master的負載和網絡帶寬形成壓力，此時能夠考慮級聯複製，即 A->B->C ）
   mysql支持的複製類型：
   　　（１）：基於語句的複製： 在主服務器上執行的SQL語句，在從服務器上執行一樣的語句。MySQL默認採用基於語句的複製，效率比較高。
   一旦發現無法精確複製時， 會自動選着基於行的複製。
   　　（２）：基於行的複製：把改變的內容複製過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持
   　　（３）：混合類型的複製: 默認採用基於語句的複製，一旦發現基於語句的沒法精確的複製時，就會採用基於行的複製。
   複製類型還能夠分爲 異步複製和半同步複製。
   一般沒說明指的都是異步，即主庫執行完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):                          [  肯定  ]