Diese Seite wurde von der Cloud Translation API übersetzt.

Allgemeine Best Practices

MySQL | PostgreSQL | SQL Server

Auf dieser Seite finden Sie Best Practices für eine optimale Leistung, Langlebigkeit und Verfügbarkeit mit Cloud SQL.

Wenn Probleme mit Ihrer Cloud SQL-Instanz auftreten, prüfen Sie bei der Fehlerbehebung Folgendes:

Instanzkonfiguration und -verwaltung

Best Practice	Weitere Informationen
Lesen und beachten Sie die Betriebsrichtlinien, um dafür zu sorgen, dass alle Instanzen das Cloud SQL-SLA erfüllen.
Konfigurieren Sie für die primäre Instanz ein Wartungsfenster, in dem betriebsunterbrechende Updates erfolgen können.	Siehe Wartungsfenster.
Fügen Sie für leselastige Workloads Lesereplikate hinzu, um die primäre Instanz zu entlasten.	Sie können auch einen Load-Balancer wie HAProxy verwenden, um den Traffic zu den Replikaten zu verwalten.
Wenn Sie Instanzen regelmäßig löschen und neu erstellen, sollten Sie die Instanz-ID mit einem Zeitstempel versehen, um die Wahrscheinlichkeit zu erhöhen, dass neue Instanz-IDs verwendet werden können.
Starten Sie keinen neuen Verwaltungsvorgang, bevor der letzte Vorgang abgeschlossen ist.	Cloud SQL-Instanzen akzeptieren keine neuen Vorgangsanfragen, bis sie den vorherigen Vorgang abgeschlossen haben. Wenn Sie dennoch versuchen, einen neuen Vorgang zu starten, schlägt die Anfrage fehl. Das betrifft auch Neustarts der Instanz. Der Instanzstatus in der Google Cloud Console gibt nicht an, ob gerade ein Vorgang ausgeführt wird. Das grüne Häkchen zeigt nur an, dass sich die Instanz im Status `RUNNABLE` befindet. Wenn Sie wissen möchten, ob gerade ein Vorgang ausgeführt wird, wechseln Sie zum Tab Vorgänge und sehen Sie sich den Status des letzten Vorgangs an.
Konfigurieren Sie den Speicher für eine kritische Datenbankwartung.	Wenn die Instanzeinstellung Automatische Speichererweiterungen aktivieren deaktiviert ist oder die automatische Begrenzung der Speichererweiterung aktiviert ist, müssen mindestens 20 % Speicherplatz verfügbar sein, um alle kritischen Datenbankwartungsvorgänge, die von Cloud SQL ausgeführt werden, zu ermöglichen. Wenn Sie benachrichtigt werden möchten, sobald der verfügbare Speicherplatz unter 20 % liegt, erstellen Sie eine messwertbasierte Benachrichtigungsrichtlinie für den Messwert Laufwerkauslastung mit der Position über dem Schwellenwert und einem Wert von .8. Weitere Informationen zu Messwertbasierte Benachrichtigungsrichtlinien erstellen.
Verhindern Sie eine Überlastung der CPU.	Sie können den Prozentsatz der verfügbaren CPU, die von Ihrer Instanz verwendet wird, in der Google Cloud Console auf der Seite „Instanzdetails“ ansehen. Weitere Informationen finden Sie unter Messwerte. Sie können auch die CPU-Auslastung überwachen und Benachrichtigungen zu einem angegebenen Schwellenwert erhalten, indem Sie Benachrichtigungsrichtlinien mit Messwertschwellen erstellen. Um eine Überlastung zu vermeiden, können Sie die Anzahl der CPUs für Ihre Instanz erhöhen. Zum Ändern von CPUs ist ein Neustart der Instanz erforderlich. Wenn Ihre Instanz bereits die maximale CPU-Anzahl erreicht hat, müssen Sie Ihre Datenbank auf mehrere Instanzen aufteilen.
Vermeiden Sie eine Erschöpfung des Arbeitsspeichers.	Wenn Sie nach Anzeichen für Speicherausschöpfung suchen, sollten Sie hauptsächlich den Messwert usage verwenden. Um Fehler aufgrund von Speicherplatzmangel zu vermeiden, sollte dieser Messwert unter 90 % bleiben. Sie können auch den Messwert total_usage verwenden, um den Prozentsatz des verfügbaren Speichers zu beobachten, den Ihre Cloud-SQL-Instanz verwendet, einschließlich des vom Datenbankcontainer verwendeten Speichers und des vom Cache des Betriebssystems zugewiesenen Speichers. Anhand des Unterschieds zwischen den beiden Messwerten können Sie ermitteln, wie viel Arbeitsspeicher von Prozessen verwendet wird und wie viel vom Cache des Betriebssystems verwendet wird. Sie können den Arbeitsspeicher in diesem Cache wiederverwenden. Um Probleme mit unzureichendem Speicherplatz vorherzusagen, prüfen Sie beide Messwerte und interpretieren Sie sie gemeinsam. Wenn die Messwerte hoch erscheinen, hat die Instanz möglicherweise zu wenig Arbeitsspeicher. Dies kann an einer benutzerdefinierten Konfiguration, an der zu niedrigen Instanzgröße für die Arbeitslast oder an einer Kombination dieser Faktoren liegen. Skalieren Sie Ihre Cloud SQL-Instanz, um den Arbeitsspeicher zu erhöhen. Zum Ändern der Speichergröße der Instanz ist ein Neustart der Instanz erforderlich. Wenn Ihre Instanz bereits die maximale Speichergröße erreicht hat, müssen Sie Ihre Datenbank auf mehrere Instanzen aufteilen. Weitere Informationen zum Überwachen beider Messwerte in der Google Cloud Console finden Sie unter Messwerte.
Achten Sie darauf, dass Ihre Instanz optimale Transaktions-IDs hat.	Sie können die Transaktions-ID-Nutzung Ihrer Instanz auf der Seite Metrics Explorer in der Google Cloud Console anzeigen, wenn Sie den `Resource Type` als `Cloud SQL Database` und `Metric` als `Percentage of instance's transaction IDs consumed` einstellen. Weitere Informationen finden Sie unter Diagramme mit dem Metrics Explorer erstellen. Das Optimieren und Überwachen von Datenbankinstanzen kann dazu beitragen, vakuumbedingte Probleme zu reduzieren oder zu vermeiden. Überwachen Sie die Transaktions-ID-Nutzung Ihrer Instanz und aktivieren und passen Sie die Parameter `autovacuum` entsprechend der Arbeitslast auf Ihrer Instanz an. Weitere Informationen finden Sie unter Wraparound-Schutz mit Transaktions-ID (TXID) überwinden.

