讀取「適用於 MySQL 的 Azure 資料庫」中的複本

MySQL 是一種熱門的資料庫引擎，可執行網際網路規模的 Web 和行動應用程式。許多客戶將適用於 MySQL 的 Azure 資料庫用於各種應用程式，包括線上教育、視訊串流、數位支付、電子商務、遊戲、新聞入口網站、政府和醫療保健網站。這些服務必須能夠隨著 Web 或行動應用程式流量的增加而提供服務和擴展。

在應用程式方面，開發人員通常使用 Java 或 PHP。他們會移轉應用程式以在 Azure 虛擬機器擴展集、Azure App Services 上執行，或將應用程式容器化以在 Azure Kubernetes Service （AKS）上執行。使用虛擬機器擴展集、App Service 或 AKS 作為基礎結構，藉由立即佈建新的 VM 並複寫應用程式的無狀態元件來滿足要求，以簡化應用程式調整。然而，資料庫作為集中式有狀態元件經常成為瓶頸。

讀取複本功能可讓您將資料從適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體複寫到唯讀伺服器。您可以從來源伺服器復寫至最多 10 個複本。複本會使用 MySQL 引擎的原生二進位日誌（binlog）檔案位置型複寫技術進行非同步更新。若要深入瞭解二進位記錄複寫，請參閱 MySQL 二進位記錄複寫概觀。

您以新伺服器的形式管理複本，就像是適用於 MySQL 的 Azure 資料庫彈性伺服器來源執行個體。針對每個讀取複本，系統會根據每月虛擬核心中所佈建的計算量，以及在儲存體中所佈建的容量 (以 GB 為單位) 產生費用。如需詳細資訊，請參閱定價。

讀取複本功能僅適用於一般用途定價層或業務關鍵定價層的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。請確定來源伺服器處於這些定價層中。

若要深入瞭解 MySQL 複寫功能和問題，請參閱 MySQL 複寫檔。

附註

本文包含「從屬」一詞的參考，Microsoft 已不再使用該字詞。當我們從軟體中刪除該術語時，我們會將其從本文中刪除。

讀取複本的常見使用案例

讀取副本功能可協助您改善讀取密集型工作負載的效能並提升擴展性。您可以將讀取工作負載隔離至複本，同時將寫入工作負載導向至來源。

常見案例包括：

使用如 ProxySQL 等輕量型連線 Proxy，或使用微服務型模式，調整來自應用程式的讀取工作負載，以擴增來自讀取複本應用程式的讀取查詢
針對 BI 或分析報告工作負載，可以使用讀取複本作為資料來源
將遙測資訊輸入至 MySQL 資料庫引擎，並在 IoT 或製造情境中使用多個讀取複本來進行資料報告。

由於複本是唯讀狀態，因此不會直接降低來源伺服器上的寫入容量負擔。這項功能不是以寫入密集的工作負載為目標。

讀取複本功能會使用 MySQL 非同步複寫。此功能不適用於同步複寫案例。來源伺服器和複本之間會有顯著的延遲情形。複本上的資料，最終仍會與來源伺服器上的資料保持一致。請針對可接受此延遲的工作負載使用此功能。

跨區域複寫

您可以從來源伺服器在不同的區域中建立讀取複本。跨區域複寫有助於災害復原規劃或讓資料更接近使用者之類的案例。適用於 MySQL 的 Azure 資料庫彈性伺服器可讓您在可使用適用於 MySQL 的 Azure 資料庫彈性伺服器的任何 Azure 支援區域中佈建讀取複本。透過這項功能，來源伺服器可以在其配對區域或全球的複本區域中擁有複本。請參閱這裡，以尋找目前提供適用於 MySQL 的 Azure 資料庫彈性伺服器的 Azure 區域清單。

建立複本

當您啟動建立複本的工作流程時，您會建立一個空白的 Azure MySQL 彈性伺服器資料庫實例。新伺服器包含來源伺服器上的資料。建立時間取決於來源伺服器上的資料量，以及距離上次執行每週完整備份所經過的時間。時間的範圍可能介於數分鐘到數小時。

附註

您可以使用與來源相同的伺服器配置來建立讀取副本。您可以在建立之後變更抄本伺服器組態。您一律會在與來源伺服器相同的資源群組和訂用帳戶中建立複本伺服器。如果您想要在不同的資源群組或不同的訂用帳戶中建立複本伺服器，您可以在建立之後移動複本伺服器。將複本伺服器的組態保持在等於或大於來源的值，以確保複本可以跟上來源的步伐。

了解如何在 Azure 入口網站中建立讀取複本。

連線到複本

當您建立抄本時，它會繼承來源伺服器的連線方法。您無法變更複本的連線方法。例如，如果來源伺服器使用私人存取（VNet 整合），複本就無法使用公用存取（允許的 IP 位址）。

複本會從來源伺服器繼承系統管理員帳戶。系統會將來源伺服器上的所有使用者帳戶，複寫至讀取複本。您只能使用來源伺服器上可用的使用者帳戶，來連線到讀取複本。

