MariaDB auf Amazon RDS - Amazon Relational Database Service

MariaDB auf Amazon RDS

Amazon RDS unterstützt DB-Instancen, die mehrere MariaDB-Versionen ausführen. Sie können die folgenden Major-Versionen verwenden:

  • MariaDB 10.6

  • MariaDB 10.5

  • MariaDB 10.4

  • MariaDB 10.3

  • MariaDB 10.2 (Ende der Lebensdauer geplant für 15. Oktober 2022)

Weitere Informationen über den Support für Minor-Versionen finden Sie unter MariaDB auf Amazon RDS-Versionen.

Sie verwenden zunächst die Amazon RDS-Management-Tools bzw. Schnittstellen zum Erstellen einer MariaDB-DB-Instance. Sie können dann mit Amazon RDS-Tools Verwaltungsaktionen für die DB-Instance ausführen, wie beispielsweise das Neukonfigurieren oder Ändern der Größe der DB-Instance, das Autorisieren von Verbindungen zur DB-Instance, das Erstellen und Wiederherstellen von Backups oder Snapshots, das Erstellen von sekundären Multi-AZs, das Erstellen von Lesereplikaten sowie das Überwachen der Leistung der DB-Instance. Sie nutzen die standardmäßigen MariaDB-Dienstprogramme und -Anwendungen zum Speichern und Aufrufen der Daten in der DB-Instance.

MariaDB ist in allen AWS-Regionen verfügbar. Weitere Informationen zu AWS-Regionen finden Sie unter Regionen, Availability Zones und Local Zones.

Sie können Amazon RDS for MariaDB-Datenbanken für die Erstellung von HIPAA-kompatiblen Anwendungen verwenden. Mit können Sie Gesundheitsdaten, darunter geschützte patientenbezogene Daten (protected health information, PHI), im Rahmen eines Geschäftspartnervertrags (Business Associate Agreement, BAA) speicher AWS. Weitere Informationen finden Sie unter HIPAA compliance. AWS Die zugelassenen -Services wurden von einem externen Prüfer beurteilt. Anschließend wurde eine Zertifizierung, Compliance-Bescheinigung oder Betriebszulassung (Authority to Operate, ATO) ausgestellt. Weitere Informationen finden Sie unterAWS-Services im Rahmen des Compliance-Programms.

Bevor Sie Ihre erste DB-Instance erstellen, sollten Sie die Schritte für die Einrichtung in diesem Leitfaden durchführen. Weitere Informationen finden Sie unter Einrichten für Amazon RDS.

Häufige Verwaltungsaufgaben für MariaDB auf Amazon RDS

Im Folgenden werden die Verwaltungsaufgaben veranschaulicht, die Sie mit einer Amazon RDS DB-Instance mit MariaDB ausführen. Bei jeder Aufgabe sind Links zu relevanter Dokumentation enthalten.

Aufgabenbereich Relevante Dokumentation

Instance-Klassen, Speicher und PIOPS

Wenn Sie eine DB-Instance zu Produktionszwecken erstellen, müssen Sie wissen, wie Instance-Klassen, Speichertypen und bereitgestellte IOPS in Amazon RDS funktionieren.

DB-Instance-Klassen

Amazon RDS-Speichertypen

Multi-AZ-Bereitstellungen

Sie können mithilfe von synchronen Standby-Replikationen hohe Verfügbarkeit in einer anderen Availability Zone, automatisches Failover, Fehlertoleranz für DB-Instances durch Verwendung von Multi-AZ-Bereitstellungen und Lesereplikate anbieten.

Multi-AZ-Bereitstellungen für Hochverfügbarkeit

Amazon Virtual Private Cloud (VPC)

Wenn Ihr AWS-Konto über eine Standard-VPC verfügt, wird Ihre DB-Instance automatisch in dieser Standard-VPC erstellt. Wenn Ihr Konto über keine Standard-VPC verfügt und Sie die DB-Instance in einer VPC erstellen möchten, müssen Sie zunächst die VPC und Subnetz-Gruppen erstellen.

Ermitteln der verwendeten Plattform: EC2-VPC oder EC2-Classic

Arbeiten mit einer DB-Instance in einer VPC

Sicherheitsgruppen

DB-Instances werden standardmäßig mit einer Firewall erstellt, die den Zugriff auf die Instance verhindert. Daher müssen Sie eine Sicherheitsgruppe mit den korrekten IP-Adressen und Netzwerkkonfigurationen erstellen, um auf die DB-Instance zuzugreifen. Die Sicherheitsgruppe, die Sie erstellen, hängt von der Amazon EC2-Plattform ab, auf der sich Ihre DB-Instance befindet, und davon, ob Sie auf Ihre DB-Instance von einer Amazon EC2-Instance aus zugreifen.

Generell müssen Sie eine DB-Sicherheitsgruppe für Ihre DB-Instance erstellen, falls sich Ihre DB-Instance auf der Plattform EC2-Classic befindet. Wenn sich Ihre DB-Instance auf der Plattform EC2-VPC befindet, müssen Sie eine VPC-Sicherheitsgruppe erstellen.

Ermitteln der verwendeten Plattform: EC2-VPC oder EC2-Classic

Zugriffskontrolle mit Sicherheitsgruppen

Parametergruppen

Wenn Ihre DB-Instance spezifische Datenbankparameter erfordert, sollten Sie vor der DB-Instance eine Parametergruppe erstellen.

Arbeiten mit Parametergruppen

Importieren und Exportieren von Daten

Legen Sie Verfahren für den Import oder Export von Daten fest.

Importieren von Daten in eine MariaDB-DB-Instance

Replikation

Sie können Leseverkehr von Ihrer MariaDB-DB-Quell-Instance durch das Erstellen von Lesereplikaten entladen.

Arbeiten mit Lesereplikaten

Herstellen einer Verbindung mit einer DB-Instance

Verbinden mit Ihrer DB-Instance über eine Standard-SQL-Client-Anwendung.

Herstellen einer Verbindung mit einer DB-Instance, auf der die MariaDB-Datenbank-Engine ausgeführt wird

Sicherung und Backup

Beim Erstellen Ihrer DB-Instance können Sie automatisierte Backups konfigurieren. Sie können Ihre Datenbanken auch mithilfe von vollständigen Sicherungsdateien (.bak-Dateien) manuell sichern oder wiederherstellen.

