所以我意識到在最近出現這種情況後我沒有發表過關於此的帖子。
以下是場景：在午夜進行備份，他們使用每個數據庫的MySQL轉儲。 然後在第二天上午十點數據庫崩潰。 在我被調用之前發生了一系列事件，但他們把它帶到了MyISAM表的數據庫版本和表空間中缺少的IBD文件。
所以選項1，從備份恢復會讓我們到午夜，我們會丟失數小時的數據。 選項2，我們重新導入1000的ibd文件並保留所有內容。 然後我們有選項3，從備份恢復，然後應用binlogs進行最近的更改。
為了使它更有趣，他們沒有我被告知的所有ibd文件，我確實看到一些丟失。 所以不確定這是怎麼可能的，但是選項2變成了無效選項。 當然，他們希望盡可能減少數據丟失，因此我們選擇了3。
為了安全地做到這一點，我在端口3307下啟動了另一個MySQL實例。這使我有了一個安全的工作場所，同時流量對端口3306實例上的MyISAM數據具有讀訪問權限。
一旦所有備份轉儲文件解壓縮並導入3307實例，我就可以專注於binlog文件。
起初，這個概念聽起來比實際風險要大得多。 它實際上很簡單直接。
首先，您必須找到您之後的數據。 通過查看binlog文件，您可以了解哪些文件是相關的。 在我的情況下，他們設法重置了binlog，因此117文件中有2個日期範圍。
首先對於binlog審查，以下命令以人類可讀的格式輸出數據。
*注意......小心運行上面的命令。 請注意，我將文件直接轉儲到binlog所在的位置。 因此，確認您的文件名有效。 這個mysql-bin.000117.sql與這個mysql-bin.000117 .sql不同。 您將使用第二個選項和.sql之前的空格來丟失binlog。
現在保存數據，以便可以應用它。 由於我有幾個binlogs，我創建了一個文件，我想要仔細檢查時間範圍。
現在我將這些binlog中的所有數據應用於給定的時間範圍。 客戶端仔細檢查了所有數據，並非常高興能夠全部恢復。
對於這種情況存在幾種不同的選擇，這恰好與客戶一起鍛煉。
一旦驗證的all在恢復的版本上沒問題，它就是一個簡單的停止兩個數據庫，移動數據目錄（想要保持datadir默認完整），chown目錄只是為了安全並啟動MySQL。 現在，已恢復的實例已在端口3306上啟動。
以下是場景：在午夜進行備份，他們使用每個數據庫的MySQL轉儲。 然後在第二天上午十點數據庫崩潰。 在我被調用之前發生了一系列事件，但他們把它帶到了MyISAM表的數據庫版本和表空間中缺少的IBD文件。
所以選項1，從備份恢復會讓我們到午夜，我們會丟失數小時的數據。 選項2，我們重新導入1000的ibd文件並保留所有內容。 然後我們有選項3，從備份恢復，然後應用binlogs進行最近的更改。
為了使它更有趣，他們沒有我被告知的所有ibd文件，我確實看到一些丟失。 所以不確定這是怎麼可能的，但是選項2變成了無效選項。 當然，他們希望盡可能減少數據丟失，因此我們選擇了3。
為了安全地做到這一點，我在端口3307下啟動了另一個MySQL實例。這使我有了一個安全的工作場所，同時流量對端口3306實例上的MyISAM數據具有讀訪問權限。
一旦所有備份轉儲文件解壓縮並導入3307實例，我就可以專注於binlog文件。
起初，這個概念聽起來比實際風險要大得多。 它實際上很簡單直接。
首先，您必須找到您之後的數據。 通過查看binlog文件，您可以了解哪些文件是相關的。 在我的情況下，他們設法重置了binlog，因此117文件中有2個日期範圍。
首先對於binlog審查，以下命令以人類可讀的格式輸出數據。
mysqlbinlog
--defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose
mysql-bin.000117 > review_mysql-bin.000117.sql *注意......小心運行上面的命令。 請注意，我將文件直接轉儲到binlog所在的位置。 因此，確認您的文件名有效。 這個mysql-bin.000117.sql與這個mysql-bin.000117 .sql不同。 您將使用第二個選項和.sql之前的空格來丟失binlog。
現在保存數據，以便可以應用它。 由於我有幾個binlogs，我創建了一個文件，我想要仔細檢查時間範圍。
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-09
00:00:00" --stop-datetime="2019-07-10 00:00:00" mysql-bin.000117 >
binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000118 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000119 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-10
00:00:00" --stop-datetime="2019-07-10 10:00:00" mysql-bin.000117
>> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000120 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000121 >> binlog_restore.sql
mysql --socket=/var/lib/mysql_restore/mysql.sock -e "source /var/lib/mysql/binlog_restore.sql"
現在我將這些binlog中的所有數據應用於給定的時間範圍。 客戶端仔細檢查了所有數據，並非常高興能夠全部恢復。
對於這種情況存在幾種不同的選擇，這恰好與客戶一起鍛煉。
一旦驗證的all在恢復的版本上沒問題，它就是一個簡單的停止兩個數據庫，移動數據目錄（想要保持datadir默認完整），chown目錄只是為了安全並啟動MySQL。 現在，已恢復的實例已在端口3306上啟動。