您可以使用複本的主機名稱和有效使用者帳戶，來連線到該複本，如同連線到一般適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。對於名為 myreplica 且管理員使用者名稱為 myadmin 的伺服器，您可以使用 MySQL CLI 連線至抄本：

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

在出現提示時，請輸入使用者帳戶的密碼。

監視複寫

適用於 MySQL 的 Azure 資料庫彈性伺服器會在 Azure 監視器中提供 以秒為單位的復寫延遲 計量。此計量僅適用於複本。 Azure 監視器使用 MySQL 的SHOW SLAVE STATUS命令中的seconds_behind_master指標來計算此指標。設定警示，以便在複寫延遲超過工作負載不可接受的臨界值時通知您。

如果您看到複寫延遲增加，請參閱針對複寫延遲的疑難排解，以進行排查並瞭解可能的原因。

重要事項

讀取副本使用基於儲存的複寫技術，這已不再使用 MySQL 命令 SHOW SLAVESTATUS'/'SHOWREPLICA STATUS 中可用的 SLAVE_IO_RUNNING/REPLICA_IO_RUNNING 指標。此值一律顯示為「否」，且不表示複寫狀態。若要瞭解複寫的正確狀態，請參閱「監控」頁面下的複寫指標 - 複本 IO 狀態 和 複本 SQL 狀態 。

停止複寫

您可以停止來源伺服器與抄本伺服器之間的抄寫。當您停止來源伺服器與僅供讀取複本之間的複寫時，複本伺服器會變成獨立伺服器。獨立式伺服器包含了在您啟動停止複寫命令時，複本伺服器上可用的資料。獨立伺服器不會同步處理來源伺服器中的任何遺漏資料。

當您停止抄寫至抄本伺服器時，抄本伺服器會遺失其先前來源伺服器及其他抄本伺服器的所有鏈結。來源伺服器及其複本伺服器之間沒有自動容錯移轉功能。

重要事項

您無法將獨立伺服器轉換回複本伺服器。在您停止讀取複本上的複寫之前，請確定複本伺服器已經有您需要的所有資料。

如需詳細資訊，請參閱停止複寫至複本。

容錯移轉

來源伺服器及複本伺服器之間沒有自動容錯移轉功能。

讀取複本會擴展讀取密集型工作負載，但不會為伺服器提供高可用性。您可以透過將讀取複本以讀寫模式帶到線上來停止複寫，執行手動容錯移轉。

由於複寫是非同步的，因此來源與複本之間存在延遲。許多因素都會影響延遲量，例如來源伺服器上的工作負載和資料中心之間的延遲。在大多數情況下，複本延遲範圍在幾秒鐘到幾分鐘之間。您可以使用每個複本可用的複 本延遲 指標來追蹤實際複寫延遲。此計量會顯示自最後一次重新執行交易所經過的時間。我們建議您觀察一段時間內的複本延遲，以識別平均延遲。您可以設定複本延遲的警示，當延遲情況超出預期範圍時，便可採取行動。

秘訣

如果您切換到複本，那麼在解除複本與來源的連結時的延遲將顯示遺失的資料量。

在您決定容錯移轉至複本後：

停止複寫至複本

您需要停止複寫，讓複本伺服器能夠接受寫入。此程序會解除抄本伺服器與來源的鏈結。起始停止複寫之後，後端程序通常需要大約兩分鐘才能完成。請參閱本文的停止複製一節，以瞭解此動作的影響。
將應用程式指向 (先前) 複本

每部伺服器都具有唯一的連接字串。更新應用程式以指向 (先前) 複本，而非來源伺服器。

當您的應用程式成功處理讀取和寫入時，您就完成容錯移轉。應用程式遇到的停機時間取決於您偵測到問題並完成步驟 1 和 2 的時間。

全域交易識別碼 (GTID)

全域交易識別碼（GTID）是來源伺服器使用每個已認可交易建立的唯一識別碼。適用於 MySQL 的 Azure 資料庫彈性伺服器預設會關閉 GTID。 5.7 版和 8.0 版支援 GTID。如需有關 GTID 以及複寫如何使用它的詳細資訊，請參閱 MySQL 的 GTID 複寫文件。

使用下列伺服器參數來設定 GTID：

伺服器參數	描述	預設值	價值
`gtid_mode`	指出是否使用 GTID 來識別交易。模式之間的變更一次只能按升序一步完成（例如， `OFF` ->`OFF_PERMISSIVE` ->`ON_PERMISSIVE` ->`ON`）	`OFF*`	`OFF`：新交易和複寫交易都必須為匿名狀態 `OFF_PERMISSIVE`：新交易是匿名狀態。複寫的交易可以是匿名交易或 GTID 交易。 `ON_PERMISSIVE`：新交易是 GTID 交易。複寫的交易可以是匿名交易或 GTID 交易。 `ON`：新交易和複寫的交易都必須是 GTID 交易。
`enforce_gtid_consistency`	藉由僅允許執行可以交易安全方式記錄的陳述式，來強制執行 GTID 一致性。在啟用 GTID 複寫之前設定值 `ON` 。	`OFF*`	`OFF`：允許所有交易違反 GTID 一致性。 `ON`：禁止交易違反 GTID 一致性。 `WARN`：允許所有交易違反 GTID 一致性，但會產生警告。

