Kontingente und Limits

Auf dieser Seite erfahren Sie mehr über die Kontingente und Limits von Cloud SQL. Kontingente gelten jeweils pro Projekt. Limits gelten jeweils entweder für die Instanz oder für das Projekt.

Kontingente

Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen darf. Cloud SQL ist ein Beispiel für diesen Ressourcentyp.

Bei Cloud SQL sind Kontingente Teil eines Systems, das Folgendes tut:

  • Nutzung oder Verbrauch von Cloud SQL-Instanzen überwachen
  • Nutzung dieser Instanzen aus Gründen wie Fairness und Reduzierung von Nutzungsspitzen einschränken
  • Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen
  • Eine Möglichkeit bieten, Kontingentänderungen anzufordern

Wenn ein Kontingent überschritten wird, blockiert das System in den meisten Fällen sofortden Zugriff auf die entsprechende Instanz und die Aufgabe, die Sie ausführen möchten, schlägt fehl. Kontingente gelten für alle Google Cloud-Projekte sowie für alle Instanzen, die dieses Projekt verwenden.

Berechtigungen zum Prüfen und Erhöhen Ihrer Kontingente

Zum Prüfen und Erhöhen Ihrer Kontingente benötigen Sie die folgenden Berechtigungen:

Standardmäßig sind diese Berechtigungen in den einfachen IAM-Rollen „Editor“ und „Owner“ sowie in der vordefinierten Rolle Quota Administrator enthalten. Wenn Sie zusätzliche Berechtigungen benötigen, wenden Sie sich an Ihren Kontingentadministrator.

Kontingente prüfen

Die aktuell gültigen Kontingente für Ressourcen in Ihrem Projekt finden Sie in der Google Cloud Console auf der Seite Kontingente. Filtern Sie dort nach Cloud SQL Admin API. Diese Kontingente gelten nur für API-Aufrufe. Es sind keine Datenbankabfragen enthalten.

Kontingente erhöhen

Bei einer intensiveren Nutzung von Google Cloud können Ihre Kontingente entsprechend erhöht werden. Wenn Sie eine deutlich höhere Nutzung erwarten, empfehlen wir Ihnen, schon einige Tage vorher entsprechend höhere Kontingente anzufordern.

Für die Anforderung einer Kontingenterhöhung fallen keine Gebühren an. Ihre Kosten erhöhen sich nur, wenn Sie mehr Ressourcen verwenden.

So erhöhen Sie Ihre Kontingente:

  1. Öffnen Sie in der Google Cloud Console die Seite Kontingente.

    Zur Seite „Kontingente“

  2. Filtern Sie nach dem Dienst Cloud SQL Admin API.

    Wenn Sie diesen Dienst nicht sehen, aktivieren Sie die Cloud SQL Admin API.

  3. Klicken Sie auf die Kästchen neben den Kontingenten, die Sie ändern möchten, und dann auf Kontingente bearbeiten.

  4. Geben Sie für jedes ausgewählte Kontingent im Feld Neues Limit den Wert für das gewünschte Limit ein.

  5. Geben Sie im Feld Beschreibung des Grundes einen Grund für die Anfrage nach einer Kontingenterhöhung ein und klicken Sie dann auf Fertig.

  6. Klicken Sie auf Next (Weiter).

  7. Geben Sie Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Anfrage senden.

    Wenn Sie Probleme haben, Ihre Kontingente zu erhöhen, reichen Sie eine Supportanfrage ein.

Auffüllung von Ressourcenkontingenten

Tageskontingente werden täglich um Mitternacht gemäß Pacific Time  (UTC-7) aufgefüllt.

Kontingente und Ressourcenverfügbarkeit

Mit Ressourcenkontingenten wird festgelegt, wie viele Ressourcen eines Typs Sie maximal erstellen können, wenn diese Ressourcen verfügbar sind. Sie bedeuten jedoch nicht, dass jederzeit Ressourcen zur Verfügung stehen. Wenn eine Ressource für Ihre Region physisch nicht verfügbar ist, können Sie keine neuen Ressourcen dieses Typs erstellen, selbst wenn in Ihrem Projekt noch ausreichendes Kontingent vorhanden ist.

Ratenkontingente

Cloud SQL unterstützt Ratenkontingente, die auch als Ratenbegrenzungen oder API-Kontingente bezeichnet werden. Ratenkontingente definieren, wie viele Anfragen Sie an die Cloud SQL Admin API senden können.

Jedes Ratenkontingent entspricht allen Anfragen für eine Kategorie von einer oder mehreren Cloud SQL Admin API-Methoden. Ratenkontingente werden nach einem für Cloud SQL spezifischen Zeitintervall zurückgesetzt (z. B. der Anzahl der API-Anfragen pro Minute).

