分享方式：

在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中進行備份與還原

  • 文章

適用於：適用於 MySQL 的 Azure 資料庫 - 彈性伺服器

適用於 MySQL 的 Azure 資料庫彈性伺服器會自動建立伺服器備份，並將其安全地儲存於區域內的本地備援儲存體中。 備份可以用來將伺服器還原至某個時間點。 備份和還原可保護資料免於意外損毀或刪除，是商務持續性策略中不可或缺的一部分。

備份概觀

適用於 MySQL 的 Azure 資料庫彈性伺服器支援兩種類型的備份，以提供增強的彈性來維護業務關鍵資料的備份。

自動備份

適用於 MySQL 的 Azure 資料庫彈性伺服器會進行資料檔案的快照集備份，並將其儲存在本地備援儲存體中。 伺服器也會進行交易記錄備份，並將其儲存在本地備援儲存體中。 在您設定的備份保留期限內，這些備份可讓您將伺服器還原至任何時間點。 預設的備份保留期限是七天。 您可以選擇性設定從 1 到 35 天的資料庫備份。 所有備份都會使用 AES 256 位元加密儲存待用資料。

隨選備份

除了服務所建立的自動備份外，適用於 MySQL 的 Azure 資料庫彈性伺服器也可讓您觸發生產工作負載的隨選備份，並配合伺服器的備份保留原則予以儲存。 您可以使用這些備份作為最快的還原點來執行時間點還原，以縮短最多 90% 的還原時間。 預設的備份保留期限是七天。 您可以選擇性設定從 1 到 35 天的資料庫備份。 您可以從入口網站觸發總計 50 個隨選備份。 所有備份都會使用 AES 256 位元加密儲存待用資料。

無法匯出這些備份檔案。 備份只可供適用於 MySQL 的 Azure 資料庫彈性伺服器用於還原作業。 您也可以從 MySQL 用戶端使用 mysqldump 來複製資料庫。

備份頻率

彈性伺服器上的備份是以快照集為基礎。 伺服器建立後，會立即進行第一次快照集備份的排程。 快照集備份會每天進行一次。 交易記錄備份會每五分鐘執行一次。 如果排程的備份失敗，備份服務會每隔 20 分鐘嘗試進行備份，直到成功備份為止。 而伺服器執行個體上的高交易生產負載，可能會導致備份失敗。

注意

  • 如果伺服器遇到高交易負載，導致較大型且較快成長的 binlog 檔案，則備份服務會每天執行多個備份，以確保使用這些備份進行可靠且更快速的還原。
  • 對於5.7部伺服器，長時間執行/大型交易可以防止全域實例層級鎖定擷取，這是每日成功備份所需的。 在這種情況下，每日備份可能會失敗。 若要解決此問題，請終止長時間執行的交易或重新啟動伺服器。 為了確保作業更順暢，建議您使用 主要版本升級，將 MySQL 5.7 伺服器升級至 8.0 版。

備份備援選項

適用於 MySQL 的 Azure 資料庫彈性伺服器會儲存多個備份副本，以保護您的資料不受計劃性和非計劃性事件影響，包括暫時性硬體故障、網路或電力中斷，以及大規模的天然災害。 適用於 MySQL 的 Azure 資料庫彈性伺服器可讓您在基本服務層級、一般用途服務層級和業務關鍵服務層級中，彈性地選擇本地備援備份儲存體、區域備援備份儲存體或異地備援備份儲存體。 依照預設，適用於 MySQL 的 Azure 資料庫彈性伺服器之備份儲存體屬於本地備援，適用於具有相同區域的高可用性 (HA)、或沒有該設定的伺服器；而區域備援則適用於具有區域備援 HA 設定的伺服器。

