MySQL 備份與還原

備份 MySQL 資料庫的方法有兩種：實體和邏輯方式。實體備份會複製實際資料檔案，而邏輯備份會產生 CREATE TABLE 和 INSERT 等可重新建立資料的陳述式。

實體備份包含磁碟上所有檔案和目錄的原始副本。這種備份方式適合大型資料庫，因為相較於邏輯備份，複製原始檔案的速度更快。

優點：

• 實體備份簡單又有效率；不需要大量記憶體或執行多個 CPU 週期

• 實體備份不需要任何額外工作即可產生原始檔案，只要將原始檔案和目錄複製到備份位置即可

• 實體備份的還原速度比邏輯備份更快，因為 MySQL 不需要重新建立資料庫物件並匯入資料

缺點：

• 除了 InnoDB 資料表空間 (由每個 table.ibd 檔案共用，且通常含有零碎空間) 以外，由於實體備份包含交易記錄檔和復原記錄檔等，通常比邏輯備份需要更多空間。

• 實體備份不一定能在平台、作業系統和 MySQL 版本之間轉移

• 由於實體備份會複製原始檔案，如果這些檔案有任何基礎毀損，就會一併複製到備份檔案

MySQL 生態系統中的一些常見實體備份工具

• MySQL Enterprise Backup
• Percona XtraBackup
• MariaDB Mariabackup

邏輯備份包含資料庫中的資料，其中採用的格式可由 MySQL 解譯為 SQL 格式或分隔的文字格式。它是以一系列 SQL 陳述式呈現的資料庫表示法，可用來執行重建資料庫物件和匯入資料。這種備份類型適合小型資料庫，因為邏輯備份作業的還原時間可能比還原實體備份更長。如果要遷移資料至雲端的代管資料庫服務或從雲端移轉，這個備份類型也非常實用。

優點：

• 邏輯備份具備高度靈活性。針對伺服器層級 (所有資料庫)、資料庫層級 (特定資料庫中的所有資料表)、資料表層級，甚至是資料列層級 (資料表中符合指定 WHERE 條件的資料列)，提供高精細度的備份和還原作業。

• 邏輯備份較容易還原：只要將備份檔案傳輸至 MySQL 用戶端，然後使用 LOAD DATA 陳述式或 mysqlimport 指令載入分隔的文字檔案即可。

• 邏輯備份可以透過其他機器遠端執行，讓您能透過網路備份與還原資料庫。這對於雲端資料庫 (例如 Google Cloud SQL、Amazon RDS 和 Microsoft Azure) 而言非常實用，因為使用者無法直接存取虛擬機器。

• 邏輯備份可避免資料損毀。實體備份資料可能會損毀，而且可能到驗證階段才會發現。邏輯備份通常為文字檔案，使用文字編輯器就能輕鬆查看，並發現損毀情形。邏輯備份極少損毀。

• 有別於實體備份，邏輯備份在平台、作業系統和 MySQL 版本之間具高度可攜性。

• 邏輯備份具有高度壓縮能力。

缺點：

• 邏輯備份的建立速度較慢，因為您需要查詢 MySQL 伺服器來取得結構定義和資料列，然後轉換成邏輯格式

• 此外，由於 MySQL 需要執行 SQL 陳述式來建立資料表、匯入資料列及重建索引，因此邏輯備份的還原速度較慢

• 與實體備份相比，邏輯備份需要更多伺服器資源 (CPU、RAM 和磁碟 I/O) 才能進行備份和還原作業

一些常見的邏輯備份工具

• mysqldump
• mydumper
• mysqlpump

MySQL 殼層公用程式 — 轉儲 | 載入

顧名思義，時間點復原可協助您將執行個體復原至特定時間點。舉例來說，如果因錯誤導致資料遺失，您可以將資料庫復原為發生錯誤之前的狀態。

PITR 是兩個步驟的流程，仰賴使用二進位記錄檔：

1. 還原完整的實體或邏輯備份，使伺服器處於備份時相同的狀態
2. 套用二進位記錄檔，重播備份時間點與所需時間點之間的變更

二進位記錄檔包含對資料庫執行個體所做的任何變更，例如建立資料表、插入/更新/刪除資料列等。舉例來說，假設每天的備份在早上 6:00 執行，而您希望將執行個體復原至上午 10:15 分之前。為了要復原在上午 10:15 的狀態，您必須先還原從上午 6:00 開始的完整備份，然後再重播從早上 6:00 到 10:15 之間二進位記錄檔事件。這會讓伺服器在所需時間達到所需的狀態。

複製和執行 PITR 時必須指定二進位記錄檔，它和基礎資料一樣重要。您必須即時備份二進位記錄檔，才能在還原規劃中有效執行，並使用 mysqlbinlog 指令下載。

