Fehlerbehebung für Amazon RDS - Amazon Relational Database Service

Fehlerbehebung für Amazon RDS

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

Informationen über das Beheben von Problemen mithilfe der Amazon RDS-API finden Sie unter Fehlerbehebung für Anwendungen in Amazon RDS.

Verbindung zur Amazon RDS-DB-Instance kann nicht 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. Zugriff wird über eine Sicherheitsgruppe gewährt, die der VPC zugeordnet ist und Datenverkehr in die und aus der DB-Instance zulässt. 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 IP-Adressbereich 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 des Zugriffs auf Ihre DB-Instance in der VPC durch Erstellen einer Sicherheitsgruppe.

    Anmerkung

    Client-Verbindungen von IP-Adressen im Bereich 169.254.0.0/16 sind nicht erlaubt. Dies ist der APIPA-Bereich (Automatic Private IP Addressing), der für die Local-Link-Adressierung verwendet wird.

  • Öffentliche Zugänglichkeit– Um eine Verbindung mit Ihrer DB-Instance von außerhalb der VPC herzustellen, 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 Deaktivieren des öffentlichen Zugriffs aus dem Internet auf die DB-Instance in einer VPC.

  • 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 AWS Management Console an und öffnen Sie die Amazon RDS-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 auf der Registerkarte Connectivity & security (Konnektivität und Sicherheit) die Werte der VPC-ID unter VPC und die Subnetz-ID unter Subnets (Subnetze).

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

    5. Wählen Sie im Navigationsbereich Internet Gateways aus. Überprüfen Sie, ob Ihrer VPC ein Internet-Gateway angefügt ist. Falls nicht, wählen Sie Create Internet Gateway, um ein Internet-Gateway zu erstellen. Wählen Sie das Internet-Gateway aus, klicken Sie auf die Option Attach to VPC, und folgen Sie den Anleitungen, um das Gateway Ihrer VPC anzufügen.

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

    7. Überprüfen Sie, ob auf der Registerkarte Route Table eine Route mit 0.0.0.0/0 unter "Destination" und das Internet-Gateway für Ihre VPC unter „Target“ vorhanden ist. Wenn Sie eine Verbindung mit Ihrer Instance mithilfe der IPv6-Adresse herstellen, überprüfen Sie, dass eine Route für den gesamten IPv6-Datenverkehr (::/0) vorhanden ist, die zum Internet-Gateway führt. 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 Add route (Route hinzufügen) aus, verwenden Sie ::/0 als Ziel und das Internet-Gateway als Ziel.

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

    Weitere Informationen finden Sie unter Arbeiten mit einer DB-Instance in einer VPC.

Informationen zu Engine-spezifischen Verbindungsproblemen finden Sie in den folgenden Themen:

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 einen 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

Internet Control Message Protocol (ICMP)-Datenverkehr, einschließlich Ping, wird von Amazon RDS nicht akzeptiert.

Fehlerbehebung bei der Verbindungsauthentifizierung

Wenn Sie eine Verbindung zu Ihrer DB-Instance herstellen können, aber Authentifizierungsfehler erhalten, sollten Sie möglicherweise das Master-Benutzerpasswort für die DB-Instance zurücksetzen. Sie können dies tun, indem Sie die RDS-Instance ändern.

Weitere Informationen über das Ändern einer DB-Instance finden Sie unter Ändern einer Amazon RDS-DB-Instance.

Amazon RDS-Sicherheitsprobleme

Verwenden Sie niemals Ihren Master-AWS-Benutzernamen und das Passwort für ein Benutzerkonto, um Sicherheitsprobleme zu vermeiden. Die bewährte Methode besteht darin, Ihr AWS-Masterkonto zu verwenden, um AWS Identity and Access Management (IAM)-Benutzer zu erstellen und diese DB-Benutzerkonten zuzuweisen. Sie können Ihr Hauptkonto auch verwenden, um bei Bedarf andere Benutzerkonten zu erstellen.

