分享方式:


適用於 MySQL 的 Azure 資料庫讀取複本 - 彈性伺服器

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

MySQL 是一種熱門的資料庫引擎,可執行網際網路規模的 Web 和行動應用程式。 我們有許多客戶將其用於線上教育服務、影片串流服務、數位付款解決方案、電子商務平台、遊戲服務、新聞入口網站、政府和醫療保健網站。 當 Web 或行動裝置應用程式上的流量增加時,需要這些服務才能提供和調整流量。

在應用程式端上,該應用程式通常在 JAVA 或 PHP 中進行開發,並移轉至 Azure 虛擬機器擴展集或 Azure App Service 上執行,或以容器化形式在 Azure Kubernetes Service (AKS) 上執行。 以虛擬機器擴展集、App Service 或 AKS 作為基礎結構,藉由立即佈建新的 VM 並複寫應用程式的無狀態元件以滿足要求,而簡化了應用程式調整,但最後資料庫通常是集中式具狀態元件的瓶頸。

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

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

注意

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

若要深入了解 MySQL 複寫功能與問題,請參閱 MySQL 複寫文件 \(英文\)。

注意

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

讀取複本的常見使用案例

讀取複本功能可針對需大量讀取的工作負載,協助改善效能及調整能力。 讀取工作負載可隔離至複本,而寫入工作負載可以導向到來源。

常見案例如下:

  • 使用如 ProxySQL 等輕量型連線 Proxy,或使用微服務型模式,調整來自應用程式的讀取工作負載,以擴增來自讀取複本應用程式的讀取查詢
  • BI 或分析報告工作負載,可以使用讀取複本作為報告的資料來源
  • 針對 IoT 或製造業案例,其中的遙測資訊會內嵌於 MySQL 資料庫引擎,而多個讀取複本會用於資料報告中

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

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

跨區域複寫

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

建立複本

如果來源伺服器沒有現有的複本伺服器,則來源伺服器會先重新啟動,以準備進行複寫。

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

注意

將以與來源伺服器相同的伺服器設定,來建立讀取複本。 複本伺服器設定在建立後可以變更。 複本伺服器一律會在與來源伺服器相同的資源群組和訂閱中建立。 如果您想要將複本伺服器建立到不同的資源群組或不同的訂閱,您可以在建立後移動複本伺服器。 建議複本伺服器設定的值應保持等於或大於來源伺服器,以確保複本伺服器與來源伺服器保持一致。

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

連線到複本

複本會在建立期間繼承來源伺服器的連線方法。 您無法變更複本的連線方法。 例如,如果來源伺服器具有私人存取 (VNet 整合),則複本不能位於公用存取 (允許的 IP 位址)

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

您可以使用其主機名和有效的用戶帳戶來連線到複本,就像在一般 適用於 MySQL 的 Azure 資料庫 彈性伺服器實例上一樣。 若伺服器名稱為 myreplica,且統管理員使用者名稱為 myadmin,則您可以使用 mysql CLI 來連線到複本:

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

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

監視複寫

適用於 MySQL 的 Azure 資料庫 彈性伺服器提供Azure 監視器中的復寫延遲以秒為單位計量。 此計量僅適用於複本。 在計算此計量時,會使用可於 MySQL 的 SHOW SLAVE STATUS 命令中取得的 seconds_behind_master 計量。 請設定警示,以在複寫延遲接近工作負載無法接受的值時通知您。

如果您發現複寫延遲增加,請參閱針對複寫延遲進行疑難排解,瞭解可能原因並進行疑難排解。

重要

讀取複本會使用以儲存體為基礎的複寫技術,不再使用 MySQL 的 'SHOW SLAVE STATUS'/'SHOW REPLICA STATUS' 命令中提供的 'SLAVE_IO_RUNNING'/'REPLICA_IO_RUNNING' 計量。 這個值一律會顯示為「No」,而不會指出複寫狀態。 若要知道複寫的正確狀態,請參閱 [監視] 刀鋒視窗下的複寫計量 - 複本 IO 狀態複本 SQL 狀態

停止複寫

您可以停止來源伺服器與複本伺服器之間的複寫。 當您停止來源伺服器和讀取複本之間的複寫,該複本就會成為獨立伺服器。 獨立伺服器中的資料是起始「停止複寫」命令時,複本上所包含的可用資料。 獨立伺服器不會與來源伺服器保持一致。

當您選擇停止複寫至複本時,其會失去與其先前來源伺服器和其他複本的所有連結。 來源伺服器及其複本之間沒有自動容錯移轉功能。

重要

獨立伺服器無法再次設定為複本。 在您停止讀取複本上的複寫之前,請確定該複本上已經有您所需要的所有資料。

了解如何停止複寫至複本

容錯移轉

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

讀取複本的目的是調整讀取密集型工作負載,並非設計為符合伺服器的高可用性需求。 執行手動容錯移轉的方式,是停止讀取複本上的複寫,並以讀取寫入模式將其上線。

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

提示

如果您容錯移轉至複本,則當您從來源伺服器取消複本連結時,延遲會指出遺失的資料數量。

當您決定要容錯移轉至複本後:

  1. 停止複寫至複本
    這是讓複本伺服器可接受寫入作業的必要步驟。 在此處理序中,系統會從來源伺服器取消複本伺服器的連結。 當您停止複寫時,後端處理序通常需要大約 2 分鐘才能完成。 請參閱本文的停止複寫章節,以了解此動作的含意。

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

在應用程式順利處理讀取和寫入作業後,您便完成容錯移轉。 應用程式的停機時間長度,取決於您偵測到問題並完成上述步驟 1 和 2 的時間點。

全域交易識別碼 (GTID)

全域交易標識碼 (GTID) 是與來源伺服器上每個認可交易一起建立的唯一標識符,預設為 OFF 適用於 MySQL 的 Azure 資料庫 彈性伺服器。 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 並設定一致性行為,請使用 Azure 入口網站Azure CLI 更新 gtid_modeenforce_gtid_consistency 伺服器參數。

如果在來源伺服器上啟用 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 複寫限制完整清單

下一步