Lesereplikate verwalten

Auf dieser Seite wird beschrieben, wie Lesereplikate verwaltet werden. Diese Vorgänge umfassen das Deaktivieren und Aktivieren der Replikation, das Hochstufen eines Replikats, das Konfigurieren der parallelen Replikation und das Prüfen des Replikationsstatus.

Weitere Informationen zur Funktionsweise von Replikaten finden Sie unter Replikation in Cloud SQL.

Replikation deaktivieren

Standardmäßig beginnt ein Replikat mit aktivierter Replikation. Sie können die Replikation jedoch deaktivieren, zum Beispiel zur Fehlerbehebung oder um den Instanzstatus zu analysieren. Wenn Sie bereit sind, können Sie die Replikation ausdrücklich wieder aktivieren. Durch das Deaktivieren oder erneute Aktivieren der Replikation wird die Replikatinstanz nicht neu gestartet.

Durch das Deaktivieren der Replikation wird die Replikatinstanz nicht gestoppt. Sie wird zu einer schreibgeschützten Instanz, die sich nicht mehr von ihrer primären Instanz repliziert. Für die Instanz fallen weiterhin Kosten an. Auf dem deaktivierten Replikat können Sie die Replikation wieder aktivieren, das Replikat löschen oder es zu einer eigenständigen Instanz hochstufen.

So deaktivieren Sie die Replikation:

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Wählen Sie eine Replikatinstanz, indem Sie auf den Namen klicken.
  3. Klicken Sie in der Schaltflächenleiste auf Replikation deaktivieren.
  4. Klicken Sie auf OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST Version 1

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:patch" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

JSON-Text anfordern:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:patch" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON-Text anfordern:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Replikation aktivieren

Wenn ein Replikat lange nicht mehr repliziert wurde, braucht es einige Zeit, um auf den aktuellen Stand der primären Instanz zu gelangen. Löschen Sie in diesem Fall das Replikat und erstellen Sie ein neues.

So aktivieren Sie die Replikation:

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Wählen Sie eine Replikatinstanz, indem Sie auf den Namen klicken.
  3. Klicken Sie auf Replikation aktivieren.
  4. Klicken Sie auf OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST Version 1

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:patch" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

JSON-Text anfordern:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:patch" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON-Text anfordern:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Replikat hochstufen

Wenn Sie ein Lesereplikat hochstufen, wird die Replikation beendet und die Instanz in eine eigenständige primäre Cloud SQL-Instanz mit Lese- und Schreibfunktionen umgewandelt.

Beim Hochstufen werden Lesereplikate automatisch mit Sicherungen konfiguriert. Sie werden jedoch nicht automatisch als Hochverfügbarkeitsinstanzen konfiguriert. Allerdings können Sie Hochverfügbarkeit nach dem Hochstufen des Replikats wie bei jeder Nicht-Replikatinstanz aktivieren. Die Konfiguration eines Lesereplikats für Hochverfügbarkeit erfolgt auf die gleiche Weise wie für eine primäre Instanz. Mehr über das Konfigurieren von Instanzen für Hochverfügbarkeit erfahren

Bevor Sie ein Lesereplikat hochstufen, sofern die primäre Instanz noch verfügbar ist und für Clients ausgeführt wird, sollten Sie Folgendes tun:

  1. Beenden Sie alle Schreibvorgänge an die primäre Instanz.
  2. Prüfen Sie den Replikationsstatus des Replikats. Folgen Sie dazu der Anleitung auf dem Tab psql-Client.
  3. Sie sollten kontrollieren, dass das Replikat die Replikation ausführt, und dann warten, bis die vom Messwert replay_lag gemeldete Replikationsverzögerung 0 ist.

Andernfalls fehlen in einer neu hochgestuften Instanz möglicherweise einige Transaktionen, für die in der Primärinstanz ein Commit durchgeführt wurde.

So stufen Sie ein Replikat zu einer eigenständigen Instanz hoch:

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Wählen Sie eine Replikatinstanz, indem Sie auf den Namen klicken.
  3. Klicken Sie auf Replikat heraufstufen.
  4. Klicken Sie auf OK.