Weitere Informationen zum Erstellen von IAM-Benutzern finden Sie unter Erstellen eines IAM-Benutzers.

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 IAM-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-Instance- 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-Kontobesitzer das Hauptbenutzerpasswort 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 mithilfe der Amazon RDS-Konsole, des AWS CLI-Befehls modify-db-instance oder der API-Operation ModifyDBInstance ändern. Weitere Informationen über das Ändern einer DB-Instance finden Sie unter Ändern einer Amazon RDS-DB-Instance.

Ausfall oder Neustart einer 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 auftreten, wenn Sie Ihre DB-Instance entweder manuell neu starten oder eine DB-Instance-Einstellung ändern, für die ein Neustart erforderlich ist, damit sie wirksam werden kann.

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 in Kraft treten lassen, oder während des Wartungsfensters der DB-Instance.

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 und setzen Apply Immediately (Direkt anwenden) auf true.

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

  • Sie ändern den Speichertyp von Magnetic (Standard) (Magnetisch (Standard)) zu General Purpose (SSD) (Allzweck (SSD)) oder Provisioned IOPS (SSD) (Bereitgestellte IOPS (SSD)) oder von Provisioned IOPS (SSD) (Bereitgestellte IOPS (SSD)) oder General Purpose (SSD) (Allzweck (SSD)) zu Magnetic (Standard) (Magnetisch (Standard)).

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.

Um eine Tabelle mit den DB-Instance-Aktionen und dem Effekt der Einstellung des Wertes Apply Immediately anzuzeigen, siehe Ändern einer Amazon RDS-DB-Instance.

Amazon RDS-DB-Parameter Änderungen wirken sich nicht aus

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 explizit die RebootDBInstance API-Operation aufrufen (ohne Failover, wenn sich die DB-Instance in einem Multi-AZ deployment befindet). Da die zugeordnete DB-Instance nach der Änderung eines statischen Parameters neu gestartet werden muss, wird das Risiko einer fehlerhaften Konfiguration gesenkt, die API-Aufrufe beeinträchtigen könnte. Ein Beispiel hierfür könnte der Aufruf von ModifyDBInstance zur Änderung der DB-Instance-Klasse sein. Weitere Informationen finden Sie unter Ändern von Parametern in einer DB-Parametergruppe.

Amazon RDS-DB-Instance hat zu wenig Speicher

Wenn Ihre DB-Instance zu wenig Speicherplatz hat, ist sie möglicherweise nicht mehr verfügbar. Wir empfehlen dringend, die in CloudWatch veröffentlichte FreeStorageSpace-Metrik regelmäßig zu kontrollieren, um sicherzustellen, dass Ihre DB-Instance über ausreichend freien Speicherplatz verfügt.

Wenn Ihre Datenbank-Instance nicht mehr über ausreichend Speicher verfügt, ändert sich der Status in storage-full. Zum Beispiel gibt das Aufrufen der DescribeDBInstances-API-Operation für eine DB-Instance, deren Speicher aufgebraucht ist, Folgendes aus.

aws rds describe-db-instances --db-instance-identifier mydbinstance DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Um diesen Zustand zu beenden, fügen Sie Ihrer Instance zusätzlichen Speicherplatz hinzu, indem Sie die ModifyDBInstance-API-Operation oder den folgenden AWS CLI-Befehl verwenden.

Für Linux, macOS oder Unix:

aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --allocated-storage 60 \ --apply-immediately

Für Windows:

aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --allocated-storage 60 ^ --apply-immediately
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Nun werden Sie feststellen, dass Ihre DB-Instance den Status modifying aufweist. Das bedeutet, dass der Speicherplatz skaliert wird.

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa modifying mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Nachdem die Speicherskalierung abgeschlossen ist, ändert sich der Status Ihrer DB-Instance in available.

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 60 sa available mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Sie können Benachrichtigungen erhalten, wenn Ihr Speicherplatz durch die DescribeEvents-Operation erschöpft ist. Wenn Sie in einem solchen Fall nach diesen Operationen beispielsweise DescribeEvents aufrufen, wird Ihnen Folgendes angezeigt werden.

aws rds describe-events --source-type db-instance --source-identifier mydbinstance
2009-12-22T23:44:14.374Z mydbinstance Allocated storage has been exhausted db-instance 2009-12-23T00:14:02.737Z mydbinstance Applying modification to allocated storage db-instance 2009-12-23T00:31:54.764Z mydbinstance Finished applying modification to allocated storage

