MySQL 刪庫到恢復 失誤刪庫不一定要跑路，只要有合理的備份策略，絕大多數情況都可以恢復到刪庫之前的那一刻。如果要恢復，一般采用的辦法是使用上一次全備先恢復數據，增量數據通過導入從全備開始到誤操作之前的 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。在目標實例上查詢數據（此時的數據已經恢復到誤操作前一刻）： 最終可以將誤刪除的庫恢復到原實例。