備份備援可確保資料庫符合其可用性和持久性的目標，不用擔心失敗，適用於 MySQL 的 Azure 資料庫彈性伺服器更為使用者提供以下三種選項：

  • 本地備援備份儲存體：當備份儲存在本地備援備份儲存體時，多個備份副本會儲存在相同的資料中心。 此選項可保護資料，以防伺服器機架或磁碟機出現故障。 此外，備份物件的年持久性不低於 99.999999999% (11 個 9)。 依照預設，具有相同區域高可用性 (HA)、或沒有該設定的伺服器備份儲存體，皆會設為本地備援。

  • 區域備援備份儲存體：當備份儲存位在區域備援備份儲存體時，多個副本不僅儲存在裝載伺服器的可用性區域內，也會複寫到相同區域中的另一個可用性區域。 此選項適合高可用性需求的方案，或將資料複寫限制在單一國家或地區內，以符合資料落地需求。 此外，備份物件的年持久性不低於 99.9999999999% (12 個 9)。 您可以在伺服器建立時，選取 [區域備援高可用性] 的選項，以確定區域備援備份儲存體。 伺服器的高可用性可於建立後停用，但備份儲存體會維持區域備援能力。

  • 異地備援備份儲存體：當備份儲存在異地備援備份儲存體，多個副本不僅會儲存在裝載伺服器的區域內，也會複寫到地理位置配對的區域。 這樣能提供更好的保護性和功能，當發生災害時，您就可以在不同區域中還原伺服器。 此外，備份物件的年持久性不低於 99.99999999999999% (16 個 9)。您可以在伺服器建立時，啟用 [異地備援] 選項，以確定異地備援備份儲存體。 而且，您可以在伺服器建立後，從本地備援儲存體移至異地備援儲存體。 針對裝載於任何 Azure 配對區域中的伺服器，支援異地備援。

注意

支援區域備援的區域備援高可用性目前只會以建立時間作業的形式呈現。 目前，對於區域備援高可用性伺服器，異地備援只能在伺服器建立時間啟用/停用。

從其他備份儲存體選項移至異地備援備份儲存體

您可以使用下列建議的方式，將現有的備份儲存體移至異地備援儲存體：

  • 從本地備援移至異地備援備份儲存體 - 若要將備份儲存體從本地備援儲存體移至異地備援儲存體，您可以從 Azure 入口網站變更 [計算 + 儲存體] 伺服器設定，以啟用本地備援來源伺服器的異地備援。 相同的區域備援 HA 伺服器也可以透過與基礎備份儲存體在本地備援時的相同方式還原為異地備援伺服器。

  • 從區域備援移至異地備援備份儲存體 - 適用於 MySQL 的 Azure 資料庫彈性伺服器在完成佈建後，不支援透過變更 [計算 + 儲存體] 設定，將區域備援儲存體轉換為異地備援儲存體。 有兩個選項可將備份儲存體從區域備援儲存體移至異地備援儲存體：a) 使用 PITR (時間點還原) 還原具有所需設定的伺服器。 b) 建立具有所需設定的新伺服器，並使用傾印和還原移轉資料。

備份保留

備份會根據伺服器上的備份保留期間設定加以保留。 您可以選取 1 到 35 天的保留期間，預設保留期間為七天。 您可以在伺服器建立期間或稍後使用 Azure 入口網站更新備份設定時設定保留期間。

備份保留期限會控制可往回多少時間來執行時間點還原作業，因為這會以可用的備份為基礎。 從還原的觀點來看，備份保留期間也可以視為復原時段。 備份保留期間內執行時間點還原所需的所有備份都會保留在備份儲存體中。 例如 - 如果備份保留期間設定為七天，則復原時段會被視為過去七天。 在此案例中，系統會保留過去七天內還原伺服器所需的所有備份。 使用七天的備份保留時段，資料庫快照集和交易記錄備份會儲存過去八天 (時段的前 1 天)。

備份儲存體成本

適用於 MySQL 的 Azure 資料庫彈性伺服器可提供高達 100% 的已佈建伺服器儲存體作為備份儲存體，且不須支付額外費用。 額外使用的任何備份儲存體以每月 GB 數計費。 例如，如果您佈建的伺服器具有 250 GB 的儲存空間，則您將有 250 GB 的儲存空間可供伺服器備份使用，而不需要額外付費。 如果每日備份使用量為 25GB，則最多可以有 10 天的免費備份儲存體。 針對備份超過 250 GB 所耗用儲存體會根據定價模式收費。

您可以使用 Azure 入口網站所提供 Azure 監視器中 [使用的備份儲存體] 計量來監視伺服器所使用的備份儲存體。 使用的 [備份儲存體] 計量代表根據為伺服器設定的備份保留期間，保留的所有資料庫備份和記錄備份所耗用的儲存空間總和。 不論資料庫大小總計，伺服器上頻繁的交易活動可能會導致備份儲存體使用量增加。 用於異地備援伺服器的備份儲存體是本地備援伺服器的兩倍。