Arbeiten mit Backups

Überwachung

Überwachen Sie Ihre MariaDB-DB-Instance mithilfe von Amazon CloudWatch-RDS-Metriken, -Ereignissen und „Enhanced Monitoring“ (Erweiterte Überwachung). Sehen Sie sich Protokolldateien für Ihre MariaDB-DB-Instance an.

Anzeigen von Metriken in der Amazon RDS-Konsole

Anzeigen von Amazon RDS-Ereignissen

Protokolldateien

Sie können auf die Protokolldateien für Ihre MariaDB-DB-Instance zugreifen.

Überwachen von Amazon RDS-Protokolldateien

MariaDB-Datenbank-Protokolldateien

Es gibt auch erweiterte administrative Aufgaben für die Arbeit mit DB-Instances mit MariaDB. Weitere Informationen finden Sie in der folgenden Dokumentation:

MariaDB auf Amazon RDS-Versionen

In MariaDB werden die Versionsnummern als Version X.Y.Z organisiert. In der Amazon RDS-Terminologie bezeichnet X.Y die Hauptversion und Z ist die Nummer der Unterversion. Bei Amazon RDS-Implementierungen gilt ein Versionswechsel als wesentlich, wenn sich die Hauptversionsnummer ändert, z. B. von Version 10.5 auf 10.6. Eine Versionsänderung gilt als geringfügig, wenn sich nur die Nebenversionsnummer ändert, z. B. von Version 10.6.5 auf 10.6.7.

Amazon RDS unterstützt derzeit die folgenden MariaDB-Versionen:

Hauptversion Unterversion

MariaDB 10.6

  • 10.6.7

  • 10.6.5

MariaDB 10.5

  • 10.5.15

  • 10.5.13

  • 10.5.12

MariaDB 10.4

  • 10.4.24

  • 10.4.22

  • 10.4.21

MariaDB 10.3

  • 10.3.34

  • 10.3.32

  • 10.3.31

  • 10.3.28

MariaDB 10.2

  • 10.2.43

  • 10.2.41

  • 10.2.40

  • 10.2.39

Sie können alle aktuell unterstützten MariaDB-Versionen beim Erstellen einer neuen DB-Instanz angeben. Sie können die Hauptversionen (wie z. B. MariaDB 10.5) sowie eine beliebige unterstützte Unterversion für die festgelegte Hauptversion festlegen. Wenn keine Version angegeben wird, verwendet Amazon RDS standardmäßig eine unterstützte Version - in der Regel die aktuelle Version. Wenn die Hauptversion, jedoch nicht die Unterversion, festgelegt ist, verwendet Amazon RDS standardmäßig den letzten Release der Hauptversion, die Sie festgelegt haben. Eine Liste aller unterstützten Versionen sowie der Standardversionen für neu erstellte DB-Instances können Sie mit dem AWS CLI-Befehl describe-db-engine-versions aufrufen.

Die Standard-MariaDB-Version kann je nach AWS-Region variieren. Um eine DB-Instance mit einer bestimmten Unterversion zu erstellen, geben Sie die Unterversion bei der Erstellung der DB-Instance an. Sie können die Standard-Unterversion für eine AWS-Region mithilfe des folgenden AWS CLI-Befehls ermitteln:

aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version major-engine-version --region region --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text

Ersetzen Sie major-engine-version durch die Engine-Hauptversion, und ersetzen Sie region durch die AWS-Region. Der folgende AWS CLI-Befehl gibt beispielsweise die standardmäßige MariaDB-Engine-Unterversion für die Hauptversion 10.5 und die USA West (Oregon)-AWS-Region (us-west-2) zurück:

aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version 10.5 --region us-west-2 --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text

MariaDB 10.2 Ende der Lebensdauer

Am 15. Oktober 2022 startet Amazon RDS den Prozess für das Ende der Lebensdauer von MariaDB Version 10.2 nach dem folgenden Zeitplan, der Upgrade-Empfehlungen enthält. Der Prozess für das Ende der Lebensdauer beendet die Standardunterstützung für diese Version. Wir empfehlen Ihnen, alle DB-Instances von MariaDB 10.2 so schnell wie möglich auf MariaDB 10.3 oder höher zu aktualisieren. Weitere Informationen finden Sie unter Aktualisieren der MariaDB-DB-Engine.

Aktion oder Empfehlung Datumsangaben

Wir empfehlen Ihnen, DB-Instances von MariaDB 10.2 manuell auf die Version Ihrer Wahl zu aktualisieren. Sie können direkt auf MariaDB Version 10.3 oder 10.6 aktualisieren.

Jetzt – 15. Oktober 2022

Wir empfehlen Ihnen, Snapshots von MariaDB 10.2 manuell auf die Version Ihrer Wahl zu aktualisieren.

Jetzt – 15. Oktober 2022

Sie können keine neuen DB-Instances von MariaDB 10.2 mehr erstellen.

Sie können weiterhin Lesereplikate bestehender DB-Instances von MariaDB 10.2 erstellen und diese von Single-AZ-Bereitstellungen in Multi-AZ-Bereitstellungen ändern.

15. Juli 2022

Amazon RDS startet automatische Upgrades Ihrer DB-Instances von MariaDB 10.2 auf Version 10.3.

15. Oktober 2022

Amazon RDS startet automatische Upgrades auf Version 10.3 für alle DB-Instances von MariaDB 10.2, die aus Snapshots wiederhergestellt wurden.

15. Oktober 2022

Weitere Informationen zum Ende der Lebensdauer von Amazon RDS for MariaDB 10.2 finden Sie unter Ankündigung: Das Ende der Lebensdauer von Amazon Relational Database Service (Amazon RDS) for MariaDB 10.2 ist der 15. Oktober 2022.

MariaDB-Funktionsunterstützung in Amazon RDS

In den folgenden Abschnitten finden Sie die MariaDB-Funktionsunterstützung in Amazon RDS for MariaDB-Hauptversionen:

Informationen über unterstützte Nebenversionen von Amazon RDS for MariaDB finden Sie unter MariaDB auf Amazon RDS-Versionen.

MariaDB 10.6-Unterstützung in Amazon RDS

