Fehlerbehebung für Amazon Aurora - Amazon Aurora
Verbindung zur -DB-Instance kann nicht hergestellt werdenSicherheitsproblemeZurücksetzen des Besitzerpassworts der DB-InstanceAusfall oder Neustart einer DB-InstanceParameteränderungen wirken sich nicht ausProbleme mit dem freien Aurora-SpeicherProbleme mit der SQL Replikation von Aurora My

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung für Amazon Aurora

Verwenden Sie die folgenden Abschnitte, um Probleme zu beheben, die Sie mit DB-Instances in Amazon RDS und Amazon Aurora haben.

Informationen zu Debugging-Problemen mit Amazon finden Sie RDS API unterFehlerbehebung für Anwendungen in Aurora.

Es kann keine Verbindung zur Amazon RDS DB-Instance hergestellt werden

Wenn Sie keine Verbindung zu einer DB-Instance herstellen können, sind die folgenden Punkte häufige Ursachen:

  • Regeln für eingehenden Datenverkehr – Die von Ihrer lokalen Firewall erzwungenen Zugriffsregeln und die für den Zugriff auf Ihre DB-Instance autorisierten IP-Adressen stimmen möglicherweise nicht überein. Das Problem sind höchstwahrscheinlich die Regeln für eingehenden Datenverkehr in Ihrer Sicherheitsgruppe.

    Standardmäßig erlauben DB-Instances keinen Zugriff. Der Zugriff wird über eine der zugeordnete Sicherheitsgruppe gewährtVPC, die den Datenverkehr in und aus der DB-Instance ermöglicht. Fügen Sie der Sicherheitsgruppe bei Bedarf Regeln für eingehenden und ausgehenden Datenverkehr für Ihre besondere Situation hinzu. Sie können eine IP-Adresse, einen Bereich von IP-Adressen oder eine andere VPC Sicherheitsgruppe angeben.

    Anmerkung

    Wenn Sie eine neue Regel für eingehenden Datenverkehr hinzufügen, können Sie für Source (Quelle) die Option My IP (Meine IP) auswählen, um den Zugriff auf die DB-Instance von der in Ihrem Browser erkannten IP-Adresse zu ermöglichen.

    Weitere Informationen zum Einrichten von Sicherheitsgruppen finden Sie unter Ermöglichen Sie den Zugriff auf den DB-Cluster in der, VPC indem Sie eine Sicherheitsgruppe erstellen.

    Anmerkung

    Client-Verbindungen von IP-Adressen im Bereich 169.254.0.0/16 sind nicht erlaubt. Dies ist der automatische private IP-Adressierungsbereich (APIPA), der für die Adressierung lokaler Links verwendet wird.

  • Öffentlicher Zugriff — Um von außerhalb eine Verbindung zu Ihrer DB-Instance herzustellenVPC, z. B. mithilfe einer Client-Anwendung, muss der Instance eine öffentliche IP-Adresse zugewiesen sein.

    Um die Instance öffentlich zugänglich zu machen, ändern Sie sie und wählen Sie unter Public accessibility (Öffentlicher Zugriff) die Option Yes (Ja) aus. Weitere Informationen finden Sie unter Einen in einem VPC aus dem Internet verstecken.

  • Port – Der Port, den Sie beim Erstellen der DB-Instance angegeben haben, kann aufgrund Ihrer lokalen Firewall-Beschränkungen nicht zum Senden oder Empfangen von Nachrichten verwendet werden. Wenden Sie sich an Ihren Netzwerkadministrator, um herauszufinden, ob Ihr Netzwerk den angegebenen Port für eingehende und ausgehende Kommunikation zulässt.

  • Verfügbarkeit – Bei einer neu erstellten DB-Instance lautet ihr Status creating, bis die DB-Instance bereit für die Verwendung ist. Wenn sich der Status in available ändert, können Sie die Verbindung zur DB-Instance herstellen. Abhängig von der Größe Ihrer DB-Instance kann es bis zu 20 Minuten dauern, bevor eine Instance verfügbar ist.

  • Internet-Gateway – Damit öffentlich auf eine DB-Instance zugegriffen werden kann, müssen die Subnetze in seiner DB-Subnetzgruppe über ein Internet-Gateway verfügen.

    So konfigurieren Sie ein Internet-Gateway für ein Subnetz

    1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/.

    2. Wählen Sie im Navigationsbereich Databases (Datenbanken) und dann den Namen der DB-Instance aus.

    3. Notieren Sie sich auf der Registerkarte Konnektivität und Sicherheit die Werte der VPC ID unter VPCund der Subnetz-ID unter Subnetze.

    4. Öffnen Sie die VPC Amazon-Konsole unter https://console.aws.amazon.com/vpc/.

    5. Wählen Sie im Navigationsbereich Internet Gateways aus. Stellen Sie sicher, dass ein Internet-Gateway an Ihr angeschlossen istVPC. Falls nicht, wählen Sie Create Internet Gateway, um ein Internet-Gateway zu erstellen. Wählen Sie das Internet-Gateway aus und wählen Sie dann Anhängen an VPC. Folgen Sie den Anweisungen, um es an Ihr Gerät anzuschließenVPC.

    6. Wählen Sie im Navigationsbereich die Option Subnets und dann Ihr Subnetz aus.

    7. Stellen Sie auf der Registerkarte Routentabelle sicher, dass es eine Route mit 0.0.0.0/0 dem Ziel und das Internet-Gateway für Sie VPC als Ziel gibt.

      Wenn Sie über deren IPv6 Adresse eine Verbindung zu Ihrer Instance herstellen, stellen Sie sicher, dass es eine Route für den gesamten IPv6 Datenverkehr (::/0) gibt, die auf das Internet-Gateway verweist. Andernfalls gehen Sie wie folgt vor:

      1. Wählen Sie die ID der Routing-Tabelle (rtb-xxxxxxxx) aus, um zur Routing-Tabelle zu gelangen.

      2. Klicken Sie auf der Registerkarte Routes (Routen) auf Edit routes (Routen bearbeiten). Wählen Sie Add route (Route hinzufügen) aus, verwenden Sie 0.0.0.0/0 als Ziel und das Internet-Gateway als Ziel.

        Wählen Sie für IPv6 Route hinzufügen, ::/0 als Ziel verwenden und das Internet-Gateway als Ziel aus.

      3. Wählen Sie Save Rules (Routen speichern) aus.

      Wenn Sie versuchen, eine Verbindung zum IPv6 Endpunkt herzustellen, stellen Sie außerdem sicher, dass der IPv6 Client-Adressbereich autorisiert ist, eine Verbindung zur DB-Instance herzustellen.

    Weitere Informationen finden Sie unter Arbeiten mit einem in einem VPC.