控制備份儲存體成本的主要方式是設定適當的備份保留期限。 您可選取 1 到 35 天的保留期間。

重要

從在區域備援高可用性設定中設定的資料庫伺服器進行備份時，會從主要資料庫伺服器進行備份，因為快照集備份的額外負荷很小。

檢視可用的完整備份

Azure 入口網站中的 [備份與還原] 刀鋒視窗會提供您在任何指定時間點都能使用的完整備份清單。 其中包括自動備份以及隨選備份。 您可以使用此刀鋒視窗來檢視伺服器保留期間內所有可用完整備份的完成時間戳記，以及使用這些完整備份來執行還原作業。 可用的備份清單包括保留期間內的所有完整備份、顯示成功完成的時間戳記、指出備份將保留多久的時間戳記，以及還原動作。

還原

在適用於 MySQL 的 Azure 資料庫彈性伺服器中，還原執行作業會從原始伺服器的備份中建立新的伺服器。 有兩種類型的還原可使用：

  • 時間點還原可搭配任意備份備援選項使用，且會在原始伺服器所在的相同區域中建立新伺服器。
  • 異地還原：只有在已為異地備援儲存體設定伺服器時才能使用，其可讓您將伺服器還原到異地配對區域或任何其他有提供彈性伺服器的 Azure 支援區域。

伺服器復原的估計時間取決於數個因素：

  • 資料庫的大小
  • 相關的交易記錄數目
  • 需要重新執行以復原到還原點的活動數目
  • 還原到不同區域的網路頻寬
  • 要在目標區域中處理的並行還原要求數目
  • 資料庫的資料表中存在主索引鍵。 若要加快復原速度，請考慮為資料庫中的所有資料表新增主索引鍵。

注意

已啟用高可用性的伺服器會在時間點還原和異地還原後，變成非 HA (已停用高可用性)。

還原時間點

在適用於 MySQL 的 Azure 資料庫彈性伺服器中，執行時間點還原會在與來源伺服器相同的區域中，從彈性伺服器的備份建立新的伺服器。 其會使用原始伺服器的設定來建立，包含計算層、虛擬核心數目、儲存大小、備份保留期限，以及備份備援選項。 此外，也會從來源伺服器繼承虛擬網路和防火牆等標記和設定。 還原後伺服器的計算與儲存層、設定與安全性設定可以在還原完成之後進行變更。

注意

還原作業之後，有兩個伺服器參數會重設為預設值 (且不會從主要伺服器複製)

  • time_zone - 此值會設定為預設值 SYSTEM
  • event_scheduler - 針對 MySQL 5.7 版伺服器，在起始備份時，伺服器參數 event_scheduler 會自動關閉 『OFF』，而伺服器參數 event_scheduler 會在備份順利完成之後重新開啟 『ON』。 在適用於 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器的 MySQL 8.0 版中，備份期間event_scheduler不會受到影響。 為了確保作業更順暢，建議您使用 主要版本升級，將 MySQL 5.7 伺服器升級至 8.0 版。

時間點還原適用於多種案例。 一些常見的使用案例包括 -

  • 當使用者意外刪除資料庫中的資料時
  • 使用者卸除重要的資料表或資料庫
  • 使用者應用程式可能會因為應用程式缺陷，而意外以不正確的資料覆寫正確的資料。

您可以透過 Azure 入口網站選擇最新的還原點、自訂還原點和最快還原點 (使用完整備份還原)。

  • 最新的還原點：最新的還原點選項可協助您在觸發還原作業時，將伺服器還原至時間戳記。 此選項有助於將伺服器快速還原至最新的狀態。
  • 自訂還原點：此選項可讓您在為此伺服器定義的保留期間內選擇任何時間點。 此選項適用於在精確時間點還原伺服器，以從使用者錯誤還原。
  • 最快還原點：此選項可讓使用者在為伺服器定義的保留期間內，盡可能在指定日期內，以最快的時間還原伺服器。 選擇完整備份完成時的時間點還原即可進行最快的還原。 此還原作業只會還原完整快照集備份，而不保證還原或復原記錄，因此會加快復原速度。 我們建議您選取大於成功還原作業最早還原點的完整備份時間戳記。