Unzureichende Kapazität der Amazon RDS-DB-Instance

Der Fehler InsufficientDBInstanceCapacity kann zurückgegeben werden, wenn Sie versuchen, eine DB-Instance zu erstellen oder zu ändern, oder wenn Sie versuchen, eine DB-Instance aus einem DB-Snapshot wiederherzustellen. Häufige Gründe für diesen Fehler sind:

  • Die spezifische DB-Instance-Klasse ist in der angeforderten Availability Zone nicht verfügbar. Sie können folgende Aktionen ausführen, um zu versuchen, das Problem zu beheben:

    • Wiederholen Sie die Anforderung mit einer anderen FB-Instance-Klasse.

    • Wiederholen Sie die Anforderung mit einer anderen Availability Zone.

    • Wiederholen Sie die Anforderung ohne explizite Angabe einer Availability Zone.

    Informationen zur Behebung von Kapazitätsproblemen im Zusammenhang mit Amazon EC2-Instances finden Sie unter Unzureichende Instance-Kapazität im Amazon Elastic Compute Cloud-Benutzerhandbuch.

  • Die DB-Instance befindet sich auf der EC2-Classic-Plattform und daher nicht in einer VPC. Einige DB-Instance-Klassen benötigen eine VPC. Wenn Sie sich z. B. auf der EC2-Classic-Plattform befinden und versuchen, die Kapazität zu erhöhen, indem Sie auf eine DB-Instance-Klasse umschalten, die eine VPC erfordert, führt dies zu diesem Fehler. Informationen zu Amazon EC2-Instance-Typen, die ausschließlich in einer VPC verfügbar sind, finden Sie unter In EC2-Classic verfügbare Instance-Typen im Amazon Elastic Compute Cloud-Benutzerhandbuch. Um das Problem zu beheben, können Sie die DB-Instance in eine VPC verschieben. Weitere Informationen finden Sie unter Verschieben einer DB-Instance von außerhalb einer VPC in eine VPC.

Informationen zum Ändern einer DB-Instance finden Sie unter Ändern einer Amazon RDS-DB-Instance.

Amazon RDS Probleme mit MySQL und MariaDB

Sie können Probleme mit MySQL- und MariaDB-DB-Instances diagnostizieren und beheben.

Maximale Anzahl von MySQL- und MariaDB-Verbindungen

Die maximale Anzahl der für eine RDS MySQL- oder MariaDB-DB-Instance zulässigen Verbindungen basiert auf der Menge des für die DB-Instance-Klasse verfügbaren Arbeitsspeichers. Eine DB-Instance Klasse mit mehr verfügbarem Arbeitsspeicher resultiert in einer größeren Anzahl von verfügbaren Verbindungen. Weitere Informationen zu DB-Instance-Klassen finden Sie unter DB-Instance-Klassen.

Das Verbindungslimit einer DB-Instance ist standardmäßig festgelegt auf die maximale Verbindungsanzahl für die DB-Instance-Klasse. Sie können die Anzahl gleichzeitiger Verbindungen auf einen beliebigen Wert bis zur maximal zulässigen Anzahl von Verbindungen beschränken. Verwenden Sie den max_connections-Parameter in der Parametergruppe für die DB-Instance. Weitere Informationen finden Sie unter Maximale Anzahl von Datenbankverbindungen und Arbeiten mit DB-Parametergruppen.

Sie können die maximal zulässige Anzahl von Verbindungen für eine MySQL- oder MariaDB-DB-Instance abrufen, indem Sie die folgende Abfrage ausführen.

SELECT @@max_connections;

Sie können die Anzahl der aktiven Verbindungen zu einer MySQL- oder MariaDB-DB-Instance abrufen, indem Sie die folgende Abfrage ausführen.

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

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

Nachdem Sie ein MySQL- oder MariaDB-Lesereplikat erstellt haben und das Replikat verfügbar ist, repliziert Amazon RDS zunächst die an der Quell-DB-Instance vorgenommen Änderungen ab dem Zeitpunkt der Operation der Lesereplikaterstellung. 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 CloudWatch anhand der Metrik Amazon RDS ReplicaLag überwachen.