Testen der Verbindung zu einer DB-Instance

Sie können Ihre Verbindung zu einer DB-Instance mit gängigen Linux- oder Microsoft Windows-Tools testen.

Sie können die Verbindung über ein Linux- oder Unix-Terminal testen, indem Sie Folgendes eingeben. Ersetzen Sie DB-instance-endpoint durch den Endpunkt und port durch den Port Ihrer DB-Instance.

nc -zv DB-instance-endpoint port

Das folgende Beispiel zeigt einen Beispielbefehl und den Rückgabewert.

nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299

  Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

Windows-Benutzer können Telnet verwenden, um die Verbindung zu einer DB-Instance zu testen. Telnet-Aktionen werden nur zum Testen der Verbindung unterstützt. Wenn eine Verbindung erfolgreich ist, gibt die Aktion keine Nachricht zurück. Wenn eine Verbindung nicht erfolgreich ist, erhalten Sie eine Fehlermeldung wie die folgende.

C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819

  Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
  connection to the host, on port 819: Connect failed

Wenn Telnet-Aktionen erfolgreich sind, wurde Ihre Sicherheitsgruppe ordnungsgemäß konfiguriert.

Anmerkung

Amazon akzeptiert RDS keinen Datenverkehr mit dem Internet Control Message Protocol (ICMP), einschließlich Ping.

