Betriebsrichtlinien für MySQL-Instanzen

Die SLA-Vereinbarung für Cloud SQL schließt Ausfälle aus, die durch Faktoren außerhalb der Kontrolle von Google verursacht wurden. Auf dieser Seite wird beschrieben, welche nutzerseitig gesteuerten Konfigurationen zu Ausfällen einer Cloud SQL für MySQL-Instanz der zweiten Generation führen können, die vom Cloud SQL-SLA ausgeschlossen sind.

Für Cloud SQL for PostgreSQL- bzw. SQL Server-Instanzen sind zwar noch keine Betriebsrichtlinien verfügbar, aber es gelten die gleichen Grundsätze.

Einführung

Cloud SQL wurde so eingerichtet, dass Sie die größtmögliche Kontrolle über die Konfiguration Ihrer Instanz erhalten. Dies umfasst einige Konfigurationen, die das Risiko von Instanzausfällen in Abhängigkeit von der Last und anderen Konfigurationsparametern erhöhen. Wenn Ihre Instanz ausfällt und Cloud SQL feststellt, dass die auf dieser Seite beschriebenen Betriebsbeschränkungen nicht eingehalten wurden, wird die Ausfallzeit nicht durch das Cloud SQL SLA abgedeckt (bzw. nicht darauf angerechnet).

Sie erhalten hier eine Übersicht über die Betriebsbeschränkungen, damit Sie wissen, bei welchen Konfigurationen diese Risiken auftreten, wie Sie ein versehentliches Wechseln zu einer dieser Konfigurationen vermeiden können und wie Sie die Risiken mindern können, wenn die Konfiguration für Ihr Geschäftsumfeld erforderlich ist.

Ausgeschlossene Konfigurationen

Die ausgeschlossenen Konfigurationen fallen in die folgenden Kategorien:

  • Allgemeine Konfigurationsanforderungen
  • Datenbank-Flag-Werte
  • Ressourcenlimits

Allgemeine Konfigurationsanforderungen

Das SLA deckt nur Cloud SQL-Instanzen ab, die für eine hohe Verfügbarkeit mit mindestens einer dedizierten CPU konfiguriert sind. Instanzen mit gemeinsam genutztem Kern und Instanzen mit einer einzelnen Zone sind vom SLA nicht abgedeckt.

Datenbank-Flag-Werte

Mit Cloud SQL können Sie Ihre Instanz mit Datenbank-Flags konfigurieren. Einige dieser Flags können so eingestellt werden, dass die Stabilität der Instanz oder Langlebigkeit ihrer Daten beeinträchtigt wird.

In der folgenden Tabelle sind die Flags aufgelistet, deren Werte zu einem SLA-Ausschluss führen:

Flag Beschreibung Ausgeschlossene Einstellung Mögliche Auswirkungen Risikominimierung
general_log Aktiviert das allgemeine MySQL-Log. Ist aktiviert, mit dem Flag-Wert TABLE für log_output Langsame Neustarts. Setzen Sie das Flag log_output auf FILE.
slow_query_log Aktiviert das langsame Abfrage-Log von MySQL. Ist aktiviert, mit dem Flag-Wert TABLE für log_output Langsame Neustarts. Setzen Sie das Flag log_output auf FILE.
max_heap_table_size Bestimmt die Größe der Speichertabelle. Größer als der Standardwert Instanzausfall aufgrund eines Fehlers wegen unzureichendem Speicherplatz. Behalten Sie die Standardeinstellung bei.
tmp_table_size Bestimmt die Größe der temporären Tabelle Größer als der Standardwert Instanzausfall aufgrund eines Fehlers wegen unzureichendem Speicherplatz Behalten Sie die Standardeinstellung bei oder planen Sie die Arbeitslast sorgfältig, damit Sie eine Überschreitung der Instanzkapazität vermeiden können.
query_cache_size und query_cache_type Zusammen bestimmen diese Flags die Größe des Abfragecache. Größer als der Standardwert Instanzausfall aufgrund eines Fehlers wegen unzureichendem Speicherplatz Behalten Sie die Standardeinstellung bei oder planen Sie die Arbeitslast sorgfältig, damit Sie eine Überschreitung der Instanzkapazität vermeiden können.

