配額與限制

本頁提供 Cloud SQL 配額與限制的相關資訊。配額適用於專案層級；限制則視本身特性，可能適用於執行個體，也可能適用於專案層級。

配額

配額會限制 Google Cloud 專案可使用的 Google Cloud 資源數量，Cloud SQL 就是這類資源。

Cloud SQL 的配額系統具備以下功能：

  • 監控 Cloud SQL 執行個體的使用情形或用量
  • 限制這些執行個體的用量，原因包括確保公平性，以及減少用量劇烈波動的情況
  • 維護自動強制執行指定限制的設定
  • 提供配額變更或申請管道

如果超過配額，系統通常會立即封鎖相關執行個體的存取權，您嘗試執行的工作也會失敗。配額會套用至各個 Google Cloud 專案，並由使用該專案的所有執行個體共用。

檢查及提高配額的權限

如要查看及提高配額，您必須具備下列權限：

根據預設，編輯者和擁有者這些基本 IAM 角色，以及預先定義的配額管理員角色，都擁有這些權限。如需其他權限，請與配額管理員聯絡。

查看配額

如要查看專案中資源目前的配額，請前往Google Cloud 控制台的「Quotas」(配額) 頁面，然後篩選「Cloud SQL Admin API」。這些配額僅適用於 API 呼叫，不含資料庫查詢。

提高配額

隨著您的 Google Cloud 使用量增加，配額也會隨之提高。如果您預期用量將有顯著增長，請提早幾天提出要求，確保配額充足。

申請提高配額不會產生任何費用。除非使用的資源更多，否則費用不會增加。

如要提高配額，請按照下列步驟操作：

  1. 前往 Google Cloud 控制台的「Quotas」(配額) 頁面。

    前往「配額」頁面

  2. 篩選 Cloud SQL Admin API 服務。

    如果找不到這項服務，請啟用 Cloud SQL Admin API。

  3. 找出要變更的配額，勾選旁邊的核取方塊，然後按一下「編輯配額」。

  4. 針對您選取的每個配額，在「New limit」(新增限制) 欄位中，輸入所需限制的值。

  5. 在「Reason description」(原因說明) 欄位中，輸入要求增加配額的原因，然後按一下「Done」(完成)。

  6. 點選「下一步」。

  7. 填寫姓名、電子郵件地址和電話號碼，然後按一下「提交要求」。

    如果無法提高配額，請提交客服案件。

資源配額的補充方式

每日配額會在太平洋時間午夜重設。

配額與資源可用性

在資源供應無虞的前提下，資源配額指的是您能夠建立特定類型資源的數量上限。配額並無法保證您隨時可以使用這些資源，如果某區域沒有實體資源，您就無法建立該類型的新資源，即使專案中仍有剩餘配額亦然。

頻率配額

Cloud SQL 支援頻率配額，也稱為頻率限制或 API 配額。頻率配額定義了您可以向 Cloud SQL Admin API 發出的要求數量。

每個頻率配額都對應到一或多個 Cloud SQL Admin API 方法類別的所有要求。頻率配額會在 Cloud SQL 特定的時間間隔後重設 (例如每分鐘的 API 要求數量)。

使用 gcloud CLI 或 Google Cloud 控制台時，您會向 Cloud SQL Admin API 發出要求，這些要求會計入頻率配額。如果您使用服務帳戶存取 API，這些要求也會計入頻率配額。

Cloud SQL 會每隔 60 秒自動強制執行及補充頻率配額。如果專案在 60 秒內達到頻率配額上限，您必須等待該配額重新填滿，才能在該類別中提出更多要求。如果專案超出這項限制，您會收到 HTTP 429 狀態碼，原因為 rateLimitExceeded。

Cloud SQL Admin API 分為下列類別：

  • 連線：查詢連線至 Cloud SQL 資料庫所需的值。
  • Get：擷取資源的相關資訊 (例如執行個體、作業或備份)。
  • List：列出資源。
  • 變動：建立、修改及刪除資源。
  • 每個區域的預設值：與 Cloud SQL 執行個體互動，無須連線、擷取、列出或變動該執行個體。
  • 預設：列出 Cloud SQL 執行個體的資料庫旗標和機型 (層級)。這個類別的 API 適用於全球。

Cloud SQL 會針對每個類別，為每位使用者和每個區域設定每分鐘的速率配額。Cloud SQL 會針對這些屬性的每個不重複組合，分別設定頻率限制。

Cloud SQL Admin API 會產生詳細指標，協助您追蹤 API 用量、監控 Cloud SQL 執行個體和 API 的效能，以及找出執行個體和 API 之間的問題。詳情請參閱「監控 API 用量」。

下表提供各類別的指標、API 和預設限制資訊：

類別 指標 API 預設限制
連結

