移轉至適用於 MySQL 的 Azure 資料庫的已知問題

下列章節將說明與移轉至適用於 MySQL 的 Azure 資料庫相關的已知問題。

v8.0 MySQL 彈性伺服器目標的結構描述移轉問題

  • 錯誤:當啟用為 InnoDB 資料表產生隱藏主索引鍵的功能時,移轉至具有引擎 8.0.30 版或更新版本的 MySQL 彈性伺服器可能會失敗 (請參閱 MySQL :: MySQL 8.0 參考手冊 :: 13.1.20.11 產生的隱藏主索引鍵)。 當將資料表結構描述從來源移轉至目標、在線上移轉複寫階段期間套用變更、重試移轉,或移轉至已手動移轉結構描述的目標時,可能會發生失敗。

    可能的錯誤訊息

    • 「未知的錯誤。」
    • 「無法產生隱藏的主索引鍵。 自動遞增欄已存在。」
    • 「資料庫 'database' 中目標資料表 'table name' 中的資料行 'my_row_id' 不存在於來源資料表上。」

    限制:DMS 不支援移轉至啟用 sql_generate_invisible_primary_key 的 MySQL 彈性伺服器執行個體。

    因應措施:將目標 MySQL 彈性伺服器的伺服器參數 sql_generate_invisible_primary_key 設定為 OFF。 您可以在目標 MySQL 彈性伺服器 [所有] 索引標籤下的 [伺服器參數] 窗格中找到伺服器參數。 此外,刪除目標資料庫並重新開始 DMS 移轉,以免出現任何不符合的結構描述。

不相容的 SQL 模式

一或多個不相容的 SQL 模式可能會導致許多不同的錯誤。 以下是範例錯誤,以及在此錯誤發生時應該查看的伺服器模式。

  • 錯誤:活動 '{activity}' 期間,在伺服器 '{server}' 的資料庫 '{database}' 中準備資料表 '{table}' 進行移轉時發生錯誤。 因此,此資料表將不會進行移轉。

    限制:當下列其中一個 SQL 模式設定在一部伺服器上,但未設定在另一部伺服器時,就會發生此錯誤。

    因應措施

    • NO_ZERO_DATE

      在來源上,資料表或資料上日期的預設值為 0000-00-00,且目標伺服器已設定 NO_ZERO_DATE SQL 模式時,結構描述和/或資料移轉會失敗。 有兩種可能的因應措施。 第一種是將欄的預設值變更為 NULL 或有效的日期。 第二個選項是從全域 SQL 模式變數中移除 NO_ZERO_DATE SQL 模式。

    • NO_AUTO_CREATE_USER

      當執行從 MySQL 來源伺服器 5.7 至 MySQL 目標伺服器 8.0 的移轉作業 (正在執行常式的結構描述移轉) 時,如果在 MySQL 來源伺服器 5.7 上設定 no_auto_create_user SQL 模式,就會發生錯誤。

Binlog 保留問題

  • 錯誤:讀取 binlog 時發生嚴重錯誤。 此錯誤可能表示 binlog 檔案名稱及/或初始位置未正確指定。

    限制:如果 binlog 保留期間太短,就會發生此錯誤。

    因應措施:在此案例中有多個可以設定的變數:binlog_expire_logs_seconds 決定保留期間,而且可將 binlog_expire_logs_auto_purge 設定為 off,來完全防止 binlog 刪除。 MySQL 5.7 已棄用系統變數 expire_logs_days。

取得資料表鎖定逾時

  • 錯誤:嘗試在伺服器 '{server}' 上取得讀取鎖定以建立一致檢視時發生例外狀況。

    限制:啟用交易一致性時,若在取得所有資料表的鎖定時出現逾時,就會發生此錯誤。

    因應措施:確定選取的資料表未遭鎖定,或沒有長時間執行的交易正在其上執行。

將超過 4 MB 的資料寫入至 Azure 儲存體

  • 錯誤:要求本文太大且超過允許的上限。

    限制:有太多資料表要移轉 (>10k) 時,可能會發生此錯誤。 每次呼叫 Azure 儲存體服務的大小限制為 4 MB。

    因應措施:透過建立支援要求來連絡支援人員,而且我們可以提供自訂指令碼來直接存取 REST API。