Die Metrik ReplicaLag erfasst den Wert des Feldes Seconds_Behind_Master im MySQL- oder MariaDB--Befehl SHOW SLAVE STATUS. Weitere Informationen finden Sie unter SHOW SLAVE STATUS. Wenn die Metrik ReplicaLag den Wert 0 erreicht, hat das Replica den Stand der Quell-DB-Instance erreicht. Wenn die Metrik ReplicaLag den Wert -1 zurückgibt, ist die Replikation möglicherweise nicht aktiv. Um einen Replikationsfehler zu beheben, lesen Sie Diagnose und Lösung eines Fehlers bei einer MySQL oder MariaDB Read Replica. Ein ReplicaLag -Wert von -1 kann auch bedeuten, dass der Seconds_Behind_Master-Wert nicht bestimmt werden kann oder NULL ist.

Die Metrik ReplicaLag 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 ReplicaLag wieder überprüfen.

Die MySQL- und MariaDB-Lesereplikationstechnologie ist asynchron. Daher können Sie gelegentliche Erhöhungen für die BinLogDiskUsage-Metrik in der Quell-DB-Instance und für die ReplicaLag -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 E/A-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 MySQL finden Sie in unter Replication Implementation Details in der MySQL-Dokumentation. Weitere Informationen zu Read Replicas und MariaDB finden Sie unter Replication Overview in der MariaDB-Dokumentation.

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.

  • Erwärmen Sie den Puffer-Pool auf dem Lesereplikat für InnoDB für MySQL, InnoDB für MariaDB 10.2 oder höher oder XtraDB für MariaDB 10.1 oder niedriger. 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.

    Für Linux, macOS oder Unix:

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

    Für Windows:

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

Diagnose und Lösung eines Fehlers bei einer MySQL oder MariaDB Read Replica

Amazon RDS überwacht den Replikationsstatus Ihrer Lesereplikate und aktualisiert das Feld Replication State (Replikationsstatus) der Lesereplikat-Instance auf Error, wenn die Replikation aus irgendeinem Grund beendet wird. Die Einzelheiten des von den MySQL- oder MariaDB-Engines ausgelösten Fehlers finden Sie im Feld Replication Error (Replikationsfehler). Ereignisse, die den Status des Lesereplikats angeben, werden ebenfalls generiert, einschließlich RDS-EVENT-0045, RDS-EVENT-0046 und RDS-EVENT-0047. Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter Verwenden von Amazon RDS-Ereignisbenachrichtigungen. Wenn eine MySQL-Fehlermeldung zurückgegeben wird, lesen Sie den Fehler in der MySQL Fehlermeldungsdokumentation nach. Wenn eine MariaDB-Fehlermeldung ausgegeben wird, überprüfen Sie den Fehler in der MariaDB-Fehlermeldungsdokumentation.

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 Data Manipulation Language (DML) anzugeben, die in der Datenbank ausgeführt werden kann. Wenn der max_allowed_packet-Wert für die Quell-DB-Instance niedriger ist als der max_allowed_packet-Wert für das Lesereplikat, kann der Replikationsprozess einen Fehler auslösen und die Replikation stoppen. The most common error is 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.

  • Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Read Replicas erfordern eine transaktionale Speicher-Engine. Die Replikation wird nur für die folgenden Speicher-Engines unterstützt: InnoDB für MySQL, InnoDB für MariaDB 10.2 oder höher oder XtraDB für MariaDB 10.1 oder früher.

    Führen Sie zum Umwandeln einer MyISAM-Tabelle in eine InnoDB-Tabelle den folgenden Befehl aus:

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

  • Verwenden von nicht-deterministischen Abfragen wie SYSDATE(). Weitere Informationen finden Sie unter Determination of Safe and Unsafe Statements in Binary Logging in der MySQL-Dokumentation.

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. Ihre MySQL- oder MariaDB DB-Instance muss eine Version ausführen, die die mysql_rds_skip_repl_error Verfahren umfasst. 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 mit dem mysql_rds_next_master_log-Befehl ändern. Ihre MySQL- oder MariaDB-DB-Instance muss eine Version ausführen, die den mysql_rds_next_master_log-Befehl unterstützt, um die Replikatswiedergabeposition zu ändern. Versionsinformationen finden Sie unter mysql.rds_next_master_log.

  • Wenn aufgrund einer hohen DML-Last ein temporäres Leistungsproblem auftritt, können Sie den innodb_flush_log_at_trx_commit-Parameter in der DB-Parametergruppe auf dem Lesereplikat auf 2 stellen. Dies kann das Aufholen des Lesereplikats unterstützen, auch wenn es vorübergehend die Atomizität, die Konsistenz, die Isolation und die Haltbarkeit (Atomicity, Consistency, Isolation und Durability – ACID) verringert.

  • Sie können das Lesereplikat löschen und eine Instance mit derselben DB-Instance-Kennung erstellen. Wenn Sie dies tun, 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 Fehlerbehebung für ein Problem mit einer MySQL Read Replica.