Datenarchitektur

Best Practice	Weitere Informationen
Teilen Sie große Instanzen nach Möglichkeit in kleinere Instanzen auf.	Mehrere kleine Cloud SQL-Instanzen sind oft besser als eine große Instanz. Die Verwaltung einer einzigen großen, monolithischen Instanz bringt einige Probleme mit sich, die bei einer Gruppe kleinerer Instanzen nicht auftreten.
Verwenden Sie nicht zu viele Datenbanktabellen.	Beschränken Sie die Anzahl der Tabellen Ihrer Instanz auf weniger als 10.000. Zu viele Datenbanktabellen können sich auf den Zeitaufwand für das Datenbankupgrade auswirken.

Anwendungsimplementierung

Best Practice	Weitere Informationen
Greifen Sie auf Best Practices für das Verbindungsmanagement zurück, z. B. Verbindungs-Pooling und exponentieller Backoff.	Diese Methoden optimieren die Nutzung der Ressourcen durch die Anwendung und erleichtern die Einhaltung der Verbindungslimits für Cloud SQL. Weitere Informationen und Codebeispiele finden Sie unter Datenbankverbindungen verwalten.
Testen Sie die Reaktion der Anwendung auf Wartungsupdates, die im Rahmen eines Wartungsfensters jederzeit auftreten können.	Mit einer Selfservice-Wartung können Sie ein Wartungsupdate simulieren. Während der Wartung ist Ihre Instanz für einen kurzen Zeitraum nicht verfügbar und bestehende Verbindungen werden getrennt. Durch das Testen von Wartungs-Rollouts erhalten Sie ein besseres Verständnis dafür, wie Ihre Anwendung mit geplanten Wartungsarbeiten umgeht und wie schnell das System wiederhergestellt werden kann.
Testen Sie die Reaktion der Anwendung auf Failover, die jederzeit vorkommen können.	Sie können ein Failover manuell über die Google Cloud Console, die gcloud CLI oder die API starten. Weitere Informationen finden Sie unter Failover initialisieren.
Vermeiden Sie große Transaktionen.	Kleine, kurze Transaktionen sind zu bevorzugen. Umfangreiche Datenbankupdates führen Sie besser in mehreren kleinen Transaktionen statt in einer einzelnen großen Transaktion durch.
Falls Sie den Cloud SQL Auth-Proxy verwenden, achten Sie darauf, dass es die neueste Version ist.	Weitere Informationen finden Sie unter Cloud SQL Auth-Proxy auf dem aktuellen Stand halten.