預估的復原時間取決於數個因素，包括資料庫大小、交易記錄備份大小、SKU 的計算大小，以及還原的時間。 交易記錄復原是還原程序最耗時的部分。 如果選擇更接近快照集備份排程的還原時間，則還原作業會較為快速，因為交易記錄應用程式最少。 若要估計伺服器的準確復原時間，我們強烈建議您在環境中進行測試，因為具有太多環境特定的變數。

重要

如果您要還原設定了區域備援高可用性的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體，則還原後的伺服器會設定為位於與主要伺服器相同的區域 (region) 和區域 (zone) 中，並以非 HA 模式部署為單一伺服器。 請參閱適用於彈性伺服器的區域備援高可用性。

重要

您可以在刪除適用於 MySQL 的 Azure 資料庫彈性伺服器後的 5 天內，復原已刪除的適用於 MySQL 的 Azure 資料庫彈性伺服器資源。 如需關於如何還原已刪除伺服器的詳細指南，請參閱記錄的步驟。 若要在部署後防止伺服器資源遭到意外刪除或非預期的變更，管理員可以利用管理鎖定。

異地復原

如果您已經為伺服器設定異地備援備份，則可以將伺服器還原至有提供服務的異地配對區域，或還原至任何其他有提供適用於 MySQL 的 Azure 資料庫彈性伺服器的 Azure 支援區域。 可還原至任何非配對 Azure 支援區域 (Brazil South、USGov Virginia 和 West US 3) 除外) 的能力稱為「通用異地還原」。

當您的伺服器因為裝載伺服器區域中的事件而無法使用時，異地還原就是預設的復原選項。 如果區域中的大規模意外導致您無法使用資料庫應用程式，則您可以從異地備援備份，將伺服器還原到任何其他區域中的伺服器。 異地還原會利用伺服器的最新備份。 在建立備份及將其複寫至不同區域之間會有延遲。 此延遲可能最長達一小時，因此當發生災害時，最多可能會遺失最長達一小時的資料。

您也可以在利用 Azure CLI 的已停止伺服器上執行異地還原。 請參閱使用 Azure CLI 還原適用於 MySQL 的 Azure 資料庫彈性伺服器，以深入了解如何使用 Azure CLI 來異地還原伺服器。

預估的復原時間取決於數個因素，包括資料庫大小、交易記錄大小、網路頻寬，以及在相同區域中同時進行復原的資料庫總數。

注意

如果您要異地還原設定了區域備援高可用性的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體，則還原後的伺服器會設定為位於異地配對區域 (region) 以及與主要伺服器相同的區域 (zone) 中，並以非 HA 模式部署為單一的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。 請參閱適用於 MySQL 的 Azure 資料庫彈性伺服器的區域備援高可用性。

重要

當主要區域關閉時，無法在個別的異地配對區域中建立異地備援伺服器，因為主要區域中無法佈建儲存體。 您必須等候主要區域啟動，才能在地理位置配對區域中佈建異地備援伺服器。 當主要區域關閉時，您可以將來源伺服器異地還原至地理位置配對區域，方法是在還原入口網站體驗的 [計算 + 儲存體設定伺服器] 設定中停用異地備援選項，並還原為本地備援伺服器，以確保商務持續性。

執行還原之後的工作

從最新的還原點或自訂還原點其中任何一種復原機制還原之後，您應執行下列工作，讓您的使用者和應用程式回復正常執行狀態︰

  • 如果新伺服器用來取代原始伺服器，則系統會將用戶端和用戶端應用程式重新導向至新伺服器。
  • 確定有適當的伺服器層級防火牆與虛擬網路規則可供使用者連線。
  • 確定有適當的登入和資料庫層級權限。
  • 視情況設定警示。

長期保留 (預覽)

Azure 備份和適用於 MySQL 的 Azure 資料庫彈性伺服器服務已針對適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體建置企業級的長期備份解決方案，可保留最多 10 年的備份。 除了適用於 MySQL 的 Azure 資料庫彈性伺服器所提供的自動備份解決方案之外，您還可以獨立使用長期保留，該伺服器最多可保留 35 天。 自動備份是適用於作業復原的快照備份，當您想要從最新的備份還原時，尤其適用。 長期備份可協助您符合合規性需求和稽核需求。 除了長期保留之外，此解決方案還提供下列功能：

  • 客戶控制的排程和隨選備份
  • 從稱為備份中心的單一窗格管理及監視伺服器、資源群組、位置、訂用帳戶和租用戶的所有備份相關作業和工作。
  • 儲存在個別安全性和容錯網域中的備份。 如果來源伺服器或訂用帳戶遭入侵，備份保存庫中的備份仍安全無虞 (在 Azure 備份受控儲存體帳戶中)。