Wenn Sie die gcloud CLI oder die Google Cloud Console verwenden, stellen Sie Anfragen an die Cloud SQL Admin API und diese Anfragen werden auf Ihre Ratenkontingente angerechnet. Wenn Sie mithilfe von Dienstkonten auf die API zugreifen, werden diese Anfragen auch auf Ihre Ratenkontingente angerechnet.

Cloud SQL erzwingt und füllt Ratenkontingente automatisch in 60-Sekunden-Intervallen. Wenn Ihr Projekt das Limit eines Ratenkontingents zu einem beliebigen Zeitpunkt innerhalb von 60 Sekunden erreicht, müssen Sie warten, bis dieses Kontingent aufgebraucht ist, bevor Sie in dieser Kategorie weitere Anfragen stellen. Wenn Ihr Projekt dieses Limit überschreitet, erhalten Sie den HTTP-Statuscode 429 mit dem Grund rateLimitExceeded.

Die Cloud SQL Admin API ist in die folgenden Kategorien unterteilt:

  • Verbinden: Werte auflisten, die erforderlich sind, um eine Verbindung zu einer Cloud SQL-Datenbank herzustellen.
  • Abrufen: Informationen zu einer Ressource abrufen (z. B. einer Instanz, einem Vorgang oder einer Sicherung).
  • Auflisten: Ressourcen auflisten.
  • Ändern: Ressourcen erstellen, ändern und löschen.
  • Standard pro Region: Mit einer Cloud SQL-Instanz interagieren, ohne eine Verbindung zu dieser herzustellen, sie abzurufen, aufzulisten oder zu ändern.
  • Standard: Datenbank-Flags und Maschinentypen (Stufen) für Cloud SQL-Instanzen auflisten. Die APIs in dieser Kategorie sind global.

In Cloud SQL gelten Ratenkontingente für jede Kategorie pro Minute, Nutzer und Region. Für jede eindeutige Kombination dieser Attribute gibt Cloud SQL eine separate Ratenbegrenzung an.

Die Cloud SQL Admin API bietet detaillierte Messwerte, mit denen Sie Ihre Nutzung der API verfolgen, die Leistung Ihrer Cloud SQL-Instanz und der API überwachen und Probleme zwischen Ihrer Instanz und der API erkennen können. Weitere Informationen finden Sie unter Monitoring API-Nutzung.

Die folgende Tabelle enthält Informationen zum Messwert, zu den APIs und zum Standardlimit für jede Kategorie:

Kategorie Messwert APIs Standardlimit
Verbinden

sqladmin.googleapis.com/connect

Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden.

 1000
Get

sqladmin.googleapis.com/get

Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden.

 500
Liste

sqladmin.googleapis.com/list

Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden.

 500
Ändern

sqladmin.googleapis.com/mutate

Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden.

 180
Standard pro Region

sqladmin.googleapis.com/
default_per_region

Die Anzahl der regionalen Standardanfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden.

 180
Standard

sqladmin.googleapis.com/default

Die Anzahl der Standardanfragen, die pro Minute und Nutzer gesendet werden, um die APIs in dieser Kategorie zu verwenden.

 180

Limits

Für manche Cloud SQL-Ressourcen, die nicht regelmäßig aufgefüllt werden und nicht auf der Seite "Kontingente" in der Google Cloud Console zu sehen sind, gelten Einschränkungen. Einige dieser Limits können erhöht werden, andere nicht.

Konfigurierbare Limits

Instanzen pro Projekt

Standardmäßig können Sie bis zu 1.000 Instanzen pro Projekt haben. In einigen Fällen ist dies jedoch auf 100 beschränkt. Stellen Sie eine Supportanfrage, um eine Erhöhung anzufordern. Lesereplikate werden als Instanzen gezählt.

Wir empfehlen, die Anzahl der Instanzen auf mehrere Projekte zu verteilen, um die Abhängigkeit von Anfragen zur Kontingenterhöhung zu reduzieren. Dadurch werden potenzielle Blockierungen vermieden.

Maximale Anzahl gleichzeitiger Verbindungen

Sie können das Flag max_connections verwenden, um ein Verbindungslimit zu konfigurieren. MySQL ermöglicht maximal 32.000 Verbindungen. Stellen Sie eine Verbindung zu Ihrer Datenbank her und führen Sie den folgenden Befehl aus, um das Verbindungslimit für Ihre Instanz zu finden: SHOW VARIABLES LIKE "max_connections";

Vorsichtsmaßnahmen

