mysql災備演練問題

前期寫的mysql熱備份腳本恢復，尚未正式用到過，可是今天演練災備恢復，可是遇到幾個問題。

測試環境：

搭建mysql，安裝xtrabackup

vim /etc/yum.repos.d/Percona.repo

[percona]
name = CentOS $releasever - Percona
baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona
gpgcheck = 0

 yum install percona-xtrabackup.x86_64 -y

 

一、演練恢復數據：

拿到生產環境備份數據，運行恢復數據腳本。http://www.cnblogs.com/jjzd/p/6659607.html

結果運行失敗，緣由是全量備份日期計算錯誤，原腳本已修改。

二、停掉mysql，刪除mysql數據（移動/var/lib/mysql到/var/lib/mysql_bak）

三、運行修改備份恢復腳本。

四、修改權限，chown -R mysql.mysql /var/lib/mysql

五、啓動mysql，service mysql restart，報錯：

Starting MySQL...The server quit without updating PID file (/var/lib/mysql/mysql.pid).[失敗]

 緣由最好的辦法是先查看下錯誤日誌：

（1）、多是/var/lib/mysql/mysql.pid文件沒有寫的權限

解決方法 ：給予權限，而後從新啓動mysqld！

（2）、可能進程裏已經存在mysql進程

解決方法：用命令「ps -ef|grep mysqld」查看是否有mysqld進程，若是有使用「kill -9  進程號」殺死，而後從新啓動mysqld！

（3）、多是第二次在機器上安裝mysql，有殘餘數據影響了服務的啓動。

解決方法：去mysql的數據目錄/data看看，若是存在mysql-bin.index，就趕快把它刪除掉吧，它就是罪魁禍首了。

（4）、mysql在啓動時沒有指定配置文件時會使用/etc/my.cnf配置文件，請打開這個文件查看在[mysqld]節下有沒有指定數據目錄(datadir)。

解決方法：請在[mysqld]下設置這一行：datadir = /usr/local/mysql/data

（5）、skip-federated字段問題

解決方法：檢查一下/etc/my.cnf文件中有沒有沒被註釋掉的skip-federated字段，若是有就當即註釋掉吧。

（6）、錯誤日誌目錄不存在

解決方法：使用「chown」 「chmod」命令賦予mysql全部者及權限

（7）、selinux惹的禍，若是是centos系統，默認會開啓selinux

解決方法：關閉它，打開/etc/selinux/config，把SELINUX=enforcing改成SELINUX=disabled後存盤退出重啓機器試試。本人就是使用第三條方法解決的 ！

 

故障排除完後，啓動數據庫，恢復上一次備份後產生的數據變化：

六、恢復二進制文件：

去徹底備份的目錄下查看一下當時備份時候binlog的日誌信息（由於增量備份是被應用到徹底備份裏的，固然，查看最後一次增量備份目錄中的這個文件信息也能夠，其實兩個內容是同樣的）

[root@manager1 mysql]# cat xtrabackup_binlog_pos_innodb
mysql-bin.000001	3710
#讀取該二進制日誌的位置並保存至.sql文件
[root@manager1 ~]# mysqlbinlog --start-position=3710 /var/lib/mysql_bak/mysql-bin.000001 > /tmp/1.sql
[root@manager1 mysql]# mysql -h127.0.0.1 -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.6.37-log MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
#進入mysql且先關閉二進制功能，進行恢復，再開啓二進制功能：
mysql> set sql_log_bin = 0;
Query OK, 0 rows affected (0.55 sec)

mysql> source /tmp/1.sql;
Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

 自此，恢復OK，進入數據庫能夠檢查數據。

注意，當腳本不能自動恢復時，緊急狀況下，請手動恢復，步驟無非就是在全量的基礎上增量恢復：

先進行徹底備份的準備：

innobackupex --apply-log --redo-only /backup/2017-10-17_01-09-48/

再進行增量備份的準備：

innobackupex --apply-log --redo-only /backup/2017-10-17_01-09-48/ --incremental-dir=/backup/2017-10-17_13-26-38/

確保2次操做都出現成功的提示：

completed OK!

由於增量備份的數據都已合併到徹底備份中去了，因此此時只恢復徹底備份便可

innobackupex --copy-back /backup/2017-10-17_01-09-48/

手動備份：

全量：innobackupex --user=backup -password=123456 /backup/
增量備份：innobackupex -user=backup -password=123456 --incremental /backup --incremental-basedir=BASEDIR


 

xtrabackup_checkpoints ： 備份類型（如徹底或增量）、備份狀態（如是否已經爲prepared狀態，這個爲準備工做，包括事務日誌和數據文件，把事務日誌中已提交的事務同步至數據文件，未提交的進行回滾）和LSN(日誌序列號)範圍信息；每一個InnoDB頁(一般爲16k大小)都會包含一個日誌序列號，即LSN。LSN是整個數據庫系統的系統版本號，每一個頁面相關的LSN可以代表此頁面最近是如何發生改變的。查看一下其內容：

cat xtrabackup_checkpoints 
backup_type = full-backuped   # 表示備份類型爲徹底備份
from_lsn = 0                  # LSN號從0開始
to_lsn = 5618613              # LSN號到0結束
last_lsn = 5618613            # 最後的lsn號，換句話說，一會進行增量備份時會以這個數字開始，能夠理解爲                                  xtrabackup爲每次備份打的開始和結束的標記
compact = 0                   # 0表示未啓用壓縮

xtrabackup_binlog_info： mysql服務器當前正在使用的二進制日誌文件及至備份這一刻爲止二進制日誌事件的位置；

xtrabackup_binary：備份中用到的xtrabackup的可執行文件；

backup-my.cnf：備份命令用到的配置選項信息，也就是my.cnf配置文件中定義的相關參數