本頁說明 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 秒，停機時間幾乎為零。
如果執行個體在維護期間的活動量較高，停機時間可能會較長。
必要條件和限制
PostgreSQL 適用的 Cloud SQL Enterprise Plus 版本執行個體上的讀取副本數量，必須小於為
max_wal_senders和max_replication_slots旗標設定的值。詳情請參閱設定資料庫標記。如果使用 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 點至凌晨 1 點 (美國東部時間)
- 維護時間：
Week 2 - 拒絕維護期：11 月 1 日至 1 月 15 日。
除了維護時間設為 Week 2 之外，預先發布環境的維護設定完全相同。這樣一來，您就能在維護作業推出至正式環境前，至少提前七天在預先發布環境中，對維護版本執行作業驗收測試。如果暫存環境發生問題，您有時間診斷及修正問題，或設定拒絕維護期，確保實際運作環境不受影響。
即將進行維護作業的通知
您可以設定在預定維護作業開始前至少一週，透過電子郵件接收通知。如要為通知設定電子郵件篩選器，電子郵件標題為「Cloud SQL 執行個體『執行個體名稱』即將進行維護作業」。
系統預設不會傳送維護通知。你必須選擇接收維護通知。 此外，您必須選取維護時段，才能收到通知。
系統會將通知寄到與你 Google 帳戶連結的電子郵件地址。你無法設定自訂電子郵件別名 (例如團隊電子郵件別名)。
您可以選擇接收特定專案中，所有設有維護期間的 Cloud SQL 執行個體維護通知。每個執行個體會收到一則通知。系統不會針對唯讀副本傳送即將進行維護作業的通知。
您也可以在 Google Cloud 控制台中查看即將進行的維護作業資訊。
- 在「Instances」(執行個體) 清單的「Maintenance」(維護) 欄中，如果已排定維護作業，系統會顯示排定的開始日期和時間。您可以使用「維護」一詞篩選執行個體清單，找出所有排定維護作業的執行個體。只有在專案中一或多個執行個體排定維護作業時，才會顯示「維護」欄。如果沒有排定維護作業，系統會隱藏該欄。
- 在「維護」窗格的「執行個體詳細資料」頁面中。如果已排定維護作業，系統會在「即將進行」下方顯示排定的開始日期和時間。
前往 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 小時，重新安排維護時間。
您可以重新排定專案中一或多個執行個體的維護作業。但一次只能重新排定一個執行個體 (無法大量重新排定)。
只要重新安排的維護作業時間在您為執行個體設定的維護時間範圍內，您就能將維護作業重新安排到拒絕維護期內，甚至是維護期間外。
如果正在進行維護作業，系統會延後重新排定時間，直到作業完成為止。
拒絕維護期的限制
拒絕維護期有幾項須知事項：
即使您未為執行個體設定維護期，也可以設定拒絕維護期。拒絕維護期可從 1 天到 90 天不等。
拒絕維護期優先於任何排定的維護期。如果維護期間與拒絕維護期發生衝突，系統會優先採用拒絕維護期。
拒絕維護期和維護時間是獨立的功能。如果您為具有
Week 1維護時間的執行個體建立拒絕維護期，這不會影響具有Week 2維護時間的執行個體排定更新作業。如果排定的維護更新落在拒絕維護期間內，Cloud SQL 就不會針對您已設定維護時間的執行個體傳送通知。如果主要執行個體設定了拒絕維護期，與主要執行個體相關聯的所有副本也會拒絕維護。舉例來說，位於 A 地區的主要執行個體有三個唯讀備用資源：兩個位於 A 地區，一個位於 B 地區。如果主要執行個體設定了拒絕維護期，系統不會對每個備用資源 (包括 B 區域的備用資源) 進行維護，直到主要執行個體的拒絕維護期結束為止。
如果在排定維護作業後設定拒絕維護期，且該期間與排定的維護時間重疊，系統就會略過更新。
如要在開始和結束日期參數中排除年份，可以將拒絕維護期設為每年重複。如果指定年份，系統只會為該年設定拒絕維護期。
您可以在一年內設定多個拒絕維護時段。建議您避免將拒絕期串連在一起，以免略過連續的排定維護事件。請務必掌握 Cloud SQL 維護作業的最新資訊，確保執行個體運作無虞。通常 Cloud SQL 維護作業每隔幾個月就會排定一次。
為確保服務可靠性，如果執行個體執行的維護版本已超過 12 個月，Cloud SQL 可能會通知使用者，下次必須推出維護版本。
拒絕維護期結束後，系統會恢復正常維護作業。
拒絕維護期不會影響使用者觸發的作業，例如自助式維護。
維護作業常見問題
- 維護停機時間是否會計入服務水準協議？
- 維護作業對唯讀副本有何影響？
- 可以取消預定維護作業嗎？
- 如果維護事件取消，會發生什麼情況？
- Cloud SQL 維護作業是否會累積？
- 如果執行個體在排定的維護更新期間停止，會發生什麼情況？
- 主要執行個體的所有唯讀備用資源完成自助式維護作業需要多久時間？
- 如果主要執行個體有多個唯讀備用資源，可以對單一唯讀備用資源執行自助式維護作業嗎？
維護停機時間是否會計入服務水準協議？
正常維護作業造成的停機時間不會計入服務水準協議。不過，Cloud SQL 會將時間敏感型維護作業的停機時間計入服務水準協議。
維護作業對唯讀副本有何影響？
- Cloud SQL 一律會維護主要執行個體之前的唯讀備用資源。如果主要執行個體有維護期間，唯讀副本也會遵守相同的維護期間。
- 如果主要執行個體有多個唯讀備用資源，Cloud SQL 可能會同時更新部分備用資源。
- 唯讀備用資源會遵守為主要執行個體設定的拒絕維護期。
我可以取消預定維護作業嗎？
您無法取消排定的維護期間，但可以重新排定。您也可以設定與排定維護時間重疊的拒絕維護週期，有效略過維護作業。
如果維護活動取消，會怎麼樣？
如果 Cloud SQL 取消維護事件，系統會盡可能提前通知您維護作業已取消。
如果維護作業重新排程，您會收到新的通知。
Cloud SQL 維護作業是否會累積？
維護更新是累加的。您不必套用可能錯過的每個維護更新。系統會在下次排定的維護更新中，套用最新的維護版本。或者，您也可以使用自助式維護功能，套用最新的維護更新。
如果執行個體在排定的維護更新期間停止，會發生什麼情況？
如果執行個體在排定的維護更新期間停止運作，Cloud SQL 會略過維護更新。不過，下次重新啟動執行個體時，Cloud SQL 會自動將執行個體更新至最新維護版本。
主要執行個體的所有唯讀備用資源完成自助式維護作業需要多久時間？
自助式維護更新作業所需時間，取決於主要執行個體的唯讀備用資源總數。如要縮短自助式維護更新作業所需的時間，您可以個別更新幾個唯讀副本，然後對主要執行個體執行更新，以更新其餘的唯讀副本。
第二次更新時，系統會略過已採用目標維護版本的備用資源。
如果主要執行個體有多個唯讀備用資源，是否可以對單一唯讀備用資源執行自助式維護作業？
可以，您可以在 個別唯讀備用資源執行個體上執行自助式維護作業。不過，建議您在不久後將其餘唯讀副本和主要執行個體更新至相同維護版本。建議您以相同的維護版本運作所有唯讀副本和主要執行個體。