Fehlerbehebung bei der Verbindungsauthentifizierung

In einigen Fällen können Sie eine Verbindung mit Ihrer DB-Instance herstellen, erhalten jedoch Authentifizierungsfehler. In diesen Fällen sollten Sie das Hauptbenutzerpasswort für die DB-Instance zurücksetzen. Sie können dies tun, indem Sie die RDS Instance ändern.

RDSSicherheitsprobleme bei Amazon

Um Sicherheitsprobleme zu vermeiden, verwenden Sie niemals Ihre AWS-Konto Root-Benutzer-E-Mail-Adresse und Ihr Passwort für ein Benutzerkonto. Es empfiehlt sich, Ihren Root-Benutzer zu verwenden, um Benutzer zu erstellen und diese DB-Benutzerkonten zuzuweisen. Sie können Ihren Root-Benutzer auch verwenden, um bei Bedarf weitere Benutzerkonten zu erstellen.

Informationen zum Erstellen von Benutzern finden Sie unter Erstellen eines IAM Benutzers in Ihrem AWS-Konto. Informationen zum Erstellen von Benutzern in AWS IAM Identity Center finden Sie unter Identitäten verwalten in IAM Identity Center.

Fehlermeldung „Failed to retrieve account attributes, certain console functions may be impaired (Fehler beim Abrufen von Kontoattributen, bestimmte Konsolenfunktionen können beeinträchtigt sein).“

Dieser Fehler kann verschiedene Ursachen haben. Es kann daran liegen, dass Ihrem Konto Berechtigungen fehlen oder Ihr Konto nicht ordnungsgemäß eingerichtet wurde. Wenn Ihr Konto neu ist, haben Sie möglicherweise nicht abgewartet, bis das Konto bereit ist. Wenn dies ein vorhandenes Konto ist, könnten Berechtigungen in Ihren Zugriffsrichtlinien fehlen, um bestimmte Aktionen auszuführen, wie z. B. das Erstellen einer DB-Instance. Um das Problem zu beheben, muss Ihr Administrator die erforderlichen Rollen für Ihr Konto bereitstellen. Weitere Informationen finden Sie in der IAM Dokumentation.

Zurücksetzen des Besitzerpassworts der DB-Instance

Wenn Sie aus Ihrem DB--Cluster ausgesperrt werden, können Sie sich als Hauptbenutzer anmelden. Anschließend können Sie die Anmeldeinformationen für andere administrative Benutzer oder Rollen zurücksetzen. Wenn Sie sich nicht als Hauptbenutzer anmelden können, kann der AWS Kontoinhaber das Masterbenutzer-Passwort zurücksetzen. Weitere Informationen zu den Administratorkonten oder -rollen, die Sie möglicherweise zurücksetzen müssen, finden Sie unter Berechtigungen von Hauptbenutzerkonten.

Sie können das DB-Instance-Passwort ändern, indem Sie die RDS Amazon-Konsole modify-db-instance, den AWS CLI Befehl oder die odifyDBInstanceAPIM-Operation verwenden. Weitere Informationen zum Ändern einer DB-Instance in einen DB-Cluster finden Sie unter Ändern einer DB-Instance in einem DB-Cluster.

Ausfall oder Neustart der Amazon RDS DB-Instance

Ein Ausfall der DB-Instance kann auftreten, wenn eine DB-Instance neu gestartet wird. Er kann auch auftreten, wenn die DB-Instance in einen Zustand versetzt wird, der den Zugriff darauf verhindert, und wenn die Datenbank neu gestartet wird. Ein Neustart kann erfolgen, wenn Sie Ihre DB-Instance manuell neu starten. Ein Neustart kann auch auftreten, wenn Sie eine DB-Instance-Einstellung ändern, für die ein Neustart erforderlich ist, um wirksam zu werden.

