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
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. |
|
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. |
|
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 |
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 |
Parametergruppen Wenn Ihre DB-Instance spezifische Datenbankparameter erfordert, sollten Sie vor der DB-Instance eine Parametergruppe erstellen. |
|
Importieren und Exportieren von Daten Legen Sie Verfahren für den Import oder Export von Daten fest. |
|
Replikation Sie können Leseverkehr von Ihrer MariaDB-DB-Quell-Instance durch das Erstellen von Lesereplikaten entladen. |
|
Herstellen einer Verbindung mit einer DB-Instance Verbinden mit Ihrer DB-Instance über eine Standard-SQL-Client-Anwendung. |
|
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. |
|
Ü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. |
|
Protokolldateien Sie können auf die Protokolldateien für Ihre MariaDB-DB-Instance zugreifen. |
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 |
|
MariaDB 10.5 |
|
MariaDB 10.4 |
|
MariaDB 10.3 |
|
MariaDB 10.2 |
|
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
--regionregion
--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:
Themen
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 neuesys_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:
-
Der Standardwert für die folgenden Parameter hat sich von
utf8
inutf8mb3
geändert:Obwohl sich die Standardwerte für diese Parameter geändert haben, gibt es keine funktionale Änderung. Weitere Informationen finden Sie unter Unterstützte Zeichensätze und Sortierungen
. -
Der Standardwert des Parameters collation_connection
hat sich von utf8_general_ci
inutf8mb3_general_ci
geändert. Obwohl sich der Standardwert für diesen Parameter geändert hat, gibt es keine funktionale Änderung. -
Der Standardwert des old_mode
-Parameters wurde von unset in UTF8_IS_UTF8MB3
geändert. Obwohl sich der Standardwert für diesen Parameter geändert hat, gibt es keine funktionale Änderung.
-
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)
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
auf2
festgelegt. In MariaDB Version 10.5 ist der Wert dieses Parameters auf festgeleg1
.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 Parametersinnodb_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 PrivilegREPLICATION SLAVE
. In MariaDB Version 10.5 benötigt der äquivalenteSHOW REPLICA STATUS
Befehl dasREPLICATION 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 Prozessmysql.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 PrivilegREPLICATION SLAVE
. In MariaDB Version 10.5 benötigt dieser Befehl das PrivilegREPLICATION 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:
-
Der Standardwert des Parameters max_connections
hat sich in LEAST({DBInstanceClassMemory/25165760},12000)
geändert. Hinweise zur ParameterfunktionLEAST
finden Sie unter DB-Parameter-Funktionen. -
Der Standardwert des Parameters innodb_adaptive_hash_index
wurde in OFF
(0
) geändert. -
Der Standardwert des Parameters innodb_checksum_algorithm
hat sich in full_crc32
geändert. -
Der Standardwert des Parameters innodb_log_file_size
wurde auf 2 GB geändert.
-
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)
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:
-
Verbesserungen bei der Sicherheit von Benutzerkonten – Verbesserungen beim Passwortablauf
und bei der Kontosperrung -
Optimizer-Verbesserungen – Optimizer-Ablaufverfolgungsfunktion
-
InnoDB-Verbesserungen – Sofortige DROP COLUMN-Unterstützung
und sofortige VARCHAR
-Erweiterung fürROW_FORMAT=DYNAMIC
undROW_FORMAT=COMPACT
-
Neue Parameter – Einschließlich tcp_nodedelay
, tls_version und gtid_cleanup_batch_size
Eine Liste aller Funktionen von MariaDB 10.4 und die entsprechende Dokumentation finden Sie unter Änderungen und Verbesserungen in MariaDB 10.4
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
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
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_check
undcracklib_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
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
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
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
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 auf1
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 auf0
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
, undSET 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
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 |
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 diemysql
Version 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
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
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.
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
Entladen und Laden des Zwischenspeicher-Pools auf Abruf
Sie können den Cache auf Abruf mit den folgenden gespeicherten Prozeduren speichern und laden:
Rufen Sie die gespeicherte Prozedur mysql.rds_innodb_buffer_pool_dump_now auf, um den aktuellen Zustand des Bufferpools auf der Festplatte zu verwerfen.
Rufen Sie die gespeicherte Prozedur mysql.rds_innodb_buffer_pool_load_now auf, um den Zustand des Bufferpools auf der Festplatte zu laden oder zu speichern.
Rufen Sie die gespeicherte Prozedur mysql.rds_innodb_buffer_pool_load_abort auf, um eine ladende Operation abzubrechen.
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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