Ressourcenlimits

Diese Ressourcenlimits müssen Sie vermeiden, um die Abdeckung durch das SLA sicherzustellen:

Einschränkung Beschreibung Erkennung Lösung Prävention
Speicher voll Wenn Ihre Instanz keinen ausreichenden Speicherplatz mehr hat und die automatische Speichererweiterung nicht aktiviert ist, wird die Instanz offline geschaltet. Dieser Ausfall ist nicht durch das SLA abgedeckt. Sie können den von Ihrer Instanz belegten Speicherplatz in der Cloud Console auf der Seite "Instanzdetails" ansehen. Weitere Informationen.

Richten Sie eine Stackdriver-Warnung ein, um die Speicherbelegung zu überwachen und Warnungen bei Erreichen eines bestimmten Schwellenwerts zu erhalten. Weitere Informationen

Erhöhen Sie die Speichergröße für die Instanz. Die Speichergröße kann zwar erhöht, aber nicht verringert werden. Aktivieren Sie die automatische Speichererweiterung für die Instanz. Weitere Informationen
CPU überlastet Wenn die CPU-Auslastung sechs Stunden lang bei über 98 % liegt, ist Ihre Instanz nicht richtig für Ihre Arbeitslast dimensioniert. In diesem Fall ist keine SLA-Abdeckung gegeben. Sie können den Prozentsatz der verfügbaren CPU, der von Ihrer Instanz verwendet wird, in der Cloud Console auf der Seite "Instanzdetails" ansehen. Weitere Informationen.

Richten Sie eine Stackdriver-Warnung ein, um die CPU-Auslastung zu überwachen und Warnungen bei Erreichen eines bestimmten Schwellenwerts zu erhalten. Weitere Informationen

Erhöhen Sie die Anzahl der CPUs für Ihre Instanz. Beachten Sie, dass bei einer Änderung der Instanzstufe ein Neustart erforderlich ist.

Wenn Ihre Instanz bereits die maximale CPU-Anzahl erreicht hat, teilen Sie Ihre Datenbank auf mehrere Instanzen auf.

Überwachen Sie die CPU-Auslastung und erhöhen Sie bei Bedarf die CPU-Anzahl. Beachten Sie, dass bei einer Änderung der Instanzstufe ein Neustart erforderlich ist.
Zu viele Datenbanktabellen Wenn in einer einzelnen Instanz 10.000 oder mehr Datenbanktabellen vorhanden sind, kann dies dazu führen, dass die Instanz nicht mehr reagiert oder keine Wartungsvorgänge ausführen kann. Die Instanz ist in diesem Fall nicht vom SLA abgedeckt. So sehen Sie, wie viele Tabellen in Ihrer Instanz vorhanden sind: SELECT COUNT(*) FROM information_schema.tables; So sehen Sie, wie viele Tabellen in jeder Datenbank vorhanden sind: SELECT TABLE_SCHEMA,COUNT(*) FROM information_schema.tables group by TABLE_SCHEMA; Reduzieren Sie die Anzahl der Tabellen auf weniger als 10.000.

Wenn Sie die Tabellenanzahl nicht sofort reduzieren können, können Sie zumindest die Wahrscheinlichkeit verringern, dass Ihre Instanz von der hohen Tabellenanzahl beeinträchtigt wird. Setzen Sie dazu das Flag innodb_file_per_table auf OFF. Durch diese Einstellung wird die Instanz aber nicht wieder SLA-konform.

Wenn Ihre Datenarchitektur viele Tabellen erfordert, teilen Sie die Daten auf mehrere Instanzen auf.