共用方式為


將資料複寫至適用於 MySQL 的 Azure 資料庫 - 彈性伺服器

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

資料輸入複寫可讓您將外部 MySQL 伺服器的資料同步至「適用於 MySQL 的 Azure 資料庫」彈性伺服器執行個體。 外部伺服器可位於內部部署環境、虛擬機器、「適用於 MySQL 的 Azure 資料庫」單一伺服器,或其他雲端提供者託管的資料庫服務內。 資料輸入複寫是基於二進位記錄 (binlog) 檔案位置或 GTID 型複寫。 若要深入了解 binlog 複寫,請參閱 MySQL 複寫

注意

僅支援透過 GTID 型複寫為啟用了高可用性的伺服器設定資料輸入複寫。

使用資料輸入複寫的時機

適合考慮使用資料輸入複寫的主要案例包含:

  • 混合式資料同步:透過資料輸入複寫,您可以在內部部署伺服器與「適用於 MySQL 的 Azure 資料庫」彈性伺服器之間保持資料同步。 此同步有助於建立混合式應用程式。 當您目前擁有本機資料庫伺服器,但想要將資料移到更接近使用者的區域時,這個方法很吸引人。
  • 多雲同步:針對複合的雲端解決方案,使用資料輸入複寫來同步處理「適用於 MySQL 的 Azure 資料庫」彈性伺服器與不同雲端提供者 (包括這些雲端中所裝載的虛擬機器和資料庫服務) 之間的資料。
  • 移轉:客戶可以使用開放原始碼工具 (例如具有資料輸入複寫功能的 MyDumper/MyLoader) 在最短的時間內進行移轉。 使用資料輸入複寫,可以選擇性地將生產負載從來源完全移轉至目的地資料庫。

對於移轉案例,請使用 Azure 資料移轉服務 (DMS)。

限制與考量

不會複寫資料

不會複寫來源伺服器上的 mysql 系統資料庫。 此外,也不會複寫來源伺服器上對於帳戶和權限的變更。 如果您在來源伺服器上建立帳戶,且此帳戶需要存取複本伺服器,請在複本伺服器上手動建立相同的帳戶。 若要了解系統資料庫中的資料表,請參閱 MySQL 手冊

啟用高可用性 (HA) 的伺服器支援資料輸入複寫

只有在透過 GTID 型複寫時,才會為已啟用高可用性 (HA) 的伺服器支援資料輸入複寫。

使用 GTID 的複寫預存程序可透過 mysql.az_replication_change_master_with_gtid 名稱在所有已啟用 HA 的伺服器上使用。

篩選器

參數 replicate_wild_ignore_table 會為複本伺服器上的資料表建立複寫篩選條件。 若要從 Azure 入口網站修改此參數,請瀏覽至作為複本的「適用於 MySQL 的 Azure 資料庫」彈性伺服器執行個體,然後選取 [伺服器參數] 以檢視/編輯 replicate_wild_ignore_table 參數。

需求

  • 來源伺服器版本必須至少是 MySQL 5.7 版。

  • 我們建議針對來源和複本伺服器版本具有相同的版本。 例如,兩者都必須是 MySQL 5.7 版,或兩者都必須是 MySQL 8.0 版。

  • 我們建議在每個資料表中都有主索引鍵。 如果我們的資料表沒有主索引鍵,您可能會面臨複寫速度緩慢的問題。

  • 來源伺服器應使用 MySQL InnoDB 引擎。

  • 使用者必須具有正確的權限才能設定二進位記錄,以及在來源伺服器上建立新的使用者。

  • 在複本套用這些變更之前,不應該清除來源伺服器上的二進位記錄檔。 如果來源是「適用於 MySQL 的 Azure 資料庫」彈性伺服器,請參閱如何為彈性伺服器單一伺服器的設定 binlog_expire_logs_seconds

  • 如果來源伺服器已啟用 SSL,請確定為網域提供的 SSL CA 憑證已包含在 mysql.az_replication_change_master 預存程序中。 請參閱下列範例master_ssl_ca 參數。

  • 請確定裝載來源伺服器的機器允許連接埠 3306 上的輸入和輸出流量。

  • 對於公用存取,請確定來源伺服器具有公用 IP 位址、DNS 可供公開存取,或來源伺服器具有完整網域名稱 (FQDN)。 如果您有私人端點且已停用公用存取,則不支援數據輸入複寫

  • 使用私人存取 (VNet 整合),確保來源伺服器名稱可以解析,並從執行 適用於 MySQL 的 Azure 資料庫 彈性伺服器實例的 VNet 存取。 (如需詳細資料,請造訪 Azure 虛擬網路中資源的名稱解析)。

產生的隱藏主索引鍵

針對 MySQL 8.0 版和更新版本,預設會針對所有 適用於 MySQL 的 Azure 資料庫 彈性伺服器實例啟用產生的不可見主鍵 (GIPK)。 MySQL 8.0+ 伺服器會在資料表中新增隱藏的資料行 my_row_id 並在該資料行上新增主索引鍵,且在建立 InnoDB 資料表時不會有明確的主索引鍵。 啟用此功能後,可能會影響某些資料輸入複寫使用案例,如下所述:

  • 如果來源伺服器在沒有主索引鍵的資料表上建立主索引鍵,則資料輸入複寫會失敗並出現複寫錯誤:「錯誤 1068 (42000):定義了多個主索引鍵」。 為了減少失敗,請執行下列 sql 命令、略過複寫錯誤,然後重新啟動資料輸入複寫

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);
    
  • 如果來源伺服器新增 auto_increment 資料行作為唯一索引鍵,則資料輸入複寫會失敗並出現複寫錯誤:「錯誤 1075 (42000):不正確的資料表定義;只能有一個自動資料行,並且必須將其定義為索引鍵」。 為了減少失敗,請執行下列 sql 命令、將「sql_generate_invisible_primary_key」設定為 OFF、略過複寫錯誤,然後重新啟動資料輸入複寫

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;
    
  • 如果來源伺服器執行「sql_generate_invisible_primary_key」為 ON 時不支援的任何其他 SQL,則資料輸入複寫會失敗。 例如,建立分割區資料表。 在這種情況下,減少失敗的方法是將「sql_generate_invisible_primary_key」設定為 OFF,並重新啟動資料輸入複寫

下一步