Ein Neustart der DB-Instance tritt auf, wenn Sie eine Einstellung ändern, für die ein Neustart erforderlich ist, oder wenn Sie einen Neustart manuell durchführen. Ein Neustart kann sofort erfolgen, wenn Sie eine Einstellung ändern und die Änderung sofort wirksam werden soll. Oder er kann während des Wartungsfensters der DB-Instance auftreten.

Ein Neustart der DB-Instance wird sofort ausgeführt, wenn eine der folgenden Situationen eintritt:

  • Sie ändern den Aufbewahrungszeitraum für Backups für eine DB-Instance von 0 auf einen Wert ungleich Null oder von einem Wert ungleich Null auf 0. Anschließend legen Sie Apply Immediately (Sofort anwenden) auf true fest.

  • Sie ändern die DB-Instance-Klasse und Apply Immediately (Direkt anwenden) ist auf true eingestellt.

Ein Neustart der DB-Instance tritt während des Wartungsfensters auf, wenn eine der folgenden Situationen eintritt:

  • Sie ändern den Aufbewahrungszeitraum für Backups für eine DB-Instance von 0 auf einen Wert ungleich Null oder von einem Wert ungleich Null auf 0 und Apply Immediately (Direkt anwenden) ist auf false festgelegt.

  • Sie ändern die DB-Instance-Klasse und Apply Immediately (Direkt anwenden) ist auf false eingestellt.

Wenn Sie einen statischen Parameter in einer DB-Parametergruppe ändern, wird die Änderung erst wirksam, wenn die der Parametergruppe zugeordnete DB-Instance neu gestartet wird. Die Änderung erfordert einen manuellen Neustart. Die DB-Instance wird während des Wartungsfensters nicht automatisch neu gestartet.

Amazon RDS DB-Parameteränderungen werden nicht wirksam

In einigen Fällen können Sie einen Parameter in einer DB-Parametergruppe ändern, aber die Änderungen werden nicht wirksam. Wenn dies der Fall ist, müssen Sie wahrscheinlich die DB-Instance, die der DB-Parametergruppe zugeordnet ist, neu starten. Wenn Sie einen dynamischen Parameter ändern, wird die Änderung sofort wirksam. Wenn Sie einen statischen Parameter ändern, wird die Änderung erst wirksam, wenn Sie die der Parametergruppe zugeordnete DB-Instance neu starten.

Sie können eine DB-Instance über die RDS Konsole neu starten. Oder Sie können den RebootDBInstanceAPIVorgang explizit aufrufen. Sie können ohne Failover neu starten, wenn sich die DB-Instance in einer Multi-AZ-Bereitstellung befindet. Die Anforderung, die zugehörige DB-Instance nach einer Änderung eines statischen Parameters neu zu starten, trägt dazu bei, das Risiko zu verringern, dass sich eine Fehlkonfiguration eines Parameters auf einen API Aufruf auswirkt. Ein Beispiel hierfür ist der Aufruf von ModifyDBInstance zur Änderung der DB-Instance-Klasse. Weitere Informationen finden Sie unter Ändern von Parametern in einer DB-Parametergruppe in Amazon Aurora.

Freier Speicher ist der gesamte Direktzugriffsspeicher (RAM) einer DB-Instance, der der Datenbank-Engine zur Verfügung gestellt werden kann. Es ist die Summe aus dem freien Arbeitsspeicher des Betriebssystems und dem verfügbaren Puffer- und Seitencache-Speicher. Die Datenbank-Engine verwendet den größten Teil des Speichers auf dem Host, aber auch Betriebssystemprozesse verwenden einen Teil RAM des Speichers. Speicher, der derzeit der Datenbank-Engine zugewiesen oder von Betriebssystemprozessen verwendet wird, ist nicht im freisetzbaren Speicher enthalten. Wenn der Datenbank-Engine der Speicher ausgeht, kann die DB-Instance den temporären Speicherplatz nutzen, der normalerweise zum Puffern und Zwischenspeichern verwendet wird. Wie bereits erwähnt, ist dieser temporäre Speicherplatz im freisetzbaren Speicher enthalten.