Datenimport und -export

Best Practice	Weitere Informationen
Verwenden Sie serverlose Exporte.	Serverlose Exporte übertragen den Exportvorgang auf eine temporäre Instanz, sodass die primäre Instanz weiterhin Abfragen verarbeiten und Vorgänge mit der üblichen Leistung ausführen kann. Wenn der Datenexport abgeschlossen ist, wird die temporäre Instanz automatisch gelöscht.
Beschleunigen Sie Importe für kleine Instanzen.	Bei kleinen Instanzen können Sie vorübergehend die CPU-Zahl und den RAM einer Instanz erhöhen, um beim Importieren großer Datasets die Leistung zu optimieren.
Wenn Sie Daten für den Import in Cloud SQL exportieren, müssen Sie auf das richtige Vorgehen achten.	Weitere Informationen finden Sie unter Daten exportieren.

Sicherung und Wiederherstellung

Best Practice	Weitere Informationen
Schützen Sie Ihre Daten mit den jeweils am besten geeigneten Cloud SQL-Funktionen.	Sicherungen, die Wiederherstellung zu einem bestimmten Zeitpunkt und Exporte sind Möglichkeiten, Datenredundanz und Schutz zu bieten. Beide ergänzen sich, schützen vor unterschiedlichen Szenarien und sind Teil einer robusten Datenschutzstrategie. Sicherungen benötigen nicht viele Ressourcen. Damit können Sie die Daten einer Instanz zum Zeitpunkt der Sicherung wiederherstellen. Es gelten jedoch einige Einschränkungen. Wenn Sie eine Instanz löschen, werden auch ihre Sicherungen gelöscht. Sie können keine einzelne Datenbank oder Tabelle sichern. Wenn die Region, in der sich die Instanz befindet, nicht verfügbar ist, können Sie die Instanz aus dieser Sicherung nicht wiederherstellen, auch nicht in einer verfügbaren Region. Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie eine Instanz in einem bestimmten Zustand zurückversetzen. Wenn beispielsweise ein Fehler zu einem Datenverlust geführt hat, haben Sie die Möglichkeit, genau den Zustand der Datenbank wiederherzustellen, den sie zum Zeitpunkt vor Auftreten des Fehlers hatte. Bei der Wiederherstellung zu einem bestimmten Zeitpunkt wird immer eine neue Instanz erstellt. Diese Art der Wiederherstellung kann nicht so durchgeführt werden, dass dabei der wiederhergestellte Zustand in eine vorhandene Instanz integriert wird. Exporte dauern länger, da in Cloud Storage eine externe Datei erstellt werden muss, die zum Wiederherstellen der Daten verwendet werden kann. Exporte sind vom Löschen einer Instanz nicht betroffen. Außerdem können Sie je nach Exportformat auch eine einzelne Datenbank oder sogar nur eine Tabelle exportieren.
Berücksichtigen Sie bei der Bemessung der Instanzengrößen die Aufbewahrung von (binären) Transaktionslogs.	Eine hohe Schreibaktivität in die Datenbank kann eine große Anzahl von (binären) Transaktionslogs erzeugen, die sehr viel Speicherplatz belegen können und zu einem Laufwerkwachstum für Instanzen führen, bei denen die automatische Speichererweiterung aktiviert ist. Wir empfehlen, bei der Bemessung des Instanzspeichers die Aufbewahrung von Transaktionslogs zu berücksichtigen.
Schützen Sie Ihre Instanz und Ihre Sicherungen vor versehentlichem Löschen.	Eine Cloud SQL-Instanz, die Sie in der Google Cloud Console oder über Terraform erstellen, ermöglicht standardmäßig den Schutz vor versehentlichem Löschen. Verwenden Sie das Exportfeature in Cloud SQL, um Ihre Daten für zusätzlichen Schutz zu exportieren. Cloud Scheduler mit der REST API verwenden, um die Exportverwaltung zu automatisieren. Für komplexere Szenarien verwenden Sie zur Automatisierung Cloud Scheduler mit Cloud Run-Funktionen.