附註

對於已啟用高可用性功能的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體，預設值會設定為 ON。

啟用 GTID 後，您將無法將其關閉。如果您需要關閉 GTID，請聯絡支援團隊。

您一次只能在一個步驟中，以遞增順序的模式將 GTID 從某個值變更為另一個值。例如，如果gtid_mode目前設定為OFF_PERMISSIVE，您可以將其變更為ON_PERMISSIVE，但不能變更為ON。

您無法針對主要或複本伺服器更新，以保持資料庫複寫的一致性。

將enforce_gtid_consistency設為ON之後，再將gtid_mode設為ON。

若要啟用 GTID 並設定一致性行為，請更新 gtid_mode 和 enforce_gtid_consistency 伺服器參數。使用 [使用 Azure 入口網站在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中設定伺服器參數 ] 或 [使用 Azure CLI 在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中設定伺服器參數]。

如果來源伺服器啟用 GTID （），gtid_mode = ON則新建立的複本也會啟用 GTID 並使用 GTID 複寫。為了確保複寫一致性，在建立已啟用 GTID 的主要或複本伺服器之後，您無法變更 gtid_mode 。

考量與限制

狀況	限制/考量
高載定價層中伺服器上的複本	不支援
定價	執行複本伺服器的成本取決於複本伺服器執行的區域。
來源伺服器停機/重新啟動	建立讀取複本時不需要重新啟動或停機。此作業是線上作業。
新複本	您將讀取複本建立為新的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。您無法將現有伺服器變成複本。您無法為另一個讀取複本建立複本。
複本設定	您可以使用與來源相同的伺服器配置來建立抄本。建立複本之後，您可以獨立於來源伺服器變更數個設定：計算產生、虛擬核心、儲存體和備份保留期間。您也可以獨立變更計算層。重要 - 將來源伺服器組態更新為新值之前，請將複本組態更新為相等或更大的值。此動作可確保複本可以跟上來源伺服器上所做的變更。當您建立複本時，連線方法和參數設定會從來源伺服器繼承至複本。之後，複本的規則就已獨立。
已停止的複本	如果您停止在來源伺服器和讀取複本之間進行複寫，已停止的複本就會成為獨立伺服器，同時接受讀取和寫入作業。您無法再次將獨立伺服器再製成複製品。
已刪除的來源伺服器	刪除來源伺服器時，所有讀取複本的複寫都會停止。這些複本會自動變成獨立伺服器，並且可以同時接受讀取和寫入。來源伺服器本身會被刪除。
使用者帳戶	系統會將來源伺服器上的使用者複寫到讀取複本。您只能使用來源伺服器上可用的使用者帳戶，來連線到讀取複本。
伺服器參數	若要防止資料不同步，以及避免潛在的資料遺失或損毀，則會在使用讀取複本時，有些伺服器參數會被鎖定而無法更新。來源伺服器和複本伺服器都會鎖定下列伺服器參數： - `innodb_file_per_table` - `log_bin_trust_function_creators` 複本伺服器上會鎖定 `event_scheduler` 參數。若要更新來源伺服器上的上述其中一個參數，請刪除複本伺服器、更新來源上的參數值，然後重新建立複本。
工作階段層級參數	在僅供讀取複本上設定工作階段層級參數（例如「foreign_keys_checks」）時，請確定您在僅供讀取複本上設定的參數值與來源伺服器的參數值一致。
將AUTO_INCREMENT主鍵欄位新增至來源伺服器中的現有資料表	我們不建議在建立讀取副本後變更 `AUTO_INCREMENT` 資料表格，因為此操作會中斷資料庫複製。如果您想要在建立複本伺服器之後新增自動遞增直欄，請考慮下列方法： - 建立與您要修改的資料表具有相同結構描述的新資料表。在新表格中，使用 `AUTO_INCREMENT`變更資料行，然後從原始表格還原資料。刪除舊表並在源中重命名它;此方法不需要刪除複本伺服器，但建立備份資料表可能會產生大量的插入成本。 - 新增所有自動遞增欄位後，重新建立副本。
其他	- 不支援建立複本的複本。 - 記憶體內表格可能會導致抄本不同步。此限制是由於MySQL複製技術造成的。如需詳細資訊，請參閱 MySQL 參考文件。 - 請確定來源伺服器資料表具有主索引鍵。缺少主索引鍵，可能會造成來源伺服器和複本伺服器之間，所產生的複寫延遲。 - 檢閱 MySQL 文件中 MySQL 複寫限制的完整清單。

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-08-18