Sie verwenden die FreeableMemory Metrik in Amazon CloudWatch , um den freien Speicher zu überwachen. Weitere Informationen finden Sie unter Überwachungstools für Amazon Aurora.

Wenn Ihre DB-Instance ständig wenig möglichen freien Speicher hat oder Auslagerungsbereiche verwendet, erwägen Sie, auf eine größere DB-Instance-Klasse hochzuskalieren. Weitere Informationen finden Sie unter Amazon Aurora Aurora-DB-Instance-Klassen.

Sie können auch die Speichereinstellungen ändern. In Aurora My SQL können Sie SQL beispielsweise die Größe des innodb_buffer_pool_size Parameters anpassen. Dieser Parameter ist standardmäßig auf 75 Prozent des physischen Speichers festgelegt. Weitere Tipps SQL zur Problembehebung finden Sie unter Wie kann ich einen Mangel an freiem Speicherplatz in einer Amazon RDS for SQL My-Datenbank beheben?

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Aurora Serverless v2, FreeableMemory steht für die Menge an ungenutztem Speicher, die verfügbar ist, wenn Aurora Serverless v2 Die DB-Instance wird auf ihre maximale Kapazität skaliert. Möglicherweise haben Sie die Instance auf relativ niedrige Kapazität herunterskaliert, aber sie meldet immer noch einen hohen Wert für FreeableMemory, weil die Instance hochskalieren kann. Dieser Speicher ist derzeit nicht verfügbar, aber Sie können ihn bei Bedarf erhalten.

Für jede Aurora-Kapazitätseinheit (ACU), bei der die aktuelle Kapazität unter der maximalen Kapazität liegt, FreeableMemory steigt sie um etwa 2 GiB. Daher nähert sich diese Metrik erst null, wenn die DB-Instance so hoch wie möglich hochskaliert ist.

Wenn sich diese Metrik dem Wert 0 nähert, ist die DB-Instance möglichst hoch skaliert. Sie nähert sich der Grenze des verfügbaren Speichers. Erwägen Sie, die maximale ACU Einstellung für den Cluster zu erhöhen. Wenn sich diese Metrik dem Wert 0 nähert, erwägen Sie bei einer Reader-DB-Instance, dem Cluster weitere Reader-DB-Instances hinzuzufügen. Auf diese Weise können Sie den schreibgeschützten Teil der Workload auf mehrere DB-Instances verteilen und so die Speicherauslastung für jede Reader-DB-Instance reduzieren. Weitere Informationen finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2.

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Aurora Serverless v1, Sie können den Kapazitätsbereich ändern, um mehr zu nutzenACUs. Weitere Informationen finden Sie unter Ändern eines Aurora Serverless v1-DB-Clusters.

Amazon Aurora Meine SQL Replikationsprobleme

Einige Probleme mit der SQL My-My-Replikation gelten auch für Aurora MySQL. Sie können diese Probleme diagnostizieren und beheben.

Diagnose und Lösung bei Verzögerungen zwischen Read Replicas (Lesereplikaten)

Nachdem Sie eine My SQL erstellt haben und die Replik verfügbar ist, repliziert Amazon RDS zunächst die Änderungen, die an der Quell-DB-Instance seit dem Start des Read Replica-Erstellungsvorgangs vorgenommen wurden. Während dieser Phase ist die Verzögerungszeit der Replikation für das Lesereplikat größer als 0. Sie können diese Verzögerungszeit in Amazon überwachen, CloudWatch indem Sie sich die RDS Amazon-Metrik ansehen.

