Problembehandlung 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 dem RDSfreien Meine SQL 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.

Problembehandlung für Amazon RDS

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

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

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 Zugriff auf Ihre DB-Instance in Ihrem, 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 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.

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

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.

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

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.

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 start-db-instance den Befehl

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

  1. Öffnen Sie den https://console.aws.amazon.com/rds/und wählen Sie im Navigationsbereich Datenbanken 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 das Subnetz IDs auf der Registerkarte Konnektivität und Sicherheit.

  3. Verwenden Sie den, AWS CLI um den Befehl auszuführen. start-db-instance 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 nicht RDS für SQL Server-DB-Instances.

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

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

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

  • ENICHECK: Die elastic network interface (ENI) für Ihre Datenbank ist möglicherweise nicht vorhanden.

  • GATEWAYCHECK: Das Internet-Gateway für Ihre öffentlich verfügbare Datenbank ist nicht an die angeschlossenVPC.

  • IP CHECK: In Ihren Subnetzen gibt es keine freien IP-Adressen.

  • SECURITYGROUPCHECK: Ihrer Datenbank sind keine Sicherheitsgruppen zugeordnet oder die Sicherheitsgruppen sind ungültig.

  • SUBNETCHECK: Ihre DB-Subnetzgruppe enthält keine gültigen Subnetze oder es gibt Probleme mit Ihrem Subnetz.

  • VPCCHECK: Das mit Ihrer Datenbank VPC verknüpfte 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 RDS Amazon-Konsole modify-db-instance, den AWS CLI Befehl oder die odifyDBInstanceAPIM-Operation verwenden. Weitere Informationen zum Ändern einer DB-Instance finden Sie unter Ändern einer Amazon RDS-DB-Instance.

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.

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

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

Amazon RDS DB-Instance hat nicht mehr genügend Speicherplatz

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. Ein Aufruf des DescribeDBInstances API Vorgangs für eine DB-Instance, deren Speicherplatz aufgebraucht ist, gibt beispielsweise 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 des ModifyDBInstance API Vorgangs 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

Amazon RDS unzureichende DB-Instance-Kapazität

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 Problemen mit der Instance-Kapazität für Amazon EC2 finden Sie unter Unzureichende Instance-Kapazität im EC2Amazon-Benutzerhandbuch.

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

Probleme mit freiem Speicher in RDS

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

Sie können auch die Speichereinstellungen ändern. In 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?

Meine SQL und MariaDB-Probleme

Sie können Probleme mit My- und MariaDB-DB-Instances diagnostizieren SQL und korrigieren.

Maximale My SQL - und MariaDB-Verbindungen

Die maximal zulässige Anzahl von Verbindungen zu einer RDS for My SQL - oder RDS for MariaDB-DB-Instance basiert auf der Speichermenge, die für ihre DB-Instance-Klasse verfügbar ist. 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 .

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 Parametergruppen für Amazon RDS.