Amazon RDS unterstützt die folgenden neuen Funktionen bei DB-Instances mit MariaDB-Version 10.6 oder höher:

  • MyRocks-Speicher-Engine – Sie können die MyRocks-Speicher-Engine mit RDS for MariaDB verwenden, um den Speicherverbrauch Ihrer schreibintensiven, leistungsstarken Webanwendungen zu optimieren. Weitere Informationen finden Sie unter Unterstützte Speicher-Engines für MariaDB auf Amazon RDS und MyRocks.

  • IAM-DB-Authentifizierung – Sie können die IAM-DB-Authentifizierung für bessere Sicherheit und zentrale Verwaltung von Verbindungen zu Ihren MariaDB-DB-Instances verwenden. Weitere Informationen finden Sie unter IAM-Datenbankauthentifizierung für MariaDB, MySQL und PostgreSQL.

  • Upgrade-Optionen – Sie können jetzt von jeder früheren Hauptversion (10.2, 10.3, 10.4, 10.5) auf RDS for MariaDB Version 10.6 aktualisieren. Sie können auch einen Snapshot einer vorhandenen MySQL 5.6- oder 5.7-DB-Instance auf einer MariaDB-10.6-Instance wiederherstellen. Weitere Informationen finden Sie unter Aktualisieren der MariaDB-DB-Engine.

  • Verzögerte Replikation – Sie können jetzt einen konfigurierbaren Zeitraum festlegen, für den ein Lesereplikat hinter der Quelldatenbank zurückbleibt. In einer Standard-MariaDB-Replikationskonfiguration gibt es eine minimale Replikationsverzögerung zwischen der Quelle und dem Replikat. Bei verzögerter Replikation können Sie eine absichtliche Verzögerung als Strategie für die Notfallwiederherstellung festlegen. Weitere Informationen finden Sie unter Konfigurieren der verzögerten Replikation mit MariaDB.

  • Kompatibilität mit Oracle PL/SQL – Durch die Verwendung von RDS for MariaDB Version 10.6 können Sie Ihre älteren Oracle-Anwendungen einfacher auf Amazon RDS migrieren. Weitere Informationen finden Sie unter SQL_MODE=ORACLE.

  • Atomare DDL – Ihre Dynamic-Data-Language(DDL)-Anweisungen können mit RDS for MariaDB Version 10.6 relativ absturzsicher sein. CREATE TABLE, ALTER TABLE, RENAME TABLE, DROP TABLE, DROP DATABASE und verwandte DDL-Anweisungen sind jetzt atomar. Entweder ist die Aussage erfolgreich oder sie ist komplett rückgängig gemacht. Weitere Informationen finden Sie unter Atomare DDL.

  • Weitere Verbesserungen – Zu diesen Verbesserungen gehört eine JSON_TABLE-Funktion zur Umwandlung von JSON-Daten in ein relationales Format innerhalb von SQL und schnelleres Laden von leeren Tabellendaten mit Innodb. Dazu gehören auch das neue sys_schema für die Analyse und Fehlerbehebung, die Optimierungserweiterung für das Ignorieren nicht verwendeter Indizes und Leistungsverbesserungen. Weitere Informationen finden Sie unter JSON_TABLE.

  • Neue Standardwerte für Parameter – Die folgenden Parameter haben neue Standardwerte für MariaDB-Instances der Version 10.6:

Eine Liste aller Funktionen von MariaDB 10.6 und die entsprechende Dokumentation finden Sie unter Changes and improvements in MariaDB 10.6 (Änderungen und Verbesserungen in MariaDB 10.6) und unter Release notes – MariaDB 10.6 (Versionshinweise – MariaDB 10.6) auf der MariaDB-Website.

Eine Liste der nicht unterstützten Funktionen finden Sie unter Nicht unterstützte Funktionen.

MariaDB 10.5-Unterstützung in Amazon RDS

Amazon RDS unterstützt die folgenden neuen Funktionen bei DB-Instances mit MariaDB-Version 10.5 oder höher:

  • InnoDB-Verbesserungen – MariaDB-Version 10.5 enthält Verbesserungen von InnoDB. Weitere Informationen finden Sie unter InnoDB: Performance-Verbesserungen usw.

  • Aktualisierungen des Leistungsschemas – MariaDB Version 10.5 enthält Aktualisierungen des Leistungsschemas. Weitere Informationen finden Sie unter Performance Schema Updates to Match MySQL 5.7 Instrumentation and Tables (Aktualisierungen von Leistungsschemas, zur Übereinstimmung mit MySQL 5.7-Instrumentierung und Tabellen).

  • Eine Datei im Inno DB-Redo-Log – In MariaDB-Versionen vor Version 10.5 wurde der Wert des Parameters innodb_log_files_in_group auf 2 festgelegt. In MariaDB Version 10.5 ist der Wert dieses Parameters auf festgeleg 1.

    Wenn Sie von einer früheren Version auf MariaDB Version 10.5 upgraden und die Parameter nicht ändern, bleibt der Parameterwert innodb_log_file_size unverändert. Es gilt jedoch für eine Protokolldatei statt für zwei. Das Ergebnis ist, dass Ihre aktualisierte MariaDB-Instance der Version 10.5 die Hälfte der Redo-Protokollgröße verwendet, die sie vor dem Upgrade verwendet hat. Diese Änderung kann sich spürbar auf die Leistung auswirken. Um dieses Problem anzugehen, können Sie den Wert des Parameters innodb_log_file_size verdoppeln. Weitere Informationen zum Ändern von Parametern finden Sie unter Ändern von Parametern in einer DB-Parametergruppe.

  • „SHOW SLAVE STATUS“-Befehl wird nicht unterstützt – In MariaDB-Versionen vor Version 10.5 benötigte der Befehl SHOW SLAVE STATUS das Privileg REPLICATION SLAVE. In MariaDB Version 10.5 benötigt der äquivalenteSHOW REPLICA STATUS Befehl das REPLICATION REPLICA ADMIN-Privileg. Dieses neue Privileg wird dem RDS-Master-Benutzer nicht gewährt.

    Anstatt den Befehl SHOW REPLICA STATUS zu verwenden, führen Sie den neuen gespeicherten Prozess mysql.rds_replica_status aus, um ähnliche Informationen zurückzugeben. Weitere Informationen finden Sie unter mysql.rds_replica_status.

  • „SHOW RELAYLOG EVENTS“-Befehl wird nicht unterstützt – In MariaDB-Versionen vor Version 10.5 benötigte der Befehl SHOW RELAYLOG EVENTS das Privileg REPLICATION SLAVE. In MariaDB Version 10.5 benötigt dieser Befehl das Privileg REPLICATION REPLICA ADMIN. Dieses neue Privileg wird dem RDS-Master-Benutzer nicht gewährt.

  • Neue Standardwerte für Parameter – Die folgenden Parameter haben neue Standardwerte für MariaDB-Instances der Version 10.5:

