Fehlerbehebung für Amazon RDS - Amazon Relational Database Service
Verbindung zur -DB-Instance kann nicht hergestellt werdenSicherheitsproblemeProblembehandlung bei inkompatiblem NetzwerkstatusZurücksetzen des Besitzerpassworts der DB-InstanceAusfall oder Neustart einer DB-InstanceParameteränderungen wirken sich nicht ausZu wenig Speicher für DB-InstanceUnzureichende Kapazität der DB-InstanceProbleme mit freisetzbarem Speicher in RDSMySQL- und MariaDB-ProblemeDer Aufbewahrungszeitraum für Backups kann nicht auf 0 gesetzt werden

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 RDS

Verwenden Sie die folgenden Abschnitte, um Probleme zu beheben, die Sie mit DB-Instances in Amazon RDS und Amazon 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 Ausblenden einer DB-Instance in einer VPC vor dem Internet.

  • 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 Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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 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.

      Wenn Sie versuchen, eine Verbindung mit dem IPv6-Endpunkt herzustellen, stellen Sie außerdem sicher, dass der IPv6-Adressbereich des Clients berechtigt ist, eine Verbindung mit der DB-Instance herzustellen.

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

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

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.

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

Amazon RDS-Sicherheitsprobleme

Um Sicherheitsprobleme zu vermeiden, sollten Sie niemals Ihren AWS Master-Benutzernamen und Ihr Passwort für ein Benutzerkonto verwenden. Es empfiehlt sich, Ihren Master zu verwenden AWS-Konto , um Benutzer zu erstellen und diese DB-Benutzerkonten zuzuweisen. Sie können Ihr Hauptkonto auch verwenden, um bei Bedarf andere 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 im 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.

Problembehandlung bei inkompatiblem Netzwerkstatus

Der Status „Inkompatibles Netzwerk“ bedeutet, dass auf Datenbankebene möglicherweise weiterhin auf die Datenbank zugegriffen werden kann, Sie sie jedoch nicht ändern oder neu starten können.

Ursachen

Der Status „Inkompatibles Netzwerk“ Ihrer DB-Instance könnte das Ergebnis einer der folgenden Aktionen sein:

  • Ändern der DB-Instance-Klasse.

  • Ändern der DB-Instance, um die Multi-AZ-DB-Cluster-Bereitstellung zu verwenden.

  • Ersetzen eines Hosts aufgrund eines Wartungsereignisses.

  • Starten einer Ersatz-DB-Instance.

  • Wiederherstellung aus einer Snapshot-Sicherung.

  • Starten einer angehaltenen DB-Instance

Auflösung

Verwenden Sie den Befehl start-db-instance

Gehen Sie folgendermaßen vor, um eine Datenbank zu reparieren, die sich im Status „inkompatibles Netzwerk“ befindet:

  1. Öffnen Sie die https://console.aws.amazon.com/rds/, und wählen Sie Datenbanken aus dem Navigationsbereich aus.

  2. Wählen Sie die DB-Instance aus, die sich im Status „Inkompatibles Netzwerk“ befindet, und notieren Sie sich die DB-Instance-ID, die VPC-ID und die Subnetz-IDs von der Registerkarte Konnektivität und Sicherheit.

  3. Verwenden Sie den AWS CLI , um den start-db-instance Befehl auszuführen. Geben Sie den --db-instance-identifier-Wert an.

    Anmerkung

    Wenn Sie diesen Befehl ausführen, wenn sich Ihre Datenbank im inkompatiblen Modus befindet, kann dies zu Ausfallzeiten führen.

    Der start-db-instance-Befehl behebt dieses Problem für RDS für SQL Server-DB-Instances nicht.

Ihr Datenbankstatus ändert sich zu Verfügbar, wenn der Befehl erfolgreich ausgeführt wird.

Wenn Ihre Datenbank neu gestartet wird, führt die DB-Instance möglicherweise den letzten Vorgang aus, der auf der Instance ausgeführt wurde, bevor sie in den Status „Inkompatibles Netzwerk“ versetzt wurde. Dadurch könnte die Instance wieder in den Status „Inkompatibles Netzwerk“ versetzt werden.

