Cloud SQL 執行個體的維護更新

本頁面說明 Cloud SQL 執行個體如何進行維護更新,以及如何控管這些更新的時間。如要開始使用,請參閱「查看及設定維護期間」。

總覽

Cloud SQL 這項代管服務會自動更新執行個體,確保基礎硬體、作業系統和資料庫引擎穩定、高效能、安全無虞和更新為最新版本。這類更新大多是在 Cloud SQL 執行個體啟動並運作時執行。不過,某些系統更新需要短暫中斷服務才能執行。這些更新稱為「維護」。

維護作業會更新資料庫引擎,有時也會更新作業系統。由於這些更新需要重新啟動執行個體,因此會造成一些停機時間。維護更新可帶來下列好處:

  • Cloud SQL 功能。為了推出新功能,資料庫引擎會更新,並安裝新的資料庫外掛程式。

  • 資料庫版本升級。開發 SQL Server 的資料庫軟體供應商每年會發布數次新的子版本。每個新版本都會修正錯誤、提供安全性修補程式、提升效能,並推出新的資料庫功能。如要查看 SQL Server 適用的 Cloud SQL 支援的最新子版本,請參閱版本資訊或資料庫版本和版本政策。Cloud SQL 執行個體會在最新資料庫版本發布後不久升級,讓您能執行最新的資料庫軟體。

  • 作業系統修補程式。我們會持續監控作業系統中新發現的安全漏洞。發現後,我們會修補作業系統,保護您免受新風險的影響。

維護作業影響

如果是 Cloud SQL Enterprise Plus 版本,Cloud SQL 會提供幾乎無須停機的預定維護作業。

Cloud SQL 通常每幾個月會排定一次維護更新事件。每個執行個體的維護更新作業約需 5 到 10 分鐘。如果執行個體有唯讀副本,維護更新作業的整體時間可能會更長。不過,在維護更新事件期間,每個 Cloud SQL Enterprise 版本執行個體平均會中斷連線不到 120 秒。如果執行個體在維護更新期間有大量活動,或資料集非常龐大,停機時間可能會較長。

您可以採取一些步驟,確保維護作業對營運的影響降到最低,例如使用維護設定,以及讓系統能彈性因應暫時性錯誤。

預定維護作業幾乎無需停機

Cloud SQL Enterprise Plus 版本執行個體在預定維護期間,通常只會中斷連線不到 1 秒,幾乎不會造成停機。

如果執行個體在維護期間有大量活動,停機時間可能會更長。

必要條件和限制

  • 不支援唯讀副本。
  • 只有符合下列條件,才支援具有唯讀副本的執行個體:

  • 每個執行個體支援 1 到 100 個資料庫。

  • 僅適用於 Cloud SQL Enterprise Plus 版本。

  • 適用於下列 SQL Server 版本:

    • SQL Server Enterprise 2019
    • SQL Server Enterprise 2022
    • SQL Server Enterprise 2025
  • 如果您使用 Cloud SQL Auth Proxy 或 Cloud SQL 語言連接器,請務必更新至最新版本。

  • 維護期間,SQL Server 內部伺服器名稱 SERVERPROPERTY('servername') 可能會變更。如果應用程式參照主機名稱或機器名稱,您可能需要在維護作業後更新這些值。Cloud SQL 連線字串和執行個體 IP 位址不會變更。

  • 僅支援使用者資料庫。系統資料庫無法新增至可用性群組。

  • 不支援下列資料庫類型:

    • 唯讀資料庫
    • 單一使用者資料庫
    • 指定為 AUTO_CLOSE 的資料庫
  • 不支援下列功能:

  • 維護期間,資料庫記錄會顯示來自兩個不同 VM 的訊息。
  • 如果在預定維護期間發出 DDL,變更的建立或修改時間戳記可能會晚於維護時間戳記。
  • 用戶端連線字串和查詢設定 (例如連線類型、查詢逾時和連線集區) 都可能影響觀察到的停機時間。請務必測試應用程式的設定,找出最符合需求的設定。

模擬幾乎無須停機的預定維護作業

如要測試 Cloud SQL Enterprise Plus 版本主要執行個體的預定維護停機時間,而不更新資料庫執行個體,可以模擬幾乎無須停機的預定維護作業。

如要執行這項操作,請在符合幾乎無須停機的計畫維護資格的 Cloud SQL Enterprise Plus 版本執行個體上,叫用維護事件模擬。模擬要求會導致執行個體更新作業,更新至作業前的相同維護版本。

即使執行個體有待處理的維護更新,您仍可執行模擬。在整個模擬過程中,執行個體版本會維持不變。