Eine Liste aller Funktionen von MariaDB 10.5 und die entsprechende Dokumentation finden Sie unter Changes and improvements in MariaDB 10.5 (Änderungen und Verbesserungen in MariaDB 10.5) und unter Release notes – MariaDB 10.5 (Versionshinweise – MariaDB 10.5) auf der MariaDB-Website.

Eine Liste der nicht unterstützten Funktionen finden Sie unter Nicht unterstützte Funktionen.

MariaDB 10.4-Unterstützung in Amazon RDS

Amazon RDS unterstützt die folgenden neuen Funktionen bei DB-Instances mit MariaDB-Version 10.4 oder höher:

Eine Liste aller Funktionen von MariaDB 10.4 und die entsprechende Dokumentation finden Sie unter Änderungen und Verbesserungen in MariaDB 10.4 und Versionshinweise – MariaDB 10.4 Serie auf der MariaDB-Website.

Eine Liste der nicht unterstützten Funktionen finden Sie unter Nicht unterstützte Funktionen.

MariaDB 10.3-Unterstützung in Amazon RDS

Amazon RDS unterstützt die folgenden neuen Funktionen bei DB-Instances mit MariaDB Version 10.3 oder höher:

  • Oracle-Kompatibilität – PL/SQL-kompatibler Parser, Sequenzen, INTERSECT und EXCEPT als Ergänzung zu UNION, neue Deklarationen TYPE OF und ROW TYPE OF und verborgene Spalten

  • Temporäre Datenverarbeitung – Tabellen mit Systemversionierung für die Abfrage früherer und aktueller Datenbankstatus

  • Flexibilität – Benutzerdefinierte Aggregate, speicherunabhängige Spaltenkomprimierung und Unterstützung für das Proxy-Protokoll für die Übergabe der Client-IP-Adresse an den Server

  • Verwaltbarkeit – Sofortige ADD COLUMN-Operationen und Data Definition Language (DDL)-Operationen mit Fast-Fail.

Eine Liste aller Funktionen von MariaDB 10.3 und die entsprechende Dokumentation finden Sie unter Änderungen und Verbesserungen in MariaDB 10.3 und Versionshinweise – MariaDB 10.3 Serie auf der MariaDB-Website.

Eine Liste der nicht unterstützten Funktionen finden Sie unter Nicht unterstützte Funktionen.

MariaDB 10.2-Unterstützung in Amazon RDS

Amazon RDS unterstützt die folgenden neuen Funktionen bei DB-Instances mit MariaDB Version 10.2 oder höher:

  • ALTER USER

  • Allgemeine Tabellenausdrücke

  • Komprimieren von Ereignissen, um die Größe des Binärprotokolls zu reduzieren

  • CREATE USER — neue Optionen für die Begrenzung der Ressourcennutzung und TLS/SSL

  • EXECUTE IMMEDIATE

  • Flashback

  • InnoDB — jetzt die Standard-Speicher-Engine statt XtraDB

  • InnoDB — legt die Größe des Pufferpools dynamisch fest

  • JSON-Funktionen

  • Fensterfunktionen

  • WITH

Eine Liste aller Funktionen von MariaDB 10.2 und die entsprechende Dokumentation finden Sie unter Änderungen und Verbesserungen in MariaDB 10.2 und Versionshinweise – MariaDB 10.2 Serie auf der MariaDB-Website.

Eine Liste der nicht unterstützten Funktionen finden Sie unter Nicht unterstützte Funktionen.

Nicht unterstützte Funktionen

Die folgenden MariaDB-Funktionen werden in Amazon RDS nicht unterstützt:

  • S3-Speicher-Engine

  • Authentifizierungs-Plugin – GSSAPI

  • Authentifizierungs-Plugin – Unix Socket

  • AWSKey Management-Verschlüsselungs-Plugin

  • Verzögerte Replikation für MariaDB-Versionen unter 10.6

  • Native MariaDB-Verschlüsselung im Ruhezustand für InnoDB und Aria.

    Sie können die Verschlüsselung von Daten im Ruhezustand für eine MariaDB-DB-Instance durch Befolgen der Anleitungen unter aktiviere Verschlüsseln von Amazon RDS-Ressourcen.

  • HandlerSocket

  • JSON-Tabellentyp für MariaDB-Versionen unter 10.6

  • MariaDB ColumnStore

  • MariaDB Galera-Cluster

  • Replikation aus mehreren Quellen

  • MyRocks-Speicher-Engine für MariaDB-Versionen unter 10.6

  • Passwort-Validierungs-Plugin simple_password_checkund cracklib_password_check

  • Spider-Speicher-Engine

  • Sphinx-Speicher-Engine

  • TokuDB-Speicher-Engine

  • Speicher-Engine-spezifische Objektattribute, wie unter Engine-defined New Table/Field/Index Attributes in der MariaDB-Dokumentation beschrieben.

  • Tabellen- und Tablespace-Verschlüsselung

Zum Bereitstellen einer verwalteten Service-Erfahrung, bietet Amazon RDS keinen Shell-Zugriff auf DB-Instances und schränkt den Zugriff auf bestimmte Verfahren Tabellen ein, die erweiterte Berechtigungen erfordern. Amazon RDS unterstützt den Zugriff auf Datenbanken auf einer DB-Instance mit jeder beliebigen Standard-SQL-Client-Anwendung. Amazon RDS erlaubt keinen direkten Hostzugriff auf eine DB-Instance über Telnet, Secure Shell (SSH) oder Windows Remote Desktop Connection.

Unterstützte Speicher-Engines für MariaDB auf Amazon RDS

RDS for MariaDB unterstützt die folgenden Speicher-Engines.