Die AuroraBinlogReplicaLag Metrik gibt den Wert des Seconds_Behind_Master Feldes des Befehls My an. SQL SHOW REPLICA STATUS Weitere Informationen finden Sie in der SQL Dokumentation zu My unter SHOWREPLICASTATUSStatement.

Wenn die Metrik AuroraBinlogReplicaLag 0 erreicht, hat das Replica den Stand der Quell-DB-Instance erreicht. Wenn die AuroraBinlogReplicaLag Metric auf -1 zurückgeht, ist die Replikation möglicherweise nicht aktiv. Um einen Replikationsfehler zu beheben, lesen Sie Diagnose und Behebung eines My- SQL . Ein AuroraBinlogReplicaLag-Wert von -1 kann auch bedeuten, dass der Seconds_Behind_Master-Wert nicht bestimmt werden kann oder NULL ist.

Anmerkung

Frühere Versionen von Aurora My SQL wurden SHOW SLAVE STATUS anstelle von verwendetSHOW REPLICA STATUS. Wenn Sie Aurora My SQL Version 1 oder 2 verwenden, verwenden SieSHOW SLAVE STATUS. Verwenden Sie SHOW REPLICA STATUS für Aurora My SQL Version 3 und höher.

Die Metrik AuroraBinlogReplicaLag gibt während eines Netzwerkausfalls den Wert -1 an oder wenn ein Patch während des Wartungsfensters angewendet wird. Warten Sie in diesem Fall, bis die Netzwerkverbindung wiederhergestellt ist oder die Wartung beendet ist, bevor Sie die Metrik AuroraBinlogReplicaLag wieder überprüfen.

Die Lesereplikationstechnologie von My SQL ist asynchron. Daher können Sie gelegentliche Erhöhungen für die BinLogDiskUsage-Metrik in der Quell-DB-Instance und für die AuroraBinlogReplicaLag-Metrik auf dem Lesereplikat erwarten. Betrachten Sie beispielsweise eine Situation, in der ein hohes Volumen von Schreiboperationen auf die Quell-DB-Instance parallel ausgeführt wird. Gleichzeitig werden Schreiboperationen in das Lesereplikat mit einem einzelnen I/O-Thread serialisiert. Eine solche Situation kann zu einer Verzögerung zwischen der Quell-Instance und dem Lesereplikat führen.

Weitere Informationen zu Read Replicas und My finden Sie in der Dokumentation My SQL unter Details zur Replikationsimplementierung. SQL

Sie können die Verzögerung zwischen den Updates einer Quell-DB-Instance und den nachfolgenden Updates der Lesereplikate folgendermaßen reduzieren:

  • Legen Sie für die DB-Instance-Klasse des Lesereplikats eine Speichergröße fest, die mit der Größe der Quell-DB-Instance vergleichbar ist.

  • Stellen Sie sicher, dass die Parametereinstellungen in den DB-Parametergruppen, die von der Quell-DB-Instance und dem Lesereplikat verwendet werden, kompatibel sind. Weitere Informationen und ein Beispiel finden Sie zum Thema der max_allowed_packet Parameter im nächsten Abschnitt.

  • Deaktivieren Sie den Anfrage-Cache. Bei Tabellen, die häufig geändert werden, kann die Verwendung des Anfragecaches die Replikationsverzögerung erhöhen, da der Cache häufig gesperrt und aktualisiert wird. Wenn dies der Fall ist, reduzieren Sie möglicherweise die Replikationsverzögerung durch die Deaktivierung des Anfragecaches. Sie können den Anfrage-Cache deaktivieren, indem Sie den query_cache_type parameter in der DB-Parametergruppe für die DB-Instance auf 0 setzen. Weitere Informationen zum Abfragecache finden Sie unter Abfragecache-Konfiguration.

  • Wärmen Sie den Pufferpool auf der Read Replica für InnoDB for My SQL MariaDB auf. Nehmen wir beispielsweise an, Sie haben eine kleine Gruppe von Tabellen, die häufig aktualisiert werden, und Sie verwenden das InnoDB- oder XTraDB-Tabellenschema. Legen Sie in diesem Fall diese Tabellen auf dem Lesereplikat ab. Dies führt dazu, dass die Datenbank-Engine die Zeilen dieser Tabellen auf dem Datenträger durchsucht und sie dann im Pufferpool zwischenspeichert. Dieser Ansatz kann Replikatverzögerung reduzieren. Es folgt ein Beispiel.

    Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Linux, macOS, oder Unix:

    PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null

    Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Windows:

    PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null