如要模擬停機時間近乎零的預定維護事件,請使用下列 gcloud CLI 指令:

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

將 INSTANCE_NAME 替換為要執行模擬維護作業的執行個體名稱。

維護作業設定

Cloud SQL 可讓您透過一組維護設定,設定維護更新。

您可以安排在短暫停機時間對應用程式影響最小的時段進行維護。您可以為每個 Cloud SQL 執行個體設定下列項目:

  • 維護時間 (舊稱「更新順序」)。更新 Cloud SQL 執行個體的推出期間週數。您可以採取下列做法︰

    • Any:維護更新作業可能在任何時間執行,但通常會在第 1 週內執行。
    • Week 1:維護作業會在維護通知發出後 7 到 14 天內進行。
    • Week 2:在通知傳送後的 15 到 21 天內進行維護更新。
    • Week 5:維護更新會在通知傳送後 35 到 42 天內進行。

    設定維護期間時,您會設定維護更新的時間表。

  • 維護期間。Cloud SQL 排定維護作業的星期和時段。維護期間為一小時。瞭解如何設定維護期間。

  • 拒絕維護期。Cloud SQL 不會安排維護作業的一段時間。拒絕維護期最長可設為 90 天。瞭解如何設定拒絕維護期。

預設維護期間

如未設定維護期間,Cloud SQL 會根據執行個體的時區,在下列預設期間更新執行個體:

  • 平日時段 (週一至週五):晚上 10 點至凌晨 6 點
  • 週末時段:週五晚上 10 點至週一上午 6 點

維護範例

假設您是零售商的開發人員,負責管理購物車服務。您有一個用於正式環境的 Cloud SQL 執行個體,以及另一個用於測試環境的執行個體。您希望在執行個體處理的流量最低時進行維護,也就是週日午夜左右。此外,您也希望在年末節慶購物季的忙碌期間,略過維護作業。

在這種情況下,請將正式版執行個體的維護設定設為:

  • 維護期間:每週日凌晨 12:00 至 1:00 (美國東部時間)
  • 維護時間:Week 2
  • 拒絕維護期:11 月 1 日至 1 月 15 日。

測試環境的維護設定會完全相同,但維護時間會設為 Week 2。這樣一來,您就能在維護作業推出至正式環境前至少七天,在測試環境中執行維護版本的作業驗收測試。如果測試環境發生問題,您有時間診斷及修正問題,或設定拒絕維護期,確保正式環境不受影響。

即將進行維護作業的通知

您可以設定在排定維護作業前至少一週,收到即將進行維護的電子郵件通知。如要 設定通知的電子郵件篩選器,電子郵件標題為「Upcoming maintenance for your Cloud SQL instance instancename」(Cloud SQL 執行個體「instancename」即將進行維護作業)。

系統預設不會傳送維護通知。您必須選擇加入維護通知。您必須先選取維護期間,才能接收通知。

通知會傳送至與 Google 帳戶相關聯的電子郵件地址。無法設定自訂電子郵件別名 (例如團隊電子郵件別名)。

您選擇接收特定專案中,所有設有維護期間的 Cloud SQL 執行個體維護通知。每個執行個體會收到一則通知。系統不會針對唯讀副本傳送即將進行維護的通知。

您也可以在 Google Cloud 控制台查看即將進行的維護作業資訊。

  • 在「Instances」(執行個體) 清單的「Maintenance」(維護) 欄中,如果已排定維護作業,您會看到排定的開始日期和時間。您可以使用「Maintenance」一詞篩選執行個體清單,找出所有排定維護作業的執行個體。只有在專案中有一或多個執行個體排定維護作業時,系統才會顯示「Maintenance」(維護) 欄。如果未排定維護作業,系統會隱藏這個資料欄。
  • 在「執行個體詳細資料」頁面的「維護」窗格中。如果已排定維護作業,則「Upcoming」(近期) 下方會顯示預定開始日期和時間。
  • Google Cloud 控制台的「Logs Explorer」頁面。 使用「All logs name」(所有記錄名稱) 下拉式選單搜尋 maintenance-events,然後按一下「Apply」(套用)。如果執行個體已排定維護作業,記錄會顯示執行個體名稱和排定的維護作業開始時間。

其他維護作業通知

選擇接收維護通知後,您會收到特定事件的通知:

  • 即將進行排定的維護作業
  • 已開始維護
  • 已完成維護作業
  • 已取消維護作業

重新排定維護時間