Sie können die maximal zulässige Anzahl von Verbindungen für eine My SQL - 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 My SQL - 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 My SQL DB-Instance kann für ein Speicherlimit in den Status inkompatibler Parameter 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

      Sie können den Wert für ändern. innodb_buffer_pool_size Der Wert entspricht jedoch nicht immer dem, was Sie eingegeben haben. Diese Nichtübereinstimmung tritt aus mehreren Gründen auf. Wenn es sich bei der DB-Instance um eine Micro-DB-Instance handelt, überschreiben wir zunächst den Standardwert und setzen ihn auf 256 MB. Weitere Informationen finden Sie unter Innodb_buffer_pool_size überschreiben.

      Zweitens stellen wir sicher, dass 500 MB Speicher auf der DB-Instance für den Hostmanager, die Engine, das Betriebssystem und den Kernel reserviert sind.

      Schließlich optimieren wir es, innodb_buffer_pool_size indem wir es in Einheiten unterteilen. Der Host-Manager rundet auf das nächste Vielfache dieser Einheiten ab. Die Einheiten werden durch Multiplikation mit innodb_buffer_pool_chunk_size berechnet. innodb_buffer_pool_instances Weitere Informationen finden Sie unter Konfiguration der InnoDB-Pufferpoolgröße in der SQL Dokumentation Meine.

      Die Standardeinstellung für innodb_buffer_pool_instances ist 8, sofern es nicht weniger als 1 GB innodb_buffer_pool_size ist. Wenn weniger als 1 GB innodb_buffer_pool_size ist, innodb_buffer_pool_instances ist die Standardeinstellung für 1. Die Standardeinstellung für innodb_buffer_pool_chunk_size ist 128 MB.

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size(Nur meine SQL 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 429498.

    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 in Amazon RDS.

  2. Starten Sie die DB-Instance neu.

    Weitere Informationen zum Festlegen von Parametern finden Sie unter Starten einer Amazon RDS DB-Instance, die zuvor gestoppt wurde.

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

Nachdem Sie eine My SQL - oder MariaDB-Read-Replica 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 ReplicaLagAmazon-Metrik ansehen.

Die ReplicaLag Metrik gibt den Wert des Seconds_Behind_Master Felds des MariaDB- oder SQL SHOW REPLICA STATUS My-Befehls an. Weitere Informationen finden Sie unter SHOWREPLICASTATUSStatement in der Dokumentation MySQL.

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 Behebung eines My- SQL oder MariaDB-Lesereplikationsfehlers. Ein ReplicaLag-Wert von -1 kann auch bedeuten, dass der Seconds_Behind_Master-Wert nicht bestimmt werden kann oder NULL ist.

Anmerkung

Frühere Versionen von MariaDB und My SQL wurden SHOW SLAVE STATUS stattdessen verwendet. SHOW REPLICA STATUS Wenn Sie eine MariaDB-Version vor 10.5 oder eine Meine SQL 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 Lesereplikationstechnologie My SQL und MariaDB 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 My finden Sie in der Dokumentation My SQL unter Details zur Replikationsimplementierung. SQL 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 der Read Replica für InnoDB for My SQL 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ürLinux, oder: macOS Unix

    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 Behebung eines My- SQL oder MariaDB-Lesereplikationsfehlers

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 - oder MariaDB-Engines 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. 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 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 My SQL - oder MariaDB-DB-Instance muss eine Version ausgeführt werden, die das mysql_rds_skip_repl_error Verfahren enthält. 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. Auf Ihrer My SQL - oder MariaDB-DB-Instance muss eine Version ausgeführt werden, die den mysql_rds_next_master_log Befehl zum Ändern der Replikat-Wiedergabeposition unterstützt. Versionsinformationen finden Sie unter .

  • Aufgrund der hohen Auslastung kann es zu einem vorübergehenden Leistungsproblem kommen. DML 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 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. 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 Behebung eines My SQL Read Replica-Problems.

Für das Erstellen von Triggern mit aktivierter Binärprotokollierung sind Rechte erforderlich SUPER

Wenn Sie versuchen, Trigger in einer RDS for My SQL - oder RDS for 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, SUPER ist das Recht erforderlich, das RDS für My SQL - und RDS MariaDB-DB-Instances eingeschränkt ist. Sie können Trigger erstellen, wenn die Binärprotokollierung ohne die entsprechende SUPER Berechtigung aktiviert ist, indem Sie den 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 erstellen, sodass Sie Trigger in Ihrer RDS for My SQL - oder RDS for MariaDB-DB-Instance mit aktivierter binärer Protokollierung 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 für Trigger mit aktivierter binärer Protokollierung zu erstellen, verwenden Sie den CLI

  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

Wiederherstellung einer DB-Instance, die temporäre Tabellen enthält

Wenn Sie versuchen, Ihre My SQL - 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.

PITRstützt sich sowohl auf Backup-Snapshots als auch auf Binärprotokolle (Binlogs) von My SQL oder MariaDB, um Ihre DB-Instance zu einem bestimmten Zeitpunkt wiederherzustellen. Temporäre Tabelleninformationen können in Binlogs unzuverlässig sein und zu Fehlern führen. PITR Wenn Sie temporäre Tabellen in Ihrer My SQL - oder MariaDB-DB-Instance verwenden, können Sie die Wahrscheinlichkeit eines PITR Fehlers verringern, indem Sie häufigere Backups durchführen. Ein PITR Fehler tritt am wahrscheinlichsten in der Zeit zwischen der Erstellung einer temporären Tabelle und dem nächsten Backup-Snapshot auf.

Wiederherstellung einer DB-Instance, die In-Memory-Tabellen enthält

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 Hinweise zu Backups und finden Sie PITR unter Einführung in Backups undWiederherstellen 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 My SQL - 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 My SQL - und MariaDB-DB-Instances tragen dazu bei, sicherzustellen, dass die Datenbank ACID konform ist und Read Replicas 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.