gcloud

gcloud sql instances promote-replica REPLICA_NAME

REST Version 1

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:promoteReplica" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

REST v1beta4

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:promoteReplica" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Prüfen Sie, ob die hochgestufte Instanz korrekt konfiguriert ist. Insbesondere sollten Sie bei Bedarf die Instanz für Hochverfügbarkeit konfigurieren.

Replikationsstatus prüfen

Wenn Sie eine Replikatinstanz mit der Google Cloud Console aufrufen oder sich bei einem Verwaltungsclient bei der Instanz anmelden, erhalten Sie Details zur Replikation, einschließlich Status und Messwerten. Wenn Sie die gcloud CLI verwenden, erhalten Sie eine kurze Zusammenfassung der Replikationskonfiguration.

Bevor Sie den Replikationsstatus einer Cloud SQL-Replikatinstanz prüfen, rufen Sie mit dem Befehl
gcloud sql instances describe den Status der Instanz auf. Sie können so feststellen, ob die Replikation für die Replikatinstanz aktiviert ist.

Die folgenden Messwerte stehen für Replikatinstanzen zur Verfügung. (Weitere Informationen zu zusätzlichen Messwerten, die für alle Instanzen verfügbar sind, einschließlich Nicht-Replikatinstanzen.)

MesswertBeschreibung
Replikationsstatus
(cloudsql.googleapis.com/database/replication/state)

Gibt an, ob die Replikation aktiv Logs von der primären zur Replikatdatenbank streamt. Folgende Werte sind möglich:

  • Running
  • Stopped
  • Error

Dieser Messwert gibt Running an, wenn:

  1. pg_catalog.pg_stat_wal_receiver einen status von „Streaming” meldet und
  2. pg_catalog.pg_is_wal_replay_paused() „f” (false).

Weitere Informationen finden Sie unter The Statistics Collector und Systemadministrationsfunktionen im PostgreSQL-Referenzhandbuch.
Verzögerung der Replikation
(cloudsql.googleapis.com/database/replication/replica_lag)

Die Zeit, in der der Status des Replikats vom Status der primären Instanz verzögert wird. Dies ist die Differenz zwischen (1) der aktuellen Zeit und (2) dem ursprünglichen Zeitstempel, zu dem der Primärserver die Transaktion festgeschrieben hat, die derzeit auf das Replikat angewendet wird. Insbesondere können Schreibvorgänge als verzögert gezählt werden, selbst wenn sie vom Replikat empfangen wurden, wenn das Replikat den Schreibvorgang noch nicht auf die Datenbank angewendet hat.

Bei kaskadierenden Replikaten wird jedes primäre Replikatpaar separat überwacht und es gibt keinen einzelnen Messwert, der die End-to-End-Verzögerung (Primär-zu-Replikat) verursacht.

Weitere Informationen finden Sie unter Replikationsverzögerung.
Verzögerung in Byte
(cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag)

Gibt die Anzahl der Byte an, um die das Lesereplikat der primären Instanz nacheilt. Für jedes Replikat werden vier Zeitachsen erstellt, aus denen die Anzahl der Byte im Write-Ahead-Log der primären Instanz angezeigt wird, die noch nicht …

  • sent_location: … an das Replikat gesendet wurden
  • write_location: … vom Replikat auf das Laufwerk geschrieben wurden
  • flush_location: … vom Replikat auf das Laufwerk geleert wurden
  • replay_location: … vom Replikat noch einmal wiedergegeben wurden

Diese Messwerte dienen unterschiedlichen Zwecken, Beispiel: replay_location gibt Aufschluss über die Replikationsverzögerung (die Anzahl der Transaktionen, die per Commit an die primäre Instanz übergeben werden und noch nicht auf das Replikat angewendet wurden). flush_location gibt an, wie viele Transaktionen für die Replikatinstanz nicht dauerhaft aufgezeichnet wurden.