如果執行個體有維護期間,您可以在排定的維護更新時間前,重新排定維護更新時間,最多可提前 24 小時。舉例來說,如果您要在排定的維護期間推出新服務,可能需要將維護更新延後到推出後的幾天。

重新安排維護更新作業時,有一些限制。Cloud SQL 傳送通知電子郵件後,會在七週的時間範圍內執行維護更新,避免與下次 Cloud SQL 維護更新重疊。舉例來說,如果您選取第 1 週或第 2 週的維護時間,則最多可將維護更新時間延後至原定日期後的 4 週 (28 天)。如果將執行個體的維護時間設為第 5 週,則只能將維護事件重新排定在原定日期後最多一週 (7 天) 內。您可以多次重新安排維護作業,只要重新安排的維護事件在您為執行個體設定的維護時間所定義的重新安排時間範圍內即可。

如要瞭解其他限制,請參閱「重新排程限制」。

您可以選擇以下幾種方式,排定新的維護期間:

  • 立即套用更新。您可以立即將更新套用至執行個體,不必等待排定的維護期間。在這種情況下,維護作業通常會在五分鐘內開始。
  • 重新安排時間。您可以透過下列兩種方式,延後排定的維護事件:

    • 下一個可用時段。這個選項會將維護作業延後至目前排定維護時間後的下一個可用維護期間,通常是一週後。
    • 特定時間。這個選項可讓您選擇特定時間,重新排定執行個體維護時間所定義的維護時間長度。
      • 如果選取第 1 週或第 2 週維護時間,則為 28 天
      • 如果選取第 5 週維護時間,則為 7 天

如需重新安排維護作業的操作說明,請參閱「重新安排預定的維護作業」。

維護作業的運作方式

為縮短維護時間,Cloud SQL 採用維護容錯移轉工作流程,與高可用性執行個體的自動容錯移轉工作流程大致相同。

簡而言之,步驟如下:

  1. 使用新軟體設定更新後的 VM。
  2. 停止原始 VM 上的資料庫。
  3. 將磁碟和靜態 IP 切換至更新後的 VM。
  4. 在更新後的 VM 上啟動資料庫。

逐步瀏覽下列分頁,查看工作流程的詳細資料,包括維護前和維護後。

維護前

在維護作業前,用戶端會透過靜態 IP 位址與原始 VM 通訊。資料會儲存在連接至原始 VM 的永久磁碟上。在本範例中,Cloud SQL 執行個體已設定高可用性,這表示另一個 VM 處於待命狀態,可在發生非預期中斷時接管。Cloud SQL 執行個體正在為應用程式提供流量。

圖表:維護前的狀態

步驟 1

設定新的 VM。

設定新的虛擬機器 (VM),並安裝最新的資料庫軟體和 VM 作業系統 (OS)。更新後的 VM OS 會啟動。此時,資料庫引擎尚未啟動。如果是高可用性執行個體,系統也會設定新的待命 VM。

在原始 Cloud SQL 執行個體仍處理流量時,在另一個 VM 上安裝軟體更新,可大幅縮短總停機時間。

設定 VM 的圖表

步驟 2

停止原始 VM 上的資料庫。

資料庫引擎會關閉,以便從原始 VM 卸載磁碟,並連接至更新後的 VM。關閉前,資料庫引擎會等待幾秒,讓進行中的交易提交,並讓現有連線的要求耗盡。之後,任何開啟或長時間執行的交易都會復原。資料庫會停止接受新的連線,並捨棄現有連線。執行個體會變成無法使用,並開始維護停機時間。

容錯移轉後的執行個體圖表

步驟 3

切換至更新後的 VM。

磁碟會從原始 VM 卸載,並連接至更新後的 VM。靜態 IP 位址會重新設定,指向更新後的 VM。這可確保應用程式在維護後使用與維護前相同的 IP 位址。資料庫快取會與原始 VM 一起循環,也就是說,資料庫快取會在維護期間有效清除。

切換至更新後 VM 的圖表

步驟 4

在更新後的 VM 上啟動資料庫。

更新後的資料庫引擎會在資料磁碟上啟動。使用通用資料磁碟,可確保維護前寫入原始執行個體的所有交易,在維護後仍存在於更新後的資料庫中。如果資料庫關閉期間,未完成的交易未完成復原,資料庫會自動進行當機復原,確保資料庫還原至可用狀態。

啟動更新後 VM 的圖表

維護後

完成步驟 4 後,Cloud SQL 執行個體即可接受連線,並恢復為應用程式提供流量。

對應用程式而言,除了軟體更新外,Cloud SQL 執行個體看起來都一樣。應用程式仍會使用相同的靜態 IP 位址連線至 Cloud SQL 執行個體,且更新後的 VM 會在與原始 VM 相同的可用區中運作。寫入原始資料庫的所有資料都會保留。

