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:
serviceusage.quotas.get:Kontingente prüfenserviceusage.quotas.update:Kontingente erhöhen
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:
Öffnen Sie in der Google Cloud Console die Seite Kontingente.
Filtern Sie nach dem Dienst Cloud SQL Admin API.
Wenn Sie diesen Dienst nicht sehen, aktivieren Sie die Cloud SQL Admin API.
Klicken Sie auf die Kästchen neben den Kontingenten, die Sie ändern möchten, und dann auf Kontingente bearbeiten.
Geben Sie für jedes ausgewählte Kontingent im Feld Neues Limit den Wert für das gewünschte Limit ein.
Geben Sie im Feld Beschreibung des Grundes einen Grund für die Anfrage nach einer Kontingenterhöhung ein und klicken Sie dann auf Fertig.
Klicken Sie auf Weiter.
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 |
Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden. |
1000 | |
| Abrufen |
Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden. |
500 | |
| Liste |
Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden. |
500 | |
| Ändern |
Die Anzahl der Anfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden. |
|
180 |
| Standard pro Region |
Die Anzahl der regionalen Standardanfragen, die pro Minute, Nutzer und Region gesendet werden, um die APIs in dieser Kategorie zu verwenden. |
180 | |
| Standard |
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
MySQL
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";
PostgreSQL
Mit dem Flag
max_connections können Sie Verbindungslimits konfigurieren. Wenn Sie eine Instanz von Cloud SQL for PostgreSQL erstellen, wird in den
Konfigurationseinstellungen des Maschinentyps automatisch der Bereich der verfügbaren Arbeitsspeichergrößen angepasst (basierend auf der Anzahl der ausgewählten Kerne). Damit werden auch die für die Instanz eingerichteten anfänglichen Standardverbindungslimits festgelegt.
Stellen Sie eine Verbindung zu Ihrer Datenbank her und führen Sie den folgenden Befehl aus, um die Verbindungslimits für Ihre Instanz zu finden: SELECT * FROM pg_settings WHERE name = 'max_connections';
Der Wert für Replikate muss größer oder gleich dem Wert für das Primärreplikat sein. Änderungen am Primärreplikat werden an Replikate weitergegeben, deren Wert niedriger als der neue Wert für das Primärreplikat ist oder für die der Standardwert gilt.
Wenn der Wert auf dem Primärknoten default ist, kann der Wert für die Replikate nicht geändert werden. Wenn Sie den Wert für die Replikate ändern möchten, müssen Sie zuerst den Wert im Primärelement auf eine Ganzzahl festlegen.
SQL Server
Die tatsächliche Anzahl gleichzeitig zugelassener Nutzerverbindungen hängt von der genutzten Version von SQL Server sowie von den Einschränkungen Ihrer Anwendung bzw. Anwendungen und Hardware ab. SQL Server lässt maximal 32.767 Nutzerverbindungen zu.
Weitere Informationen zum Konfigurieren von Nutzerverbindungen in SQL Server finden Sie in der Referenzdokumentation.
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.
Um Probleme zu vermeiden, sollten Sie die Gesamtzahl der Instanzen pro Netzwerk auf unter 500 begrenzen.
Wenn ein solches Problem auftritt, 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.
Limit für die Messwertsammlung
PostgreSQL-Messwerte werden für bis zu 500 Datenbanken erfasst. Wenn mehr als 500 Datenbanken vorhanden sind, werden nur die ersten 500 Datenbanken für einen bestimmten Messwert einbezogen. Diese Datenbanken haben die höchste Transaktionszahl.
Cloud SQL-Speicherlimits
- Dedizierter Kern: bis zu 64 TB.
- Gemeinsam genutzter Kern: bis zu 3 TB.
Weitere Informationen finden Sie unter Instanzpreise.
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
Wenn Sie die integrierte Cloud SQL-Verbindung in Cloud Run verwenden, sind Cloud Run-Containerinstanzen auf 100 Verbindungen pro 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.
Diese Einschränkung gilt nicht, wenn Sie andere Verbindungsmethoden wie den Cloud SQL Auth-Proxy in einem Sidecar, die Cloud SQL-Sprach-Connectors oder eine direkte Verbindung zur IP-Adresse der Cloud SQL-Instanz verwenden.
Limits für Cloud Run-Funktionen
Cloud Run 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 Run Functions (2. Generation) basiert auf Cloud Run und hat ein Limit von 100 Datenbankverbindungen pro Instanz.