IBM Cloud Docs
移轉考量

移轉考量

Microsoft SQL Server 資料庫支援許多方法將現有的 SQL Server 資料庫移轉至 IBM Cloud VPC。 本文件不會深入說明移轉,但會討論一些方法,可讓您根據需求及後續評量來選擇一或多個方法。

  • 原生 SQL Server 備份/還原。
  • 交易式抄寫。
  • 資料庫鏡映。
  • 日誌傳送。
  • 一律開啟可用性群組。
  • 一律開啟分散式可用性群組。

移轉時需要考量資料移動以外的其他事項,例如:

  • 正在新伺服器上重建 SQL 工作。
  • 在新伺服器上重建登入。
  • 資料加密。
  • 抄寫期間的回復選項。
  • 要傳輸的資料數量。
  • 現行軟體版本及版本中可用的特性。

原生 SQL Server 備份/還原

Microsoft SQL Server 資料庫支援使用完整及差異備份 (.bak) 檔案或差異還原及日誌還原的原生備份及還原作業。 使用原生 .bak 檔是備份及還原 SQL Server 資料庫的最簡單方法,並且是實例中單一或多個資料庫的簡式移轉方法。 會取得現有伺服器上資料庫的完整備份,並複製到 IBM Cloud Object Storage 儲存區。 然後會透過具有 s3fsrclone 及 SMB\Samba 共用的暫置伺服器,在 IBM Cloud VPC中的 SQL Server 資料庫實例虛擬伺服器上還原它。

交易式抄寫

交易式抄寫可讓變更在一個資料庫與另一個資料庫之間傳送。 這些變更可能包括: 資料、表格、儲存程序、視圖等。 架構由下列項目組成:

  • 發佈者-發佈資料的主要資料庫。
  • 訂閱者-接收抄寫資料的次要資料庫。
  • 經銷商-儲存交易式抄寫的 meta 資料和交易的伺服器,最好是發佈者或訂閱者的個別伺服器。

處理程序的運作方式如下:

  • 交易式抄寫會在發佈資料庫中建立物件及資料的 Snapshot ,並將它傳送至訂閱者資料庫。 Snapshot 會套用至訂閱者資料庫。
  • 在發佈者進行的資料變更及綱目修改,會依其發生的順序傳送至訂閱者,並以相同的順序套用至訂閱者。
  • 當兩個資料庫已同步且處於維護時間範圍時:
    • 停止對發佈者的任何存取。
    • 請確定抄寫已完成。
    • 刪除訂閱。
    • 啟用對訂閱者的存取權。
    • 解除發佈者的任務。

如需進一步資訊,請參閱 交易式抄寫

資料庫鏡映

在 SQL Server 2012 中已淘汰資料庫鏡映,不過,仍在 SQL 2019 文件中參照,請參閱 SQL Server。 這裡討論移轉方法的完整性,不過,如果您想要在移轉中使用此方法,請仔細研究此方法。

SQL Server 中的資料庫鏡映可讓您在待命伺服器上保留 SQL Server 資料庫的副本或鏡映。 鏡映可確保資料的兩個個別副本一律存在。 相較於日誌傳送,資料庫鏡映的設定較為複雜,而且有更多限制。 如果夥伴關係中的兩部伺服器都位於相同的「Windows 網域」中,則資料庫鏡映更容易設定,但如果不是這樣,您可以使用憑證來進行端點鑑別。 移轉的基本步驟包括:

  • 配置資料庫鏡映。
  • 在必要的一段時間內,停止正在主要伺服器上使用主體資料庫的應用程式。
  • 請確定每一個資料庫都處於已同步狀態。
  • 失效接手每一個鏡映使用者資料庫。
  • 移除鏡映夥伴關係。
  • 將應用程式重新導向至新的資料庫伺服器。
  • 解除原始伺服器的任務。

日誌傳送

SQL Server 日誌傳送可以在資料庫層次配置,並且在指定的時段內,將取得 SQL Server 交易日誌備份並複製到目的地伺服器並還原。 交易日誌包含 SQL Server 資料庫中發生的所有交易的日誌。 從中傳送交易日誌備份的 SQL Server 實例稱為主要,而其中傳送交易日誌備份的 SQL Server 實例稱為次要。 在配置日誌傳送之前,資料庫必須處於完整回復模型或大量記載模式。

SQL Server 交易日誌備份設定容許定址至網路路徑,且備份工作排程器可以定義為執行備份工作,依預設,設定為每 15 分鐘執行一次備份工作。 排定資料庫備份之後,它會建立一個資料庫完整備份,需要在次要伺服器上回復。 在維護時間期間,可以執行從主要伺服器到次要伺服器的切換,停用日誌傳送,並解除主要伺服器的任務。

一律開啟可用性群組

SQL Server Always On 可用性群組提供高可用性及災難回復解決方案,並在 SQL Server 2012 以及更新版本中提供。 此特性可用來將現有的 SQL Server 資料庫移轉至 IBM Cloud ,並將關閉時間降至最低。 如果您具有具有 Always On 可用性群組的現有 Windows Server Failover Cluster ,則可以透過建立具有非同步抄寫的其他次要抄本,在移轉期間暫時延伸叢集。 在維護時間期間,可以執行手動失效接手來啟用切換。

一律開啟分散式可用性群組

SQL Server Always On 分散式可用性群組跨越兩個不同的可用性群組。 每一個可用性群組都在兩個不同的 Windows Server Failover Cluster (WSFC) 上配置,一個位於來源位置,一個位於 IBM Cloud VPC。 作業系統及 SQL Server 版本不必是相同的版本,只要它們能夠支援 WSFC 及可用性群組即可。 此移轉方法適用於重新管理關鍵任務 SQL Server 資料庫。 分散式可用性群組架構是一種有效率的資料傳送方法,因為主要抄本只會傳送 IBM Cloud中的轉遞程式抄本,然後轉遞程式會負責將資料與 IBM Cloud中的次要抄本同步化。 一般架構如下:

  • 來源 WSFC 叢集管理 Always On 可用性群組,具有兩個節點並使用同步抄寫,具有自動失效接手。
  • 在 IBM Cloud 中管理的目標 WSFC 叢集具有 Always On 可用性群組,具有兩個節點,一個位於多區域區域 (MZR) 中的「可用性區域 (AZ)」,並使用同步抄寫,具有自動失效接手。
  • 網路連線 (通常是直接鏈結連線) 會連接兩個叢集。
  • 配置 Always On 分散式可用性群組,並將資料從來源 WSFC 叢集的主要抄本傳送至目標 WSFC 叢集中的主要抄本 (轉遞者)。
  • 轉遞者負責將資料傳送至目標 WSFC 叢集中的次要抄本。

在維護時間期間,可以執行手動失效接手,以啟用切換,且目標 WSFC 中的主要資料庫會變成從應用程式讀取/寫入的來源。

如需相關資訊,請參閱 分散式可用性群組