本頁說明 Cloud SQL 執行個體的維護更新作業,以及如何控管這些更新的時間。如要開始使用,請參閱「尋找及設定維護期間」。
總覽
Cloud SQL 是一種代管服務,會自動更新執行個體,確保基礎硬體、作業系統和資料庫引擎穩定、高效能、安全無虞和更新為最新版本。這類更新大多是在 Cloud SQL 執行個體啟動並運作時執行。不過,某些系統更新需要短暫的服務中斷才能執行。這類更新稱為維護作業。
維護作業會更新資料庫引擎,在某些情況下也會更新作業系統。由於這些更新需要重新啟動執行個體,因此會造成停機時間。維護更新可帶來下列優點:
Cloud SQL 功能為了推出新功能,資料庫引擎會更新,並安裝資料庫的新外掛程式。
資料庫版本升級開發 PostgreSQL 的資料庫軟體供應商每年會發布幾次新的次要版本。每個新版本都會提供錯誤修正、安全性修補程式、效能提升和新的資料庫功能。您可以查看發布說明或資料庫版本和版本政策,瞭解 Cloud SQL for PostgreSQL 支援的最新次要版本。Cloud SQL 執行個體會在發布後不久升級至最新的資料庫版本,讓您能享有執行最新資料庫軟體的好處。
作業系統修補程式。我們會持續監控作業系統中新發現的安全漏洞。一旦發現,我們就會修補作業系統,保護您免受新風險威脅。
維護作業影響
對於 Cloud SQL Enterprise Plus 版本,Cloud SQL 提供幾乎無停機時間的預定維護服務。
Cloud SQL 通常會每隔幾個月安排一次維護更新事件。每個執行個體的維護更新作業可能需要 5 到 10 分鐘。如果執行個體有唯讀備用資源,維護更新的整體時間可能會更長。不過,在維護更新事件期間,每個 Cloud SQL Enterprise 版執行個體的連線中斷時間平均不到 30 秒。如果執行個體在維護更新事件期間有大量活動,或擁有非常大的資料集,停機時間可能會更長。
您可以採取一些措施,確保維護作業對營運的影響降到最低,方法是使用我們的維護設定,並讓系統具備抵抗暫時性錯誤的韌性。
預定的維護作業幾乎無需停機
在預定維護作業中,Cloud SQL Enterprise Plus 版執行個體的停機時間通常會縮短到不到 1 秒。
如果執行個體在維護期間的活動量較高,停機時間可能會更長。
必要條件和限制
Cloud SQL for PostgreSQL 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 執行個體,以及一個用於測試環境的 Cloud SQL 執行個體。您希望維護作業在執行個體處理流量最少的時間執行,也就是星期日午夜時分。您也應該在繁忙的年底節慶購物季期間,略過維護作業。
在這種情況下,您可以將正式版執行個體的維護設定設為:
- 維護期間:週日凌晨 12 點至凌晨 1 點 (美國東部時間)
- 維護時間:
Week 2
- 拒絕維護期:11 月 1 日至 1 月 15 日。
除了維護時間設為 Week 2
以外,測試環境的維護設定會完全相同。這樣可確保您在維護作業推出正式版前,至少能在測試環境中為維護版本執行營運驗收測試七天。如果暫存環境發生問題,您有時間診斷並修正問題,或是設定拒絕維護期間,讓實際運作環境不受影響。
即將執行維護作業的通知
您可以設定在預定維護作業開始前至少一週,系統會將即將進行的維護作業通知傳送到您的電子郵件。如果您想為通知設定電子郵件篩選器,電子郵件標題為「Cloud SQL 執行個體 instancename 即將進行維護作業」。
根據預設,系統不會傳送維護通知。您必須選擇接收維護通知。您必須先選取維護期間,才能收到通知。
通知會傳送到與 Google 帳戶相關聯的電子郵件地址。無法設定自訂電子郵件別名 (例如團隊電子郵件別名)。
您可以選擇在特定專案中,為所有有維護期間的 Cloud SQL 執行個體啟用維護通知。每個執行個體會收到一則通知。系統不會針對唯讀備用資料庫傳送即將進行的維護作業通知。
您也可以在 Google Cloud 控制台中查看即將進行的維護作業資訊。
- 在「Instances」清單的「Maintenance」欄中,如果已排定維護作業,您會看到排定開始維護作業的日期和時間。您可以使用「Maintenance」這個字詞篩選執行個體清單,找出所有已排定維護作業的執行個體。只有在專案中一或多個執行個體排定維護作業時,系統才會顯示「維護」欄。如果沒有排定維護作業,資料欄就會隱藏。
- 在「Maintenance」窗格中的「Instance details」頁面。如果已排定維護作業,您會在「即將進行」下方看到排定開始維護作業的日期和時間。
在 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 作業系統 (OS) 設定新的虛擬機器 (VM)。已啟動更新後的 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 維護作業的時間安排為每隔幾個月一次。
為確保服務可靠性,Cloud SQL 可能會通知執行維護版本的執行個體使用者,請在下次維護版本推出時進行更新。
拒絕維護期結束後,系統會恢復一般維護行為。
拒絕維護期不會影響使用者觸發的作業,例如自助維護。
維護常見問題
- 維護期間是否會計入服務水準協議?
- 維護作業對唯讀備用資源有何影響?
- 我可以取消預定的維護作業嗎?
- 如果維護事件遭到取消,會發生什麼情況?
- Cloud SQL 維護作業是否會累積?
- 如果在例行維護更新期間停止執行個體,會發生什麼情況?
- 主要執行個體的所有唯讀備用資源自助式維護作業需要多久時間?
- 如果主要執行個體有多個唯讀備用資源,我可以針對單一唯讀備用資源進行自助維護嗎?
維護作業的停機時間是否會計入服務水準協議?
正常維護作業的停機時間不會計入服務水準協議。不過,Cloud SQL 會將時間敏感的維護作業停機時間計入服務水準協議。
維護作業對唯讀備用資源有何影響?
- Cloud SQL 一律會先維護主要執行個體的唯讀備用資源。如果主要執行個體有維護期間,唯讀副本也會採用相同的維護期間。
- 如果主要執行個體有多個唯讀備用資源,Cloud SQL 可能會同時更新部分備用資源。
- 唯讀備用資源會遵循主要執行個體的拒絕維護期設定。
我可以取消預定的維護作業嗎?
您無法取消已排定的維護期間,但可以重新排定。您也可以設定與排定維護時間重疊的拒絕維護期間,有效地略過維護作業。
如果維護事件取消,會發生什麼事?
如果 Cloud SQL 取消維護事件,您會收到通知,說明維護作業已取消 (如果可行)。
維護事件重新排定後,您會收到即將進行的維護作業通知。
Cloud SQL 維護作業是否會累積?
維護更新是累積的,您不需要套用可能遺漏的每項維護更新。最新的維護版本會在下次排定的維護更新中套用。或者,您也可以使用自助式維護套用最新的維護更新。
如果執行個體在預定維護更新期間停止運作,會發生什麼情況?
如果執行個體在預定維護更新期間停止,Cloud SQL 會略過維護更新。不過,下次重新啟動執行個體時,Cloud SQL 會自動使用最新的維護更新來更新執行個體。
主要執行個體的所有唯讀備用資源自助式維護作業需要多久?
自助維護更新作業所需的時間長短,取決於主要執行個體的唯讀備用資源總數。為縮短自助維護更新作業所需的時間,您可以個別更新幾個唯讀備用資源,然後在主要執行個體上執行更新作業,以便更新其餘的唯讀備用資源。
第二次更新會略過已擁有目標維護作業版本的備用資源。
如果我有主要執行個體的多個唯讀備用資源,是否可以針對單一唯讀備用資源進行自助維護?
可以,您可以對 個別唯讀備用資源執行個體執行自助維護作業。不過,建議您盡快將其他唯讀副本和主要執行個體更新為相同的維護版本。建議您讓所有唯讀副本和主要執行個體使用相同的維護作業版本。