MySQL 至適用於 MySQL 的 Azure 資料庫資料移轉 - MySQL 一致快照集
MySQL 一致快照集是一項新功能，可讓使用者取得 MySQL 伺服器的一致快照集，而不會因為持續的 CRUD (建立、讀取、更新和刪除) 作業而失去來源的資料完整性。 透過此功能，不需要將來源伺服器設成唯讀模式，即可達到交易一致性。 此外，向使用者呈現多個資料一致性選項 - [啟用一致快照集並具有讀取鎖定 (GA)]、[啟用一致快照集而不鎖定 (預覽)]、[將來源伺服器設為唯讀] 和 [無]。 選取 [無] 選項意味著不需要採取任何額外的措施，即可確保資料一致性。 兩個選項 [啟用一致快照集並具有讀取鎖定 (GA)] 和 [啟用一致快照集而不鎖定]，可支援執行線上移轉。 強烈建議選取選項 [啟用一致快照集而不鎖定]，以維持交易一致性。
啟用一致快照集而不鎖定 (預覽)
啟用此選項時，會在初始載入之後發生協調階段。 這是要確保寫入目標的資料，與來自二進位記錄檔中特定位置的來源伺服器在交易上保持一致。
透過此功能，我們不會在伺服器上取得讀取鎖定。 相反地，我們會在不同的時間點讀取資料表，同時追蹤每個資料表的不同 binlog 位置。 這有助於在追趕模式中執行複寫，以取得一致的快照集，來協調資料表到初始載入的結尾。
啟用一致快照集而不鎖定的主要功能：
- 能夠支援具有長時間執行交易的一或多部繁重工作負載伺服器，而不需要讀取鎖定。
- 即使在失敗是由於暫時性網路/伺服器暫時的改變，導致所有預先建立連線遺失時，在完成移轉方面具有可復原性。
啟用一致快照集並具有讀取鎖定 (GA)
啟用此選項時，此服務會以讀取鎖定來取得時間點快照集，以排清來源伺服器上的所有資料表。 此排清動作是因為全域鎖定比嘗試鎖定個別資料庫或資料表更可靠。 因此，即使不是要移轉伺服器中的全部資料庫，在設定移轉程序時也都會鎖定。 移轉服務會起始可重複的讀取，並結合目前的資料表狀態與復原記錄檔的內容以產生快照集。 在取得全伺服器鎖定幾秒鐘並產生移轉所需的幾個連線之後，就會產生快照集。 建立所有用於移轉的連線之後，就會解除資料表上的鎖定。
啟用可重複的讀取以確保在移轉期間仍可存取復原記錄檔，但因為長時間執行連線，會增加來源所需的儲存體。 具有多個資料表變更的長時間執行移轉，會導致需要重新執行廣泛復原記錄檔歷程記錄，且也可能增加來源伺服器上的計算需求和負載。
將來源伺服器設為唯讀
選取此選項可藉由在移轉期間防止來源伺服器上的寫入/刪除作業，維護目標資料庫的資料完整性。 當您在移轉程序中將來源伺服器設為唯讀時，該選項會套用至來源伺服器的所有資料庫，而不論是否選取要移轉。
將來源伺服器設為唯讀就無法對資料庫進行任何更新作業，可防止使用者修改資料。 不過，如果未啟用此選項，則移轉期間有可能更新資料。 因此，由於在不同的時間讀取資料庫快照集，移轉的資料可能不一致。
啟用一致快照集並具有讀取鎖定 (GA) 的必要條件
若要在啟用一致快照集並具有讀取鎖定的情況下成功完成移轉：
請確定嘗試使用讀取鎖定來排清資料表的使用者具有 RELOAD 或 FLUSH 權限。
使用 mysql 用戶端工具查明來源伺服器上是否啟用 log_bin。 Bin 記錄檔並未預設為一律開啟，因此在開始移轉之前應該檢查是否已啟用。 Mysql 用戶端工具用來執行此命令，以查明來源上是否已啟用 log_bin：SHOW VARIABLES LIKE 'log_bin';
注意
適用於 MySQL 的 Azure 資料庫單一伺服器，最多可支援 4TB 且預設不會啟用。 不過，如果您升階來源伺服器的讀取複本，然後刪除讀取複本，參數會設定為 ON。
- 在來源伺服器上設定 binlog_expire_logs_seconds 參數，以確保在複本認可變更之前不會清除 binlog 檔案。 成功完全移轉後，可以重設此值。
啟用一致快照集而不鎖定的已知問題和限制
- 不支援具有串聯或 Set Null on delete/on update 子句的外部索引鍵資料表。
- 初始載入期間不應發生 DDL 變更。
啟用一致快照集並具有讀取鎖定 (GA) 的已知問題和限制
與「一致備份」相關聯的已知問題和限制大致分為兩種類別：鎖定和重試。
注意
移轉服務會針對所有背景工作執行緒執行 START TRANSACTION WITH CONSISTENT SNAPSHOT 查詢，以取得伺服器快照集。 但只有 InnoDB 才支援此功能。 更多資訊在此處。
鎖定
一般而言，取得鎖定是很直接的程序，只需要幾秒鐘到幾分鐘就可完成。 不過，在少數情況下，嘗試在來源伺服器上取得鎖定可能失敗。
長時間執行的查詢可能導致不必要的停機時間，因為 DMS 可能鎖定一組資料表，然後在等候使用最後幾個資料表時逾時。 開始移轉之前，請執行 SHOW PROCESSLIST 命令來檢查是否有任何長時間執行的作業。
如果來源伺服器在要求鎖定時遇到大量寫入更新，則無法立即取得鎖定，可能在鎖定等候逾時之後失敗。 這發生在資料表中批次處理工作的情況下，進行這些工作時可能導致拒絕要求鎖定。 如先前所述，要求的鎖定是整個伺服器的單一全域層級鎖定，因此即使只有一個資料表或資料庫正在處理，鎖定要求還是必須等候進行中的工作結束。
另一項限制與從 AWS RDS 來源伺服器移轉有關。 RDS 不支援排清具有讀取鎖定的資料表，LOCK TABLE 查詢會在幕後於選取的資料表上執行。 由於個別鎖定資料表，鎖定程序可能較不可靠，可能需要花較多時間來取得鎖定。
重試
移轉會處理暫時性連線問題，通常會為此預先佈建額外的連線。 我們查看移轉設定，特別是來源上的平行讀取作業數目，並套用因數 (通常 ~1.5) 和預先建立一樣多的連線。 如此一來，服務可確保我們保持作業平行執行。 隨時，如果連線中斷或服務無法取得鎖定，服務就會使用已佈建的剩餘連線來重試移轉。 如果所有佈建的連線都耗盡，導致時間點同步失敗，則必須從頭開始移轉。 不論成功或失敗，此離線移轉服務會執行所有清除動作，使用者不需要執行任何明確的清除動作。