常見的最佳做法

本頁面提供最佳做法,有助您實現 Cloud SQL 的最佳效能、耐用性和可用性。

如果 Cloud SQL 執行個體發生問題,請在排解問題時查看下列項目:

執行個體設定與管理

最佳做法 更多資訊
請詳讀並遵守操作指南,以確保您的執行個體在 Cloud SQL 服務水準協議的涵蓋範圍內。
設定主要執行個體的維護期間,以便控制發生中斷型更新的時間。 請參閱維護期間
如果是需要讀取大量資料的工作負載,請新增唯讀備用資源,以分擔主要執行個體的流量。 也可以選擇使用 HAProxy 等負載平衡器來管理流往備用資源的流量。
如果您會定期刪除和重新建立執行個體,請使用執行個體 ID 中的時間戳記來提高新執行個體 ID 可用的可能性。
前一項作業完成之前,請勿開始進行管理作業。

Cloud SQL 執行個體要待到完成前一項作業後,才能接受新的作業要求。如果試圖提前啟動新作業,作業要求會失敗。重新啟動執行個體也包含在內。

Google Cloud 主控台中的執行個體狀態不會顯示作業是否正在執行。綠色勾號只代表執行個體的狀態為 RUNNABLE。如要查看是否正在執行作業,請前往「Operations」(作業) 分頁查看最新的作業狀態。

設定儲存空間,以因應重要的資料庫維護作業。

如果停用「enable automatic storage increases」(啟用自動增加儲存空間) 執行個體設定,或啟用「automatic storage increase limit」(自動增加儲存空間上限),請確保至少有 20% 的可用空間,以便容納 Cloud SQL 可能執行的任何重要資料庫維護作業。

如要在可用磁碟空間低於 20% 時收到警告,請為「磁碟使用率」指標建立以指標為基礎的警告政策,並將「高於門檻」位置的值設為「0.8」。詳情請參閱「建立以指標為基礎的快訊政策」。

避免 CPU 使用率過高。

您可以在 Google Cloud 控制台的執行個體詳細資料頁面,查看執行個體使用的可用 CPU 百分比。詳情請參閱「指標」。您也可以使用「建立指標門檻快訊政策」監控 CPU 使用率,並在達到指定門檻時接收快訊。

為避免過度使用,您可以增加執行個體的 CPU 數量。變更 CPU 需要重新啟動執行個體。如果執行個體已達 CPU 數量上限,則必須將資料庫分片至多個執行個體。

避免記憶體耗盡。

如要尋找記憶體耗盡的跡象,主要應使用「用量」指標。為避免記憶體不足錯誤,建議這個指標維持在 90% 以下。

您也可以使用 total_usage 指標,觀察 Cloud SQL 執行個體使用的可用記憶體百分比,包括資料庫容器使用的記憶體,以及作業系統快取分配的記憶體。

觀察這兩項指標的差異,即可判斷程序使用的記憶體量,以及作業系統快取使用的記憶體量。您可以在這個快取中重新利用記憶體。

如要預測記憶體不足問題,請同時檢查這兩項指標並一起解讀。如果指標顯示高值,執行個體可能記憶體不足。這可能是因為自訂設定、執行個體大小不符工作負載,或這些因素的組合所致。

調度 Cloud SQL 執行個體資源,增加記憶體大小。 變更執行個體的記憶體大小需要重新啟動執行個體。 如果執行個體已達記憶體大小上限,您必須將資料庫分片到多個執行個體。如要進一步瞭解如何在 Google Cloud 控制台中監控這兩項指標,請參閱「指標」一文。

確認執行個體具有最佳交易 ID。

如要在 Google Cloud 控制台的「指標探索器」頁面中,查看執行個體的交易 ID 用量,請將 Resource Type 設為 Cloud SQL Database,並將 Metric 設為 Percentage of instance's transaction IDs consumed。詳情請參閱「使用 Metrics Explorer 建立圖表」一文。

調整及監控資料庫執行個體,有助於減少或避免與清除相關的問題。監控執行個體的交易 ID 使用情況,並根據執行個體的工作負載啟用及調整 autovacuum 參數。詳情請參閱「克服交易 ID (TXID) 環繞 (wraparound) 防護錯誤」。

安全性

最佳做法 更多資訊
偏好使用私人 IP 除非需要公開 IP 存取權,否則建議使用私人 IP。這有助於盡量減少未經授權的網路連線連至資料庫。
避免在授權網路中使用 0.0.0.0/0 請避免在「已授權的網路」中加入 0.0.0.0/0,因為這樣會允許從全球網際網路無限制地存取。
避免授權網路過大 請避免在「授權網路」中使用小型 CIDR 前置字串,因為這可能會允許過多的主機存取。建議使用不小於 /16 的 CIDR 前置字元,最好大於 /19。
啟用密碼政策 使用執行個體密碼政策, 為資料庫執行個體指定適當的密碼政策,避免設定低強度密碼、設定有效期限,以及在登入嘗試失敗時設定帳戶鎖定。 如果您要為執行個體設定公開 IP,請特別注意這點。

資料架構

最佳做法 更多資訊
盡可能將大型執行個體分割為較小的執行個體。 請盡量使用多個小型 Cloud SQL 執行個體,效果會比使用單個大型的執行個體更好。大型單體式執行個體在管理上會比多個小型執行個體更困難。
請勿使用過多的資料庫資料表。

請將執行個體的表格數量控制在 10,000 個以下。資料庫資料表過多,會影響資料庫升級時間。

應用程式實作