sqladmin.googleapis.com/connect

每位使用者在每個區域每分鐘提出的要求數量，用於使用這個類別的 API。

 1000
取得

sqladmin.googleapis.com/get

每位使用者在每個區域每分鐘可提出的要求數量，用於使用這個類別中的 API。

 500
清單

sqladmin.googleapis.com/list

每位使用者在每個區域，每分鐘可發出多少要求，以使用這個類別的 API。

 500
更改

sqladmin.googleapis.com/mutate

每位使用者在每個區域每分鐘可提出的要求數量，用於使用這個類別中的 API。

 180
每個區域的預設值

sqladmin.googleapis.com/
default_per_region

每位使用者在每個區域每分鐘可發出的預設區域要求數量，用於使用這個類別的 API。

 180
預設

sqladmin.googleapis.com/default

每位使用者每分鐘發出的預設要求數，可用於使用這個類別的 API。

 180

排解頻率限制錯誤

Cloud SQL 會依每分鐘、每位使用者和每個區域強制執行頻率配額，因此 Google Cloud 控制台的「Cloud Quotas」(Cloud 配額) 頁面不會顯示每位使用者的配額用量。如果單一使用者或服務帳戶用盡每位使用者的速率配額，Cloud SQL Admin API 會傳回 HTTP 429 Too Many Requests 狀態碼，並附上 rateLimitExceeded 原因。在這種情況下，「Cloud Quotas」頁面上的匯總專案層級配額指標，可能會顯示配額仍可用。

如要診斷哪個使用者或服務帳戶耗盡每位使用者的頻率限制，請完成下列步驟：

  1. 在 Google Cloud 控制台中，選取啟動 Cloud SQL 要求的消費者專案，然後前往「指標探索工具」頁面。
  2. 按一下「Select a metric」(選取指標)，然後在篩選列中輸入 serviceruntime.googleapis.com/api/request_count。在 子選單中，依序選取 「Consumed API」>「API」> 「Request count」，然後點選 「套用」。
  3. 在「Filter」(篩選器) 元素中，新增下列篩選器來找出遭到節流的請求：
    1. 按一下「新增篩選器」，然後選取 response_code。在篩選器對話方塊中，將「比較子」設為「= (等於)」，在「值」欄位中輸入 429，然後按一下「套用」。
    2. 再次按一下「新增篩選條件」，然後選取「service」。將「Comparator」(比較子) 設為「= (equals)」(= (等於))，在「Value」(值) 欄位中輸入 sqladmin.googleapis.com，然後點選「Apply」(套用)。
    3. 選用：如要依特定 API 方法篩選，請按一下「Add filter」(新增篩選器)，然後選取「method」。將「比較子」設為「= (等於)」，在「值」欄位中輸入方法名稱 (例如 google.cloud.sql.v1.SqlInstancesService.Get)，然後按一下「套用」。
  4. 在「Aggregation」(匯總) 元素中，確認第一個選單已設為「Sum」(總和)，然後在第二個選單 (「by」(依據) 旁邊) 選取 credential_id，依個別憑證將要求計數分組。
  5. 在結果中，找出 429 回應代碼數量最多的憑證 ID (credential_id)。這個值是服務帳戶或使用者憑證的 OAuth 2.0 用戶端 ID，這些憑證已用盡每位使用者的速率限制。
  6. 如要找出與該用戶端 ID 對應的服務帳戶，請前往Google Cloud 控制台的「Service accounts」(服務帳戶) 頁面，然後在篩選器方塊中輸入 OAuth 2.0 用戶端 ID。相符的項目就是耗盡每位使用者頻率限制的服務帳戶。

找出服務帳戶後，請採取下列一或多項緩解措施，解決錯誤：

  • 實作用戶端快取：如果應用程式經常輪詢執行個體中繼資料 (例如在容器重新啟動或健康狀態檢查期間)，請快取執行個體中繼資料，避免重複呼叫 SqlInstancesService.Get。
  • 套用指數輪詢：確保用戶端重試邏輯使用指數輪詢和抖動，避免傳送超出速率限制的大量要求。
  • 在服務帳戶之間分配工作負載：如果多個工作負載共用單一服務帳戶或消費者專案，請為每個工作負載建立專屬服務帳戶，避免某個工作負載耗用共用配額。
  • 要求調整配額：如果應用程式需要更高的處理量，請要求提高 Cloud SQL Admin API 頻率配額。

限制

部分 Cloud SQL 資源設有限制，不會定期補充，也不會顯示在 Google Cloud 控制台的「配額」頁面。您可以要求放寬某些資源的限制，但有些限制無法更動。

可調整的限制

每項專案的執行個體數