限制與考量

  • 在預覽中，LTR 還原目前可作為儲存體帳戶的 RestoreasFiles 進行使用。 未來將新增 RestoreasServer 功能。
  • 目前不支援透過 Azure CLI 建立和管理 LTR。

如需執行長期備份的詳細資訊，請瀏覽操作指南

隨選備份和匯出 (預覽)

適用於 MySQL 的 Azure 資料庫彈性伺服器現在提供隨選隨時觸發伺服器實體備份的功能，並將其匯出至 Azure 儲存體帳戶 (Azure blob 儲存體)。 匯出之後，這些備份可用於資料恢復、移轉和備援。 這些匯出的實體備份檔案可用來還原回內部部署 MySQL 伺服器，以協助符合組織的稽核/合規性/封存需求。 此功能目前處於公開預覽狀態，並且僅可在公用雲端區域中使用。

如需有關匯出備份的詳細資訊，請瀏覽操作指南

常見問題集 (FAQ)

  • 如何備份我的伺服器？

    依預設，適用於 MySQL 的 Azure 資料庫彈性伺服器會啟用整個伺服器的自動備份 (包括已建立的所有資料庫)，保留期間為預設的 7 天。 您也可以使用隨選備份功能觸發手動備份。 手動進行備份的其他方式是使用如這裡所記載的 mysqldump，或如這裡所記載的 mydumper 等社群工具。 如果您想要將適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體備份至 Blob 儲存體，請參閱我們的技術社群部落格將適用於 MySQL 的 Azure 資料庫彈性伺服器備份至 Blob 儲存體。

  • 我可以將自動備份設定為長期保留嗎？

    否，目前我們只支援最多 35 天的自動備份保留期間。 您可以進行手動備份，並將其用於長期保留需求。

  • 我的伺服器備份時段為何？ 是否可自訂時段？

    建立伺服器之後，系統會立即排程第一次快照集備份。 快照集備份會每天執行一次。 交易記錄備份會每五分鐘執行一次。 備份時段原本是由 Azure 管理，因此無法自訂。

  • 備份是否會加密？

    在查詢執行期間建立的所有適用於 MySQL 的 Azure 資料庫彈性伺服器資料、備份和暫存檔案，都會使用 AES 256 位加密進行加密。 儲存體加密會一律啟用，且無法停用。

  • 我可以還原單一/少數資料庫嗎？

    不支援還原單一/少數資料庫或資料表。 如果您想要還原特定資料庫，請執行時間點還原，然後擷取所需的資料表或資料庫。

  • 我的伺服器在備份時段是否可用？

    是。 備份是線上作業，並以快照集為基礎。 快照集作業只需要幾秒鐘的時間，且不會干擾生產工作負載，以確保伺服器的高可用性。

  • 設定伺服器的維護時段時，我們需要考慮備份時段嗎？

    否，備份會在內部觸發為受控服務的一部分，且與受控維護時段無關。

  • 我的自動備份會儲存在何處，以及如何管理其保留？

    適用於 MySQL 的 Azure 資料庫彈性伺服器會自動建立伺服器備份，並將其儲存在使用者設定的本地備援儲存體或異地備援儲存體中。 這些備份檔案無法匯出。 預設的備份保留期限是七天。 您可以選擇性設定從 1 到 35 天的資料庫備份。

  • 如何驗證我的備份？

    驗證成功完成備份可用性的最佳方式，是在 [備份與還原] 刀鋒視窗中，檢視在保留期間內建立的完整自動備份。 如果備份失敗，便不會在可用的備份清單中列出，而備份服務將每隔 20 分鐘嘗試進行備份，直到成功備份為止。 這些備份失敗的原因可能來自於伺服器上的大量交易生產負載。

  • 我可以在哪裡查看備份使用量？

    您可以在 Azure 入口網站中 [監視] 索引標籤的 [計量] 區段下，找到 [使用的備份儲存體] 計量，其可協助您監視備份使用量總計。

  • 如果我刪除伺服器，我的備份將會如何？

    如果您刪除伺服器，所有屬於該伺服器的備份也會一併刪除，且無法復原。 若要在部署後避免伺服器資源遭到意外刪除或非預期的變更，系統管理員可以使用管理鎖定。

  • 當我還原伺服器時，我的備份會發生什麼事？

    如果您還原伺服器，則一律會導致建立使用原始伺服器備份所還原的全新伺服器。 原始伺服器的舊備份不會複製到新還原的伺服器，而且會與原始伺服器一起留存。 不過，系統會在新建伺服器後，立即為該伺服器排程進行第一個快照集備份，且服務會根據所設定的伺服器保留期間，確保每天都會自動建立和儲存備份。

  • 如何根據備份的使用量來收費和計費？

    適用於 MySQL 的 Azure 資料庫可提供高達 100% 的已佈建伺服器儲存體作為備份儲存體，且不須支付額外費用。 額外使用的任何備份儲存體會根據定價模式以每月 GB 數收費。 備份儲存體計費也會受選取的備份保留期間和選擇的備份備援選項所規範，除了伺服器上的交易活動之外，也會影響直接使用的備份儲存體總數。

  • 已停止伺服器的備份如何保留？

    不會為已停止伺服器執行任何新的備份。 在停止伺服器時，將保留所有較舊的備份 (在保留時段內)，直到伺服器重新開機之後，屆時使用中伺服器的備份保留會由其備份保留時段管理。

  • 如何針對已停止伺服器的備份計費？

    當您的伺服器執行個體停止時，系統會針對佈建的儲存體 (包括佈IOPS) 和備份儲存體 (儲存在指定保留時段內的備份) 向您收取費用。 免費備份儲存體僅限於您佈建的資料庫大小，且僅適用於使用中的伺服器。

  • 我的備份資料如何受到保護？

    適用於 MySQL 的 Azure 資料庫彈性伺服器會藉由封鎖任何可能導致在所設定的保留期間內遺失復原點的作業，以保護您的備份資料。 在保留期間建立的備份只可供讀取以進行還原，並於保留期間過後刪除。 此外，適用於 MySQL 的 Azure 資料庫彈性伺服器中的所有備份，都會針對所儲存的待用資料使用 AES 256 位元加密來進行加密。

  • 時間點還原 (PITR) 作業會如何影響 IOPS 使用量？

    在「適用於 MySQL 的 Azure 資料庫 - 彈性伺服器」進行 PITR 作業期間，系統會建立新的伺服器，並將資料從來源伺服器的儲存體複製到新伺服器的儲存體。 此程序會導致來源伺服器上的 IOPS 使用量增加。 IOPS 使用量增加是正常發生的情形，不代表來源伺服器或 PITR 作業發生任何問題。 一旦 PITR 作業完成，來源伺服器上的 IOPS 使用量就會回到其平常水準。

  • 如何還原伺服器？ Azure 入口網站支援所有伺服器的時間點還原，以允許使用者還原至最新或自訂的還原點。 若要從 mysqldump/myDumper 所建立的備份手動還原伺服器，請參閱使用 myLoader 還原資料庫。

  • 為何還原如此費時？

    伺服器復原的估計時間取決於數個因素：

    • 資料庫的大小。 在復原程序中，資料庫需要從最後一個實體備份中凍結，因此復原所需的時間將會與資料庫的大小成正比。
    • 交易活動的使用中部分需要重新執行以進行復原。 根據上次成功的檢查點後所新增的交易活動而定，復原可能需要較長的時間。
    • 網路頻寬 (如果還原到不同區域)。
    • 要在目標區域中處理的並行還原要求數目。
    • 資料庫的資料表中存在主索引鍵。 若要加快復原速度，請考慮為資料庫中的所有資料表新增主索引鍵。

  • 修改工作階段層級資料庫變數是否會影響還原？

    修改工作階段層級變數並在 MySQL 用戶端工作階段中執行 DML 陳述式可能會影響 PITR (時間點還原) 作業，因為這些修改不會記錄在用於備份和還原作業的二進位記錄中。 例如，foreign_key_checks 是這類工作階段層級變數的一種，如果在執行違反外部索引鍵條件約束的 DML 陳述式時加以停用，會導致 PITR (時間點還原) 失敗。 在這類情節中，唯一的因應措施是選取比 foreign_key_checks 停用時間更早的 PITR 時間。 我們建議不要修改成功 PITR 作業的任何工作階段變數。

下一步