維護後圖表

盡可能降低維護作業的影響

一般來說, Google Cloud 建議在雲端執行應用程式的使用者,應讓系統能彈性因應暫時性錯誤,也就是因暫時無法使用而導致的短暫服務間通訊問題。在雲端環境中,偶爾發生暫時性錯誤是不可避免的。

維護期間可能發生的暫時性錯誤包括連線中斷和進行中的交易失敗。如果您設計系統並調整應用程式,使其能彈性應對暫時性錯誤,也能盡量減少資料庫維護作業造成的影響。

如要盡可能降低連線中斷的影響,可以使用連線集區。雖然維護期間會中斷集區與資料庫之間的連線,但應用程式與集區之間的連線會保留。這樣一來,應用程式就不必重新建立連線,而是由連線集區器負責。

如要減少交易失敗次數,可以限制長時間執行的交易數量。重寫查詢,使其更小、更有效率,不僅能減少維護停機時間,還能提升資料庫效能和可靠性。

如要有效率地從連線中斷和交易失敗中復原,您可以有效率地管理資料庫連線。您可以在應用程式和連線集區中,使用指數輪詢建立連線和查詢重試邏輯。如果查詢失敗或連線中斷,系統會先等待一段時間再重試,且每次重試的等待時間都會增加。舉例來說,系統可能會在第一次重試時等待幾秒,但在第四次重試時等待最多一分鐘。遵循這個模式可確保修正這些失敗,而不會使服務超載。

其他創意解決方案也能盡可能降低維護作業的影響,例如使用指令碼在維護後預熱資料庫快取,以及精簡資料庫中的資料表數量。建議您遵循資料庫管理最佳做法和操作指南,確保維護作業順利進行。

具時效性的維護作業

在極少數情況下,Cloud SQL 可能需要安排維護作業,不受維護設定限制,以便修補嚴重的穩定性問題或有時效性的安全漏洞。這類更新會快速完成,Cloud SQL 會將其計為服務水準協議的停機時間。

自助式維護

Cloud SQL 會定期發布軟體改善項目和安全漏洞修補程式,並提供新的維護版本,供您安裝在執行個體上。Cloud SQL 會為每個資料庫引擎主要版本維護 Cloud SQL 維護作業變更記錄。詳情請參閱「Cloud SQL 維護作業變更記錄」。

Cloud SQL 每隔幾個月會排定維護更新,確保您使用最新軟體。不過,在下列情況下,您可以使用自助式維護功能,讓執行個體保持最新狀態:

  • 您需要在下次排定的維護事件之前進行更新。
  • 您略過最近一次的維護更新,想趕上最新軟體版本。

如果您使用唯讀副本,則可透過自助式維護功能更新主要執行個體及其所有唯讀副本。您指定主要執行個體後,維護要求會將主要執行個體的所有唯讀副本更新至指定的維護版本。接著,主要執行個體會更新至維護版本。

維護限制

本節說明 Cloud SQL 維護作業的限制。

重新安排時間的限制

重新安排時間時,請注意以下事項:

  • 您必須在原定維護事件發生前至少 24 小時重新安排維護時間。

  • 您可以重新排定專案中一或多個執行個體的維護作業。不過,您一次只能重新排定一個執行個體 (無法大量重新排定)。

  • 您可以將維護作業重新排定在拒絕維護期內,甚至是維護期間以外的時間,只要重新排定的時間範圍在您為執行個體設定的維護時間定義的時間範圍內即可。

  • 如果維護作業正在進行,系統會延遲重新排程,直到作業完成。

拒絕維護期的限制