Erstellen von Auslösern mit aktivierter Binärprotokollierung erfordert SUPER-Berechtigung

Wenn Sie versuchen, Auslöser in einer RDS MySQL- oder MariaDB-DB-Instance zu erstellen, wird möglicherweise der folgende Fehler angezeigt.

"You do not have the SUPER privilege and binary logging is enabled"

Um Trigger zu verwenden, wenn die Binärprotokollierung aktiviert ist, ist die SUPER-Berechtigung erforderlich, die auf RDS-MySQL- und MariaDB-DB-Instancen beschränkt ist. Sie können Trigger erstellen, wenn die Binärprotokollierung ohne die SUPER-Berechtigung aktiviert wird, indem Sie die log_bin_trust_function_creators Parameter auf true setzen. Um den log_bin_trust_function_creators auf wahr zu stellen, legen Sie eine neue DB-Parametergruppe an oder ändern Sie eine vorhandene DB-Parametergruppe.

Verwenden Sie die folgenden Befehlszeilenschnittstelle-Befehle, um eine neue DB-Parametergruppe zu erstellen, mit der Sie Trigger in Ihrer RDS-MySQL- oder MariaDB-DB-Instance mit aktivierter Binärprotokollierung erstellen können. Um eine vorhandene Parametergruppe zu ändern, beginnen Sie mit Schritt 2.

Um eine neue Parametergruppe zu erstellen, um Trigger mit der Binärprotokollierung zuzulassen, die über die Befehlszeilenschnittstelle aktiviert ist

  1. Neue Parametergruppe erstellen.

    Für Linux, macOS oder Unix:

    aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql8.0 \ --description "parameter group allowing triggers"

    Für Windows:

    aws rds create-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --db-parameter-group-family mysql8.0 ^ --description "parameter group allowing triggers"
  2. Ändern Sie die DB-Parametergruppe, um Trigger zuzulassen.

    Für Linux, macOS oder Unix:

    aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

    Für Windows:

    aws rds modify-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"
  3. Ändern Sie Ihre DB-Instance, um die neue DB-Parametergruppe zu verwenden.

    Für Linux, macOS oder Unix:

    aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --db-parameter-group-name allow-triggers \ --apply-immediately

    Für Windows:

    aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --db-parameter-group-name allow-triggers ^ --apply-immediately
  4. Starten Sie die DB-Instance manuell neu, damit die Änderungen wirksam werden.

    aws rds reboot-db-instance --db-instance-identifier mydbinstance

Diagnostizieren und Beheben von Point-in-Time-Wiederherstellungsfehlern

Wiederherstellen einer DB-Instance mit temporären Tabellen

Beim Versuch einer Point-in-Time-Wiederherstellung (PITR) Ihrer MySQL- oder MariaDB-DB-Instance kann der folgende Fehler auftreten.

Database instance could not be restored because there has been incompatible database activity for restore functionality. Common examples of incompatible activity include using temporary tables, in-memory tables, or using MyISAM tables. In this case, use of Temporary table was detected.