Diagnose und Behebung eines My- SQL

Amazon RDS überwacht den Replikationsstatus Ihrer Read Replicas. RDSaktualisiert das Feld Replication State der Read Replica-Instance auf den Wert, Error ob die Replikation aus irgendeinem Grund beendet wird. Sie können die Details des zugehörigen Fehlers überprüfen, der von den My SQL ausgelöst wurde, indem Sie das Feld Replikationsfehler aufrufen. Ereignisse, die den Status des Lesereplikats angeben, werden ebenfalls generiert, einschließlich RDS-EVENT-0045, RDS-EVENT-0046 und RDS-EVENT-0057. Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter Mit RDS Amazon-Event-Benachrichtigungen arbeiten. Wenn die SQL Fehlermeldung Meine Fehlermeldung zurückgegeben wird, überprüfen Sie den Fehler in der Dokumentation Meine SQL Fehlermeldung.

Die folgenden, allgemeinen Situationen können häufig zu Replikationsfehlern führen:

  • Der Wert für den max_allowed_packet-Parameter für ein Lesereplikat ist niedriger als der max_allowed_packet-Parameter für die Quell-DB-Instance.

    Der max_allowed_packet-Parameter ist ein benutzerdefinierter Parameter, den Sie in einer DB-Parametergruppe festlegen können. Der max_allowed_packet Parameter wird verwendet, um die maximale Größe der Datenmanipulationssprache (DML) anzugeben, die in der Datenbank ausgeführt werden kann. In einigen Fällen ist der max_allowed_packet-Wert für die Quell-DB-Instance möglicherweise größer als der max_allowed_packet-Wert des Lesereplikats. In diesen Fällen kann der Replikationsprozess einen Fehler ausgeben und die Replikation anhalten. Der häufigste Fehler ist packet bigger than 'max_allowed_packet' bytes. Sie können den Fehler beheben, indem Sie die DB-Parametergruppe der Quelle und des Lesereplikats mit denselben Parameterwerten für max_allowed_packet verwenden.

  • Schreibvorgänge auf Tabellen in einem Lesereplikat. Wenn Sie Indizes für ein Lesereplikat erstellen, müssen Sie den read_only-Parameter auf 0 setzen, um die Indizes zu erstellen. Wenn Sie in Tabellen auf dem Lesereplikat schreiben, kann die Replikation unterbrochen werden.

  • Verwenden Sie eine nicht transaktionale Speicher-Engine wie My. ISAM Read Replicas erfordern eine transaktionale Speicher-Engine. Die Replikation wird nur für die folgenden Speicher-Engines unterstützt: InnoDB for My SQL oder MariaDB.

    Sie können eine ISAM My-Tabelle mit dem folgenden Befehl in InnoDB konvertieren:

    alter table <schema>.<table_name> engine=innodb;

  • Verwenden von nicht-deterministischen Abfragen wie SYSDATE(). Weitere Informationen finden Sie in der Dokumentation My SQL unter Bestimmung sicherer und unsicherer Anweisungen bei der Binärprotokollierung.