關於拒絕維護期,請留意下列事項:

  • 自 2025 年 8 月 15 日起,如果執行個體的維護版本推出超過 12 個月,就無法設定拒絕維護期。如果執行個體使用的維護版本超過 12 個月,就必須更新。如要查看執行個體上安裝的維護版本日期,請使用 gcloud sql instances describe 指令,或查看Google Cloud 控制台「Instance overview」(執行個體總覽) 頁面的「Maintenance」(維護) 區段。如要進一步瞭解如何查看執行個體的維護版本,請參閱「查看執行個體資訊」。如要判斷發布日期,請查看維護版本的名稱。舉例來說,如果維護版本的名稱是 SQLSERVER_2022_ENTERPRISE_CU14.R20250302.00_28,則對應的發布日期是 2025 年 3 月 2 日。

    如要更新執行個體,請執行自助式維護,或等待下個維護期間自動更新。更新執行個體後,即可設定拒絕維護期。

  • 即使未設定執行個體的維護期間,您仍可設定拒絕維護期。拒絕維護期可介於 1 到 90 天。

  • 拒絕維護期優先於任何排定的維護期間。如果維護期間與拒絕維護期衝突,則以拒絕維護期為準。

  • 拒絕維護期和維護時間是獨立的功能。如果為維護時間設為 Week 1 的執行個體建立拒絕維護期,則不會影響系統為維護時間設為 Week 2 的執行個體決定 排定更新時間。 如果排定的維護更新落在拒絕維護期內,Cloud SQL 就不會針對您設定維護時間的執行個體傳送通知。

  • 如果主要執行個體設有拒絕期間,與主要執行個體相關聯的所有副本也會拒絕維護。舉例來說,位於區域 A 的主要執行個體有三個唯讀副本:兩個在區域 A,一個在區域 B。在主要執行個體上設定拒絕期間後,各個副本 (包括區域 B 中的副本) 的維護作業,都會等到主要執行個體的拒絕期間到期後才會執行。

  • 如果在排定維護作業後設定拒絕維護期,導致拒絕維護期與排定的維護時間重疊,系統就會略過更新。

  • 只要在開始和結束日期參數中不包含年份,即可將拒絕維護期設為每年重複。如果指定年份,則拒絕維護期只會設定在該年份。

  • 一年內可設定多個拒絕維護期。不過,如果執行個體執行的維護版本已超過 12 個月,就無法設定拒絕維護期。請避免將拒絕期鏈結在一起,以略過連續的排定維護事件。請務必及時完成 Cloud SQL 維護作業,確保執行個體穩定運作。Cloud SQL 維護作業通常每幾個月排定一次。

  • 為確保服務穩定性,如果使用者執行個體執行的維護版本已超過 12 個月,Cloud SQL 會通知使用者必須進行下一次維護作業。

  • 拒絕維護期結束後,系統會恢復一般維護行為。

  • 拒絕維護期不會影響使用者觸發的操作,例如自助維護。

  • 停止、啟動或重新啟動執行個體後,拒絕維護期仍會繼續套用。如果執行個體處於有效的拒絕維護期,當您停止並啟動或重新啟動執行個體時,由於拒絕維護期仍有效,因此執行個體重新啟動時會略過任何排定的維護更新。

維護常見問題

維護停機時間是否會計入服務水準協議?

正常維護造成的停機時間不計入服務水準協議。不過,Cloud SQL 會將時效性維護停機時間計入服務水準協議。

維護作業對唯讀副本有何影響?

  • Cloud SQL 一律會先維護唯讀副本,再維護主要執行個體。如果主要執行個體有維護期間,唯讀副本也會遵循相同的維護期間。
  • 如果主要執行個體有多個唯讀副本,Cloud SQL 可能會同時更新部分副本。
  • 唯讀副本會遵循主要執行個體設定的拒絕維護期。

可以取消排定的維護作業嗎?

您無法取消排定的維護期間,但可以重新排定。您也可以設定與排定維護時間重疊的拒絕維護期,有效略過維護作業。

如果維護事件取消,會發生什麼事?

如果 Cloud SQL 取消維護事件,您會盡可能提前收到維護作業取消的通知。

重新安排維護事件後,您會收到即將進行維護的新通知。

Cloud SQL 維護作業會累計嗎?

維護作業更新會累計。您不必套用可能錯過的每個維護更新。最新的維護版本會在下次排定的維護更新中套用。或者,您也可以使用自助式維護功能,套用最新的維護更新。

如果執行個體在排定的維護更新期間停止,會發生什麼情況?

如果執行個體在排定的維護更新期間停止,Cloud SQL 會略過維護更新。不過,下次重新啟動執行個體時,Cloud SQL 會自動套用最新的維護更新。

主要執行個體的所有唯讀副本,需要多久時間才能完成自助式維護作業?

自助維護更新所需的時間,取決於主要執行個體的唯讀副本總數。如要縮短自助維護更新可能需要的時間,您可以個別更新幾個唯讀副本,然後在主要執行個體上執行更新,以更新其餘的唯讀副本。

第二次更新會略過已採用目標維護版本的副本。

如果主要執行個體有多個唯讀副本,可以只對其中一個執行自助式維護作業嗎?

可以,您可以對個別唯讀副本執行個體執行自助維護作業。不過,建議您盡快將其餘唯讀副本和主要執行個體更新至相同的維護版本。建議您在所有唯讀副本和主要執行個體上,使用相同的維護版本。

後續步驟