Kontingentnutzung für Cloud SQL-Connectors

Der Cloud SQL Auth-Proxy und andere Cloud SQL-Connectors nutzen das Kontingent der Cloud SQL Admin API. Die Cloud SQL-Connectors führen etwa jede Stunde einen Aktualisierungsvorgang aus. Bei diesem Aktualisierungsvorgang werden zwei API-Aufrufe ausgeführt. Mit einem Aufruf werden die Instanzmetadaten abgerufen und mit dem anderen wird ein sitzungsspezifisches Zertifikat abgerufen.

Die Kontingentnutzung wird folgendermaßen berechnet:

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

Wenn Sie beispielsweise drei Prozesse haben, die einen Connector ausführen, der Connector für eine Verbindung zu zwei Cloud SQL-Instanzen konfiguriert ist und zwei API-Aufrufe für eine Stunde durchgeführt werden, beträgt der Kontingentverbrauch 12 (3 Prozesse * 2 Instanzen * 2 API-Aufrufe).

Wenn Sie beginnen, Cloud SQL zu verwenden, sollten Sie wegen der obigen Formel Folgendes beachten:

  • Wie schnell Sie neue DB-Clients hochskalieren

  • Wie schnell Sie weitere Instanzen hinzufügen

  • Verwendung unterschiedlicher Dienstkonten für jede Anwendung

Cloud SQL-IAM-Datenbankauthentifizierung

Für jede Instanz gilt ein Anmeldungskontingent pro Minute, das sowohl erfolgreiche als auch fehlgeschlagene Anmeldungen umfasst. Wenn das Kontingent überschritten wird, sind Anmeldungen vorübergehend nicht möglich. Wir empfehlen, häufige Anmeldungen zu vermeiden und Anmeldungen mithilfe von autorisierten Netzwerken einzuschränken. Das Kontingent für die Autorisierung von Anmeldungen beträgt 12.000 pro Minute und Instanz.

Kontingent für Weiterleitungsregeln

Jede Cloud SQL-Instanz besteht aus einer Weiterleitungsregel und einem Load-Balancer. Für die Weiterleitungsregel gilt ein Kontingentlimit, das auf der Art des Load-Balancers basiert, auf den sie verweist. Es gibt mehrere Kontingente für jede Art von Weiterleitungsregel, pro Projekt, pro Netzwerk und pro Peering-Gruppe. Es gibt auch eine Überschreibungsregel für Kontingente pro Netzwerk und Kontingente pro Peering-Gruppe für Cloud SQL. Wenn wir also das Kontingent pro Netzwerk für Erstellernetzwerke erhöhen, wird das Kontingent pro Peering-Gruppe auf den gleichen Wert erhöht.

Die Cloud SQL-Ersteller-VPC wird mit der VPC des Kunden verbunden. Daher erreichen wir häufig das Netzwerkkontingent für das Cloud SQL-Erstellernetzwerk und das Peering-Gruppenkontingent für die VPC des Kunden.

Wenn das Kontingent erreicht ist, können bestimmte Vorgänge fehlschlagen. Dazu gehören:

  • Erstellungsvorgang: Wir benötigen neue Weiterleitungsregeln, wenn wir neue Instanzen erstellen.

  • Aktualisierungsvorgang: Kunden können das Netzwerk der Instanzen wechseln, sodass wir im neuen Netzwerk neue Weiterleitungsregeln benötigen.

  • Wartungsvorgang: Weiterleitungsregeln werden neu erstellt.

Wenn solche Probleme auftreten, können Sie eine Supportanfrage stellen, damit wir die entsprechenden Kontingente für Sie erhöhen.

Feste Limits

IOPS

IOPS sind die Anzahl der Eingabe-/Ausgabevorgänge (oder Lese-/Schreibvorgänge), die Ihr Laufwerk pro Sekunde verarbeiten kann.

Cloud SQL verwendet Compute Engine-VMs mit nichtflüchtigen Speicherlaufwerken. Weitere Informationen zu bestimmten VM-Leistungsmerkmalen finden Sie in der Tabelle Maximale IOPS (kontinuierlich) auf der Seite Leistung des nichtflüchtigen Speichers.

Tabellenlimit

Cloud SQL for MySQL hat standardmäßig ein Limit von 50.000 Tabellen oder 500.000 Tabellen für eine Instanz, wenn Sie die Mindesthardwareanforderungen von mindestens 32 Kernen und mindestens 200 G Arbeitsspeicher erfüllen. Für eine optimale Leistung empfehlen wir, dass die Anzahl der Tabellen in einer einzelnen Datenbank 50.000 nicht überschreitet.