單一專案中的執行個體數量上限取決於這些執行個體的網路架構：

  • 新版 SQL 網路架構：每項專案最多可有 1,000 個執行個體。
  • 舊版 SQL 網路架構：每個專案最多可有 100 個執行個體。
  • 同時使用兩種架構：上限介於 100 到 1,000 之間，視執行個體在兩種架構中的分配情形而定。

提交客服案件，要求提高配額。唯讀副本會計為執行個體。

建議您將執行個體數量分配到多個專案，減少對配額提高要求的依賴。這有助於避免任何潛在的阻礙。

並行連線數上限

您可以使用 max_connections 標記設定連線限制。建立 MySQL 適用的 Cloud SQL 執行個體時，您需要選擇機型，這會決定記憶體容量。可用記憶體量會決定執行個體的連線限制。

如要查看執行個體的連線數量限制，請連線至資料庫並執行下列指令： SHOW VARIABLES LIKE "max_connections";

注意事項

Cloud SQL 連接器的配額用量

Cloud SQL Auth Proxy 和其他 Cloud SQL 連接器會使用 Cloud SQL Admin API 的配額。Cloud SQL 連接器大約每小時會執行一次重新整理作業。這項重新整理作業會發出兩次 API 呼叫。一個呼叫會擷取執行個體中繼資料，另一個呼叫則會擷取臨時憑證。

配額用量的計算方式如下：

Quota usage = connector processes running * instances * 2 API calls per hour

舉例來說，假設您有三個程序執行連接器，連接器設定為連線至兩個 Cloud SQL 執行個體，且一小時內發出兩次 API 呼叫，則配額用量為 12 (3 個程序 * 2 個執行個體 * 2 次 API 呼叫)。

如果您剛開始使用 Cloud SQL，請記住上述公式，並注意以下事項：

  • 擴充新資料庫用戶端的速度

  • 新增執行個體的速度

  • 為每個應用程式使用不同的服務帳戶

Cloud SQL IAM 資料庫驗證

每個執行個體每分鐘都有登入配額，包括成功和失敗的登入。超過配額時，系統會暫時停用登入功能。建議您避免頻繁登入，並使用授權網路限制登入。 每個執行個體的登入授權配額為每分鐘 12,000 次。

轉送規則配額

每個 Cloud SQL 執行個體都包含轉送規則和負載平衡器。轉送規則的配額限制取決於指向的負載平衡器類型。每項專案、網路和對等群組，對各類轉送規則都有多項配額。Cloud SQL 也有每個網路配額和每個對等群組配額的覆寫規則。也就是說，當我們提高供應商網路的每個網路配額時，每個對等群組的配額也會提高到相同的值。

Cloud SQL 供應商虛擬私有雲與客戶的虛擬私有雲對接，因此 Cloud SQL 供應商網路和客戶虛擬私有雲的對等互連群組，經常會達到個別網路配額。

達到配額上限時，某些作業可能會失敗，包括：

  • 建立作業：建立新執行個體時，需要新的轉送規則。

  • 更新作業：我們允許客戶切換執行個體的網路，因此需要在新網路中設定新的轉送規則。

  • 維護作業：重新建立轉送規則。

為避免發生問題，建議您將每個網路的執行個體總數限制在 500 個以下。

如果遇到問題，請提交客服案件，我們會為您提高相關配額。

固定限制

IOPS

IOPS 是指磁碟每秒可處理的輸入/輸出作業 (或讀取/寫入) 數量。

Cloud SQL 會使用搭載永久儲存空間磁碟的 Compute Engine 虛擬機器 (VM)。如要進一步瞭解特定 VM 的效能特性，請參閱永久磁碟效能頁面上的持續 IOPS 上限表格。

表格限制

MySQL 適用的 Cloud SQL 預設限制為 50,000 個資料表，如果符合最低硬體需求 (至少 32 個核心和 200G 記憶體)，則執行個體可有 500,000 個資料表。為獲得最佳效能，建議單一資料庫中的資料表數量不要超過 50,000 個。

超過這些限制的執行個體不在服務水準協議的涵蓋範圍內。如果啟用 innodb_file_per_table 資料庫旗標，且資料表大小達到 16 TB (Linux 分割區的大小上限)，就無法再新增資料。

執行個體所需的記憶體取決於多項因素。如要進一步瞭解 MySQL 適用的 Cloud SQL 如何使用記憶體，請參閱「MySQL 如何使用記憶體」。

如果有效資料表數量大於 Cloud SQL 預設值，或整體快取大小相當大，則必須調整執行個體。如要維持最佳效能，您可以：

  • 升級至 Cloud SQL Enterprise Plus 版本，即可選用更高的記憶體。
  • 升級 Cloud SQL 機器，為執行個體新增記憶體。
  • 調低 innodb_buffer_pool_size 資料庫旗標的值。