Mit den folgenden Schritten können Sie Ihren Replikationsfehler beheben:

  • Wenn Sie einen logischen Fehler feststellen und den Fehler sicher überspringen können, befolgen Sie die Schritte in Überspringen von Fehlern für die aktuelle Replikation. Auf Ihrer Aurora My SQL DB-Instance muss eine Version ausgeführt werden, die das mysql_rds_skip_repl_error Verfahren beinhaltet. Weitere Informationen finden Sie unter mysql_rds_skip_repl_error.

  • Wenn ein Problem mit der Position des Binärprotokolls (Binlog) auftritt, können Sie die Replikatswiedergabeposition ändern. Sie tun dies mit dem mysql.rds_next_master_log Befehl für Aurora My SQL Version 1 und 2. Sie tun dies mit dem mysql.rds_next_source_log Befehl für Aurora My SQL Version 3 und höher. Auf Ihrer Aurora My SQL DB-Instance muss eine Version ausgeführt werden, die diesen Befehl unterstützt, um die Replikat-Wiedergabeposition zu ändern. Weitere Versionsinformationen finden Sie unter mysql_rds_next_master_log.

  • Wenn Sie aufgrund einer hohen DML Auslastung auf ein vorübergehendes Leistungsproblem stoßen, können Sie den Parameter in der innodb_flush_log_at_trx_commit DB-Parametergruppe auf der Read Replica auf 2 setzen. Dies kann dazu beitragen, dass die Read Replica aufholt, obwohl dadurch vorübergehend Atomarität, Konsistenz, Isolierung und Haltbarkeit reduziert werden (). ACID

  • Sie können das Lesereplikat löschen und eine Instance mit derselben DB-Instance-Kennung erstellen. Auf diese Weise bleibt der Endpunkt derselbe wie der Ihres alten Lesereplikats.

Wenn ein Replikationsfehler korrigiert wird, ändert sich der Wert unter Replication State (Replikationsstatus) zu Replicating (Replizierend). Weitere Informationen finden Sie unter Problembehandlung bei My SQL Read Replica.

Fehler „Replication stopped (Replikation gestoppt)“

Wenn Sie den mysql.rds_skip_repl_error Befehl aufrufen, wird möglicherweise eine Fehlermeldung angezeigt, die besagt, dass die Replikation heruntergefahren oder deaktiviert ist.

Diese Fehlermeldung wird angezeigt, wenn die Replikation angehalten wird und nicht mehr neu gestartet werden kann.

Wenn Sie eine größere Anzahl von Fehlern ignorieren müssen, kann die Dauer der Verzögerung der Replikation den standardmäßigen Aufbewahrungszeitraum für binäre Protokolldateien überschreiten. In diesem Fall kann es zu einem schwerwiegenden Fehler kommen, weil binäre Protokolldateien bereinigt werden, bevor ihr Inhalt in der Replica repliziert wurde. Diese Bereinigung führt zur Beendigung der Replikation, und Sie können den Befehl mysql.rds_skip_repl_error nicht mehr aufrufen, um Replikationsfehler zu überspringen und zu ignorieren.

Sie können dieses Problem umgehen, indem Sie die Anzahl der Stunden erhöhen, für die binäre Protokolldateien in der Replikationsquelle beibehalten werden. Nachdem Sie die Aufbewahrungsdauer für binäre Protokolldateien verlängert haben, können Sie die Replikation neu starten und nach Bedarf den Befehl mysql.rds_skip_repl_error aufrufen.

Um den Aufbewahrungszeitraum für Binärprotokolle festzulegen, verwenden Sie das Verfahren mysql_rds_set_configuration. Geben Sie einen Konfigurationsparameter namens "binlog retention hours" und einen zugehörigen Wert in Stunden an, um festzulegen, wie viele Stunden binäre Protokolldateien auf dem DB-Cluster vorgehalten werden sollen (maximal 2160 Stunden = 90 Tage). Die Standardeinstellung für Aurora My SQL ist 24 (1 Tag). Beim folgenden Beispiel wird die Aufbewahrungszeit für binäre Protokolle auf 48 Stunden festgelegt.

CALL mysql.rds_set_configuration('binlog retention hours', 48);