PITR benötigt sowohl Sicherungs-Snapshots als auch Binärprotokolle (Binlogs) von MySQL oder MariaDB, um Ihre DB-Instance zu einer bestimmten Zeit wiederherzustellen. Temporäre Tabelleninformationen können in binlogs unzuverlässig sein und einen PITR-Fehler verursachen. Wenn Sie temporäre Tabellen in Ihrer MySQL- oder MariaDB DB-Instance verwenden, können Sie die Wahrscheinlichkeit eines PITR-Fehlers minimieren, indem Sie häufigere Sicherungen durchführen. Ein PITR-Fehler ist in der Zeit zwischen der Erstellung einer temporären Tabelle und dem nächsten Sicherungs-Snapshot am wahrscheinlichsten.

Wiederherstellen einer DB-Instance mit In-Memory-Tabellen

Beim Wiederherstellen einer Datenbank mit speicherinternen Tabellen kann ein Problem auftreten. In-Memory-Tabellen werden während eines Neustarts gelöscht. Infolgedessen sind Ihre speicherinternen Tabellen möglicherweise nach einem Neustart leer. Wir empfehlen, dass Sie bei der Verwendung von speicherinternen Tabellen Ihre Lösung für die Behandlung leerer Tabellen im Falle eines Neustarts erstellen. Wenn Sie In-Memory-Tabellen mit replizierten DB-Instances verwenden, müssen Sie möglicherweise die Lesereplikate nach einem Neustart neu erstellen. Dies kann erforderlich sein, wenn ein Lesereplikat neu gestartet wird und Daten aus einer leeren In-Memory-Tabelle nicht wiederherstellen kann.

Weitere Informationen zu Sicherungen und PITR finden Sie unter Arbeiten mit Sicherungen und Wiederherstellen einer DB-Instance zu einer bestimmten Zeit.

Fehler „Replication stopped (Replikation gestoppt)“

Beim Aufrufen des Befehls mysql.rds_skip_repl_error erhalten Sie möglicherweise die folgende Fehlermeldung:Slave is down or disabled.

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.

Verwenden Sie das mysql.rds_set_configuration-Verfahren, um den Aufbewahrungszeitraum für Binärprotokolle festzulegen. 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 720 Stunden = 30 Tage). Beim folgenden Beispiel wird die Aufbewahrungszeit für binäre Protokolle auf 48 Stunden festgelegt.

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

Erstellung von Read Replica fehlgeschlagen oder Replikationsunterbrechungen mit schwerwiegendem Fehler 1236

Nach dem Ändern der Standardparameterwerte für eine MySQL- oder MariaDB DB-Instance kann eines der folgenden Probleme auftreten:

  • Sie können kein Lesereplikat für die DB-Instance erstellen.

  • Replication fails with fatal error 1236.

Einige Standardparameterwerte für MySQL- und MariaDB-DB-Instances helfen dabei sicherzustellen, dass die Datenbank ACID-konform ist und Lesereplikate absturzsicher sind. Sie tun dies, indem sie sicherstellen, dass jeder Commit vollständig synchronisiert wird, indem sie die Transaktion in das Binärprotokoll schreiben, bevor sie festgeschrieben wird. Wenn Sie diese Parameter so ändern, dass sie von ihren Standardwerten abweichen, um die Leistung zu verbessern, kann die Replikation fehlschlagen, wenn eine Transaktion nicht in das Binärprotokoll geschrieben wurde.

Legen Sie die folgenden Parameterwerte fest, um dieses Problem zu beheben:

  • sync-binlog = 1

  • innodb_support_xa = 1

  • innodb_flush_log_at_trx_commit = 1

Der Aufbewahrungszeitraum für Backups kann nicht auf 0 gesetzt werden

Es gibt mehrere Gründe, warum Sie möglicherweise den Aufbewahrungszeitraum für Backups auf 0 setzen müssen. Beispielsweise können Sie automatische Backups unmittelbar deaktivieren, indem Sie den Aufbewahrungszeitraum 0 setzen.

In einigen Fällen können Sie den Wert auf 0 festlegen und erhalten eine Meldung, dass der Aufbewahrungszeitraum zwischen 1 und 35 liegen muss. Stellen Sie in diesen Fällen sicher, dass Sie kein Lesereplikat für die Instance eingerichtet haben. Lesereplikate benötigen Sicherungen für die Verwaltung der Lesereplikatsprotokolle, deshalb können Sie den Aufbewahrungszeitraum nicht auf 0 setzen.