table_open_cache 和 table_definition_cache 旗標可用於修改 MySQL 適用的 Cloud SQL 資料表快取。您可以使用成效結構定義，預估執行個體的資料表快取大小。詳情請參閱 MySQL 說明文件。

如果作用中資料表的數量遠大於 Cloud SQL 資料表預設值和 MySQL 建議的開啟資料表數量，Cloud SQL 建議您使用執行個體的作用中資料表數量，設定 table_open_cache 和 table_definition_cache 資料庫旗標。詳情請參閱「MySQL 開啟及關閉資料表的方式」。

作業限制

微型和小型級別機型會限制並行作業數量。如果超過限制，系統就會傳回 Too many operations 錯誤。

db-custom-1-3840 (單一 CPU) 機型的並行作業數量上限為 50 項。

f1-micro (共用核心 CPU) 機型的並行作業數量上限為 20。

Cloud SQL 儲存空間限制

Cloud SQL 儲存空間選項

如要設定儲存空間選項，以獲得最佳效能，請務必瞭解您的工作負載，並選擇適當的磁碟類型和大小。如要進一步瞭解我們為 Cloud SQL 提供的各種選擇，請參閱執行個體設定的相關說明。

App Engine 限制

以 App Engine 標準環境來說，當中運作的執行個體與其他執行個體之間的並行連線數不得超過 100 個。如果是以 PHP 5.5 編寫而成的應用程式，則上限為 60 個並行連線。

App Engine 應用程式必須符合要求時間限制，實際情況則視用量和環境而定。詳情請參閱 App Engine 標準和 彈性環境中的執行個體管理方式。

App Engine 應用程式也必須符合其他 App Engine 配額與限制的規定，詳情請參閱 App Engine 配額頁面。

Cloud Run 限制

如果您在 Cloud Run 上使用內建的 Cloud SQL 連線，則 Cloud Run 容器執行個體每個 Cloud SQL 資料庫最多只能有 100 個連線。

Cloud Run 服務或工作的每個執行個體，最多可與資料庫建立 100 個連線。隨著服務或工作規模擴大，每次部署的連線總數也會增加。

如果使用其他連線方式，例如在 sidecar 中使用 Cloud SQL Auth Proxy、Cloud SQL 語言連接器，或直接連線至 Cloud SQL 執行個體的 IP 位址，則不適用這項限制。

Cloud Run functions 限制

Cloud Run functions (第 1 代) 限制每個執行個體只能並行執行一項作業。不會有單一第 1 代函式執行個體同時處理兩項要求的情況。在多數情況下，您只需要一個資料庫連線。

Cloud Run functions (第 2 代) 以 Cloud Run 為基礎，每個執行個體最多可建立 100 個資料庫連線。

已儲存的查詢限制

值 限制
每個專案可儲存的查詢數量上限 (包括其他 Google Cloud 產品的已儲存查詢) 10,000
每個查詢的大小上限 1 MiB

Cloud SQL 儲存空間限制

Cloud SQL 儲存空間選項

如要設定儲存空間選項，以獲得最佳效能，請務必瞭解您的工作負載，並選擇適當的磁碟類型和大小。如要進一步瞭解我們為 Cloud SQL 提供的各種選擇，請參閱執行個體設定的相關說明。

App Engine 限制

以 App Engine 標準環境來說，當中運作的執行個體與其他執行個體之間的並行連線數不得超過 100 個。如果是以 PHP 5.5 編寫而成的應用程式，則上限為 60 個並行連線。

App Engine 應用程式必須符合要求時間限制，實際情況則視用量和環境而定。詳情請參閱如何管理 App Engine 標準環境的執行個體： 標準和 彈性環境。

App Engine 應用程式也必須符合其他 App Engine 配額與限制的規定，詳情請參閱 App Engine 配額頁面。

Cloud Run 限制

如果您在 Cloud Run 上使用內建的 Cloud SQL 連線，則 Cloud Run 容器執行個體每個 Cloud SQL 資料庫最多只能有 100 個連線。

Cloud Run 服務或工作的每個執行個體，最多可與資料庫建立 100 個連線。隨著服務或工作規模擴大，每次部署的連線總數也會增加。

如果使用其他連線方式，例如在 sidecar 中使用 Cloud SQL Auth Proxy、Cloud SQL 語言連接器，或直接連線至 Cloud SQL 執行個體的 IP 位址，則不適用這項限制。

Cloud Run functions 限制

Cloud Run functions (第 1 代) 限制每個執行個體只能並行執行一項作業。不會有單一第 1 代函式執行個體同時處理兩項要求的情況。在多數情況下，您只需要一個資料庫連線。

Cloud Run functions (第 2 代) 以 Cloud Run 為基礎，每個執行個體最多可建立 100 個資料庫連線。