Wenn der start-db-instance-Befehl nicht erfolgreich ist oder die Instance in den Status „Inkompatibles Netzwerk“ zurückkehrt, öffnen Sie die Seite Datenbanken in der RDS-Konsole, und wählen Sie die Datenbank aus. Navigieren Sie zum Abschnitt Protokolle und Ereignisse. Der Abschnitt Aktuelle Ereignisse zeigt weitere Lösungsschritte an, die Sie befolgen können. Die Nachrichten sind wie folgt klassifiziert:

  • INTERNER RESSOURCENCHECK: Möglicherweise liegen Probleme mit Ihren internen Ressourcen vor.

  • DNS-PRÜFUNG: Überprüfen Sie die DNS-Auflösung und die Hostnamen für die VPC in der VPC-Konsole.

  • ENI-PRÜFUNG: Die Elastic-Network-Schnittstelle (ENI) für Ihre Datenbank ist möglicherweise nicht vorhanden.

  • GATEWAY-PRÜFUNG: Das Internet-Gateway für Ihre öffentlich verfügbare Datenbank ist nicht mit der VPC verbunden.

  • IP-PRÜFUNG: Es gibt keine freien IP-Adressen in Ihren Subnetzen.

  • PRÜFUNG DER SICHERHEITSGRUPPE: Ihrer Datenbank sind keine Sicherheitsgruppen zugeordnet, oder die Sicherheitsgruppen sind ungültig.

  • SUBNETZPRÜFUNG: Es gibt keine gültigen Subnetze in Ihrer DB-Subnetzgruppe, oder es gibt Probleme mit Ihrem Subnetz.

  • VPC-PRÜFUNG: Die mit Ihrer Datenbank verknüpfte VPC ist ungültig.

Führen Sie die point-in-time Wiederherstellung durch

Es empfiehlt sich, eine Sicherungskopie (Snapshot oder logisch) zu erstellen, falls Ihre Datenbank in den Zustand „Inkompatibles Netzwerk“ übergeht. Siehe Einführung in Backups. Wenn Sie automatische Backups aktiviert haben, beenden Sie vorübergehend alle Schreibvorgänge in die Datenbank und führen Sie eine point-in-time Wiederherstellung durch.

Anmerkung

Wenn eine Instance in den Status „Inkompatibles Netzwerk“ übergeht, kann möglicherweise nicht mehr auf die DB-Instance zugegriffen werden, um ein logisches Backup durchzuführen.

Wenn Sie automatische Sicherungen nicht aktiviert haben, erstellen Sie eine neue DB-Instance. Migrieren Sie dann die Daten mit AWS Database Migration Service (AWS DMS) oder mithilfe eines Sicherungs- und Wiederherstellungstools.

Wenn das Problem dadurch nicht behoben wird, wenden Sie sich an uns, AWS Support um weitere Unterstützung zu erhalten.

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 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 Amazon RDS-Konsole, den AWS CLI Befehl modify-db-instanceoder den API-Vorgang ModifyDBInstance verwenden. Weitere Informationen zum Ä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 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.

  • 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 mithilfe der RDS-Konsole neu starten. Oder Sie können die API-Operation RebootDBInstance explizit aufrufen. Sie können ohne Failover neu starten, wenn sich die DB-Instance in einer Multi-AZ-Bereitstellung 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 ist der Aufruf von ModifyDBInstance zur Änderung der DB-Instance-Klasse. 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 Ihnen dringend, die in veröffentlichte FreeStorageSpace Metrik ständig zu überwachen CloudWatch , 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 dieses Szenario zu überwinden, fügen Sie Ihrer Instance mithilfe der ModifyDBInstance API-Operation oder des folgenden AWS CLI Befehls mehr Speicherplatz hinzu.

