Best Practices

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. Nach dem Löschen einer Instanz kann die Instanz-ID einige Tage lang nicht wiederverwendet werden.
Starten Sie keinen neuen Verwaltungsvorgang, bevor der letzte Vorgang abgeschlossen ist.

Solange der vorherige Vorgang nicht abgeschlossen ist, nehmen Cloud SQL-Instanzen keine neuen Vorgangsanfragen an. Wenn Sie dennoch versuchen, einen neuen Vorgang zu starten, schlägt die Anfrage fehl. Das betrifft auch Neustarts der Instanz.

Der Instanzstatus in der 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.

Systemtabellen nach Updates bereinigen MySQL-Systemtabellen (z. B. mysql.user oder mysql.db) verwenden das MyISAM-Speichermodul. Diese Tabellen können bei nicht korrektem Herunterfahren beschädigt werden. Führen Sie nach beliebigen Änderungen an den Tabellen den Befehl FLUSH CHANGES aus, z. B. nach dem Hinzufügen oder Aktualisieren eines Nutzers über den mysql-Client. Wenn MyISAM beschädigt wird und die Instanz neu gestartet werden kann, können Sie mit den Befehlen CHECK TABLE und REPAIR TABLE versuchen, den Schaden zu beheben. Jedoch bleibt der Tabelleninhalt möglicherweise trotzdem fehlerhaft.

Datenarchitektur

Best Practice Weitere Informationen
Erstellen Sie wenn möglich Shards Ihrer Instanzen. 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 größeren Anzahl kleinerer Instanzen nicht auftreten.
Verwenden Sie nicht zu viele Datenbanktabellen.

Zu viele Datenbanktabellen können sich auf die Antwortzeit der Instanz auswirken. Bei mehr als 10.000 Tabellen gibt es Auswirkungen auf die Gültigkeit des SLA. Weitere Informationen finden Sie in den Betriebsrichtlinien.

Tabellen sollten einen Primärschlüssel bzw. eindeutigen Schlüssel haben. Cloud SQL verwendet die zeilenbasierte Replikation, die sich am besten für Tabellen mit Primärschlüsseln bzw. eindeutigen Schlüsseln eignet.

Anwendungsimplementierung

Best Practice Weitere Informationen
Greifen Sie auf Best Practices für das Verbindungsmanagement zurück, beispielsweise Verbindungs-Pooling und exponentieller Backoff. Diese Methoden nutzen die Ressourcen der Anwendung umfassender 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 jederzeit während eines Wartungsfensters auftreten können. Die Änderung des Maschinentyps einer Instanz kommt einem Wartungsupdate am nächsten, außer dass während eines Wartungsupdates zuerst das Failover-Replikat aktualisiert (und offline genommen) wird, danach die primäre Instanz, sobald der Aktualisierungsvorgang für das Replikat abgeschlossen ist. Bei Maschinentypänderungen geht erst die primäre Instanz offline, dann das Replikat. Achten Sie darauf, dass die Anwendung nach einer Wartung ordnungsgemäß fortgesetzt wird. Dazu sollte sie mindestens 10 Minuten lang versuchen, die Datenbankverbindung wiederherzustellen, bevorzugt über einen exponentiellen Backoff. Weitere Informationen finden Sie unter Datenbankverbindungen verwalten.
Testen Sie die Reaktion der Anwendung auf Failover, die jederzeit vorkommen können. Sie können ein Failover manuell über die Cloud Console, das gcloud-Befehlszeilentool 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 Cloud SQL Proxy verwenden, achten Sie darauf, dass es die neueste Version ist. Weitere Informationen finden Sie unter Aktuelle Version des Cloud SQL Proxys.

Import und Export von Daten

Best Practice Weitere Informationen
Beschleunigen Sie Importe für kleine Instanzen. Bei kleinen Instanzen können Sie vorübergehend die Stufe einer Instanz erhöhen, um beim Importieren großer Datasets die Leistung zu optimieren.
Verwenden Sie das richtige Verfahren, wenn Sie Daten für den Import in Cloud SQL exportieren. Weitere Informationen finden Sie unter Daten exportieren.
Beschleunigen Sie Importe durch Verwendung des passenden mysqldump-Befehls beim Export. Wenn Sie Daten mit dem Dienstprogramm mysqldump für den Import in Cloud SQL exportieren, sollten Sie folgende Optionen berücksichtigen:
  • Deaktivieren Sie "autocommit" und fassen Sie die Datei oder Tabelle mithilfe der Option --single-transaction in einer einzigen Transaktion zusammen.
  • Fügen Sie mit der Option --extended-insert (standardmäßig aktiviert) mehrere Zeilen in jede INSERT-Anweisung ein.
Verwenden Sie beim Migrieren von Daten mit einem Export und Import denselben SQL-Modus für den Import wie für den Export. Weitere Informationen finden Sie unter Denselben SQL-Modus für Import und Export verwenden.
Schützen Sie Ihre Daten mit den jeweils am besten geeigneten Cloud SQL-Funktionen.

Sicherungen und Exporte sind zwei Möglichkeiten, für Datenredundanz und Datenschutz zu sorgen. 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.

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.