淘汰公告后 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器會發生什麼事？
適用於：
適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器
適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器處於淘汰路徑，並排定於 2025 年 3 月 28 日淘汰。
適用於 PostgreSQL 的 Azure 資料庫 – 單一伺服器已於 2018 年正式推出。 鑒於客戶意見反應和 Azure 資料庫環境中計算、可用性、延展性和效能功能的新進展，單一伺服器供應項目必須淘汰並升級為新的架構。 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器是新一代的服務，併為您提供最佳的 Azure 開放原始碼資料庫平臺。
在此淘汰中，我們不再支援從 2023 年 11 月 30 日開始的 Azure 入口網站 建立新的單一伺服器實例。 如果您需要建立單一伺服器實例以符合商務持續性需求，您可以繼續使用 Azure CLI 和 ARM 範本。 不過，自 2025 年 3 月起，這些方法將不再使用。
如果您目前有裝載生產伺服器的 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器服務，我們很高興通知您，您可以將您的 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。
適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器是完全受控的生產就緒資料庫服務，專為更細微地控制和彈性的資料庫管理功能和組態設定所設計。 如需 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器的詳細資訊，請流覽 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。
從 適用於 PostgreSQL 的 Azure 資料庫 移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器
瞭解如何使用單一伺服器移轉至彈性伺服器移轉工具，從 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。
常見問題集 (FAQ)
問： 為何 適用於 PostgreSQL 的 Azure 資料庫- 單一伺服器即將淘汰？
A. 適用於 PostgreSQL 的 Azure 資料庫 – 單一伺服器已於 2018 年正式推出。 鑒於客戶意見反應和 Azure 資料庫環境中計算、可用性、延展性和效能功能的新進展，單一伺服器供應項目必須淘汰並升級為新的架構。 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器是新一代的服務，併為您提供最佳的 Azure 開放原始碼資料庫平臺。
問： 為什麼我被要求移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器？
A.適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器是在 Azure 上執行所有開放原始碼 PostgreSQL 工作負載的最佳平臺。 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器具有經濟效益、在所有服務層級之間提供更佳的效能，以及控制成本的更多方式，以更便宜且更快速的災害復原。 彈性伺服器的其他改善包括：
- 支援 Postgres 第 11 版和更新版本，以及內建的安全性增強功能
- 支援高載層計算選項的更佳價格效能。
- 藉由在相同或不同的可用性區域和使用者控制的維護時段上設定熱待命來改善運行時間。
- 高效能數據工作負載的簡化開發人員體驗。
問： 我必須多久才能將單一伺服器移轉至彈性伺服器？
A. 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器已排定於 2025 年 3 月 28 日淘汰，因此強烈建議您儘早將單一伺服器移轉至彈性伺服器，以確保有足夠的時間在移轉生命週期中執行，並使用彈性伺服器所提供的優點。
問： 我現有的 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器實例會發生什麼事？
A. 您現有的 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器工作負載將繼續支援，直到 2025 年 3 月為止。
問： 在 2023 年 11 月社群 EOL 日期之後，我仍然可以建立新版本 11 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器嗎？
A. 從 2023 年 11 月 30 日開始，您將無法再透過 Azure 入口網站，為 PostgreSQL 第 11 版建立新的單一伺服器實例。 不過，您仍然可以 透過 CLI 進行，直到 2024 年 11 月為止。 我們會透過版本控制支持原則，繼續支援單一伺服器。最好立即開始移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。
問： 我可以在 2025 年 3 月 28 日日落日期之後繼續執行我的 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器嗎？
A. 我們計劃支援單一伺服器，直到 2025 年 3 月 28 日的日落日期，我們強烈建議您儘快開始規劃您的移轉。 我們計劃在 2025 年 3 月 28 日日落數據終止對單一伺服器部署的支援。
問： 在單一伺服器淘汰公告之後，如果我仍然需要建立新的單一伺服器以符合我的商務需求，則該怎麼辦？
A. 我們不會停止立即建立新單一伺服器的能力，因此您可以繼續透過 CLI 建立新的單一伺服器，以滿足 適用於 PostgreSQL 的 Azure 資料庫 – 單一伺服器支援的所有 PostgreSQL 版本所需的商務需求。 我們強烈建議您探索彈性伺服器，並查看這是否符合您的需求。 如有必要，請毫不猶豫地與我們連絡，以便引導您，併為您建議最好的前進道路。
問： 是否有任何與執行移轉相關聯的額外成本？
A. 您在移轉期間支付目標彈性伺服器和來源單一伺服器的費用。 目標彈性伺服器的組態和運算將決定產生的額外成本（如需詳細資訊，請參閱 定價 ）。 在成功移轉后解除委任來源單一伺服器之後，您只需支付彈性伺服器的費用。 使用單一伺服器到彈性伺服器移轉工具不需要額外成本。 如果您有將單一伺服器移轉至彈性伺服器成本的問題或疑慮，請連絡您的 Microsoft 帳戶代表。
問： 我的帳單是否會受到執行 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器而不是 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器的影響？
A. 如果您選擇與 適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器類似的設定，則計費應該相當。 不過，如果您針對目標彈性伺服器選取具有高可用性的相同區域或區域備援，您的帳單將會高於單一伺服器上。 相同的區域或區域備援高可用性需要額外的熱待命伺服器才能啟動並儲存備援備份數據，因此第二部伺服器增加了成本。 此架構可在非計劃性中斷和計劃性維護期間減少停機時間。 一般而言，彈性伺服器可提供更佳的價格效能，不過，這取決於您的工作負載。
問： 當我將 Azure 資料庫從 PostgreSQL - 單一伺服器移轉至彈性伺服器時，是否會產生停機時間？
A. 目前，單一伺服器到彈性伺服器移轉工具僅支援離線移轉。 在移轉程式期間，離線移轉需要應用程式停機。 如需詳細資訊，請參閱移轉工具 - 適用於 PostgreSQL 的 Azure 資料庫 單一伺服器到彈性伺服器。
停機時間取決於數個因素，包括資料庫數目、資料庫大小、每個資料庫內的數據表數目、索引數目，以及跨數據表的數據分佈。 它也取決於來源和目標伺服器的 SKU，以及來源和目標伺服器上可用的 IOPS。
假設移轉牽涉到許多因素，估計應用程式停機時間的最佳方法是嘗試從主伺服器還原的 PITR 伺服器上移轉，以規劃生產移轉。
離線移轉較不複雜，失敗的機會很少，而且建議使用服務時段執行從單一伺服器移轉至彈性伺服器的方式。
如果單一伺服器提供的離線移轉不符合停機時間需求，您可以連絡您的帳戶小組，以使用彈性移轉工具。
注意
即將推出在線移轉的支援。
問： 未來是否會更新單一伺服器以支援最新的 PostgreSQL 版本？
A. 如果您必須在最新的 PostgreSQL 引擎版本上執行，建議您移轉至彈性伺服器。 我們會繼續部署社群針對Postgres第11版發行的次要版本，直到2023年11月由社群淘汰為止。
注意
我們正在擴充在社群淘汰日期之後對 Postgres 第 11 版的支援，並將在單一伺服器和彈性伺服器上支援 PostgreSQL 第 11 版，以簡化此轉換。 請考慮移轉至彈性伺服器，以使用最新 Postgres 引擎版本的優點。
問： 彈性伺服器 99.99% 可用性 SLA 與單一伺服器有何不同？
A. 彈性伺服器區域備援部署提供 99.99% 的可用性，具有區域性層級的復原能力，而單一伺服器提供 99.99% 的可用性，但沒有區域性復原功能。 彈性伺服器高可用性 （HA） 架構會部署具有備援計算和記憶體的熱待命伺服器（每個月台的數據儲存在 3 倍複本中）。 單一伺服器 HA 架構沒有被動熱待命，可協助從區域性失敗中復原。 彈性伺服器 HA 架構可減少非計劃性中斷和計劃性維護期間的停機時間。
問： 我的單一伺服器部署在不支援彈性伺服器的區域中。 我應該如何進行移轉？
A. 我們接近單一伺服器的區域同位。 這些區域沒有彈性伺服器存在。
- 中國東部（CE和CE2）
- 中國北方（CN和CNN2）
- 印度西部
- 瑞典北部
我們建議移轉至 CN3/CE3、印度中部、瑞典中部和瑞典南部區域。 問： 我已為單一伺服器設定私人連結，且彈性伺服器目前不支援此功能。 我應如何移轉？
A. 私人鏈接的彈性伺服器支援是我們最高優先順序和藍圖。 這項功能計劃於 2023 年第 4 季推出。 另一個選項是考慮移轉至 VNET 插入的彈性伺服器。
問： 是否有選項可將單一伺服器復原至彈性伺服器移轉？
A. 您可以執行任意數目的測試移轉、測試移轉的成功，並在準備好後執行最終移轉。 測試移轉不會影響單一伺服器來源，在您執行移轉之前仍可運作。 如果在測試移轉期間發生任何錯誤，您可以延後最終移轉，並讓來源伺服器保持執行。 解決錯誤之後，您接著可以重新嘗試最終的移轉。 執行最後移轉至彈性伺服器並針對生產工作負載開啟它之後，您將失去回到單一伺服器的能力，而不會造成數據遺失。
問： 如何移轉我的 DB （> 1TB）
A.單一伺服器到彈性伺服器移轉工具 可以將各種大小的資料庫從單一伺服器移轉至彈性伺服器。 新版本的工具沒有任何資料庫大小的限制。
問： 是否支援跨地區移轉？
A. 目前，單一伺服器到彈性伺服器移轉工具不支援跨區域移轉。 在稍後的時間點支援它。 您可以使用pg_dump/pg_restore跨區域執行移轉。
應該避免跨區域數據遷移，因為移轉需要很長的時間才能完成。 若要這麼做，最簡單的方法是在目標 GeoRegion 中啟動讀取複本、故障轉移您的應用程式，並遵循稍早所述的步驟。
問： 是否支援跨訂用帳戶移轉？
A. 單一伺服器到彈性伺服器移轉工具支援跨訂用帳戶移轉。
問： 是否支援跨資源群組訂用帳戶？
A. 單一伺服器到彈性伺服器移轉工具支援跨資源群組移轉。
問： 是否有跨版本支援？
A. 單一伺服器到彈性伺服器移轉服務支援從較低的 PostgreSQL 版本 （PG 9.5 和更新版本） 移轉至任何更高版本。 一如往常，應事先檢查與較高 PostgreSQL 版本的應用程式相容性。
單一伺服器到彈性伺服器移轉工具
單 一伺服器到彈性伺服器移轉工具 是功能強大的工具，可讓您輕鬆地將 SQL Server 資料庫從單一伺服器移轉至彈性伺服器。 使用此工具，您可以輕鬆地將資料庫從內部部署伺服器或虛擬機移至雲端中的彈性伺服器，讓您能夠利用雲端運算的延展性和彈性。
問： 哪些資料、結構描述和中繼資料元件會作為移轉的一部分來被移轉？
A. 單一伺服器到彈性伺服器移轉工具會將架構、數據和元數據從來源移轉至目的地。 下列所有資料、架構和元資料元件都會移轉為資料庫移轉的一部分：
資料移轉
- 來自所有資料庫/架構的所有數據表。
架構移轉：
- 命名
- 主要金鑰
- 資料類型
- 序數位置
- 預設值
- Null 屬性
- 自動增減屬性
- 次要索引
中繼資料移轉：
- 預存程序
- 函式
- 觸發程序
- 檢視
- 外鍵條件約束
問： 離線和線上移轉有何差異？
A. 單一伺服器到彈性伺服器移轉工具現在支援離線移轉，即將推出在線移轉。 透過離線移轉，應用程式停機會在移轉開始時開始。 使用在線移轉時，停機時間僅限於在移轉結束時剪下所需的時間，但會使用邏輯復寫機制。 您的資料/架構必須傳遞這些 開放原始碼PG引擎限制 ，才能進行在線移轉。 建議您測試離線移轉，以判斷是否可接受的停機時間。
下表比較了線上和離線移轉：
| 面積 | 線上移轉 | 離線移轉 |
|---|---|---|
| 移轉期間讀取的資料庫可用性 | 可用 | 可用 |
| 移轉期間寫入的資料庫可用性 | 可用的 | 通常，不建議如此。 未擷取或移轉之後起始的任何「寫入」 |
| 「應用程式合適性」 | 需要最大執行時間的應用程式 | 可承受計劃性停機時段或有禁止在線移轉之架構/工作負載 限制 的應用程式 |
| 大量寫入工作負載的適用性 | 適合，但預期會在移轉期間減少工作負載 | 只有在您可以在移轉期間停用寫入時，才建議使用這個解決方案。 移轉開始之後，來源的任何寫入都不會移轉至目標伺服器 |
| 手動完全移轉 | 必要 | 非必要 |
| 需要停機時間 | 無論數據大小為何，小型和固定 | 與數據大小和其他因素成正比。 對於較大型資料庫來說，它可能只有幾分鐘的時間小到數小時 |
| 移轉時間 | 取決於資料庫大小和寫入活動，直到完全移轉 | 視資料庫大小而定 |
問： 是否有任何建議可優化單一伺服器至彈性伺服器移轉工具的效能？
A. 是。 若要執行更快速的移轉，請為您的彈性伺服器挑選較高的 SKU。 挑選至少 4VCore 或更新版本，以快速完成移轉。 您一律可以變更 SKU，以符合移轉後的應用程式需求。
問： 使用單一伺服器到彈性伺服器移轉工具執行離線移轉需要多久時間？
A. 下表顯示使用單一伺服器到彈性伺服器移轉工具，針對各種大小之資料庫執行離線移轉的時間。 移轉是使用具有 SKU 的彈性伺服器來執行：
Standard_D4ds_v4（4 核心、16GB 記憶體、128GB 磁碟和 500 IOPS）
| 資料庫大小 | 時間 （HH：MM） |
|---|---|
| 1 GB | 00:01 |
| 5 GB | 00:03 |
| 10 GB | 00:08 |
| 50 GB | 00:35 |
| 100 GB | 01:00 |
| 500 GB | 04:00 |
| 1,000 GB | 07:00 |
注意
上述數字大約是完成移轉所花費的時間。 若要取得移轉至伺服器所需的精確時間，強烈建議您將單一伺服器的 PITR（時間點還原），並針對單一伺服器執行至彈性伺服器移轉工具。
問： 使用單一伺服器到彈性伺服器移轉工具執行在線移轉需要多久時間？
A. 線上移轉牽涉到下列步驟：
- 資料庫的初始複本
- 異動數據擷取 - 在步驟 1 期間重新執行來源上的所有交易至目標。
步驟 1 中花費的時間與離線移轉相同（請參閱上一個問題）。
步驟 #2 所花費的時間取決於來源上發生的交易。 如果是需要大量寫入的工作負載，步驟 #2 所花費的時間會更長。
其他支援
問： 我還有關於退休的進一步問題。
A. 您可以透過幾種不同的方式取得進一步的資訊。
取得 Microsoft Q&A 社群專家的解答。
如果您有支援方案，且需要技術協助，請建立支援要求：
- 在 [摘要] 的部分，輸入您的問題描述。
- 針對 [問題類型]，選取 [技術]。
- 在 [訂閱] 的部分，選取您的訂閱。
- 在 [服務]的部分，選取 [我的服務]。
- 針對 [服務類型]，選取 [適用於 PostgreSQL 的 Azure 資料庫 單一伺服器]。
- 針對 [資源]，選取您的資源。
- 針對 [問題類型]，選取 [移轉至適用於 PostgreSQL 的 Azure DB]。
- 針對 [問題] 子類型，選取 [從單一移轉至彈性伺服器]。
警告
本文不適用於 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器使用者。 這是針對需要升級至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器的單一伺服器客戶 適用於 PostgreSQL 的 Azure 資料庫。
我們知道移轉服務可能是令人沮喪的體驗，我們事先為您道歉，因為可能會造成任何不便。 您可以選擇最適合您和環境的案例。