Für LinuxmacOS, oderUnix:

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

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, zu starten oder zu ändern. Er kann auch zurückgegeben werden, wenn Sie versuchen, eine DB-Instance aus einem DB-Snapshot wiederherzustellen. Wenn dieser Fehler zurückgegeben wird, besteht die Ursache häufig darin, dass die spezifische DB-Instance-Klasse in der angeforderten Availability Zone nicht verfügbar ist. 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-EC2-Benutzerhandbuch.

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

Probleme mit freisetzbarem Speicher in Amazon RDS

Freisetzbarer Speicher ist der gesamte Random Access Memory (RAM, Arbeitsspeicher) 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 Betriebssystemprozesse verbrauchen ebenfalls RAM. 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 Übersicht über die Überwachung von Metriken in Amazon RDS.

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 DB-Instance-Klassen.

Sie können auch die Speichereinstellungen ändern. Beispiel: Bei RDS for MySQL können Sie die Größe des Parameters innodb_buffer_pool_size anpassen. Dieser Parameter ist standardmäßig auf 75 Prozent des physischen Speichers festgelegt. Weitere Tipps zur MySQL-Fehlerbehebung finden Sie unter Wie kann ich Probleme mit geringem freisetzbaren Speicher in einer Datenbank von Amazon RDS für MySQL beheben?

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 für MySQL- oder RDS für 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 erhalten Sie unter Maximale Anzahl von Datenbankverbindungen und Arbeiten mit 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';

Diagnostizieren und Auflösen des Status "incompatible-parameters" für ein Speicherlimit

Eine MariaDB- oder MySQL-DB-Instance kann in den Status incompatible-parameters für ein Speicherlimit versetzt werden, wenn die folgenden Bedingungen erfüllt sind:

  • Die DB-Instance wird entweder mindestens dreimal innerhalb einer Stunde oder mindestens fünfmal an einem Tag neu gestartet, wenn der Status der DB-Instance Verfügbar lautet.

  • Ein Versuch, die DB-Instance neu zu starten, schlägt fehl, weil eine Wartungsaktion oder ein Überwachungsprozess die DB-Instance nicht neu starten konnte.

  • Die potenzielle Arbeitsspeicherauslastung der DB-Instance übersteigt das 1,2-Fache des Arbeitsspeichers, der ihrer DB-Instance-Klasse zugewiesen ist.

Wenn eine DB-Instance zum dritten Mal innerhalb einer Stunde oder zum fünften Mal an einem Tag neu gestartet wird, wird eine Prüfung der Arbeitsspeicherauslastung durchgeführt. Die Prüfung erstellt eine Berechnung der potenziellen Arbeitsspeicherauslastung der DB-Instance. Der von der Berechnung gelieferte Wert ist die Summe der folgenden Werte:

  • Wert 1 – Die Summe der folgenden Parameter:

    • innodb_additional_mem_pool_size

    • innodb_buffer_pool_size

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size (nur MySQL Version 5.7)

    • tmp_table_size

  • Wert 2 – Der Parameter max_connections multipliziert mit der Summe der folgenden Parameter:

    • binlog_cache_size

    • join_buffer_size

    • read_buffer_size

    • read_rnd_buffer_size

    • sort_buffer_size

    • thread_stack

  • Wert 3 – Wenn der Parameter performance_schema aktiviert ist, multiplizieren Sie den Parameter max_connections mit 257700.

    Wenn der Parameter performance_schema deaktiviert ist, ist dieser Wert 0.

Der von der Berechnung gelieferte Wert ist also folgender:

Value 1 + Value 2 + Value 3

Wenn dieser Wert das 1,2-Fache des Arbeitsspeichers überschreitet, der der von der DB-Instance verwendeten DB-Instance-Klasse zugewiesen ist, wird die DB-Instance in den Status incompatible-parameters versetzt. Weitere Informationen über den Arbeitsspeicher, der DB-Instance-Klassen zugewiesen ist, finden Sie unter Hardware-Spezifikationen für DB-Instance-Klassen .