Andere Speicher-Engines werden derzeit nicht von RDS for MariaDB unterstützt.

Die InnoDB-Speicher-Engine

MariaDB unterstützt zwar mehrere Speicher-Engines mit unterschiedlichen Fähigkeiten und Kapazitäten, jedoch sind nicht alle von ihnen für die Wiederherstellung und für Datenbeständigkeit optimiert. InnoDB ist das empfohlene Speichermodul für MariaDB-DB-Instances in Amazon RDS. Amazon-RDS-Funktionen wie Point-In-Time-Wiederherstellung und Snapshot-Wiederherstellung erfordern eine wiederherstellbare Speicher-Engine und werden nur für die empfohlene Speicher-Engine für die MariaDB-Version unterstützt.

Weitere Informationen finden Sie unter InnoDB.

Die MyRocks-Speicher-Engine

Die MyRocks-Speicher-Engine ist in RDS for MariaDB Version 10.6 und höher verfügbar. Bevor Sie die MyRocks-Speicher-Engine in einer Produktionsdatenbank verwenden, empfehlen wir Ihnen, ein gründliches Benchmarking und Tests durchzuführen, um mögliche Vorteile gegenüber InnoDB für Ihren Anwendungsfall zu überprüfen.

Die Standardparametergruppe für MariaDB Version 10.6 enthält MyRocks-Parameter. Weitere Informationen finden Sie unter Parameter für MariaDB und Arbeiten mit Parametergruppen.

Um eine Tabelle zu erstellen, die die MyRocks-Speicher-Engine verwendet, geben Sie ENGINE=RocksDB in der CREATE TABLE-Anweisung an. Im folgenden Beispiel wird eine Tabelle erstellt, die die MyRocks-Speicher-Engine verwendet.

CREATE TABLE test (a INT NOT NULL, b CHAR(10)) ENGINE=RocksDB;

Es wird dringend davon abgeraten, Transaktionen auszuführen, die sowohl InnoDB- als auch MyRocks-Tabellen umfassen. MariaDB garantiert keine ACID (Atomizität, Kontinuität, Isolation, Haltbarkeit) für Transaktionen über Speicher-Engines hinweg. Obwohl es möglich ist, sowohl InnoDB- als auch MyRocks-Tabellen in einer DB-Instance zu haben, empfehlen wir diesen Ansatz nur während einer Migration von einer Speicher-Engine zur anderen. Wenn sowohl InnoDB- als auch MyRocks-Tabellen in einer DB-Instance vorhanden sind, verfügt jede Speicher-Engine über einen eigenen Pufferpool, der dazu führen kann, dass die Leistung beeinträchtigt wird.

MyRocks unterstützt keine SERIALIZABLE-Isolation oder Lückensperren. Im Allgemeinen können Sie MyRocks also nicht mit aussagebasierter Replikation verwenden. Weitere Informationen finden Sie unter MyRocks und Replikation.

Derzeit können Sie nur die folgenden MyRocks-Parameter ändern:

Die MyRocks-Speicher-Engine und die InnoDB-Speicher-Engine können basierend auf den Einstellungen für die rocksdb_block_cache_size- und innodb_buffer_pool_size-Parameter um Speicher konkurrieren. In einigen Fällen beabsichtigen Sie möglicherweise nur, die MyRocks-Speicher-Engine für eine bestimmte DB-Instance zu verwenden. Wenn dies der Fall ist, empfehlen wir, den innodb_buffer_pool_size minimal-Parameter auf einen minimalen Wert und das rocksdb_block_cache_size so hoch wie möglich zu setzen.

Sie können auf MyRocks-Protokolldateien zugreifen, indem Sie DescribeDBLogFiles und DownloadDBLogFilePortion-Operationen verwenden.

Weitere Informationen zu MyRocks finden Sie unter MyRocks auf der MariaDB-Website.

MariaDB-Dateigrößenlimits in Amazon RDS

Bei MariaDB-DB-Instances beträgt die Maximalgröße einer Tabelle 16 TB, wenn InnoDB-Datei-pro-Tabelle-Tablespaces verwendet werden. Dieses Limit beschränkt auch den Tabellenraum des Systems auf maximal 16 TB. InnoDB-Datei-pro-Tabelle-Tablespaces (mit Tabellen in jeweils einem eigenen Tablespace) werden für MariaDB-DB-Instances standardmäßig festgelegt. Dieses Limit hängt nicht mit dem maximalen Speicherlimit für MariaDB-DB-Instances zusammen. Weitere Informationen über das Speicherlimit finden Sie unter Amazon RDS-DB-Instance-Speicher.

Die Option der InnoDB-Tabellenräumen (innodb_file_per_table) bietet abhängig von der Anwendung sowohl Vor- als auch Nachteile. Um den besten Ansatz für Ihre Anwendung zu bestimmen, lesen Sie File-per-table tablespaces in der MySQL-Dokumentation.

Es wird nicht empfohlen, die Tabellen bis zur maximal möglichen Größe anwachsen zu lassen. Generell hat es sich bewährt, Daten in kleinere Tabellen zu partitionieren, wodurch sich die Leistung und die Wiederherstellungszeiten verbessern.

Eine Möglichkeit, mit der Sie eine große Tabelle in kleinere Tabellen aufteilen können, ist die Partitionierung. Die Partitionierung verteilt Teile Ihrer großen Tabelle in separate Dateien auf der Basis von Regeln, die Sie angeben. Wenn Sie beispielsweise Transaktionen nach Datum speichern, können Sie Partitionierungsregeln erstellen, mit denen ältere Transaktionen in separate Dateien partitioniert werden. Anschließend können Sie regelmäßig die historischen Transaktionsdaten archivieren, die für Ihre Anwendung nicht ständig verfügbar sein müssen. Weitere Informationen finden Sie unter Partitionierung in der MySQL-Dokumentation.

So bestimmen Sie die Dateigröße einer Tabelle

Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Tabellen zu groß ist und evtl. partitioniert werden sollte. Führen Sie den Befehl ANALYZE TABLE für jede Tabelle aus, um die Tabellenstatistik zu aktualisieren. Weitere Informationen finden Sie unter ANALYZE TABLE in der MySQL-Dokumentation.

SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)", DATA_FREE FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');