最佳做法 更多資訊
使用適合的連線管理做法,例如連線集區和指數輪詢。 使用這些技術可改善應用程式的資源運用,也有助於遵守 Cloud SQL 連線限制。如需詳細資訊和程式碼範例,請參閱「管理資料庫連線」。
測試應用程式對維護更新的回應,更新在維護期間隨時可能會發生。 請嘗試自助式維護,模擬維護更新。維護期間,執行個體會短暫無法使用,現有連線也會中斷。測試維護作業推出,可協助您進一步瞭解應用程式如何處理排定的維護作業,以及系統的復原速度。
測試應用程式對於容錯移轉的回應,容錯移轉隨時可能發生。 您可以使用 Google Cloud 控制台、gcloud CLI 或 API 手動啟動容錯移轉。請參閱「啟動容錯移轉」。
避免進行大量交易。 盡量維持小型的簡短交易。如果需要更新大型資料庫,請分成多項小型交易進行,而非進行單次的大型交易。
如果使用 Cloud SQL 驗證 Proxy,請務必使用最新版本。 請參閱「保持 Cloud SQL 驗證 Proxy 的最新狀態」。

資料匯入與匯出

最佳做法 更多資訊
使用無伺服器匯出功能。 無伺服器匯出 會將匯出作業卸載至臨時執行個體,讓主要執行個體能繼續以正常效能處理查詢及執行作業。資料匯出完成後,系統會自動刪除暫時執行個體。
加速匯入小型執行個體。 針對較小的執行個體,您可以暫時增加執行個體的 CPU 和 RAM,以改善匯入較大資料集時的效能。
如果正在匯出資料以匯入至 Cloud SQL,請務必採用正確程序。 請參閱「 從外部代管的資料庫伺服器匯出資料」。

備份與還原

最佳做法 更多資訊
使用合適的 Cloud SQL 功能保護您的資料。

備份、時間點復原和匯出是提供資料備援和資料保護的方式。這兩種方式可在不同情境下各自提供保護,在健全的資料保護策略中下,兩者相輔相成。

建立備份既輕鬆又快速,能夠將執行個體上的資料還原至你在備份時的狀態。不過備份有一些限制。如果刪除執行個體,也會一併刪除備份。您無法備份單一資料庫或資料表。而且如果執行個體所在的地區無法使用,即使您身在可用的地區,也無法透過備份還原執行個體。

時間點復原功能可協助您將執行個體復原至特定時間點。舉例來說,如果發生錯誤導致資料遺失,您可以將資料庫復原到錯誤發生前的狀態。時間點復原一律會建立新的執行個體,您無法對現有的執行個體執行時間點復原。

匯出所需的時間較長,因為會在 Cloud Storage 建立外部檔案,讓您用來重新建立資料。即使刪除執行個體,也不會影響到匯出的資料。此外,您只能匯出單一資料庫或資料表,視您選擇的匯出格式而定。

調整執行個體大小,以因應交易 (二進位) 記錄檔保留作業。 如果資料庫的寫入活動頻繁,可能會產生大量交易 (二進位) 記錄檔,進而耗用大量磁碟空間,並導致已啟用自動增加儲存空間功能的執行個體磁碟空間增加。建議您根據交易記錄保留時間調整執行個體儲存空間大小。
避免執行個體和備份資料遭到意外刪除。

在 Google Cloud 控制台或透過 Terraform 建立的 Cloud SQL 執行個體,預設會啟用防止意外刪除功能。

使用 Cloud SQL 的匯出功能匯出資料,以獲得額外保護。搭配使用 Cloud Scheduler 和 REST API,自動管理匯出作業。如要處理更進階的情境,請搭配使用 Cloud Scheduler 和 Cloud Run functions 進行自動化。

調整及監控

調整及監控資料庫執行個體有助於減少或避免與清除相關的問題。

VACUUM 作業有不同變體,鎖定層級也不同:標準 VACUUMVACUUM FULLVACUUM FULL 選項可以回收更多磁碟空間,但會獨占鎖定表格,且執行速度緩慢。請改用標準形式的 VACUUM,這可與實際工作環境資料庫作業並行執行。使用 VACUUM 作業時,SELECT, INSERT, UPDATE, and DELETE 等指令仍會正常運作。在清除資料表的過程中,您無法使用 ALTER TABLE 等指令修改資料表定義。

以下提供幾項建議,有助於縮短完成 VACUUM 作業所需的時間:

  • 增加系統記憶體和 maintenance_work_mem。 這樣一來,每次疊代都會批次處理更多元組,並盡快完成工作。請注意,自動清除垃圾時,系統可能會分配高達 autovacuum_max_workers 倍的記憶體,因此請小心不要將預設值設得太高。
  • VACUUM 作業會產生大量預寫記錄 (WAL) 記錄。如果可以減少 WAL 記錄的數量 (例如未為這個執行個體設定任何副本),作業就會更快完成。
  • 如果資料表已達到 20 億個交易 ID 的上限,但沒有任何元組遭到凍結,請嘗試減少單一使用者模式下的工作量。其中一個可能選項是設定 vacuum_freeze_min_age=1,000,000,000 (允許的最大值,高於預設的 50,000,000)。這個新值最多可減少兩倍的凍結元組數量。
  • PostgreSQL 12.0 以上版本支援清除和 VACUUM 作業,不必清除索引項目。這點至關重要,因為清理索引需要完整掃描索引,如果有多個索引,總時間取決於索引大小。
  • 較大的索引會耗費大量時間進行索引掃描,因此建議使用 INDEX_CLEANUP OFF 快速清除及凍結表格資料。如果 PostgreSQL 版本低於 12.0,則需要調整索引數量。也就是說,如果存在非重要索引,則刪除 NON-CRITICAL 索引可能有助於加快清除作業。