例如：

<binlog_filename> 將是第一個要下載的檔案，mysqlbinlog 之後將自動切換至下一個檔案。這些二進位記錄檔會寫入目前執行 mysqlbinlog 指令的伺服器所在目錄。您可以使用 --result-file 選項來變更檔案名稱和位置，也可以使用 --stop-never 選項，讓 mysqlbinlog 二進位記錄檔與伺服器保持連線，並在寫入時下載新變更。

詳情請參閱 mysqlbinlog 手冊，瞭解如何連線至遠端伺服器並在寫入時下載二進位記錄檔。

Cloud SQL 是適用於 MySQL 的 Google Cloud 代管資料庫服務，提供自動備份和時間點復原 (PITR) 機制，方便您保護資料。根據預設，系統會啟用這些功能，這是在 MySQL 適用的 Cloud SQL 執行個體上啟用高可用性 (HA) 的必要條件。

所有 Cloud SQL 備份都是實體備份的一種，因為這些備份是在永久磁碟 (PD) 中拍攝的快照。Cloud SQL 提供彈性的自動備份機制，您隨時可以視需求執行備份作業。您仍可使用標準 MySQL 邏輯備份工具 (例如 mysqldump、mydumper、mysqlpump 等) 進行邏輯備份，不會干擾代管備份。

讓我們深入探討 Cloud SQL 備份的運作方式。

Cloud SQL 使用 Persistent Disk (PD) 做為儲存空間，而且每個 Cloud SQL 執行個體中都有一個永久性資料磁碟，用於儲存資料庫檔案和目錄。

Cloud SQL 使用 PD 快照進行備份，這些快照是指資料磁碟在特定時間點的狀態。PD 的第一個快照是包含 PD 所有資料的完整快照，後續的快照則是隨著時間增加，且只包含自上次快照以來的任何新資料或修改後的資料。您可以將這些快照視為雲端代管永久性資料磁碟實體副本，這類快照是所有 Cloud SQL 備份與還原功能 (包括 PITR) 的基礎。

Cloud SQL 可執行兩種類型的代管備份：自動化與隨選。根據預設，這兩種類型都會儲存在最接近執行個體的多區域位置。舉例來說，如果您的 Cloud SQL 執行個體位於 us-central1，系統預設會將備份儲存在美國的多區域。不過，australia-southeast1 之類的預設位置在多區域之外，將會放置在最接近的多區域，也就是亞洲。您也可以為備份選擇自訂位置。

自動備份

系統每天都會自動在指定的 4 小時內擷取備份。備份作業會在備份期間開始，並可能會在備份時間之外繼續執行，直到完成為止。您可以設定要保留的自動備份數量，範圍介於 1 至 365 之間。預設保留政策是保留最近七個備份。

隨選備份

您隨時都能建立隨選備份。如果需要備份，而且不想等到備份時間，這些方法就能派上用場。此外，有別於自動備份，系統不會自動刪除隨選備份。它們會一直存在，直到您刪除隨選備份或刪除其執行個體為止。

您可以將備份還原至相同位置的執行個體，或還原至同一專案中的其他執行個體。請注意，在還原備份時，目標執行個體不應是唯讀備用資源本身，也不應有唯讀備用資源，因為唯讀備用資源是主要執行個體副本，會造成備用資源無法與主要執行個體保持同步的風險。您之後可以隨時新增唯讀備用資源。

還原備份時，系統會從備份快照建立新的 PD，並將其附加至執行個體。資料庫會先使用新的磁碟，並執行標準 MySQL 當機復原程序，然後從快照進行更新的還原，並恢復完善的 MySQL 資料庫運作。

還原至相同執行個體

還原至其他執行個體

從備份還原至不同的執行個體時，目標執行個體中的資料會更新為當初建立備份時的來源執行個體狀態。

重要事項：還原備份會覆寫目標執行個體中的所有現有資料，包括之前的時間點復原記錄。資料一經覆寫即無法復原。

在 Cloud SQL 中，PITR 一律會建立新的執行個體來繼承來源執行個體的設定，與複製執行個體作業類似。來源執行個體必須啟用自動備份和時間點復原 (二進位記錄檔)，才能使用這項功能。二進位記錄檔預設的資料保留政策為 7 天，您可以將保留期限設定為 1 到 7 天之間的任何天數。

PITR 是透過原始執行個體備份建立的新執行個體，並將原始執行個體資料磁碟中儲存的二進位記錄檔重播至指定的時間點來進行。

在 Cloud SQL 執行時間點復原時，客戶可以選擇複製執行個體目前的狀態，或是複製過去的時間戳記。

執行時間點復原功能的使用者介面如下所示。