So aktivieren Sie InnoDB-Datei-pro-Tabelle-Tabellenräume

  • Um InnoDB-Datei-pro-Tabelle-Tablespaces zu aktivieren, legen Sie den Parameter innodb_file_per_table in der Parametergruppe für die DB-Instance auf 1 fest.

So deaktivieren Sie InnoDB-Datei-pro-Tabelle-Tabellenräume

  • Um InnoDB-Datei-pro-Tabelle-Tablespaces zu deaktivieren, legen Sie den Parameter innodb_file_per_table in der Parametergruppe für die DB-Instance auf 0 fest.

Weitere Informationen über das Updaten von Parametergruppen finden Sie unter Arbeiten mit Parametergruppen.

Wenn Sie InnoDB-Datei-pro-Tabelle-Tabellenräume aktiviert oder deaktiviert haben, können Sie den Befehl ALTER TABLE ausführen. Sie können diesen Befehl verwenden, um eine Tabelle vom globalen Tablespace in einen eigenen Tablespace zu verschieben. Oder Sie können eine Tabelle aus ihrem eigenen Tablespace in den globalen Tablespace verschieben. Im Folgenden sehen Sie ein Beispiel.

ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=COPY;

MariaDB-Sicherheit auf Amazon RDS

Die Sicherheit von MariaDB DB-Instancen wird auf drei Ebenen verwaltet:

  • AWS Identity and Access Management kontrolliert, wer Amazon RDS Management-Aktionen bei DB-Instances ausführen kann. Wenn Sie sich in AWS mit den IAM-Anmeldeinformationen anmelden, muss Ihr IAM-Konto über die IAM-Zugriffsrichtlinien verfügen, die erforderlichen Berechtigungen für das Durchführen von Amazon RDS-Verwaltungsvorgängen erteilen. Weitere Informationen finden Sie unter Identity and Access Management in Amazon RDS.

  • Beim Erstellen einer DB-Instance verwenden Sie entweder eine VPC-Sicherheitsgruppe oder eine DB-Sicherheitsgruppe, um zu steuern, welche Geräte und Amazon EC2-Instances Verbindungen zum Endpunkt und Port der DB-INstance öffnen können. Diese Verbindungen können über Secure Socket Layer (SSL) erfolgen. Zusätzlich können Firewall-Regeln in Ihrem Unternehmen steuern, ob Geräte in Ihrem Unternehmen bestehende Verbindungen zur DB-Instance öffnen können.

  • Sobald eine Verbindung zu einer MariaDB DB-Instance geöffnet worden ist, erfolgt die Authentifizierung der Anmeldung und Berechtigungen werden auf die gleiche Weise, wie bei einer eigenständigen Instance von MariaDB angewendet. Befehle wie CREATE USER, RENAME USER, GRANT, REVOKE, und SET PASSWORD arbeiten genauso wie es bei eigenständigen Datenbanken der Fall ist, wie auch das direkte Ändern der Datenbankschematabellen.

Wenn Sie eine Amazon RDS DB-Instance erstellen, hat der Master-Benutzer standardmäßig folgende Berechtigungen:

  • alter

  • alter routine

  • create

  • create routine

  • create temporary tables

  • create user

  • create view

  • delete

  • drop

  • event

  • execute

  • grant option

  • index

  • insert

  • lock tables

  • process

  • references

  • reload

    Dieses Privileg ist auf MariaDB DB-Instancen begrenzt. Es bietet keinen Zugriff auf die FLUSH LOGS oder FLUSH TABLES WITH READ LOCK-Operationen.

  • replication client

  • replication slave

  • select

  • show databases

  • show view

  • trigger

  • update

Weitere Informationen zu diesen Berechtigungen finden Sie unter Benutzerkontenmanagement in der MariaDB Dokumentation.

Anmerkung

Obwohl Sie der Master-Benutzer einer DB-Instance löschen können, empfehlen wir, dies nicht zu tun. Um den Master-Benutzer neu zu erstellen, verwenden Sie die ModifyDBInstance API oder das modify-db-instance-AWS CLI, um ein neues Master-Benutzer-Passwort mit dem entsprechenden Parameter anzugeben. Wenn der Masterbenutzer nicht bereits in der Instance vorhanden ist, wird der Masterbenutzer mit dem angegebenen Passwort erstellt.

Um Verwaltungsdienste für jede DB-Instance bereitzustellen, wird der rdsadmin-Benutzer erstellt, wenn die DB-Instance erstellt wird. Ein Versuch, das Passwort auszulassen oder umzubenennen, oder Berechtigungen für das rdsadmin Konto zu ändern, führt zu einem Fehler.

Um die Verwaltung der DB-Instance zu erlauben, wurden die Befehle kill und kill_query beschränkt. Die Amazon RDS-Befehle mysql.rds_kill, mysql.rds_kill_query und mysql.rds_kill_query_id werden für den Einsatz in MariaDB und MySQL bereitgestellt, damit Sie Benutzersitzungen oder Abfragen auf DB-Instances beenden können.

Verwenden von SSL mit einer MariaDB DB-Instance

Amazon RDS unterstützt Secure Sockets Layer (SSL)-Verbindungen mit DB-Instances, die die MariaDB Datenbank-Engine ausführen. MariaDB verwendet jetzt OpenSSL für sichere Verbindungen.

Amazon RDS erstellt ein SSL-Zertifikat und installiert das Zertifikat auf der DB-Instance, wenn Amazon RDS die Instance bereitstellt. Diese Zertifikate werden von einer Zertifizierungsstelle signiert. Das SSL-Zertifikat enthält den DB-Instance-Endpunkt als allgemeinen Name (Common Name CN) für das SSL-Zertifikat, um gegen Spoofing-Angriffe zu schützen.

Informationen zum Herunterladen von Zertifikaten finden Sie unter Verwenden von SSL/TLS für die Verschlüsselung einer Verbindung zu einer DB-Instance.

Amazon RDS for MariaDB unterstützt Transport Layer Security (TLS) Version 1.0, 1.2 und 1.3 In der folgenden Tabelle ist dargestellt, welche TLS-Versionen für die MySQL-Versionen unterstützt werden.

MariaDB-Version TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3

MariaDB 10.6

Unterstützt

Unterstützt

Unterstützt

Unterstützt

MariaDB 10.5