Instanzen, die diese Limits überschreiten, sind nicht vom SLA abgedeckt. Wenn die Tabellengröße 16 TB erreicht, die maximale Größe für Linux-Partitionen, können keine weiteren Daten hinzugefügt werden.

Der von Ihrer Instanz benötigte Arbeitsspeicher hängt von verschiedenen Faktoren ab. Weitere Informationen zur Arbeitsspeichernutzung durch Cloud SQL for MySQL finden Sie unter Arbeitsspeichernutzung von MySQL.

Wenn die Anzahl der aktiven Tabellen größer ist als die Cloud SQL-Standardeinstellungen ist oder wenn die Größe des Cache insgesamt sehr groß ist, müssen Sie Anpassungen an der Instanz vornehmen. Gehen Sie so vor, um eine optimale Leistung zu erzielen:

  • Führen Sie ein Upgrade auf die Cloud SQL Enterprise Plus-Version durch, um Optionen für mehr Arbeitsspeicher zu erhalten.
  • Aktualisieren Sie die Cloud SQL-Maschine, um der Instanz Arbeitsspeicher hinzuzufügen.
  • Reduzieren Sie den Wert des Datenbank-Flags innodb_buffer_pool_size.

Mit den Flags table_open_cache und table_definition_cache können Sie den Tabellen-Cache von Cloud SQL for MySQL ändern. Mit dem Leistungsschema können Sie eine Schätzung der Tabellen-Cache-Größe für Ihre Instanz abrufen.

Wenn die Anzahl der aktiven Tabellen sowohl erheblich größer als die Standardeinstellungen für Cloud SQL-Tabellen als auch erheblich größer als die Empfehlung für offene Tabellen durch MySQL ist, empfiehlt Cloud SQL, die Datenbank-Flags table_open_cache und table_definition_cache mit der Anzahl der aktiven Tabellen Ihrer Instanz zu konfigurieren. Weitere Informationen finden Sie unter So werden in MySQL Tabellen geöffnet und geschlossen.

Vorgangslimit

Maschinentypen für Mikro- und kleine Ebenen begrenzen die Anzahl gleichzeitiger Vorgänge. Das Überschreiten dieser Beschränkung führt zu einem Too many operations-Fehler.

Das Maschinentyp-Limit für db-custom-1-3840 (einzelne CPU) beträgt 50 gleichzeitige Vorgänge.

Das Maschinentyp f1-micro (CPU mit gemeinsam genutztem Kern) beträgt 20 gleichzeitige Vorgänge.

Cloud SQL-Speicherlimits

Cloud SQL-Speicheroptionen

Wenn Sie eine Speicheroption für beste Leistung konfigurieren möchten, müssen Sie zuerst Ihre Arbeitslast verstehen und ein Laufwerk mit passendem Typ und passender Größe auswählen. Weitere Informationen zu den verfügbaren Optionen für Cloud SQL finden Sie unter Instanzeinstellungen.

App Engine-Limits

Eine App Engine-Instanz, die in einer Standardumgebung ausgeführt wird, kann maximal 100 Verbindungen gleichzeitig zu einer Instanz aufbauen. Bei Anwendungen, die in PHP 5.5 geschrieben sind, ist die Anzahl der gleichzeitigen Verbindungen auf 60 beschränkt.

App Engine-Anwendungen unterliegen je nach Nutzung und Umgebung bestimmten Zeitlimits für Anfragen. Weitere Informationen finden Sie in den Erläuterungen dazu, wie Instanzen in der App Engine-Standardumgebung bzw. der flexiblen App Engine-Umgebung verwaltet werden.

App Engine-Anwendungen unterliegen außerdem weiteren Kontingenten und Limits von App Engine. Sie sind auf der Seite Kontingente beschrieben.

Cloud Run-Limits

Cloud Run-Containerinstanzen sind auf 100 Verbindungen zu einer Cloud SQL-Datenbank beschränkt. Jede Instanz eines Cloud Run-Dienstes oder -Jobs kann 100 Verbindungen zur Datenbank haben. Wenn dieser Dienst oder Job skaliert wird, kann die Gesamtzahl der Verbindungen pro Bereitstellung wachsen.

Cloud Functions-Limits

Cloud Functions (1. Generation) begrenzt gleichzeitige Ausführungen auf eine Instanz. Zwei Anfragen werden nie gleichzeitig von einer einzelnen Funktionsinstanz der 1. Generation verarbeitet. In den meisten Fällen ist nur eine Datenbankverbindung erforderlich.

Cloud Functions (2. Generation) basiert auf Cloud Run und hat ein Limit von 100 Datenbankverbindungen pro Instanz.