Die Berechnung multipliziert den Wert des Parameters max_connections mit der Summe mehrerer Parameter. Wenn der Parameter max_connections auf einen großen Wert festgelegt ist, kann das dazu führen, dass die Prüfung einen übermäßig hohen Wert für die potenzielle Arbeitsspeicherauslastung der DB-Instance zurückgibt. In diesem Fall sollten Sie erwägen, den Wert des Parameters max_connections zu senken.

Um das Problem zu lösen, führen Sie die folgenden Schritte aus:

  1. Passen Sie die Arbeitsspeicherparameter der DB-Parametergruppe, die der DB-Instance zugeordnet ist, entsprechend an. Die potenzielle Arbeitsspeicherauslastung sollte niedriger sein als das 1,2-fache des Arbeitsspeichers, der der DB-Instance-Klasse zugewiesen ist.

    Weitere Informationen zum Festlegen von Parametern finden Sie unter Ändern von Parametern in einer DB-Parametergruppe.

  2. Starten Sie die DB-Instance neu.

    Weitere Informationen zum Festlegen von Parametern finden Sie unter Starten einer angehaltenen Amazon RDS-DB-Instance.

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 überwachen, CloudWatch indem Sie sich die Amazon ReplicaLagRDS-Metrik ansehen.

DieReplicaLag Metrik gibt den Wert desSeconds_Behind_Master Feldes des MariaDB- oderSHOW REPLICA STATUS MySQL-Befehls an. Weitere Informationen finden Sie unter SHOW REPLICA STATUS-Anweisung in der MySQL-Dokumentation.

Wenn die Metrik ReplicaLag 0 erreicht, hat das Replica den Stand der Quell-DB-Instance erreicht. Wenn die ReplicaLag Metric auf -1 zurückgeht, 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.

Anmerkung

In früheren Versionen von MariaDB und MySQL werden SHOW SLAVE STATUS anstelle von SHOW REPLICA STATUS verwendet. Wenn Sie eine MariaDB-Version vor 10.5 oder eine MySQL-Version vor 8.0.23 verwenden, verwenden Sie SHOW SLAVE STATUS.

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

  • Wärmen Sie den Pufferpool auf dem Lesereplikat für InnoDB für MySQL oder 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.

    Für LinuxmacOS, oderUnix:

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

    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. RDS aktualisiert das Feld Replication State (Replikationsstatus) der Lesereplikat-Instance auf Error, wenn die Replikation aus irgendeinem Grund angehalten 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-0057. Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter Arbeiten mit 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. 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.

  • 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 for MySQL oder MariaDB.

    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.

  • Möglicherweise tritt aufgrund einer hohen DML-Last ein vorübergehendes Leistungsproblem auf. In diesem Fall können Sie den Parameter innodb_flush_log_at_trx_commit in der DB-Parametergruppe für das Lesereplikat auf 2 festlegen. 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 für MySQL- oder RDS für 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 für MySQL- und RDS für 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.

Sie können eine neue DB-Parametergruppe anlegen, mit der Sie Auslöser in Ihrer DB-Instance von RDS für MySQL oder RDS für MariaDB mit aktivierter Binärprotokollierung erstellen können. Verwenden Sie dazu die folgenden CLI-Befehle. 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 CLI aktiviert ist

  1. Neue Parametergruppe erstellen.

    Für LinuxmacOS, oderUnix:

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

    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 LinuxmacOS, oderUnix:

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

    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 LinuxmacOS, oderUnix:

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

    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

Diagnose und Behebung von Wiederherstellungsfehlern point-in-time

Wiederherstellen einer DB-Instance mit temporären Tabellen

Wenn Sie versuchen, Ihre MySQL- oder MariaDB-DB-Instance point-in-time wiederherzustellen (PITR), tritt möglicherweise der folgende Fehler auf.

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. Führen Sie dazu häufigere Backups durch. 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 Einführung in Backups und Wiederherstellen einer DB-Instance zu einer bestimmten Zeit.

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.

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.