Unterstützt

Unterstützt

Unterstützt

Unterstützt

MariaDB 10.4

Unterstützt

Unterstützt

Unterstützt

Unterstützt

MariaDB 10.3

Unterstützt

Unterstützt

Unterstützt

Unterstützt

MariaDB 10.2

Unterstützt

Unterstützt

Unterstützt

Unterstützt

Wichtig

Die mysql-Client-Programmparameter unterscheiden sich geringfügig, wenn Sie die MySQL 5.7-Version, die MySQL 8.0-Version oder die MariaDB Version verwenden.

Um herauszufinden, welche Version Sie haben, führen Siemysql-Befehl mit --version-Option aus. Im folgenden Beispiel zeigt die Ausgabe, dass das Client-Programm von MariaDB stammt.

$ mysql --version mysql Ver 15.1 Distrib 10.5.15-MariaDB, for osx10.15 (x86_64) using readline 5.1

Die meisten Linux-Distributionen wie Amazon Linux, CentOS, SUSE und Debian haben MySQL durch MariaDB ersetzt, und diemysqlVersion in ihnen ist von MariaDB.

Um Verbindungen mithilfe des standardmäßigen mysql-Clients zu verschlüsseln, starten Sie den Client mit dem Parameter --ssl-ca, um auf den öffentlichen Schlüssel zu verweisen, wie in den folgenden Beispielen dargestellt.

Im folgenden Beispiel sehen Sie für MySQL 5.7 und höher, wie der Client mit dem Parameter --ssl-ca gestartet wird.

mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=[full path]global-bundle.pem --ssl-mode=REQUIRED

Im folgenden Beispiel sehen Sie für MariaDB, wie der Client mit dem Parameter --ssl-ca gestartet wird.

mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=[full path]global-bundle.pem --ssl

Informationen zum Herunterladen von Zertifikatenbündel finden Sie unter Verwenden von SSL/TLS für die Verschlüsselung einer Verbindung zu einer DB-Instance.

Sie können SSL-Verbindungen für bestimmte Benutzerkonten anfordern. Verwenden Sie beispielsweise eine der folgenden Anweisungen – abhängig von Ihrer MariaDB-Version – um SSL-Verbindungen für das Benutzerkonto anzuforder encrypted_user.

Verwenden Sie die folgende Anweisung:

ALTER USER 'encrypted_user'@'%' REQUIRE SSL;

Weitere Informationen über SSL-Verbindungen mit MariaDB finden Sie in der SSL-Übersicht in der MariaDB-Dokumentation.

Cache-Warming

InnoDB Cache-Warming kann Leistungssteigerungen für Ihre MariaDB-DB-Instance zur Verfügung stellen, indem es den aktuellen Zustand des Zwischenspeicher-Pools speichert, wenn die DB-Instance deaktiviert ist und dann den Zwischenspeicher-Pool von den gespeicherten Informationen lädt, wenn die DB-Instance gestartet wird. Dieser Ansatz umgeht die Notwendigkeit, dass sich der Zwischenspeicher-Pool für den normalen Datenbankbetrieb „erwärmen“ muss und stattdessen wird der Zwischenspeicher-Pool mit den Seiten für bekannte häufige Anfragen geladen. Weitere Informationen über die Cache-Initialisierung finden Sie unter Dumping und Wiederherstellung des Buffer-Pools in der MariaDB-Dokumentation.

Die Cache-Initialisierung ist standardmäßig für MariaDB 10.2 und höhere DB-Instances aktiviert. Um die Cache-Initialisierung zu aktivieren, setzen Sie die Parameter innodb_buffer_pool_dump_at_shutdown und innodb_buffer_pool_load_at_startup in der Parametergruppe für Ihre DB-Instance auf 1. Das Ändern dieser Parameterwerte in einer Parametergruppe betrifft alle MariaDB DB-Instancen, die die gleiche Parametergruppe verwenden. Um die Cache-Initialisierung für spezifische MariaDB-DB-Instances zu aktivieren, müssen Sie möglicherweise eine neue Parametergruppe für diese DB-Instances erstellen. Weitere Informationen zu Parametergruppen finden Sie unter Arbeiten mit Parametergruppen.

Cache-Warming erzeugt vor allem einen Leistungsvorteil für DB-Instances, die Standardspeicher verwenden. Wenn Sie PIOPS-Speicher verwenden, sehen Sie häufig keinen bedeutenden Leistungsgewinn.

Wichtig

Wenn Ihre MariaDB DB-Instance nicht normal herunterfährt, wie bei einem Failover, dann ist der Zwischenspeicher-Pool nicht auf der Festplatte gespeichert. In diesem Fall lädt MariaDB einen verfügbaren Zwischenspeicher-Pool, wenn die DB-Instance gestartet wird. Das ist nicht schlimm, aber der wiederhergestellte Zwischenspeicher-Pool spiegelt möglicherweise nicht den aktuellsten Stand des Zwischenspeicher-Pools vor dem Neustart dar. Wir empfehlen Ihnen Ihren Bufferpool in regelmäßigen Abschnitten in Ihrem Interesse zu verwerfen, um sicherzustellen, dass Sie immer den aktuellsten Zustand in Ihrem Bufferpool für die Initialisierung des Cache beim Starten von haben. Sie können den Zwischenspeicher-Pool auf Abruf laden oder entladen.

Sie können ein Ereignis zum automatischen Entladen des Zwischenspeicher-Pools in regelmäßigen Abständen erstellen. Beispielsweise erstellt das folgende Statement ein Ereignis mit dem Namen periodic_buffer_pool_dump, das den Bufferpool stündlich verwirft.

CREATE EVENT periodic_buffer_pool_dump ON SCHEDULE EVERY 1 HOUR DO CALL mysql.rds_innodb_buffer_pool_dump_now();

Weitere Informationen finden Sie unter Events in der MariaDB-Dokumentation.

Entladen und Laden des Zwischenspeicher-Pools auf Abruf

Sie können den Cache auf Abruf mit den folgenden gespeicherten Prozeduren speichern und laden:

Datenbankparameter für MariaDB