Diese Messwerte werden durch einen Vergleich von pg_catalog.pg_current_wal_lsn() mit einem der folgenden Felder aus pg_stat_replication verglichen: sent_lsn, write_lsn, flush_lsn oder replay_lsn. Weitere Informationen finden Sie unter The Statistics Collector im PostgreSQL Reference Manual.
Maximale Verzögerung in Byte
(cloudsql.googleapis.com/database/postgresql/external_sync/max_replica_byte_lag)

Für ein Replikat einer externen primären Datenbank wird die maximale Replikationsverzögerung (in Byte) für alle Datenbanken gemeldet, die in diese Instanz repliziert werden. Dieser Wert wird für jede Datenbank als die Anzahl der Byte im Write-Ahead-Log der primären Datenbank definiert, die vom Replikat noch nicht bestätigt wurden.

Dieser Messwert wird dadurch berechnet, dass eine Abfrage an die primäre Datenbank gesendet wird, um pg_catalog.pg_current_wal_lsn() mit dem Wert von confirmed_flush_lsn für jede Datenbank zu vergleichen, die in dieser Replikatinstanz repliziert wird. Weitere Informationen finden Sie unter The Statistics Collector im PostgreSQL Reference Manual.

So prüfen Sie den Replikationsstatus:

Console

Cloud SQL meldet den Messwert Replication State im standardmäßigen Cloud SQL-Monitoring-Dashboard.

Wenn Sie andere Messwerte für regionale und regionenübergreifende Replikate und Replikate externer Server sehen möchten, erstellen Sie ein benutzerdefiniertes Dashboard und fügen Sie die Messwerte hinzu, die Sie überwachen möchten:

  1. Rufen Sie in der Google Cloud Console die Seite Monitoring auf.

    Zu Monitoring

  2. Wählen Sie den Tab Dashboards aus.
  3. Klicken Sie auf Dashboard erstellen.
  4. Geben Sie einen Namen für das Dashboard ein und klicken Sie auf „OK“.
  5. Klicken Sie auf Diagramm hinzufügen.
  6. Wählen Sie als Ressourcentyp die Option Cloud SQL-Datenbank aus.
  7. Sie haben folgende Möglichkeiten:
    1. Um den Replikationsstatuswert zu beobachten, geben Sie im Feld Messwert auswählen Replication state ein. Fügen Sie dann einen Filter für state = "Running" hinzu. Das Diagramm zeigt 1, wenn die Replikation ausgeführt wird, andernfalls 0.
    2. Wenn Sie die Replikationsverzögerung in Byte für ein Lesereplikat überwachen möchten, geben Sie im Feld Messwert auswählen Lag Bytes ein. Fügen Sie dann einen Filter für replica_lag_type = "replay_location" hinzu. Das Diagramm zeigt die Anzahl der Byte, die mit Transaktionen verknüpft sind, die auf der primären Instanz zum Commit übergeben wurden, auf dem Replikat jedoch noch nicht wiedergegeben wurden.
    3. Um die Replikationsverzögerung in Byte für ein Replikat einer externen primären Instanz zu überwachen, geben Sie im Feld Messwert auswählen Max Lag Bytes ein. Das Diagramm zeigt die Anzahl der Byte an, die Transaktionen zugeordnet sind, die mit dem Commit an die primäre Instanz übergeben wurden, für die der Empfang beim Replikat aber noch nicht bestätigt wurde.

gcloud

Prüfen Sie den Replikationsstatus einer Replikatinstanz mit:

gcloud sql instances describe REPLICA_NAME

Suchen Sie in der Ausgabe nach den Attributen databaseReplicationEnabled und masterInstanceName.

Prüfen Sie auf vorhandene Replikate einer primären Instanz mit:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Suchen Sie in der Ausgabe nach dem Attribut replicaNames.

psql-Client

Einige Messwerte zum Replikationsstatus werden von der primären Instanz erstellt und andere vom Replikat. Stellen Sie für die folgenden Schritte eine Verbindung zum Replikat oder zur primären Instanz (wie unten beschrieben) mit einem PostgreSQL-Client her.

