生產Mysql數據庫數據恢復實戰

重要數據請聯系兆柏數據恢復公司

線上環境

    mysql數據庫一主多從的架構，主寫從讀進行讀寫分離，專用從庫做數據備份，每天0點全備一次，12點增量備份一次，初始階段數據量很小的情況按此方案，后續數據量大，讀寫頻繁時，再進行相關調整，增加增量備份頻次

系統環境

[root@mysql-1 ~]# cat /etc/redhat-release 

CentOS release 6.8 (Final)

[root@mysql-1 ~]# uname -r

2.6.32-642.el6.x86_64

[root@mysql-1 ~]# mysql -v

mysql  Ver 14.14 Distrib 5.7.17, for linux-glibc2.5 (x86_64) using  EditLine wrapper

主從同步

 3306---->3307 

3307 開啟binlog日志，用做備份服務器，0點全備，12點增量備份

[root@mysql-1 ~]# netstat -lntup|grep 33

tcp 0 0 :::3306  :::* LISTEN  42473/mysqld        

tcp  0 0 :::3307  :::*  LISTEN  42769/mysqld

2   模擬線上數據寫入

數據庫同步完成，開啟3307從庫的binlog日志功能

查看目前的日志文件

寫入數據測試同步

注：查看日志文件修改時間發現有數據寫入

此時執行全備文件

全備之后寫入數據

此時出現誤操作刪除了一個數據

出現誤操作不可能第一時間發現，因此，繼續寫入數據

此時發現數據庫數據出現問題，某個數據無法訪問了，需要進行恢復

3  恢復數據

數據恢復具體操作如下

1、停止主從同步，應用與數據庫的讀寫操作，防止數據再次寫入

2、刷新binlog，生成新的日志文件

3、恢復全備文件到主庫

4、合并binlog文件生成sql，刪除誤操作語句

5、進行增量恢復

此時主庫數據恢復成功

4  測試主從同步

重新開啟同步來測試數據是否同步

ySQL 刪庫到恢復

失誤刪庫不一定要跑路，只要有合理的備份策略，絕大多數情況都可以恢復到刪庫之前的那一刻。如果要恢復，一般采用的辦法是使用上一次全備先恢復數據，增量數據通過導入從全備開始到誤操作之前的 Binlog，但是這種方式如果 Binlog 多，通常是比較慢的，并且很容易導入到一半時報錯，這篇文章就介紹另外一種方式進行誤操作的恢復。環境IP作用環境192.168.150.253源實例（誤操作的實例）CentOS 7.4、已安裝 MySQL 8.0.25、已安裝 XtraBackup 8.0.25192.168.150.123目標實例（用于恢復數據）CentOS 7.4、已安裝 MySQL 8.0.25、已安裝 XtraBackup 8.0.25大致過程：在源實例寫入基礎數據，然后進行全量備份，再寫入增量數據，之后模擬在源實例誤刪除一個數據庫，之后通過全量備份在目標實例上進行恢復，把源實例的 Binlog 傳輸到恢復數據的實例，然后修改成 relay log，再通過 start slave sql_thread until sql_before_gtids="xxx" 同步數據到誤操作前面的一個位點。在源實例創建測試庫和測試表：

寫入數據：

查詢數據：

在源實例增加備份用戶：

在源實例進行全量備份：

將全量備份傳到目標實例上：

在源實例寫入一條數據：

在源實例模擬刪庫誤操作：

關閉目標實例運行的 MySQL：

清空目標實例數據目錄和事務日志目錄：

將全備導入目標實例：

修改目標實例 MySQL 數據目錄的屬主：

修改配置文件 /data/mysql/conf/my.cnf（配置啟動時不啟動復制、relay log 元數據通過文件形式記錄，server-id 不能跟原實例相同）：

啟動 MySQL：

查看數據（此時只是恢復了全量數據，所以數據不完整）：

清空目標實例的系統變量 gtid_purged 和 gtid_executed：

設置 gtid_purged（這個位點取至 xtrabackup_binlog_info）：

讓該 MySQL 知道自己是一個從庫（192.168.1.1 是隨便指定的 IP）：

關閉目標實例：

刪除該實例的 relay-log.info：

刪除所有 relay log：

拷貝源實例 MySQL 全備之后的 Binlog：

在目標實例中，將 Binlog 改成 Relay 文件：

寫入 relay log 的索引文件：

查看  relay log 的索引文件：

修改事務日志目錄下文件的屬組：

啟動目標實例：

執行 change master：

(這個位點來源于 備份 xtrabackup_binlog_info)解析誤操作時間點的 Binlog（Binlog 較大的情況可以增加時間范圍）：

解析 Binlog 的結果文件 /data/0702.sql 內容如下：

啟動 sql 線程，同步數據到誤操作之前的一個事務：

該 gtid 值取至上面解析的 Binlog，為誤操作這個事務的 GTID。在目標實例上查詢數據（此時的數據已經恢復到誤操作前一刻）：

最終可以將誤刪除的庫恢復到原實例。

至此，整個數據恢復過程結束，通過binlog日志增量文件恢復數據成功