重複的索引鍵項目問題

  • 錯誤:錯誤通常是逾時、網路問題或目標調整的徵兆。

    潛在錯誤訊息:由於目標伺服器引發的 SQL 錯誤,無法將批次寫入至資料表 '{table}'。 針對內容,批次包含下列來源查詢所傳回的資料列子集。

    限制:此錯誤可能是由逾時或與目標的連線中斷所產生,因而導致主索引鍵重複。 這也可能是因為同時對目標執行多個移轉,或是在移轉執行時使用者在目標上執行測試工作負載。 此外,目標可能要求主索引鍵具有唯一性,即使在來源上不要求此條件。

    因應措施:若要解決此問題,請確定沒有任何重複的移轉執行中,而且來源主索引鍵是唯一的。 如果錯誤持續發生,請透過建立支援要求來連絡支援人員,而且我們可以提供自訂指令碼來直接存取 REST API。

複寫作業出現不相符的資料列錯誤

  • 錯誤:線上移轉無法複寫預期的變更數目。

    潛在錯誤訊息:將從來源伺服器二進位記錄讀取的記錄套用至目標伺服器時發生錯誤。 變更從二進位記錄 '{mysql-bin.log}' 和位置 '{position}' 開始,並於二進位記錄 '{mysql-bin.log}' 和位置 '{position}' 結束。 來源伺服器上二進位記錄 '{mysql-bin.log}' 中位置 '{position}' 之前的所有記錄均已提交至目標。

    限制:在來源上,資料表中有插入和刪除陳述式,而刪除是透過明顯的唯一索引進行。

    因應措施:建議您手動移轉資料表。

資料表資料截斷錯誤

  • 錯誤:列舉資料行在一或多個資料列中具有 Null 值,且目標 SQL 模式設定為嚴格。

    潛在錯誤訊息:由於資料截斷錯誤,無法將批次寫入至資料表 '{table}'。 請確定資料對於 MySQL 資料表資料行的資料類型不會太大。 如果資料行類型為 enum,請確定 SQL 模式未設定為 TRADITIONAL、STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES,而且在來源和目標上相同。

    限制:當歷程記錄資料具有特定設定時,若將其寫入至來源伺服器時,就會發生錯誤,但在設定進行變更時,資料無法移動。

    因應措施:若要解決此問題,建議將目標 SQL 模式變更為不嚴格 或將所有 Null 值變更為有效值。

建立物件失敗

  • 錯誤:在檢視表驗證失敗之後發生錯誤。

    限制:嘗試移轉檢視表時發生錯誤,且找不到檢視表應該參考的資料表。

    因應措施:建議您手動移轉檢視表。

找不到資料表

  • 錯誤:找不到參考資料表時發生錯誤。

    潛在錯誤訊息:由於查詢執行,管線無法使用 MySqlSchemaMigrationViewUsingTableStrategy 策略,為活動 '{activity}' 建立物件 '{object}' 的結構描述。

    限制:當檢視表參考已刪除或重新命名的資料表,或使用不正確或不完整資訊建立了檢視表時,可能會發生錯誤。 如果資料表的子集已移轉,但其相依的資料表並未移轉,則可能會發生此錯誤。

    因應措施:建議您手動移轉檢視表。 檢查是否已選取外部索引鍵和 CREATE VIEW 陳述式中參考的所有資料表進行移轉。

所有集區式連線中斷

  • 錯誤:來源伺服器上的所有連線都已中斷。

    限制:當初始載入開始時取得的所有連線,由於伺服器重新啟動、網路問題、來源伺服器上的大量流量或其他暫時性問題而遺失時,就會發生錯誤。 此錯誤不可復原。 此外,如果在維護時段嘗試移轉伺服器,就會發生此錯誤。

    因應措施:必須重新啟動移轉,並建議您提高來源伺服器的效能。 另一個問題是終止長時間執行連線的指令碼會阻止這些指令碼運作。

快照持續中斷

限制:當客戶在移轉執行個體的初始載入期間執行 DDL 時,就會發生錯誤。

因應措施:若要解決此問題,建議您避免在初始載入期間進行 DDL 變更。

外部索引鍵限制

  • 錯誤:當資料表中參考的外部索引鍵進行變更時發生錯誤。

    潛在錯誤訊息:外部索引鍵條件約束 '{key}' 中的參考資料行 '{pk column 1}' 和被參考資料行 '{fk column 1}' 不相容。

    限制:錯誤可能會導致資料表的結構描述移轉失敗,因為表 1 中的 PK 資料行可能與表 2 中的 FK 資料行不相容。

    因應措施:若要解決此問題,建議您在移轉流程完成之後,卸除外部索引鍵並將其重新建立。