Weitere Information finden Sie unter Verbindungsoptionen für externe Anwendungen.

  1. So kontrollieren Sie den Status des Replikats über die primäre Instanz: 
    select * from pg_stat_replication;
     Suchen Sie dafür die folgenden Messwerte in den Ausgabedaten des Befehls:
    • client_addr: Die IP-Adresse der Replikatinstanz.
    • state: Gibt an, ob der SQL-Thread zum Ausführen von Ereignissen im Relay-Log ausgeführt wird. Der Wert lautet streaming beim Start der Replikation.
    • replay_lag: Die Anzahl von Byte, die der Replikat-SQL-Thread hinter der primären Instanz zurückliegt. Der Wert ist O oder eine kleine Anzahl von Byte.
  2. So prüfen Sie den Replikatstatus über die Replikatinstanz: 
    select * from pg_stat_wal_receiver;

    Suchen Sie die folgenden Messwerte in den Ausgabedaten des Befehls:

    • sender_host: Gibt die IP-Adresse der primären Instanz an.
    • status: Gibt an, ob der SQL-Thread zum Ausführen von Ereignissen im Relay-Log ausgeführt wird. Der Wert lautet streaming beim Start der Replikation.
    • last_msg_send_time und last_msg_receipt_time: Die Differenz zwischen diesen beiden Zeitstempeln ist die Verzögerungszeit.

    So prüfen Sie, ob die Replikation pausiert wurde:

    select pg_is_wal_replay_paused();

    Der Wert ist t, wenn die Replikation pausiert wurde, andernfalls f.

    So prüfen Sie, ob Transaktionen vorhanden sind, die von der primären Instanz empfangen, aber noch nicht angewendet wurden:

    # for PostgreSQL 9.6
