本頁面說明 Cloud SQL 執行個體如何進行維護更新，以及如何控管這些更新的時間。如要開始使用，請參閱「查看及設定維護期間」。
總覽
Cloud SQL 這項代管服務會自動更新執行個體，確保基礎硬體、作業系統和資料庫引擎穩定、高效能、安全無虞和更新為最新版本。這類更新大多是在 Cloud SQL 執行個體啟動並運作時執行。不過，某些系統更新需要短暫中斷服務才能執行。這些更新稱為「維護」。
維護作業會更新資料庫引擎，有時也會更新作業系統。由於這些更新需要重新啟動執行個體，因此會導致停機。維護更新可帶來下列好處：
Cloud SQL 功能。為了推出新功能，資料庫引擎會更新，並安裝新的資料庫外掛程式。
資料庫版本升級。開發 PostgreSQL 的資料庫軟體供應商每年會發布數次新的子版本。每個新版本都會修正錯誤、提供安全性修補程式、提升效能，並推出新的資料庫功能。如要查看 PostgreSQL 適用的 Cloud SQL 支援的最新子版本，請參閱版本資訊或資料庫版本和版本政策。Cloud SQL 執行個體會在最新資料庫版本發布後不久升級，讓您能執行最新的資料庫軟體。
作業系統修補程式。我們會持續監控作業系統中新發現的安全漏洞。一旦發現，我們會修補作業系統，保護您免受新風險的影響。
維護作業影響
如果是 Cloud SQL Enterprise Plus 版本，Cloud SQL 會提供幾乎無須停機的預定維護。
Cloud SQL 通常每幾個月會排定一次維護更新事件。每個執行個體的維護更新作業約需 5 到 10 分鐘。如果執行個體有唯讀副本，維護更新作業的整體時間可能會更長。不過，在維護更新事件期間，每個 Cloud SQL Enterprise 版本執行個體平均會中斷連線不到 30 秒。如果執行個體在維護更新期間有大量活動，或資料集非常龐大，停機時間可能會更長。
您可以採取一些步驟，確保維護作業對營運的影響降到最低，例如使用維護設定，以及讓系統能彈性因應暫時性錯誤。
預定維護作業幾乎無需停機
Cloud SQL Enterprise Plus 版本執行個體在預定維護期間，通常只會中斷連線不到 1 秒，幾乎不會停機。
如果執行個體在維護期間活動頻繁，停機時間可能會更長。
必要條件和限制
- 不支援唯讀副本。
如果您使用 Cloud SQL Auth Proxy 或 Cloud SQL 語言連接器，請務必更新至最新版本。
預定維護作業完成後，所有未記錄的資料表都會清空。
- 維護期間，資料庫記錄會顯示來自兩個不同 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。這樣一來，您就能在維護作業正式推出前至少七天，在測試環境中執行維護版本的作業驗收測試。如果測試環境發生問題，您有時間診斷及修正問題，或設定拒絕維護期，確保正式環境不受影響。
即將進行維護作業的通知
您可以設定在排定維護作業前至少一週，收到即將進行維護的電子郵件通知。如要設定通知的電子郵件篩選器，電子郵件標題為「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 採用維護容錯移轉工作流程，與高可用性執行個體的 自動容錯移轉工作流程大致相同。
簡而言之，步驟如下：
- 使用新軟體設定更新後的 VM。
- 停止原始 VM 上的資料庫。
- 將磁碟和靜態 IP 切換至更新後的 VM。
- 在更新後的 VM 上啟動資料庫。
逐步瀏覽下列分頁，查看工作流程的詳細資料，包括維護前和維護後。
維護前
在維護作業前，用戶端會透過靜態 IP 位址與原始 VM 通訊。資料會儲存在連接至原始 VM 的永久磁碟上。在本範例中，Cloud SQL 執行個體已設定高可用性，這表示另一個 VM 處於待命狀態，可在發生非預期中斷時接管。Cloud SQL 執行個體會將流量提供給應用程式。
步驟 1
設定新的 VM。
設定新的虛擬機器 (VM)，並安裝最新的資料庫軟體和 VM 作業系統 (OS)。更新後的 VM OS 會啟動。此時，資料庫引擎尚未啟動。如果是高可用性執行個體，系統也會設定新的待命 VM。
在原始 Cloud SQL 執行個體仍處理流量時，在另一個 VM 上安裝軟體更新，可大幅縮短總停機時間。
步驟 2
停止原始 VM 上的資料庫。
資料庫引擎會關閉，以便從原始 VM 卸載磁碟，並連接至更新後的 VM。關閉前，資料庫引擎會等待幾秒，讓進行中的交易提交，並讓現有連線的要求耗盡。之後，任何開啟或長時間執行的交易都會復原。資料庫會停止接受新的連線，並捨棄現有連線。執行個體會變成無法使用，並開始維護停機時間。
步驟 3
切換至更新後的 VM。
磁碟會從原始 VM 卸載，並連接至更新後的 VM。靜態 IP 位址會重新設定，指向更新後的 VM。這可確保應用程式在維護後使用與維護前相同的 IP 位址。資料庫快取會與原始 VM 一起循環，也就是說，資料庫快取會在維護期間有效清除。
步驟 4
在更新後的 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」(維護) 部分。如要進一步瞭解如何查看執行個體的維護版本，請參閱「查看執行個體資訊」。如要判斷發布日期，請查看維護版本的名稱。舉例來說，如果維護版本的名稱是POSTGRES_16_9.R20250302.00_31，則對應的發布日期是 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 會略過維護更新。不過，下次重新啟動執行個體時，Cloud SQL 會自動套用最新的維護更新。
主要執行個體的所有唯讀副本，自助維護作業需要多久時間？
自助式維護更新所需的時間，取決於主要執行個體的唯讀副本總數。如要縮短自助式維護更新可能需要的時間，您可以個別更新幾個唯讀副本，然後在主要執行個體上執行更新，以更新其餘的唯讀副本。
第二次更新會略過已採用目標維護版本的副本。
如果主要執行個體有多個唯讀副本，可以只對其中一個執行自助維護作業嗎？
可以，您能對 個別唯讀副本執行個體執行自助維護作業。不過，建議您在不久後將其餘唯讀副本和主要執行個體更新至相同的維護版本。建議您在所有唯讀副本和主要執行個體上，使用相同的維護版本。