Best Practice

Weitere Informationen

Schützen Sie Ihre Daten mit den jeweils am besten geeigneten Cloud SQL-Funktionen.

Sicherungen, die Wiederherstellung zu einem bestimmten Zeitpunkt und Exporte sind Möglichkeiten, Datenredundanz und Schutz zu bieten. Beide ergänzen sich, schützen vor unterschiedlichen Szenarien und sind Teil einer robusten Datenschutzstrategie.

Sicherungen benötigen nicht viele Ressourcen. Damit können Sie die Daten einer Instanz zum Zeitpunkt der Sicherung wiederherstellen. Es gelten jedoch einige Einschränkungen. Wenn Sie eine Instanz löschen, werden auch ihre Sicherungen gelöscht. Sie können keine einzelne Datenbank oder Tabelle sichern. Wenn die Region, in der sich die Instanz befindet, nicht verfügbar ist, können Sie die Instanz aus dieser Sicherung nicht wiederherstellen, auch nicht in einer verfügbaren Region.

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie eine Instanz in einem bestimmten Zustand zurückversetzen. Wenn beispielsweise ein Fehler zu einem Datenverlust geführt hat, haben Sie die Möglichkeit, genau den Zustand der Datenbank wiederherzustellen, den sie zum Zeitpunkt vor Auftreten des Fehlers hatte. Bei der Wiederherstellung zu einem bestimmten Zeitpunkt wird immer eine neue Instanz erstellt. Diese Art der Wiederherstellung kann nicht so durchgeführt werden, dass dabei der wiederhergestellte Zustand in eine vorhandene Instanz integriert wird.

Exporte dauern länger, da in Cloud Storage eine externe Datei erstellt werden muss, die zum Wiederherstellen der Daten verwendet werden kann. Exporte sind vom Löschen einer Instanz nicht betroffen. Außerdem können Sie je nach Exportformat auch eine einzelne Datenbank oder sogar nur eine Tabelle exportieren.

Berücksichtigen Sie bei der Bemessung der Instanzengrößen die Aufbewahrung von (binären) Transaktionslogs.

Eine hohe Schreibaktivität in die Datenbank kann eine große Anzahl von (binären) Transaktionslogs erzeugen, die sehr viel Speicherplatz belegen können und zu einem Laufwerkwachstum für Instanzen führen, bei denen die automatische Speichererweiterung aktiviert ist. Wir empfehlen, bei der Bemessung des Instanzspeichers die Aufbewahrung von Transaktionslogs zu berücksichtigen.