select pg_catalog.pg_last_xlog_receive_location(), pg_catalog.pg_last_xlog_replay_location();
# for PostgreSQL 10 and above
select pg_catalog.pg_last_wal_receive_lsn(), pg_catalog.pg_last_wal_replay_lsn();

    Wenn die beiden Werte gleich sind, hat das Replikat alle Transaktionen verarbeitet, die es von der primären Instanz empfangen hat.

  • Weitere Details zur Ausgabe dieser Befehle finden Sie in der PostgreSQL-Dokumentation unter The Statistics Collector.

    • Fehlerbehebung

    Problem Fehlerbehebung
    Beim Erstellen hat das Lesereplikat nicht repliziert. Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.
    Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler Eines der Flags in der Anfrage ist ungültig. Dies kann ein Flag sein, das Sie explizit angegeben haben, oder ein Flag, für das ein Standardwert festgelegt wurde.

    Prüfen Sie als Erstes, ob der Wert des Flags max_connections größer oder gleich dem Wert auf der primären Instanz ist.

    Wenn das Flag max_connections korrekt festgelegt ist, prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.
    Lesereplikat kann nicht erstellt werden – unbekannter Fehler. Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.

    Lautet der Fehler set Service Networking service account as servicenetworking.serviceAgent role on consumer project, deaktivieren Sie die Service Networking API und aktivieren Sie sie dann wieder. Dadurch wird das Dienstkonto erstellt, das erforderlich ist, um den Prozess fortzusetzen.
    Laufwerk ist voll. Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden. Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren.
    Der Speicherplatz wird erheblich erhöht. Ein Slot, der nicht aktiv zum Erfassen von Daten verwendet wird, führt dazu, dass PostgreSQL unbegrenzt auf WAL-Segmente hält. Dadurch wird der Speicherplatz auf unbestimmte Zeit größer. Wenn Sie die Funktionen zur logischen Replikation und Decodierung in Cloud SQL verwenden, werden Replikationsslots automatisch erstellt und gelöscht. Nicht verwendete Replikationsslots können durch Abfrage der Systemansicht pg_replication_slots und Filterung der Spalte active erkannt werden. Nicht verwendete Slots können verworfen werden, um WAL-Segmente mit dem pg_drop_replication_slot-Befehl zu entfernen.
    Die Replikatinstanz verwendet zu viel Arbeitsspeicher. Das Replikat verwendet temporären Speicher zum Speichern häufig angeforderter Lesevorgänge im Cache, was dazu führen kann, dass es mehr Speicher als die primäre Instanz verwendet.

    Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.
    Replikation gestoppt. Das maximale Speicherlimit wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert.

    Bearbeiten Sie die Instanz, um automatic storage increase zu aktivieren.
    Replikationsverzögerung ist durchgehend hoch. Die Schreiblast ist für das Replikat zu hoch. Die Replikationsverzögerung tritt auf, wenn der SQL-Thread auf einem Replikat nicht mit dem E/A-Thread Schritt halten kann. Einige Arten von Abfragen oder Arbeitslasten können vorübergehend oder dauerhaft zu einer hohen Replikationsverzögerung für ein bestimmtes Schema führen. Typische Ursachen für Replikationsverzögerungen sind:
    • Langsame Abfragen des Replikats. Suchen Sie diese und korrigieren Sie sie.
    • Alle Tabellen müssen einen eindeutigen Schlüssel/Primärschlüssel haben. Jede Aktualisierung einer solchen Tabelle ohne eindeutigen bzw. Primärschlüssel führt zu vollständigen Tabellenscans auf dem Replikat.
    • Abfragen wie DELETE ... WHERE field < 50000000 führen bei der zeilenbasierten Replikation zu einer Replikationsverzögerung, da sich eine große Anzahl von Aktualisierungen auf dem Replikat ansammelt.

    Hier einige mögliche Lösungen:

    • Bearbeiten Sie die Instanz, um die Größe des Replikats zu erhöhen.
    • Reduzieren Sie die Belastung der Datenbank.
    • Senden Sie Lesetraffic an das Lesereplikat.
    • Indexieren Sie die Tabellen.
    • Ermitteln und beheben Sie Probleme mit langsamen Schreibabfragen.
    • Erstellen Sie das Replikat neu.
    Fehler beim Neuerstellen von Indexen in PostgreSQL 9.6. Sie erhalten von PostgreSQL einen Fehler, der Sie darüber informiert, dass Sie einen bestimmten Index neu erstellen müssen. Dies kann nur auf der primären Instanz durchgeführt werden. Wenn Sie eine neue Replikatinstanz erstellen, erhalten Sie bald wieder denselben Fehler. Hashindexe werden in PostgreSQL-Versionen unter 10 nicht an Replikate weitergegeben.

    Wenn Sie Hashindexe verwenden müssen, führen Sie ein Upgrade auf PostgreSQL 10 oder höher durch. Wenn Sie allerdings ebenfalls Replikate verwenden möchten, verwenden Sie in PostgreSQL 9.6 keine Hashindexe.
    Die Abfrage auf der primären Instanz wird immer ausgeführt. Nach dem Erstellen eines Replikats wird davon ausgegangen, dass die Abfrage SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' kontinuierlich auf Ihrer primären Instanz ausgeführt wird.
    Die Replikaterstellung schlägt bei Zeitüberschreitung fehl. Langlaufende Transaktionen ohne Commit auf der primären Instanz können dazu führen, dass die Lesereplikaterstellung fehlschlägt.

    Erstellen Sie das Replikat neu, nachdem alle laufenden Abfragen beendet sind.
    Wenn die primäre Instanz und das Replikat unterschiedliche vCPU-Größen haben, kann es zu Problemen bei der Abfrageleistung kommen, da die Abfrageoptimierung die vCPU-Größen berücksichtigt.

    So beheben Sie das Problem:

    1. Aktivieren Sie das Flag log_duration und setzen Sie den Parameter log_statement auf ddl. Dadurch erhalten Sie sowohl die Abfragen als auch die Laufzeit für die Datenbank. Je nach Arbeitslast kann dies jedoch zu Leistungsproblemen führen.
    2. Führen Sie sowohl auf der primären Instanz als auch auf dem Lesereplikat explain analyze für die Abfragen aus.
    3. Vergleichen Sie den Abfrageplan und prüfen Sie, ob Unterschiede vorliegen.

    Wenn dies eine bestimmte Abfrage ist, ändern Sie diese. Sie können beispielsweise die Reihenfolge der Joins ändern, um zu sehen, ob Sie eine bessere Leistung erzielen.

    Nächste Schritte