Auf dieser Seite finden Sie allgemeine Best Practices, mit denen Sie die Leistung, Zuverlässigkeit und Verfügbarkeit von AlloyDB for PostgreSQL verbessern können. Diese Seite richtet sich an Datenbankadministratoren und Entwickler, die bereits mit AlloyDB und PostgreSQL vertraut sind.
Instanzkonfiguration und -verwaltung
AlloyDB-Tools zum Überwachen der Datenbanknutzung und des Status verwenden.
Betriebsrichtlinien einhalten:
Wartungsfenster für die primäre Instanz konfigurieren
Lesepoolinstanzen hinzufügen, um den Lesetraffic zu reduzieren.
Replikationsverzögerung verwalten
Starten Sie keinen neuen Verwaltungsvorgang, bevor der letzte Vorgang abgeschlossen ist.
Konfigurieren Sie ausreichend Speicherkontingent für kritische Datenbankwartung.
Überlastung der CPU verhindern
Erschöpfung des Arbeitsspeichers vermeiden:
Achten Sie darauf, dass Ihre Instanz optimale Transaktions-IDs hat.
AlloyDB-Tools zum Überwachen der Datenbanknutzung und des Status verwenden
In der folgenden Tabelle finden Sie Informationen zu AlloyDB-Tools, mit denen Sie die Nutzung, den Status und die Leistung Ihrer Datenbank überwachen können.
| AlloyDB-Tool | Beschreibung |
|---|---|
| Performance Snapshot Report | Vergleicht Snapshots von Systemmesswerten zu zwei verschiedenen Zeitpunkten. |
| Query Insights | Mit Query Insights können Sie Probleme bei der Abfrageleistung in AlloyDB-Datenbanken ermitteln, diagnostizieren und verhindern. Es bietet intuitives Self-Service-Monitoring sowie Diagnoseinformationen, die über die Erkennung hinausgehen, sodass Sie die Ursache von Leistungsproblemen ermitteln können. |
| Systemstatistiken | Sie können Datenbankressourcen und ‑messwerte überwachen, darunter die Anzahl aktiver Knoten, CPU-Nutzung, Spitzenverbindungen, Protokollfehler, Transaktionen pro Sekunde und maximale Replikationsverzögerung. |
Betriebsrichtlinien einhalten
Damit Ihre Instanzen vom AlloyDB for PostgreSQL-SLA abgedeckt sind, müssen Sie die Betriebsrichtlinien einhalten.
Wartungsfenster für die primäre Instanz konfigurieren
Konfigurieren Sie für die primäre Instanz ein Wartungsfenster, in dem betriebsunterbrechende Updates erfolgen können. Weitere Informationen finden Sie unter Wartungszeiten ansehen und festlegen.
Lesepoolinstanzen hinzufügen, um Lesezugriffe auszulagern
Fügen Sie für leselastige Arbeitslasten Lesepoolinstanzen hinzu, um den Lesetraffic von der primären Instanz zu entlasten.
Konfigurieren Sie für jede Datenbank in der Instanz einen oder mehrere Lesepools, um das Caching zu verbessern.
Fügen Sie jedem Pool zusätzliche Knoten hinzu, um die automatische Lastverteilung und Hochverfügbarkeit zu ermöglichen.
Replikationsverzögerung verwalten
In AlloyDB wurden mehrere Verbesserungen vorgenommen, um die Replikationsverzögerung zu verringern. Es kann jedoch vorkommen, dass die Log-Wiedergabe blockiert wird oder nicht mithalten kann, was zu einer erhöhten Replikationsverzögerung führen kann.
Wenn die Größe Ihrer primären VM beispielsweise viel größer ist als die Knotengröße Ihres Lesepools, kann es bei hohen Schreibarbeitslasten vorkommen, dass die primäre VM Protokolldatensätze schneller generiert, als die Leseknoten sie wiedergeben können. Das gilt insbesondere, wenn auf den Leseknoten gleichzeitig eine hohe Lese-Arbeitslast ausgeführt wird. In diesem Fall kann es hilfreich sein, die Größe des Leseknotens zu erhöhen, um ihm mehr Ressourcen zur Verfügung zu stellen.
Je nach den Anforderungen Ihrer Anwendung sollten Sie die folgenden Parameter anpassen:
max_standby_streaming_delay: Legt fest, wie lange die Wiederholung wartet, bevor blockierende Anfragen abgebrochen werden.google_storage.log_replay_throttle_read_transactions: Gibt an, ob Abfragen gedrosselt werden sollen, wenn die Verzögerung hoch ist. Durch die Drosselung von Abfragen stehen mehr Ressourcen für die Replay-Funktion zur Verfügung, sodass sie schneller aufholen und vermeiden kann, veraltete Daten für Abfragen zurückzugeben.alloydb.promote_cancel_to_terminate: Gibt an, ob Abfrage-Back-Ends, die nicht auf die Abbrechen-Anfrage reagieren, zwangsweise beendet werden sollen.
Starten Sie keinen neuen Verwaltungsvorgang, bevor der letzte Vorgang abgeschlossen ist.
AlloyDB-Instanzen können keine neuen Vorgangsanfragen annehmen, bis der vorherige Vorgang abgeschlossen ist. Wenn Sie versuchen, einen neuen Vorgang zu starten, bevor der vorherige Vorgang abgeschlossen ist, 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 gibt nur an, ob sich die Instanz im Status RUNNABLE befindet. Wenn Sie wissen möchten, ob gerade ein Vorgang ausgeführt wird, klicken Sie im linken Navigationsbereich auf Vorgänge und sehen Sie sich den Status des letzten Vorgangs an.
Genügend Speicherkontingent für kritische Datenbankwartung konfigurieren
Standardmäßig können Sie bis zu 16 TB Speicher pro Cluster verwenden. Wenn Sie mehr Speicherplatz benötigen, können Sie Ihr Speicherkontingent erhöhen.
Überlastung der CPU verhindern
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 Instanzen überwachen. 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 Ihre Instanz auf eine höhere Anzahl von CPUs skalieren. Zum Ändern von CPUs ist ein Neustart der Instanz erforderlich. Wenn Ihre Instanz bereits die maximale CPU-Anzahl erreicht hat, empfehlen wir, Ihre Datenbank auf mehrere Instanzen aufzuteilen.
Erschöpfung des Arbeitsspeichers vermeiden
AlloyDB verfügt über eine automatische Arbeitsspeicherverwaltung, um Probleme aufgrund von zu wenig Arbeitsspeicher zu vermeiden. Ein konstanter Arbeitsspeicherdruck kann jedoch zu Leistungsproblemen führen. Wenn Sie nach Anzeichen für Speicherausschöpfung suchen, sollten Sie hauptsächlich den Messwert usage verwenden. Für eine optimale Leistung 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 AlloyDB-Instanz verwendet, einschließlich des vom Datenbankcontainer verwendeten Speichers und des vom Cache des Betriebssystems zugewiesenen Speichers.
Anhand des Unterschieds zwischen den Messwerten für die Nutzung und die Gesamtnutzung 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.
Skalieren Sie Ihre AlloyDB-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 Monitoring von Nutzungs- und Gesamtnutzungsmesswerten in der Google Cloud -Konsole finden Sie unter Instanzen überwachen.
Achten Sie darauf, dass Ihre Instanz optimale Transaktions-IDs hat.
Sie können die Transaktions-ID-Nutzung Ihrer Instanz in der Google Cloud Console auf der Seite „Metrics Explorer“ ansehen, indem Sie Resource Type auf AlloyDB for PostgreSQL Database und Metric auf Percentage of instance's transaction IDs consumed festlegen. Weitere Informationen finden Sie unter Diagramme mit dem Metrics Explorer erstellen.
AlloyDB verfügt über ein integriertes adaptives Autovacuum, das hilft, Probleme im Zusammenhang mit VACUUM zu minimieren.
Datenarchitektur
Große Instanzen nach Möglichkeit in kleinere Instanzen aufteilen
Verwenden Sie nicht zu viele Datenbanktabellen.
Teilen Sie große Instanzen nach Möglichkeit in kleinere Instanzen auf.
Verwenden Sie nach Möglichkeit mehrere kleine AlloyDB-Cluster anstelle einer großen 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.
Abfrageleistung
Spaltenbasierte Engine aktivieren, wenn Sie analytische Abfragen ausführen
Instanz hochskalieren, um die Abfrageleistung zu verbessern
Lesepools bereitstellen und Leseanfragen an den Lesepool auslagern:
Spaltenbasierte Engine aktivieren, wenn Sie Analyseabfragen ausführen
Übersicht über die spaltenbasierte Engine von AlloyDB Hier finden Sie Informationen zu den Arten von Anfragen, bei denen die spaltenorientierte Engine von Vorteil ist.
Sie können die Nutzung der spaltenorientierten Engine beobachten.
Wenn Sie die spaltenorientierte Engine noch nicht kennen, sollten Sie sich zuerst mit der automatischen Spaltenerstellung vertraut machen. Anschließend können Sie die Spalten manuell verwalten.
Instanz hochskalieren, um die Abfrageleistung zu verbessern
Wenn die Abfrageleistung niedrig ist, sollten Sie die Instanz hochskalieren.
Für jede SKU sind nur bestimmte vCPU- und Arbeitsspeicherkonfigurationen verfügbar und jede SKU hat nur einen begrenzten schnellen Cache. Wenn Ihre Datenmenge groß ist und die Abfrageleistung schlecht ist, sollten Sie auf eine größere Instanz umstellen.
Lesepools bereitstellen und Leseanfragen an den Lesepool auslagern
Wenn Ihre Anwendung viele Schreib- und Lesevorgänge ausführt, sollten Sie Lesepools bereitstellen und Leseanfragen an den Lesepool auslagern.
Fügen Sie für leselastige Arbeitslasten Lesepoolinstanzen hinzu, um den Lesetraffic von der primären Instanz zu entlasten.
Anwendungsimplementierung
Gute Techniken für das Verbindungsmanagement verwenden
Reaktion der Anwendung auf Wartungsupdates testen:
Reaktion der Anwendung auf Failover testen:
Große Transaktionen vermeiden:
Große Anzahl von untergeordneten Transaktionen vermeiden:
Neueste Version des Auth-Proxys verwenden:
Best Practices für das Verbindungsmanagement nutzen
Greifen Sie auf Best Practices für das Verbindungsmanagement zurück, z. B. Verbindungs-Pooling und exponentiellen Backoff.
Wenn Sie gute Methoden zur Verbindungsverwaltung verwenden, wird die Ressourcennutzung Ihrer Anwendung optimiert und Sie können die Verbindungslimits für AlloyDB einhalten.
Reaktion Ihrer Anwendung auf Wartungsupdates testen
Testen Sie die Reaktion der Anwendung auf Wartungsupdates, die jederzeit während eines Wartungsfensters auftreten können.
Sie können ein Wartungsupdate simulieren, indem Sie Rechenskalierungsvorgänge ausführen oder statische PostgreSQL-Flags aktualisieren, wodurch eine Wartung mit geringer Ausfallzeit (Low Downtime Maintenance, LDTM) ausgelöst wird.
Während des LDTM ist Ihre Instanz für einen kurzen Zeitraum nicht verfügbar und bestehende Verbindungen werden getrennt. Durch das Testen von LDTM erhalten Sie ein besseres Verständnis dafür, wie Ihre Anwendung mit geplanten Wartungsarbeiten umgeht und wie schnell das System wiederhergestellt werden kann.
Reaktion der Anwendung auf Failover testen
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 Google Cloud CLI oder die API starten. Weitere Informationen finden Sie unter Failover initialisieren.
Große Transaktionen vermeiden
Kleine, kurze Transaktionen sind zu bevorzugen. Umfangreiche Datenbankupdates führen Sie besser in mehreren kleinen Transaktionen statt in einer einzelnen großen Transaktion durch.
Viele untergeordnete Transaktionen vermeiden
Vermeiden Sie eine große Anzahl von Untertransaktionen in einer Transaktion, wenn lang andauernde Transaktionen vorhanden sind.
Wenn Sie in AlloyDB eine Transaktion in einem PL/pgSQL-Fehlerblock ausführen, werden Untertransaktionen der Transaktion erstellt, die dem Fehlerblock entspricht. Die Gesamtleistung des Systems verschlechtert sich, wenn die Anzahl der untergeordneten Transaktionen bei lang andauernden Transaktionen 64 überschreitet.
Neueste Version des Auth-Proxys verwenden
Wenn Sie den AlloyDB Auth-Proxy verwenden, achten Sie darauf, dass Sie die neueste Version verwenden. Weitere Informationen finden Sie unter Auth-Proxy-Client auf dem aktuellen Stand halten.
Datenimport und -export
Aus Cloud SQL for PostgreSQL-Sicherungen für die Migration wiederherstellen.
Importe für kleine Instanzen beschleunigen:
Aus Cloud SQL for PostgreSQL-Sicherungen für die Migration wiederherstellen
Informationen zur Migration finden Sie unter Von Cloud SQL for PostgreSQL zu AlloyDB migrieren.
Informationen zum Migrieren von Daten aus Cloud SQL for PostgreSQL zu AlloyDB mit kontinuierlicher Datenreplikation finden Sie unter Database Migration Service für PostgreSQL zu AlloyDB.
Importe für kleine Instanzen beschleunigen
Wenn Sie große Datasets für kleine Instanzen importieren, können Sie vorübergehend die CPU-Zahl und den RAM einer Instanz erhöhen, um die Leistung zu optimieren.
Sicherung und Wiederherstellung
Schützen Sie Ihre Daten mit den entsprechenden AlloyDB-Funktionen.
Instanz und Sicherungen vor versehentlichem Löschen schützen
Daten mit den entsprechenden AlloyDB-Funktionen schützen
Verwenden Sie Sicherungen, die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) und Exporte für Redundanz und Schutz. 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. Die Sicherungsfunktion von AlloyDB hat jedoch einige Einschränkungen. Wenn Sie die Instanz löschen, werden auch die 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 auf einem bestimmten Stand wiederherstellen. 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.
Das Exportieren dauert 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 Tabelle exportieren.
Instanz und Sicherungen vor versehentlichem Löschen schützen
Wenn Sie den standardmäßigen Schutz vor versehentlichem Löschen aktivieren möchten, erstellen Sie eine AlloyDB-Instanz mit der Google Cloud Console oder Terraform.
Verwenden Sie das Exportfeature in AlloyDB, um Ihre Daten für zusätzlichen Schutz zu exportieren. Cloud Scheduler mit der Cloud Scheduler API verwenden, um die Exportverwaltung zu automatisieren.
Für komplexere Szenarien verwenden Sie zur Automatisierung Cloud Scheduler mit Cloud Run-Funktionen.