MySQL 9.0 發行說明
本節說明使用二進制日誌執行時間點還原的一般概念。下一節，第 9.5.2 節，「使用事件位置進行時間點還原」，將詳細解釋此操作並提供範例。
注意
本節和下一節中的許多範例都使用 mysql 用戶端來處理 mysqlbinlog 產生的二進制日誌輸出。如果您的二進制日誌包含 \0 (null) 字元，則除非您使用 --binary-mode 選項來調用 mysql，否則該輸出無法被解析。
時間點還原的資訊來源是在完整備份作業之後產生的一組二進制日誌檔案。因此，為了讓伺服器還原到特定時間點，必須在其上啟用二進制日誌記錄，這是 MySQL 9.0 的預設設定（請參閱第 7.4.4 節，「二進制日誌」）。
若要從二進制日誌還原資料，您必須知道目前二進制日誌檔案的名稱和位置。預設情況下，伺服器會在資料目錄中建立二進制日誌檔案，但可以使用 --log-bin 選項指定路徑名稱，將檔案放置在不同的位置。若要查看所有二進制日誌檔案的清單，請使用此陳述式
mysql> SHOW BINARY LOGS;若要判斷目前二進制日誌檔案的名稱，請發出以下陳述式
mysql> SHOW BINARY LOG STATUS;mysqlbinlog 工具會將二進制日誌檔案中的事件從二進制格式轉換為文字格式，以便可以檢視或套用。mysqlbinlog 具有選項，可根據事件時間或事件在日誌中的位置來選取二進制日誌的區段。請參閱第 6.6.9 節，「mysqlbinlog — 處理二進制日誌檔案的工具」。
從二進制日誌套用事件會導致重新執行它們所代表的資料修改。這使得能夠還原特定時間範圍內的資料變更。若要從二進制日誌套用事件，請使用 mysql 用戶端處理 mysqlbinlog 輸出
$> mysqlbinlog binlog_files | mysql -u root -p如果二進制日誌檔案已加密，mysqlbinlog 無法像上一個範例那樣直接讀取它們，但可以使用 --read-from-remote-server (-R) 選項從伺服器讀取它們。例如
$> mysqlbinlog --read-from-remote-server --host=host_name --port=3306 --user=root --password --ssl-mode=required binlog_files | mysql -u root -p在此，已使用 --ssl-mode=required 選項來確保二進制日誌檔案中的資料在傳輸過程中受到保護，因為它是以未加密的格式傳送至 mysqlbinlog。
重要
對於 SSL 模式，VERIFY_CA 和 VERIFY_IDENTITY 是比 REQUIRED 更好的選擇，因為它們有助於防止中間人攻擊。若要實作其中一個設定，您必須先確保伺服器的 CA 憑證在您的環境中可靠地提供給所有使用它的用戶端，否則會導致可用性問題。請參閱加密連線的命令選項。
當您需要判斷事件時間或位置以選取執行事件之前的部分日誌內容時，檢視日誌內容會很有用。若要檢視日誌中的事件，請將 mysqlbinlog 輸出傳送到分頁程式
$> mysqlbinlog binlog_files | more或者，將輸出儲存在檔案中，並在文字編輯器中檢視檔案
$> mysqlbinlog binlog_files > tmpfile
$> ... edit tmpfile ...編輯檔案後，套用內容，如下所示
$> mysql -u root -p < tmpfile如果您有多個二進制日誌要套用至 MySQL 伺服器，請使用單一連線來套用您要處理的所有二進制日誌檔案的內容。以下是一種執行此操作的方法
$> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p另一種方法是將整個日誌寫入單一檔案，然後處理該檔案
$> mysqlbinlog binlog.000001 > /tmp/statements.sql
$> mysqlbinlog binlog.000002 >> /tmp/statements.sql
$> mysql -u root -p -e "source /tmp/statements.sql"