Standardmäßig verwendet eine MariaDB DB-Instance eine für eine MariaDB-Datenbank spezifische DB-Parametergruppe. Diese Parametergruppe enthält einige, aber nicht alle in Amazon RDS-DB-Parametergruppen für die MySQL-Datenbank-Engine enthaltenen Parameter. Sie enthält auch eine Reihe neuer, MariaDB-spezifischer Parameter. Weitere Informationen über die Parameter für RDS for MariaDB DB-Engine finden Sie unter Parameter für MariaDB.

Häufige DBA-Aufgaben für MariaDB

Das Beenden von Sitzungen oder Abfragen, das Überspringen von Replikationsfehlern, das Arbeiten mit InnoDB Tablespaces, um Crash-Recovery-Zeiten zu verbessern und die Verwaltung des globalen Statusverlaufs, sind häufige DBA-Aufgaben, die Sie bei einer MariaDB DB-Instance eventuell durchführen. Sie können diese Aufgaben ebenso wie bei einer MySQL-DB-Instance behandeln. Dies ist unter beschriebe Geläufige DBA-Aufgaben für MySQL-DB-Instances. Die Anweisungen zur Wiederherstellung nach Abstürzen dort beziehen sich auf die MySQL-InnoDB-Engine. Sie gelten aber auch für eine MariaDB-DB-Instance, die InnoDB ausführt.

Lokale Zeitzone für MariaDB DB-Instances

Standardmäßig ist die Zeitzone für eine MariaDB DB-Instance Universal Time Coordinated (koordinierte Weltzeit UTC). Sie können die Zeitzone für Ihre DB-Instance auf die lokale Zeitzone für Ihre Anwendung einstellen.

Setzen Sie den Parameter time_zone in der Parametergruppe für Ihre DB-Instance auf einen der unterstützten Werte, die weiter unten in diesem Abschnitt gelistet sind. Wenn Sie den Parameter time_zone für eine Parametergruppe setzen, wird bei allen DB-Instances und Lesereplikaten, die diese Parametergruppe verwenden, die neue lokale Zeitzone eingestellt. Weitere Informationen zum Einstellen von Parametern in einer Parametergruppe finden Sie unter Arbeiten mit Parametergruppen.

Nachdem Sie die lokale Zeitzone eingestellt haben, werden alle neuen Verbindungen zur Datenbank die Änderung reflektieren. Wenn Sie keine offenen Verbindungen zu Ihrer Datenbank haben, wenn Sie die lokale Zeitzone ändern, sehen Sie die lokale Zeitzonenaktualisierung nicht, nachdem Sie die Verbindung schließen und eine neue Verbindung öffnen.

Sie können eine andere lokale Zeitzone für eine DB-Instance sowie ein oder mehrere ihrer Lesereplikate einstellen. Verwenden Sie eine andere Parametergruppe für die DB-Instance und das/die Replica/s und stellen Sie den Parameter time_zone in jeder Parametergruppe auf eine andere lokale Zeit ein.

Wenn Sie über AWS-Regionen hinweg replizieren, verwenden die DB-Quell-Instance und das Lesereplikat unterschiedliche Parametergruppen (Parametergruppen sind eindeutig für eine AWS-Region). Sie müssen den Parameter time_zone in der Parametergruppe der Instance und des Lesereplikats einstellen, um dieselbe lokale Zeitzone für jede Instance zu verwenden.

Wenn Sie eine DB-Instance von einem DB-Snapshot wiederherstellen, wird die lokale Zeitzone auf UTC eingestellt. Sie können die Zeitzone auf Ihre lokale Zeitzone einstellen, nachdem die Wiederherstellung abgeschlossen ist. Wenn Sie die DB-Instance auf einen Zeitpunkt wiederherstellen, ist die lokale Zeitzone für die wiederhergestellte DB-Instance die Zeitzoneneinstellung von der Parametergruppe für die wiederhergestellte DB-Instance.

Sie können Ihre lokale Zeitzone auf die folgenden Werte einstellen.

Africa/Cairo

Asia/Riyadh

Africa/Casablanca

Asia/Seoul

Africa/Harare

Asia/Shanghai

Africa/Monrovia

Asia/Singapore

Africa/Nairobi

Asia/Taipei

Africa/Tripoli

Asia/Tehran

Africa/Windhoek

Asia/Tokyo

America/Araguaina

Asia/Ulaanbaatar

America/Asuncion

Asia/Vladivostok

America/Bogota

Asia/Yakutsk

America/Buenos_Aires

Asia/Yerevan

America/Caracas

Atlantic/Azores

America/Chihuahua

Australia/Adelaide

America/Cuiaba

Australia/Brisbane

America/Denver

Australia/Darwin

America/Fortaleza

Australia/Hobart

America/Guatemala

Australia/Perth

America/Halifax

Australia/Sydney

America/Manaus

Brazil/East

America/Matamoros

Canada/Newfoundland

America/Monterrey

Canada/Saskatchewan

America/Montevideo

Canada/Yukon

America/Phoenix

Europe/Amsterdam

America/Santiago

Europe/Athens

America/Tijuana

Europe/Dublin

Asia/Amman

Europe/Helsinki

Asia/Ashgabat

Europe/Istanbul

Asia/Baghdad

Europe/Kaliningrad

Asia/Baku

Europe/Moscow

Asia/Bangkok

Europe/Paris

Asia/Beirut

Europe/Prague

Asia/Calcutta

Europe/Sarajevo

Asia/Damascus

Pacific/Auckland

Asia/Dhaka

Pacific/Fiji

Asia/Irkutsk

Pacific/Guam

Asia/Jerusalem

Pacific/Honolulu

Asia/Kabul

Pacific/Samoa

Asia/Karachi

US/Alaska

Asia/Kathmandu

US/Central

Asia/Krasnoyarsk

US/Eastern

Asia/Magadan

US/East-Indiana

Asia/Muscat

US/Pacific

Asia/Novosibirsk

UTC

Reserviertes Wort InnoDB

InnoDB ist ein reserviertes Wort für RDS for MariaDB. Sie können diesen Namen für eine MariaDB-Datenbank nicht verwenden.

Veraltete Versionen für Amazon RDS for MariaDB

Version 10.0 und 10.1 von Amazon RDS for MariaDB sind veraltet.

Weitere Informationen zur Amazon RDS-Veralterungsrichtlinie für MariaDB finden Sie unter Häufig gestellte Fragen zu Amazon RDS.