Schützen Sie Ihre Instanz und Ihre Sicherungen vor versehentlichem Löschen.

Eine Cloud SQL-Instanz, die Sie in der Google Cloud Console oder über Terraform erstellen, ermöglicht standardmäßig den Schutz vor versehentlichem Löschen.

Verwenden Sie das Exportfeature in Cloud SQL, um Ihre Daten für zusätzlichen Schutz zu exportieren. Cloud Scheduler mit der REST API verwenden, um die Exportverwaltung zu automatisieren. Für komplexere Szenarien verwenden Sie zur Automatisierung Cloud Scheduler mit Cloud Run-Funktionen.

Abstimmung und Überwachung

Das Optimieren und Überwachen von Datenbankinstanzen kann dazu beitragen, bereinigungsbedingte Probleme zu reduzieren oder zu vermeiden.

Der Vorgang VACUUM hat verschiedene Varianten mit unterschiedlichen Sperrebenen: Standard-VACUUM und VACUUM FULL. Die Option VACUUM FULL kann mehr Speicherplatz zurückgewinnen, sperrt jedoch die Tabelle exklusiv und wird langsam ausgeführt. Verwenden Sie stattdessen die Standardform VACUUM, die parallel zu Produktionsdatenbankvorgängen ausgeführt werden kann. Wenn Sie den Vorgang VACUUM verwenden, funktionieren Befehle wie SELECT, INSERT, UPDATE, and DELETE weiterhin normal. Sie können die Definition einer Tabelle nicht mit Befehlen wie ALTER TABLE ändern, während das Objekt bereinigt wird.

Hier einige Empfehlungen, wie Sie den Zeitaufwand für den VACUUM-Vorgang verringern können:

Erhöhen Sie den Systemspeicher und maintenance_work_mem. Dadurch werden in jeder Iteration mehr Tupel in Batches zusammengefasst und die Aufgabe wird so schnell wie möglich abgeschlossen. Hinweis: Wenn die automatische Bereinigung (autovacuum) ausgeführt wird, kann bis zu autovacuum_max_workers Mal dieser Speicher zugeordnet werden kann. Achten Sie daher darauf, den Standardwert nicht zu hoch einzustellen.
Der VACUUM-Vorgang erzeugt viele WAL-Einträge (Write-Ahead-Log). Wenn es möglich ist, die Anzahl der WAL-Einträge zu reduzieren und beispielsweise keine Replikate für diese Instanz zu konfigurieren, wird der Vorgang schneller abgeschlossen.
Wenn die Tabelle das Limit von zwei Milliarden Transaktions-IDs erreicht hat, weil keines der Tupel blockiert ist, versuchen Sie, den Arbeitsaufwand im Einzelbenutzermodus zu reduzieren. Eine mögliche Option ist die Einstellung von vacuum_freeze_min_age=1,000,000,000 (der maximal zulässige Wert, ausgehend vom Standardwert von 50.000.000). Dieser neue Wert reduziert die Anzahl der blockierten Tupel auf das Zweifache.
PostgreSQL Version 12.0 und höher unterstützen die Bereinigung und VACUUM-Vorgänge, ohne die Indexeinträge zu bereinigen. Dies ist entscheidend, da die Bereinigung des Index einen vollständigen Indexscan erfordert. Gibt es mehrere Indexe, hängt die Gesamtzeit von der Indexgröße ab.
Größere Indexe verbrauchen viel Zeit für den Indexscan. Daher wird INDEX_CLEANUP OFF bevorzugt, um die Tabellendaten schnell zu bereinigen und zu fixieren. PostgreSQL-Versionen vor 12.0 müssen die Anzahl der Indexe abstimmen. Das heißt, wenn es nicht kritische Indexe gibt, kann es hilfreich sein, den NON-CRITICAL-Index zu entfernen, um den Bereinigungsvorgang zu beschleunigen.