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.
# Amazon RDS für MariaDB
Amazon RDS unterstützt mehrere Versionen von MariaDB für DB-Instances. Weitere Informationen zu unterstützten Versionen finden Sie unter [MariaDB auf Amazon-RDS-Versionen](MariaDB.Concepts.VersionMgmt.md).
Verwenden Sie die Amazon-RDS-Management-Tools bzw. -Schnittstellen zum Erstellen einer MariaDB-DB-Instance. Sie können dann die Amazon-RDS-Tools verwenden, um Verwaltungsaktionen für die DB-Instance durchzuführen. Dazu gehören u. a. folgende Aktionen:
+ Neukonfiguration oder Größenänderung der DB-Instance
+ Autorisieren von Verbindungen mit der DB-Instance
+ Erstellen und Wiederherstellen aus Backups oder Snapshots
+ Erstellen von sekundären Multi-AZ-Instances
+ Erstellen von Read Replicas
+ Überwachen der Leistung Ihrer DB-Instance
Verwenden Sie 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. Mehr über AWS-Regionen erfahren Sie unter [Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
Sie können Amazon RDS für 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](https://aws.amazon.com/compliance/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 unter[AWS-Services im Rahmen des Compliance-Programms](https://aws.amazon.com/compliance/services-in-scope/).
Bevor Sie eine DB-Instance erstellen, führen Sie die Schritte in [Einrichten Ihrer Umgebung für Amazon RDS](CHAP_SettingUp.md) aus. Wenn Sie eine DB-Instance erstellen, erhält das RDS-Hauptbenutzerkonto DBA-Berechtigungen mit einigen Einschränkungen. Verwenden Sie dieses Konto für administrative Aufgaben wie das Erstellen zusätzlicher Datenbankkonten.
Sie können das folgende erstellen:
+ DB-Instances
+ DB-Snapshots
+ Point-in-Time-Wiederherstellungen
+ Automatische Backups
+ Manuelle Backups
Sie können DB-Instances verwenden, auf denen MariaDB in einer Virtual Private Cloud (VPC) auf der Basis von Amazon VPC ausgeführt wird. Sie können auch Funktionen zu Ihrer MariaDB-DB-Instance hinzufügen, indem Sie verschiedene Optionen aktivieren. Amazon RDS unterstützt Multi-AZ-Bereitstellungen für MariaDB als eine Lösung mit hoher Verfügbarkeit und Failover.
**Wichtig**
Um eine verwaltete Service-Erfahrung zu bieten, ermöglicht Amazon RDS keinen Shell-Zugriff auf DB-Instances. Eingeschränkt wird auch der Zugriff auf bestimmte Systemprozeduren und Tabellen, für die erweiterte Berechtigungen erforderlich sind. Sie können mit Standard-SQL-Clients wie mysql auf Ihre Datenbank zugreifen. Sie können jedoch nicht direkt auf den Host zugreifen, indem Sie Telnet oder Secure Shell (SSH) verwenden.
**Topics**
+ [MariaDB-Funktionsunterstützung in Amazon RDS](MariaDB.Concepts.FeatureSupport.md)
+ [MariaDB auf Amazon-RDS-Versionen](MariaDB.Concepts.VersionMgmt.md)
+ [Herstellen einer Verbindung mit Ihrer MariaDB-DB-Instance](USER_ConnectToMariaDBInstance.md)
+ [Sichern von Verbindungen von MariaDB-DB-Instances](securing-mariadb-connections.md)
+ [Verbesserung der Abfrageleistung für RDS für MariaDB mit Amazon RDS Optimized Reads](rds-optimized-reads-mariadb.md)
+ [Verbesserung der Schreibleistung mit Amazon-RDS-optimierten Schreibvorgängen für MariaDB](rds-optimized-writes-mariadb.md)
+ [Upgrades der MariaDB-DB-Engine](USER_UpgradeDBInstance.MariaDB.md)
+ [Aktualisieren einer Engine-Version für MariaDB-DB-Snapshots](mariadb-upgrade-snapshot.md)
+ [Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB](MariaDB.Procedural.Importing.md)
+ [Arbeiten mit der MariaDB-Replikation in Amazon RDS](USER_MariaDB.Replication.md)
+ [Optionen für MariaDB-Datenbank-Engine](Appendix.MariaDB.Options.md)
+ [Parameter für MariaDB](Appendix.MariaDB.Parameters.md)
+ [Migrieren von Daten aus einem MySQL-DB-Snapshot in eine MariaDB-DB-Instance](USER_Migrate_MariaDB.md)
+ [MariaDB auf Amazon RDS – SQL-Referenz](Appendix.MariaDB.SQLRef.md)
+ [Lokale Zeitzone für MariaDB DB-Instances](MariaDB.Concepts.LocalTimeZone.md)
+ [Bekannte Probleme und Einschränkungen für RDS für MariaDB](CHAP_MariaDB.Limitations.md)
# MariaDB-Funktionsunterstützung in Amazon RDS
RDS für MariaDB unterstützt die meisten Funktionen von MariaDB. Einige Funktionen werden möglicherweise nur begrenzt unterstützt oder haben eingeschränkte Berechtigungen.
Sie können neue Amazon RDS Funktionen auf der [Was ist neu mit Datenbank?](https://aws.amazon.com/about-aws/whats-new/database/)-Seite filtern. Wählen Sie für den Filter **Produkte** **Amazon RDS** aus. Suchen Sie dann mit Schlüsselwörtern wie **MariaDB 2023**.
**Anmerkung**
Die folgenden Listen sind nicht vollständig.
Weitere Informationen zur Unterstützung von MariaDB-Funktionen in Amazon RDS finden Sie in den folgenden Themen.
**Topics**
+ [Unterstützte Speicher-Engines für MariaDB auf Amazon RDS](MariaDB.Concepts.Storage.md)
+ [Cache-Warming für MariaDB auf Amazon RDS](MariaDB.Concepts.XtraDBCacheWarming.md)
+ [MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden](MariaDB.Concepts.FeatureNonSupport.md)
## MariaDB-Funktionsunterstützung auf Amazon RDS für MariaDB-Hauptversionen
Den folgenden Abschnitten können Sie Informationen über die Unterstützung von MariaDB-Funktionen in Hauptversionen von Amazon RDS für MariaDB entnehmen:
**Topics**
+ [Unterstützung von MariaDB 11.8 in Amazon RDS](#MariaDB.Concepts.FeatureSupport.11-8)
+ [Unterstützung von MariaDB 11.4 in Amazon RDS](#MariaDB.Concepts.FeatureSupport.11-4)
+ [MariaDB 10.11-Unterstützung in Amazon RDS](#MariaDB.Concepts.FeatureSupport.10-11)
+ [MariaDB 10.6-Unterstützung in Amazon RDS](#MariaDB.Concepts.FeatureSupport.10-6)
+ [MariaDB 10.5-Unterstützung in Amazon RDS](#MariaDB.Concepts.FeatureSupport.10-5)
+ [MariaDB 10.4-Unterstützung in Amazon RDS](#MariaDB.Concepts.FeatureSupport.10-4)
Informationen über unterstützte Nebenversionen von Amazon RDS für MariaDB finden Sie unter [MariaDB auf Amazon-RDS-Versionen](MariaDB.Concepts.VersionMgmt.md).
### Unterstützung von MariaDB 11.8 in Amazon RDS
Amazon RDS unterstützt die folgenden neuen Funktionen für DB-Instances mit MariaDB Version 11.8 oder höher.
**Anmerkung**
In MariaDB 11.8 `require_secure_transport` ist der Standardwert für now`1`, was sichere Verbindungen erfordert. SSL/TLS Dieser Wert wird auf `0` festgelegt, wenn unsichere Verbindungen benötigt werden.
+ **Neuer Standardwert für den Parameter**: Der Standardwert des Parameters `require_secure_transport` wurde von `0` in `1` geändert, wodurch standardmäßig sichere Transportverbindungen erzwungen werden. Weitere Informationen finden Sie unter [Erforderlich SSL/TLS für alle Verbindungen zu einer MariaDB-DB-Instance auf Amazon RDS](mariadb-ssl-connections.require-ssl.md).
+ **Vektorunterstützung**: Sie können den MariaDB-Vector verwenden, um KI-generierte Vektoren direkt in MariaDB zu speichern und zu suchen. Mit dieser Funktion werden die folgenden Systemvariablen eingeführt:
+ Die Variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_distance](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_distance) gibt die Standard-Entfernungsmetrik für die MHNSW-Vektorindizierung an.
+ Die Variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_m](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_m) definiert den Standardwert für den Parameter `M` bei der MHNSW-Vektorindizierung.
+ Die Variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_ef_search](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_ef_search) definiert die Mindestanzahl von Ergebniskandidaten für Vektorindexsuchen.
+ Die Variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_max_cache_size](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_max_cache_size) legt den oberen Grenzwert für einen MHNSW-Vektorindex-Cache fest.
+ **Größenbeschränkungen für temporäre Dateien**: Sie können nun die Größe der erstellten temporären Festplattendateien und Tabellen mithilfe der zwei Systemvariablen begrenzen, die in der Parametergruppe von RDS Maria DB 11.8 verfügbar sind:
+ Die Variable [https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_session_space_usage-system-variable](https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_session_space_usage-system-variable) begrenzt das temporäre Speicherplatzkontingent pro Benutzer.
+ Die Variable [https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_total_space_usage-system-variable](https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_total_space_usage-system-variable) begrenzt das temporäre Speicherplatzkontingent für alle Benutzer.
+ **Temporäre Tablespace-Verwaltung**: Der temporäre Tablespace speichert temporäre Tabellen und wächst an, wenn Daten hinzugefügt werden. Wenn temporäre Tabellen gelöscht werden, wird der Speicherplatz nicht automatisch zurückgewonnen. Mithilfe der Prozedur [mysql.rds\$1execute\$1operation](mysql_rds_execute_operation.md) können Sie den temporären Tablespace verkleinern und Speicherplatz zurückgewinnen.
Eine Liste aller Funktionen von MariaDB 11.8 und die entsprechende Dokumentation finden Sie unter [Änderungen und Verbesserungen in MariaDB 11.8](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-8/) und unter [Versionshinweise – MariaDB 11.8 Serie ](https://mariadb.com/kb/en/release-notes-mariadb-11-8-series/) auf der MariaDB-Website.
Eine Liste der nicht unterstützten Funktionen finden Sie unter [MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden](MariaDB.Concepts.FeatureNonSupport.md).
### Unterstützung von MariaDB 11.4 in Amazon RDS
Amazon RDS unterstützt die folgenden neuen Funktionen für DB-Instances mit MariaDB Version 11.4 oder höher.
+ **Kryptografische Bibliothek** — RDS for MariaDB ersetzte OpenSSL durch AWS Libcrypto (AWS-LC), das FIPS 140-3-zertifiziert ist.
+ **Plugin für einfache Passwortüberprüfung**: Mit dem [Plugin für einfache Passwortüberprüfung](https://mariadb.com/kb/en/simple-password-check-plugin/) in MariaDB können Sie überprüfen, ob ein Passwort mindestens eine bestimmte Anzahl von Zeichen eines bestimmten Typs enthält. Weitere Informationen finden Sie unter [Verwenden des Passwortvalidierungs-Plugins für RDS für MariaDB](MariaDB.Concepts.PasswordValidationPlugins.md).
+ **Plugin für Cracklib-Passwortüberprüfung**: Sie können das [Plugin für Cracklib-Passwortüberprüfung](https://mariadb.com/kb/en/cracklib-password-check-plugin/) in MariaDB verwenden, um die Stärke neuer Passwörter zu überprüfen. Weitere Informationen finden Sie unter [Verwenden des Passwortvalidierungs-Plugins für RDS für MariaDB](MariaDB.Concepts.PasswordValidationPlugins.md).
+ **InnoDB-Verbesserungen** – Diese Verbesserungen umfassen Folgendes:
+ Der Änderungspuffer wurde entfernt. Weitere Informationen finden Sie unter [InnoDB Change Buffering](https://mariadb.com/kb/en/innodb-change-buffering/).
+ Die InnoDB-Defragmentierung wurde entfernt. Weitere Informationen finden Sie unter [InnoDB Defragmentation](https://mariadb.com/kb/en/defragmenting-innodb-tablespaces/#innodb-defragmentation).
+ **Neue Berechtigung**: Der Administratorbenutzer verfügt nun auch über die Berechtigung `SHOW CREATE ROUTINE`. Diese Berechtigung ermöglicht es dem Empfänger, die Definitionsanweisung `SHOW CREATE`einer Routine einzusehen, die einem anderen Benutzer gehört. Weitere Informationen hierzu finden Sie unter [Database Privileges](https://mariadb.com/kb/en/grant/#database-privileges).
+ **Verbesserung der Replikation**: DB-Instances von MariaDB Version 11.4 unterstützen die Binärprotokollindizierung. Sie können für jede Binärprotokolldatei einen GTID-Index erstellen. Diese Indizes verbessern die Leistung der Replikation, indem sie die Zeitdauer reduzieren, die zum Auffinden einer GTID benötigt wird. Weitere Informationen finden Sie unter [Binlog Indexing](https://mariadb.com/kb/en/gtid/#binlog-indexing).
+ **Veraltete oder entfernte Parameter**: Die folgenden Parameter wurden für DB-Instances in MariaDB Version 11.4 als veraltet eingestuft oder entfernt:
+ `engine_condition_pushdown` wurde aus [optimizer\$1switch](https://mariadb.com/kb/en/optimizer-switch/) entfernt
+ [innodb\$1change\$1buffer\$1max\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_change_buffer_max_size)
+ [innodb\$1defragment](https://mariadb.com/kb/en/innodb-system-variables/#innodb_defragment)
+ `TLSv1.0` und `TLSv1.1` wurden aus [tls\$1version](https://mariadb.com/kb/en/ssltls-system-variables/#tls_version) entfernt
+ **Neue Standardwerte für einen Parameter**: Der Standardwert des Parameters [innodb\$1undo\$1tablespaces](https://mariadb.com/kb/en/innodb-system-variables/#innodb_undo_tablespaces) wurde von `0` zu `3` geändert.
+ **Neue gültige Werte für Parameter**: Die folgenden Parameter haben neue gültige Werte für DB-Instances von MariaDB Version 11.4:
+ Die gültigen Werte für den Parameter [binlog\$1row\$1image](https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#binlog_row_image) umfassen nun `FULL_NODUP`.
+ Die gültigen Werte für den Parameter [OLD\$1MODE](https://mariadb.com/kb/en/old-mode/) beinhalten jetzt `NO_NULL_COLLATION_IDS`.
+ **Neue Parameter**: Die folgenden Parameter sind für DB-Instances von MariaDB Version 11.4 neu:
+ Der Parameter [transaction\$1isolation](https://mariadb.com/kb/en/server-system-variables/#transaction_isolation) ersetzt den Parameter [tx\$1isolation](https://mariadb.com/kb/en/server-system-variables/#tx_isolation).
+ Der Parameter [transaction\$1read\$1only](https://mariadb.com/kb/en/server-system-variables/#transaction_read_only) ersetzt den Parameter [tx\$1read\$1only](https://mariadb.com/kb/en/server-system-variables/#tx_read_only).
+ Der Parameter [block\$1encryption\$1mode](https://mariadb.com/kb/en/server-system-variables/#block_encryption_mode) definiert den Standard-Blockverschlüsselungsmodus für die Funktionen [AES\$1ENCRYPT()](https://mariadb.com/kb/en/aes_encrypt/) und [AES\$1DECRYPT()](https://mariadb.com/kb/en/aes_decrypt/).
+ Der Parameter [character\$1set\$1collations](https://mariadb.com/kb/en/server-system-variables/#character_set_collations) definiert Überschreibungen für Zeichensatz-Standardkollationen.
+ Die Parameter [binlog\$1gtid\$1index](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index), [binlog\$1gtid\$1index\$1page\$1size](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index_page_size) und [binlog\$1gtid\$1index\$1span\$1min](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index_span_min) definieren die Eigenschaften des GTID-Indexes des Binärprotokolls. Weitere Informationen finden Sie unter [Binlog Indexing](https://mariadb.com/kb/en/gtid/#binlog-indexing).
Eine Liste aller Funktionen von MariaDB 11.4 und die entsprechende Dokumentation finden Sie unter [Änderungen und Verbesserungen in MariaDB 11.4](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-4/) und [Versionshinweise – MariaDB 11.4 Serie](https://mariadb.com/kb/en/release-notes-mariadb-11-4-series/) auf der MariaDB-Website.
Eine Liste der nicht unterstützten Funktionen finden Sie unter [MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden](MariaDB.Concepts.FeatureNonSupport.md).
### MariaDB 10.11-Unterstützung in Amazon RDS
Amazon RDS unterstützt die folgenden neuen Funktionen bei DB-Instances mit MariaDB Version 10.11 oder höher.
+ **Password Reuse Check Plugin** – Sie können das MariaDB-Plug-in Password Reuse Check verwenden, um zu verhindern, dass Benutzer Passwörter wiederverwenden, und um den Aufbewahrungszeitraum für Passwörter festzulegen. Weitere Informationen finden Sie unter [Password Reuse Check Plugin](https://mariadb.com/kb/en/password-reuse-check-plugin/).
+ **GRANT-TO-PUBLIC-Autorisierung** – Sie können allen Benutzern, die Zugriff auf Ihren Server haben, Berechtigungen erteilen. Weitere Informationen finden Sie unter [GRANT TO PUBLIC](https://mariadb.com/kb/en/grant/#to-public).
+ **Trennung der SUPER- und READ-ONLY-ADMIN-Berechtigungen** – Sie können allen Benutzern READ-ONLY-ADMIN–Berechtigungen entziehen, auch Benutzern, die zuvor SUPER-Berechtigungen hatten.
+ **Sicherheit** – Sie können jetzt die Option `--ssl` als Standard für Ihren MariaDB-Client festlegen. MariaDB deaktiviert SSL nicht mehr unbemerkt, wenn die Konfiguration falsch ist.
+ **SQL-Befehle und Funktionen** – Sie können jetzt den Befehl `SHOW ANALYZE FORMAT=JSON` und die Funktionen `ROW_NUMBER`,`SFORMAT` und `RANDOM_BYTES` verwenden. `SFORMAT` ermöglicht die Formatierung von Zeichenfolgen und ist standardmäßig aktiviert. Sie können mit einem einzigen Befehl Partitionen in Tabellen und Tabellen in Partitionen konvertieren. Es gibt auch mehrere Verbesserungen der `JSON_*()`-Funktionen. Die Funktionen `DES_ENCRYPT` und `DES_DECRYPT` wurden für Version 10.10 und höher als veraltet eingestuft. Weitere Informationen finden Sie unter [SFORMAT](https://mariadb.com/kb/en/sformat/).
+ **InnoDB-Verbesserungen** – Diese Verbesserungen umfassen Folgendes:
+ Leistungsverbesserungen im Redo-Protokoll, um die Write Amplification zu reduzieren und die Gleichzeitigkeit zu verbessern
+ Die Möglichkeit, den Undo-Tablespace zu ändern, ohne das Datenverzeichnis neu zu initialisieren. Diese Verbesserung reduziert den Overhead auf der Steuerebene. Nach Änderung des Undo-Tablespace ist ein Neustart, jedoch keine Neuinitialisierung erforderlich.
+ Support für `CHECK TABLE … EXTENDED` und intern für absteigende Indizes
+ Verbesserungen bei Masseneinfügungen
+ **Binlog-Änderungen** – Diese Änderungen umfassen Folgendes:
+ Protokollierung von `ALTER` in zwei Phasen, um die Replikationslatenz zu verringern. Der Parameter `binlog_alter_two_phase` ist standardmäßig deaktiviert, kann aber über Parametergruppen aktiviert werden.
+ Protokollierung von `explicit_defaults_for_timestamp`
+ Keine Protokollierung mehr von `INCIDENT_EVENT`, wenn die Transaktion sicher rückgängig gemacht werden kann
+ **Verbesserungen** **der Replikation** – DB-Instances in MariaDB Version 10.11 verwenden standardmäßig die GTID-Replikation, wenn dies unterstützt wird. Darüber hinaus ist `Seconds_Behind_Master` genauer.
+ **Clients** – Sie können neue Befehlszeilenoptionen für `mysqlbinglog` und `mariadb-dump` verwenden. Sie können `mariadb-dump` verwenden, um historische Daten zu speichern und wiederherzustellen.
+ **System-Versionsverwaltung** – Sie können den Verlauf ändern. MariaDB erstellt automatisch neue Partitionen.
+ **Atomare DDL** – `CREATE OR REPLACE` ist jetzt atomar. Entweder ist die Aussage erfolgreich oder sie wird komplett rückgängig gemacht.
+ **Wiederholungsprotokoll-Schreibvorgang** – Das Wiederholungsprotokoll schreibt asynchron.
+ **Gespeicherte Funktionen** – Gespeicherte Funktionen unterstützen jetzt die gleichen `IN`-, `OUT`- und `INOUT`-Parameter wie in gespeicherten Prozeduren.
+ **Veraltete oder entfernte Parameter** – Die folgenden Parameter wurden für DB-Instances in MariaDB Version 10.11 als veraltet eingestuft oder entfernt:
+ [innodb\$1change\$1buffering](https://mariadb.com/kb/en/innodb-system-variables/#innodb_change_buffering)
+ [innodb\$1disallow\$1writes](https://mariadb.com/kb/en/innodb-system-variables/#innodb_disallow_writes)
+ [innodb\$1log\$1write\$1ahead\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_write_ahead_size)
+ [innodb\$1prefix\$1index\$1cluster\$1optimization](https://mariadb.com/kb/en/innodb-system-variables/#innodb_prefix_index_cluster_optimization)
+ [keep\$1files\$1on\$1create](https://mariadb.com/kb/en/server-system-variables/#keep_files_on_create)
+ [old](https://mariadb.com/kb/en/server-system-variables/#old)
+ **Dynamische Parameter** – Die folgenden Parameter sind jetzt für MariaDB-Instances der Version 10.11 dynamisch:
+ [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size)
+ [innodb\$1write\$1io\$1threads](https://mariadb.com/kb/en/innodb-system-variables/#innodb_write_io_threads)
+ [innodb\$1read\$1io\$1threads](https://mariadb.com/kb/en/innodb-system-variables/#innodb_read_io_threads)
+ **Neue Standardwerte für Parameter** – Die folgenden Parameter haben neue Standardwerte für MariaDB-Instances der Version 10.11:
+ Der Standardwert für den Parameter [explicit\$1defaults\$1for\$1timestamp](https://mariadb.com/kb/en/server-system-variables/#explicit_defaults_for_timestamp) wurde von `OFF` in `ON` geändert.
+ Der Standardwert für den Parameter [optimizer\$1prune\$1level](https://mariadb.com/kb/en/server-system-variables/#optimizer_prune_level) wurde von `1` in `2` geändert.
+ **Neue gültige Werte für Parameter** – Die folgenden Parameter haben neue gültige Werte für MariaDB-Instances der Version 10.11:
+ Die gültigen Werte für den Parameter [old](https://mariadb.com/kb/en/server-system-variables/#old) wurden mit denen für den Parameter [old\$1mode](https://mariadb.com/kb/en/server-system-variables/#old_mode) zusammengeführt.
+ Die gültigen Werte für den Parameter [histogram\$1type](https://mariadb.com/kb/en/server-system-variables/#histogram_type) beinhalten jetzt `JSON_HB`.
+ Der gültige Wertebereich für den Parameter [innodb\$1log\$1buffer\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_buffer_size) liegt jetzt zwischen `262144` und `4294967295` (256 KB bis 4 096 MB).
+ Der gültige Wertebereich für den Parameter [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size) liegt jetzt zwischen `4194304` und `512GB` (4 MB bis 512 GB).
+ Die gültigen Werte für den Parameter [optimizer\$1prune\$1level](https://mariadb.com/kb/en/server-system-variables/#optimizer_prune_level) beinhalten jetzt `2`.
+ **Neue Parameter** – Die folgenden Parameter sind für MariaDB-Instances der Version 10.11 neu:
+ Der Parameter [binlog\$1alter\$1two\$1phase](https://mariadb.com/kb/en/replication-and-binary-log-system-variables//#binlog_alter_two_phase) kann die Replikationsleistung verbessern.
+ Der Parameter [log\$1slow\$1min\$1examined\$1row\$1limit](https://mariadb.com/kb/en/server-system-variables/#log_slow_min_examined_row_limit) kann die Leistung verbessern.
+ Der Parameter [log\$1slow\$1query](https://mariadb.com/kb/en/server-system-variables/#log_slow_query) und der Parameter [log\$1slow\$1query\$1file](https://mariadb.com/kb/en/server-system-variables/#log_slow_query_file) sind Aliase für `slow_query_log` bzw. `slow_query_log_file`.
+ [optimizer\$1extra\$1pruning\$1depth](https://mariadb.com/kb/en/server-system-variables/#optimizer_extra_pruning_depth)
+ [system\$1versioning\$1insert\$1history](https://mariadb.com/kb/en/system-versioned-tables/#system_versioning_insert_history)
Eine Liste aller Funktionen von MariaDB 10.11 und die entsprechende Dokumentation finden Sie unter [Änderungen und Verbesserungen in MariaDB 10.11](https://mariadb.com/kb/en/changes-improvements-in-mariadb-1011/) und unter [Versionshinweise – MariaDB 10.11](https://mariadb.com/kb/en/release-notes-mariadb-1011-series/) auf der MariaDB-Website.
Eine Liste der nicht unterstützten Funktionen finden Sie unter [MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden](MariaDB.Concepts.FeatureNonSupport.md).
### 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 für MariaDB verwenden, um den Speicherverbrauch Ihrer schreibintensiven, leistungsstarken Webanwendungen zu optimieren. Weitere Informationen erhalten Sie unter [Unterstützte Speicher-Engines für MariaDB auf Amazon RDS](MariaDB.Concepts.Storage.md) und [MyRocks](https://mariadb.com/kb/en/myrocks/).
+ **AWS Identity and Access Management (IAM) DB-Authentifizierung** — Sie können die IAM-DB-Authentifizierung für mehr Sicherheit und zentrale Verwaltung der Verbindungen zu Ihren MariaDB-DB-Instances verwenden. Weitere Informationen finden Sie unter [IAM-Datenbankauthentifizierungfür MariaDB, MySQL und PostgreSQL](UsingWithRDS.IAMDBAuth.md).
+ **Upgrade-Optionen** – Sie können jetzt von jeder früheren Hauptversion (10.3, 10.4, 10.5) auf RDS für MariaDB Version 10.6 aktualisieren. Sie können auch einen Snapshot einer vorhandenen DB-Instance von MySQL 5.6 oder 5.7 auf einer MariaDB-10.6-Instance wiederherstellen. Weitere Informationen finden Sie unter [Upgrades der MariaDB-DB-Engine](USER_UpgradeDBInstance.MariaDB.md).
+ **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](USER_MariaDB.Replication.ReadReplicas.DelayReplication.md).
+ ** PL/SQL Oracle-Kompatibilität** — Durch die Verwendung von RDS für MariaDB Version 10.6 können Sie Ihre älteren Oracle-Anwendungen einfacher zu Amazon RDS migrieren. Weitere Informationen finden Sie unter [SQL\$1MODE=ORACLE](https://mariadb.com/kb/en/sql_modeoracle/).
+ **Atomare DDL** – Ihre Dynamic-Data-Language(DDL)-Anweisungen können mit RDS für 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](https://mariadb.com/kb/en/atomic-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\$1TABLE](https://mariadb.com/kb/en/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` in `utf8mb3` geändert:
+ [character\$1set\$1client](https://mariadb.com/kb/en/server-system-variables/#character_set_client)
+ [character\$1set\$1connection](https://mariadb.com/kb/en/server-system-variables/#character_set_connection)
+ [character\$1set\$1results](https://mariadb.com/kb/en/server-system-variables/#character_set_results)
+ [character\$1set\$1system](https://mariadb.com/kb/en/server-system-variables/#character_set_system)
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](https://mariadb.com/kb/en/supported-character-sets-and-collations/) in der MariaDB-Dokumentation.
+ Der Standardwert des Parameters [ collation\$1connection](https://mariadb.com/kb/en/server-system-variables/#collation_connection) hat sich von `utf8_general_ci` in `utf8mb3_general_ci` geändert. Obwohl sich der Standardwert für diesen Parameter geändert hat, gibt es keine funktionale Änderung.
+ Der Standardwert des [ old\$1mode](https://mariadb.com/kb/en/server-system-variables/#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)](https://mariadb.com/kb/en/changes-improvements-in-mariadb-106/) und unter [Release notes – MariaDB 10.6 (Versionshinweise – MariaDB 10.6)](https://mariadb.com/kb/en/release-notes-mariadb-106-series/) auf der MariaDB-Website.
Eine Liste der nicht unterstützten Funktionen finden Sie unter [MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden](MariaDB.Concepts.FeatureNonSupport.md).
### 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.](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/#innodb-performance-improvements-etc) in der MariaDB-Dokumentation.
+ **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)](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/#performance-schema-updates-to-match-mysql-57-instrumentation-and-tables) in der MariaDB-Dokumentation.
+ **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 in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
+ **„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 äquivalente`SHOW 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\$1replica\$1status](mysql_rds_replica_status.md).
+ **„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:
+ Der Standardwert des Parameters [max\$1connections](https://mariadb.com/kb/en/server-system-variables/#max_connections) hat sich in `LEAST({DBInstanceClassMemory/25165760},12000)` geändert. Hinweise zur Parameterfunktion `LEAST` finden Sie unter [DB-Parameter-Funktionen](USER_ParamValuesRef.md#USER_ParamFunctions).
+ Der Standardwert des Parameters [innodb\$1adaptive\$1hash\$1index](https://mariadb.com/kb/en/innodb-system-variables/#innodb_adaptive_hash_index) wurde in `OFF` (`0`) geändert.
+ Der Standardwert des Parameters [innodb\$1checksum\$1algorithm](https://mariadb.com/kb/en/innodb-system-variables/#innodb_checksum_algorithm) hat sich in `full_crc32` geändert.
+ Der Standardwert des Parameters [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#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)](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/) und unter [Release notes – MariaDB 10.5 (Versionshinweise – MariaDB 10.5)](https://mariadb.com/kb/en/release-notes-mariadb-105-series/) auf der MariaDB-Website.
Eine Liste der nicht unterstützten Funktionen finden Sie unter [MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden](MariaDB.Concepts.FeatureNonSupport.md).
### 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](https://mariadb.com/kb/en/user-password-expiry/) und bei der [Kontosperrung](https://mariadb.com/kb/en/account-locking/)
+ **Optimizer-Verbesserungen** – [Optimizer-Ablaufverfolgungsfunktion](https://mariadb.com/kb/en/optimizer-trace-overview/)
+ **InnoDB-Verbesserungen** – [Sofortige DROP COLUMN-Unterstützung](https://mariadb.com/kb/en/alter-table/#drop-column) und sofortige `VARCHAR`-Erweiterung für `ROW_FORMAT=DYNAMIC` und `ROW_FORMAT=COMPACT`
+ **Neue Parameter** – Einschließlich [tcp\$1nodedelay](https://mariadb.com/kb/en/server-system-variables/#tcp_nodelay), [tls\$1version](https://mariadb.com/kb/en/ssltls-system-variables/#tls_version) und [gtid\$1cleanup\$1batch\$1size](https://mariadb.com/kb/en/gtid/#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](https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-104/) und [Versionshinweise – MariaDB 10.4 Serie](https://mariadb.com/kb/en/library/release-notes-mariadb-104-series/) auf der MariaDB-Website.
Eine Liste der nicht unterstützten Funktionen finden Sie unter [MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden](MariaDB.Concepts.FeatureNonSupport.md).
# Unterstützte Speicher-Engines für MariaDB auf Amazon RDS
RDS für MariaDB unterstützt die folgenden Speicher-Engines.
**Topics**
+ [Die InnoDB-Speicher-Engine](#MariaDB.Concepts.Storage.InnoDB)
+ [Die Speicher-Engine MyRocks](#MariaDB.Concepts.Storage.MyRocks)
Andere Speicher-Engines werden derzeit nicht von RDS für 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](https://mariadb.com/kb/en/innodb/).
## Die Speicher-Engine MyRocks
Die MyRocks Speicher-Engine ist in RDS für MariaDB Version 10.6 und höher verfügbar. Bevor Sie die MyRocks Speicher-Engine in einer Produktionsdatenbank verwenden, empfehlen wir Ihnen, gründliche Benchmarks und Tests durchzuführen, um alle potenziellen Vorteile gegenüber InnoDB für Ihren Anwendungsfall zu überprüfen.
Die Standardparametergruppe für MariaDB Version 10.6 umfasst Parameter. MyRocks Weitere Informationen erhalten Sie unter [Parameter für MariaDB](Appendix.MariaDB.Parameters.md) und [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Um eine Tabelle zu erstellen, die die MyRocks Speicher-Engine verwendet, geben Sie `ENGINE=RocksDB` in der Anweisung Folgendes an. `CREATE TABLE` 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;
```
Wir empfehlen dringend, keine Transaktionen auszuführen, die sich sowohl auf InnoDB als auch auf MyRocks Tabellen erstrecken. 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 bei einer Migration von einer Speicher-Engine zur anderen. Wenn sowohl InnoDB als auch MyRocks Tabellen in einer DB-Instance vorhanden sind, hat jede Speicher-Engine ihren eigenen Pufferpool, was zu Leistungseinbußen führen kann.
MyRocks unterstützt keine `SERIALIZABLE` Isolations- oder Gap-Locks. Daher ist die Verwendung bei der anweisungsbasierten MyRocks Replikation im Allgemeinen nicht möglich. Weitere Informationen finden Sie unter [ MyRocks und](https://mariadb.com/kb/en/myrocks-and-replication/) Replikation.
Derzeit können Sie nur die folgenden MyRocks Parameter ändern:
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_block_cache_size](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_block_cache_size)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load_size](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load_size)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect_depth](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect_depth)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_max_latest_deadlocks](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_max_latest_deadlocks)
Die MyRocks Speicher-Engine und die InnoDB-Speicher-Engine können auf der Grundlage der Einstellungen für die `innodb_buffer_pool_size` Parameter `rocksdb_block_cache_size` und um Speicher konkurrieren. In einigen Fällen beabsichtigen Sie möglicherweise, die MyRocks Speicher-Engine nur auf einer bestimmten 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 mithilfe der [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html)Operationen [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html)und auf MyRocks Protokolldateien zugreifen.
Weitere Informationen zu MyRocks finden Sie [MyRocks](https://mariadb.com/kb/en/myrocks/)auf der MariaDB-Website.
# Cache-Warming für MariaDB auf Amazon RDS
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](http://mariadb.com/kb/en/mariadb/xtradbinnodb-buffer-pool/#dumping-and-restoring-the-buffer-pool) in der MariaDB-Dokumentation.
Die Cache-Initialisierung ist standardmäßig für MariaDB 10.3 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 [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
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.
```
1. CREATE EVENT periodic_buffer_pool_dump
2. ON SCHEDULE EVERY 1 HOUR
3. DO CALL mysql.rds_innodb_buffer_pool_dump_now();
```
Weitere Informationen finden Sie unter [Events](http://mariadb.com/kb/en/mariadb/stored-programs-and-views-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:
+ Rufen Sie die gespeicherte Prozedur [mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now](mysql-stored-proc-warming.md#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\$1innodb\$1buffer\$1pool\$1load\$1now](mysql-stored-proc-warming.md#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\$1innodb\$1buffer\$1pool\$1load\$1abort](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_abort) auf, um eine ladende Operation abzubrechen.
# MariaDB-Funktionen, die nicht von Amazon RDS unterstützt werden
Die folgenden MariaDB-Funktionen werden in Amazon RDS nicht unterstützt:
+ S3-Speicher-Engine
+ Authentifizierungs-Plugin – GSSAPI
+ Authentifizierungs-Plugin – Unix Socket
+ AWS Verschlüsselungs-Plugin für die Schlüsselverwaltung
+ 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](Overview.Encryption.md).
+ 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
+ Plugin für die Passwortvalidierung, `simple_password_check` und `cracklib_password_check` für MariaDB-Versionen unter 11.4
+ Spider-Speicher-Engine
+ Sphinx-Speicher-Engine
+ TokuDB-Speicher-Engine
+ Speicher-Engine-spezifische Objektattribute, wie in [Engine-definierte neue Table/Field/Index Attribute](http://mariadb.com/kb/en/mariadb/engine-defined-new-tablefieldindex-attributes/) in der MariaDB-Dokumentation beschrieben
+ Tabellen- und Tablespace-Verschlüsselung
+ Hashicorp Key Management Plugin
+ Parallele Ausführung von zwei Upgrades
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.
# 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 Nummer der Nebenversion ändert, z. B. von Version 10.6.14 auf 10.6.16.
**Topics**
+ [Unterstützte MariaDB-Nebenversionen in Amazon RDS](#MariaDB.Concepts.VersionMgmt.Supported)
+ [Unterstützte MariaDB-Hauptversionen in Amazon RDS](#MariaDB.Concepts.VersionMgmt.ReleaseCalendar)
+ [Arbeiten mit der Datenbank-Vorschauumgebung](#mariadb-working-with-the-database-preview-environment)
+ [MariaDB Version 11.7 in der Datenbank-Vorschauumgebung](#mariadb-preview-environment-version-11-7)
+ [Veraltete Versionen für Amazon RDS für MariaDB](#MariaDB.Concepts.DeprecatedVersions)
## Unterstützte MariaDB-Nebenversionen in Amazon RDS
Amazon RDS unterstützt derzeit die folgenden MariaDB-Nebenversionen.
**Anmerkung**
Daten mit nur einem Monat und einem Jahr sind ungefähre Angaben und werden mit einem genauen Datum aktualisiert, wenn es bekannt ist.
In der folgenden Tabelle sind die Nebenversionen von MariaDB 11.8 angegeben, die von Amazon RDS derzeit unterstützt werden.
| MariaDB-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS-Ende des Standard-Supportdatums |
| --- | --- | --- | --- |
| 11,8,6 | 04. Februar 2026 | 10. Februar 2026 | Februar 2027 |
| 11.8.5 | 14. November 2025 | 20. November 2025 | November 2026 |
| 11.8.3 | 6. August 2025 | 25. August 2025 | September 2026 |
In der folgenden Tabelle sind die Nebenversionen von MariaDB 11.4 angegeben, die von Amazon RDS derzeit unterstützt werden.
| MariaDB-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS-Ende des Standard-Supportdatums |
| --- | --- | --- | --- |
| 11.4,10 | 04. Februar 2026 | 10. Februar 2026 | Februar 2027 |
| 11.4.9 | 6. November 2025 | 18. November 2025 | November 2026 |
| 11.4.8 | 6. August 2025 | 13. August 2025 | September 2026 |
| 11.4.7 | 22. Mai 2025 | 4. Juni 2025 | September 2026 |
| 11.4.5 | 4. Februar 2025 | 24. Februar 2025 | Mai 2026 |
| 11.4.4 | 1. November 2024 | 20. Dezember 2024 | Mai 2026 |
| 11.4.3 | 8. August 2024 | 15. Oktober 2024 | Mai 2026 |
In der folgenden Tabelle sind die Nebenversionen von MariaDB 10.11 angegeben, die von Amazon RDS derzeit unterstützt werden.
| MariaDB-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS-Ende des Standard-Supportdatums |
| --- | --- | --- | --- |
| 10.11.16 | 04. Februar 2026 | 10. Februar 2026 | Februar 2027 |
| 10.11.15 | 6. November 2025 | 18. November 2025 | November 2026 |
| 10.11.14 | 6. August 2025 | 13. August 2025 | September 2026 |
| 10.11.13 | 22. Mai 2025 | 4. Juni 2025 | September 2026 |
| 10.11.11 | 4. Februar 2025 | 24. Februar 2025 | Mai 2026 |
| 10.11.10 | 1. November 2024 | 20. Dezember 2024 | Mai 2026 |
| 10.11.9 | 8. August 2024 | 4. September 2024 | Mai 2026 |
In der folgenden Tabelle sind die Nebenversionen von MariaDB 10.6 angegeben, die von Amazon RDS derzeit unterstützt werden.
| MariaDB-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS-Ende des Standard-Supportdatums |
| --- | --- | --- | --- |
| 10.6.25 | 04. Februar 2026 | 10. Februar 2026 | Juli 2026 |
| 10.6.24 | 6. November 2025 | 18. November 2025 | Juli 2026 |
| 10.6.23 | 6. August 2025 | 13. August 2025 | Juli 2026 |
| 10.6.22 | 6. Mai 2025 | 20. Mai 2025 | Juli 2026 |
| 10.6.21 | 4. Februar 2025 | 24. Februar 2025 | Mai 2026 |
| 10.6.20 | 1. November 2024 | 20. Dezember 2024 | Mai 2026 |
| 10.6.19 | 8. August 2024 | 4. September 2024 | Mai 2026 |
In der folgenden Tabelle sind die Nebenversionen von MariaDB 10.5 angegeben, die von Amazon RDS derzeit unterstützt werden.
| MariaDB-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS-Ende des Standard-Supportdatums |
| --- | --- | --- | --- |
| 10.5.29 | 6. Mai 2025 | 20. Mai 2025 | Juni 2026 |
| 10.5.28 | 4. Februar 2025 | 24. Februar 2025 | Juni 2026 |
| 10.5.27 | 1. November 2024 | 20. Dezember 2024 | Mai 2026 |
Sie können alle aktuell unterstützten MariaDB-Versionen beim Erstellen einer neuen DB-Instance 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. Verwenden Sie den Befehl, um eine Liste der unterstützten Versionen sowie die Standardeinstellungen für neu erstellte DB-Instances anzuzeigen. [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI
Um beispielsweise die unterstützten Engine-Versionen für RDS für MariaDB aufzulisten, führen Sie den folgenden CLI-Befehl aus:
```
aws rds describe-db-engine-versions --engine mariadb --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
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-Nebenversion für eine ermitteln, AWS-Region indem Sie den folgenden AWS CLI Befehl ausführen:
```
aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version major_engine_version --region region --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
*major\$1engine\$1version*Ersetzen Sie durch die Hauptversion der Engine und *region* ersetzen Sie sie durch die AWS-Region. Der folgende AWS CLI Befehl gibt beispielsweise die Standardversion der MariaDB-Nebenengine 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-Nebenversionen in Amazon RDS
**Topics**
+ [MariaDB versie 11.8.6](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.6)
+ [MariaDB versie 11.8.5](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.5)
+ [MariaDB Version 11.8.3](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.3)
+ [MariaDB versie 11.4.10](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.10)
+ [MariaDB versie 11.4.9](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.9)
+ [MariaDB Version 11.4.8](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.8)
+ [MariaDB Version 11.4.7](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.7)
+ [MariaDB Version 11.4.5](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.5)
+ [MariaDB Version 11.4.4](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.4)
+ [MariaDB versie 10.11.16](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.16)
+ [MariaDB versie 10.11.15](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.15)
+ [MariaDB Version 10.11.14](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.14)
+ [MariaDB Version 10.11.13](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.13)
+ [MariaDB Version 10.11.11](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.11)
+ [MariaDB Version 10.11.10](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.10)
+ [MariaDB versie 10.6.25](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.25)
+ [MariaDB versie 10.6.24](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.24)
+ [MariaDB Version 10.6.23](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.23)
+ [MariaDB Version 10.6.22](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.22)
+ [MariaDB Version 10.6.21](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.21)
+ [MariaDB Version 10.6.20](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.20)
+ [MariaDB Version 10.5.29](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.29)
+ [MariaDB Version 10.5.28](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.28)
+ [MariaDB Version 10.5.27](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.27)
#### MariaDB versie 11.8.6
MariaDB Version 11.8.6 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025c` basieren.
+ Es wurde ein Problem behoben, das dazu führen kann, dass einige SQL-Anweisungen nicht im Audit-Log protokolliert wurden.
#### MariaDB versie 11.8.5
MariaDB Version 11.8.5 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
#### MariaDB Version 11.8.3
MariaDB Version 11.8.3 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ **Neuer Standardwert für den Parameter**: Der Standardwert des Parameters `require_secure_transport` wurde von `0` in `1` geändert, wodurch standardmäßig sichere Transportverbindungen erzwungen werden. Weitere Informationen finden Sie unter [Erforderlich SSL/TLS für alle Verbindungen zu einer MariaDB-DB-Instance auf Amazon RDS](mariadb-ssl-connections.require-ssl.md).
#### MariaDB versie 11.4.10
MariaDB Version 11.4.10 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025c` basieren.
+ Es wurde ein Problem behoben, das dazu führen kann, dass einige SQL-Anweisungen nicht im Audit-Log protokolliert wurden.
#### MariaDB versie 11.4.9
MariaDB Version 11.4.9 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
#### MariaDB Version 11.4.8
MariaDB Version 11.4.8 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
#### MariaDB Version 11.4.7
MariaDB Version 11.4.7 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025b` basieren.
#### MariaDB Version 11.4.5
MariaDB Version 11.4.5 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025a` basieren.
#### MariaDB Version 11.4.4
MariaDB Version 11.4.4 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Zwei Änderungen der MariaDB-Community, die dazu führen, dass die point-in-time Wiederherstellung (PITR) fehlschlägt, wurden rückgängig gemacht. Weitere Informationen finden Sie unter [MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
#### MariaDB versie 10.11.16
MariaDB Version 10.11.16 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025c` basieren.
+ Es wurde ein Problem behoben, das dazu führen kann, dass einige SQL-Anweisungen nicht im Audit-Log protokolliert wurden.
#### MariaDB versie 10.11.15
MariaDB Version 10.11.15 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
#### MariaDB Version 10.11.14
MariaDB Version 10.11.14 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
#### MariaDB Version 10.11.13
MariaDB Version 10.11.13 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025b` basieren.
#### MariaDB Version 10.11.11
MariaDB Version 10.11.11 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025a` basieren.
#### MariaDB Version 10.11.10
MariaDB Version 10.11.10 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Zwei Änderungen der MariaDB-Community, die dazu führen, dass die point-in-time Wiederherstellung (PITR) fehlschlägt, wurden rückgängig gemacht. Weitere Informationen finden Sie unter [MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
#### MariaDB versie 10.6.25
MariaDB Version 10.6.25 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025c` basieren.
+ Es wurde ein Problem behoben, das dazu führen kann, dass einige SQL-Anweisungen nicht im Audit-Log protokolliert wurden.
#### MariaDB versie 10.6.24
MariaDB Version 10.6.24 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
#### MariaDB Version 10.6.23
MariaDB Version 10.6.23 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
#### MariaDB Version 10.6.22
MariaDB Version 10.6.22 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025b` basieren.
#### MariaDB Version 10.6.21
MariaDB Version 10.6.21 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025a` basieren.
#### MariaDB Version 10.6.20
MariaDB Version 10.6.20 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Zwei Änderungen der MariaDB-Community, die dazu führen, dass die point-in-time Wiederherstellung (PITR) fehlschlägt, wurden rückgängig gemacht. Weitere Informationen finden Sie unter [MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
#### MariaDB Version 10.5.29
MariaDB Version 10.5.29 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025b` basieren.
#### MariaDB Version 10.5.28
MariaDB Version 10.5.28 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025a` basieren.
#### MariaDB Version 10.5.27
MariaDB Version 10.5.27 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MariaDB-Community und in Amazon RDS hinzugefügt wurden.
**Neue Features und Verbesserungen**
+ Zwei Änderungen der MariaDB-Community, die dazu führen, dass die point-in-time Wiederherstellung (PITR) fehlschlägt, wurden rückgängig gemacht. Weitere Informationen finden Sie unter [MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
## Unterstützte MariaDB-Hauptversionen in Amazon RDS
Die Hauptversionen von RDS für MariaDB stehen mindestens bis zum Ende des Lebenszyklus der Community für die entsprechende Community-Version zur Verfügung. Sie können die folgenden Daten verwenden, um Ihre Test- und Upgrade-Zyklen zu planen. Wenn Amazon die Unterstützung für eine RDS für MariaDB-Version länger als ursprünglich geplant erweitert, planen wir, diese Tabelle zu aktualisieren, um das spätere Datum widerzuspiegeln.
**Anmerkung**
Daten mit nur einem Monat und einem Jahr sind ungefähre Angaben und werden mit einem genauen Datum aktualisiert, wenn es bekannt ist.
[Sie können auch Informationen zu den Support-Daten für wichtige Engine-Versionen anzeigen, indem Sie den AWS CLI Befehl [describe-db-major-engine-versions ausführen oder den API-Vorgang](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) Describe RDS verwenden. DBMajor EngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html)
| MariaDB Hauptversion | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | Datum des Lebensendes der Gemeinschaft | RDS-Ende des Standard-Supportdatums |
| --- | --- | --- | --- | --- |
| MariaDB 11.8 | 6. August 2025 | 25. August 2025 | Juni 2030 | Juni 2030 |
| MariaDB 11.4 | 8. August 2024 | 15. Oktober 2024 | Mai 2029 | Mai 2029 |
| MariaDB 10.11 | 16. Februar 2023 | 21. August 2023 | 16. Februar 2028 | Februar 2028 |
| MariaDB 10.6 | 6. Juli 2021 | 3. Februar 2022 | 6. Juli 2026 | August 2026 |
| MariaDB 10.5 | 24. Juni 2020 | 21. Januar 2021 | 24. Juni 2025 | August 2026 |
## Arbeiten mit der Datenbank-Vorschauumgebung
DB-Instances von RDS für MariaDB in der Datenbank-Vorschauumgebung funktionieren ähnlich wie andere DB-Instances von RDS für MariaDB. Sie können die Datenbank-Vorschauumgebung jedoch nicht für Produktions-Workloads nutzen.
Für Vorschauumgebungen gelten folgende Einschränkungen:
+ Amazon RDS löscht alle DB-Instances 60 Tage nach Erstellung zusammen mit allen Backups und Snapshots.
+ Sie können nur Allzweck-SSD und bereitgestellte IOPS-SSD als Speicher verwenden.
+ Sie können keine Hilfe von Support DB-Instances erhalten. [Stattdessen können Sie Ihre Fragen in der von uns AWS verwalteten Q&A-Community re:POST stellen.AWS](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service)
+ Sie können einen Snapshot einer DB-Instance nicht in eine Produktionsumgebung kopieren.
Die folgenden Optionen werden von der Vorschauversion unterstützt.
+ Sie können DB-Instances mithilfe von db.m6i-, db.r6i-, db.m6g-, db.m5-, db.t3-, db.r6g- und db.r5-DB-Instance-Klassen erstellen. Weitere Informationen zu RDS-Instance-Klassen erhalten Sie unter [](Concepts.DBInstanceClass.md).
+ Sie können Single-AZ- und Multi-AZ-Bereitstellungen verwenden.
+ Sie können die standardmäßigen MariaDB-Dump- und -Ladefunktionen verwenden, um Datenbanken von der Datenbank-Vorschauumgebung zu exportieren oder in diese zu importieren.
### Nicht in der Datenbank-Vorschauumgebung unterstützte Features
Die folgenden Features sind in der Datenbank-Vorschauumgebung nicht verfügbar:
+ Regionsübergreifende Snapshot-Kopie
+ Regionsübergreifende Lesereplikate
+ RDS-Proxy
### Erstellen einer neuen DB-Instance in der Datenbank-Vorschauumgebung
Sie können eine DB-Instance in der Database Preview-Umgebung mithilfe der AWS-Managementkonsole AWS CLI, oder RDS-API erstellen.
#### Konsole
**So erstellen Sie eine DB-Instance in der Datenbank-Vorschauumgebung**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Dashboard** aus.
1. Suchen Sie auf der Seite **Dashboard** nach **Datenbank-Preview-Umgebung**, wie in der folgenden Abbildung gezeigt.
![\[Der Bereich Datenbank-Vorschauumgebung mit Link in der Amazon-RDS-Konsole.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Sie können auch direkt zu [Datenbank-Preview-Umgebung](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#) navigieren. Bevor Sie fortfahren können, müssen Sie die Einschränkungen bestätigen und akzeptieren.
![\[Das Dialogfeld Servicevereinbarung für die Datenbank-Vorschauumgebung zur Bestätigung der Einschränkungen.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Um die DB-Instance von RDS für MariaDB zu erstellen, gehen Sie genauso vor wie bei der Erstellung einer DB-Instance von Amazon RDS. Weitere Informationen finden Sie im Verfahren [Konsole](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) unter [Erstellen einer DB-Instance](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
#### AWS CLI
Verwenden Sie den folgenden Endpunkt, um eine DB-Instance in der AWS CLI Database Preview-Umgebung mit dem zu erstellen.
```
rds-preview.us-east-2.amazonaws.com
```
Um die DB-Instance von RDS für MariaDB zu erstellen, gehen Sie genauso vor wie bei der Erstellung einer DB-Instance von Amazon RDS. Weitere Informationen finden Sie im Verfahren [AWS CLI](USER_CreateDBInstance.md#USER_CreateDBInstance.CLI) unter [Erstellen einer DB-Instance](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
#### RDS-API
Verwenden Sie den folgenden Endpunkt, um eine DB-Instance in der Datenbank-Vorschauumgebung über die RDS-API zu erstellen.
```
rds-preview.us-east-2.amazonaws.com
```
Um die DB-Instance von RDS für MariaDB zu erstellen, gehen Sie genauso vor wie bei der Erstellung einer DB-Instance von Amazon RDS. Weitere Informationen finden Sie im Verfahren [RDS-API](USER_CreateDBInstance.md#USER_CreateDBInstance.API) unter [Erstellen einer DB-Instance](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
## MariaDB Version 11.7 in der Datenbank-Vorschauumgebung
MariaDB Version 11.7 ist jetzt in der Datenbank-Vorschauumgebung in Amazon RDS verfügbar. MariaDB Version 11.7 enthält verschiedene Verbesserungen, die unter [Changes and improvements in MariaDB 11.7](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-7/) beschrieben werden. Diese Version bietet auch Support für den Vektordatentyp, die Indexierung und die Suche. Weitere Informationen finden Sie unter [Vector Overview](https://mariadb.com/kb/en/vector-overview/) in der MariaDB-Dokumentation.
Sie können die Database Preview-Umgebung verwenden, um Ihre Workloads anhand dieser Version zu testen, bevor sie in allen AWS-Regionen für Produktions-Workloads verfügbar ist. Weitere Informationen zur Database-Vorschauumgebung finden Sie unter [Arbeiten mit der Datenbank-Vorschauumgebung](#mariadb-working-with-the-database-preview-environment). Um von der Konsole auf die Preview-Umgebung zuzugreifen, wählen Sie [rds-preview/](https://console.aws.amazon.com/rds-preview/) aus.
## Veraltete Versionen für Amazon RDS für MariaDB
Die Versionen 10.0, 10.1, 10.2 und 10.3 von Amazon RDS für MariaDB sind veraltet.
[Informationen zur Amazon RDS-Verfallsrichtlinie für MariaDB finden Sie unter Amazon RDS. FAQs](https://aws.amazon.com/rds/faqs/)
# Herstellen einer Verbindung mit Ihrer MariaDB-DB-Instance
Nachdem Amazon RDS Ihre DB-Instance bereitgestellt hat, können Sie jede Standard-MariaDB-Client-Anwendung und jedes -Hilfsprogramm verwenden, um eine Verbindung mit der Instance herzustellen. In der Verbindungszeichenfolge geben Sie die DNS-Adresse (Domain Name System) vom DB-Instance-Endpunkt als Host-Parameter an. Sie geben auch die Portnummer vom DB-Instance-Endpunkt als Port-Parameter an.
Sie können sich mit einer Amazon-RDS-for-MariaDB-DB-Instance verbinden, indem Sie die MySQL-Befehlszeilenfunktion verwenden. Weitere Informationen zur Verwendung der MySQL-Befehlszeile finden Sie unter [mysql Command-line Client](http://mariadb.com/kb/en/mariadb/mysql-command-line-client/) in der MariaDB-Dokumentation. Eine GUI-basierte Anwendung, die Sie zum Herstellen einer Verbindung verwenden können, ist Heidi. Weitere Informationen finden Sie auf der Seite [Download HeidiSQL](http://www.heidisql.com/download.php). Weitere Informationen zum Installieren von MySQL (einschließlich des MySQL-Clients) finden Sie unter [Installation und Aktualisierung von MySQL](https://dev.mysql.com/doc/refman/8.0/en/installing.html).
Die meisten Linux-Verteilung enthalten den MariaDB Client anstelle des Oracle MySQL Clients. Führen Sie den folgenden Befehl aus, um den MySQL-Befehlszeilenclient auf Amazon Linux 2023 zu installieren:
```
sudo dnf install mariadb105
```
Führen Sie den folgenden Befehl aus, um den MySQL-Befehlszeilenclient auf Amazon Linux 2 zu installieren:
```
sudo yum install mariadb
```
Führen Sie den folgenden Befehl aus, um den MySQL-Befehlszeilenclient auf den meisten DEB-basierten Linux-Distributionen zu installieren.
```
apt-get install mariadb-client
```
Zum Überprüfen der Version des Befehlszeilenclients von MySQL führen Sie den folgenden Befehl aus.
```
mysql --version
```
Zum Lesen der MySQL-Dokumentation für Ihre aktuelle Clientversion führen Sie den folgenden Befehl aus.
```
man mysql
```
Um eine Verbindung zu einer DB-Instance von außerhalb einer Virtual Private Cloud (VPC) basierend auf Amazon VPC herzustellen, muss die DB-Instance öffentlich zugänglich sein. Außerdem muss der Zugriff unter Verwendung der eingehenden Regeln der Sicherheitsgruppe der DB-Instance gewährt werden, und andere Anforderungen müssen erfüllt sein. Weitere Informationen finden Sie unter [Verbindung zur Amazon-RDS-DB-Instance kann nicht hergestellt werden](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
Sie können SSL-Verschlüsselung für Verbindungen mit einer MariaDB-DB-Instance verwenden. Weitere Informationen finden Sie unter [SSL/TLS-Unterstützung für MariaDB-DB-Instances in Amazon RDS](MariaDB.Concepts.SSLSupport.md).
Informationen zum Suchen und Herstellen einer Verbindung mit einer DB-Instance von RDS für MariaDB finden Sie in den folgenden Themen.
**Topics**
+ [Finden der Verbindungsinformationen für eine MariaDB-DB-Instance](USER_ConnectToMariaDBInstance.EndpointAndPort.md)
+ [Herstellen einer Verbindung über den MySQL-Befehlszeilen-Client (unverschlüsselt) für RDS für MariaDB](USER_ConnectToMariaDBInstance.CLI.md)
+ [Verbindung zu RDS für MariaDB mit dem AWS JDBC-Treiber und dem Python-Treiber herstellen; AWS](MariaDB.Connecting.Drivers.md)
+ [Fehlerbehebung bei Verbindungen zu Ihrer MariaDB-DB-Instance](USER_ConnectToMariaDBInstance.Troubleshooting.md)
# Finden der Verbindungsinformationen für eine MariaDB-DB-Instance
Die Verbindungsinformationen für eine DB-Instance umfassen ihren Endpunkt, ihren Port und einen gültigen Datenbankbenutzer, z. B. den Masterbenutzer. Nehmen wir zum Beispiel an, dass ein Endpunktwert laute `mydb.123456789012.us-east-1.rds.amazonaws.com`. In diesem Fall ist `3306` der Port-Wert und der Datenbankbenutzer ist `admin`. Angesichts dieser Informationen geben Sie die folgenden Werte in einer Verbindungszeichenfolge an:
+ Geben Sie für den Host- bzw. Hostnamen oder den DNS-Namen a `mydb.123456789012.us-east-1.rds.amazonaws.com`.
+ Als Port `3306`.
+ Geben Sie für Benutzer a `admin`.
Um eine Verbindung zu einer DB-Instance herzustellen, verwenden Sie einen beliebigen Client für die MariaDB-DB-Engine. Sie könnten beispielsweise den Befehlszeilen-Client von MySQL oder MySQL Workbench verwenden.
Um die Verbindungsinformationen für eine DB-Instance zu finden, können Sie AWS-Managementkonsole, den AWS Command Line Interface-Befehl (AWS CLI) [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) oder die Amazon-RDS-API-Operation [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) verwenden, um ihre Details aufzulisten.
## Konsole
**So finden Sie die Verbindungsinformationen für eine DB-Instance im AWS-Managementkonsole**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Klicken Sie im Navigationsbereich auf **Datenbanken**, um eine Liste Ihrer DB-Instances anzuzeigen.
1. Wählen Sie den Namen der MariaDB-DB-Instance, um deren Details anzuzeigen.
1. Kopieren Sie auf der Registerkarte **Connectivity & security (Anbindung und Sicherheit)** den Endpunkt. Notieren Sie sich auch die Portnummer. Sie benötigen sowohl den Endpunkt als auch die Portnummer, um die Verbindung zur DB-Instance herzustellen.
![\[Endpunkt und Port einer DB-Instance in der Amazon-RDS-Konsole.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/endpoint-port.png)
1. Wenn Sie den Masterbenutzernamen finden müssen, wählen Sie die Registerkarte **Konfiguration** und den Wert für den **Masterbenutzernamen** an.
## AWS CLI
Um die Verbindungsinformationen für eine MariaDB-DB-Instance mit der AWS CLI zu finden, führen Sie den Befehl [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) aus. Fragen Sie beim Aufruf die DB-Instance-ID, den Endpunkt, den Port und den Masterbenutzernamen ab.
Für Linux, macOS oder Unix:
```
aws rds describe-db-instances \
--filters "Name=engine,Values=mariadb" \
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
Für Windows:
```
aws rds describe-db-instances ^
--filters "Name=engine,Values=mariadb" ^
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
Die Ausgabe sollte in etwa wie folgt aussehen.
```
[
[
"mydb1",
"mydb1.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
],
[
"mydb2",
"mydb2.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
]
]
```
## RDS-API
Rufen Sie den Operation [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) auf, um die Verbindungsinformationen für eine DB-Instance mithilfe der Amazon-RDS-API zu finden. Suchen Sie in der Ausgabe die Werte für die Endpunktadresse, den Endpunktport und den Masterbenutzernamen.
# Herstellen einer Verbindung über den MySQL-Befehlszeilen-Client (unverschlüsselt) für RDS für MariaDB
**Wichtig**
Verwenden Sie eine unverschlüsselte MySQL Verbindung nur, wenn sich Client und Server in derselben VPC befinden und das Netzwerk vertrauenswürdig ist. Weitere IInformationen zur Verwendung verschlüsselter Verbindungen finden Sie unter [Herstellen einer Verbindung zu Ihrer MariaDB-DB-Instance auf Amazon RDS über SSL/TLS den MySQL-Befehlszeilenclient (verschlüsselt)](USER_ConnectToMariaDBInstanceSSL.CLI.md).
Um über den MySQL-Befehlszeilenclient eine Verbindung zu einer DB-Instance herzustellen, geben Sie den folgenden Befehl an einer Eingabeaufforderung auf einem Clientcomputer ein. Dadurch werden Sie mit einer Datenbank auf einer MariaDB-DB-Instance verbunden. Ersetzen Sie den DNS-Namen (Endpunkt) für Ihre DB-Instance durch *``* und den Master-Benutzernamen, den Sie verwendet haben, durch *``*. Geben Sie das Master-Passwort ein, das Sie bei der Aufforderung zur Eingabe eines Passworts verwendet haben.
```
mysql -h -P 3306 -u -p
```
Nachdem Sie das Passwort für den Benutzer eingegeben haben, wird eine Ausgabe wie die folgende angezeigt.
```
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 10.6.10-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
```
# Verbindung zu RDS für MariaDB mit dem AWS JDBC-Treiber und dem Python-Treiber herstellen; AWS
Stellen Sie mit dem AWS JDBC-Treiber und dem Python-Treiber eine Connect zu RDS für MariaDB-DB-Instances her. AWS Weitere Informationen finden Sie unter den folgenden Themen.
**Topics**
+ [Herstellen einer Verbindung mit dem JDBC-Treiber von Amazon Web Services (AWS) mit RDS für MariaDB](#MariaDB.Connecting.JDBCDriver)
+ [Herstellen einer Verbindung mit dem Python-Treiber von Amazon Web Services (AWS) mit RDS für MariaDB](#MariaDB.Connecting.PythonDriver)
## Herstellen einer Verbindung mit dem JDBC-Treiber von Amazon Web Services (AWS) mit RDS für MariaDB
Der JDBC-Treiber für Amazon Web Services (AWS) ist als fortschrittlicher JDBC-Wrapper konzipiert. Dieser Wrapper ergänzt einen vorhandenen JDBC-Treiber und erweitert dessen Funktionen. Der Treiber ist Drop-In-kompatibel mit dem Connector/J Community-MySQL-Treiber und dem Connector/J Community-MariaDB-Treiber.
Um den AWS JDBC-Treiber zu installieren, hängen Sie die JAR-Datei des AWS JDBC-Treibers an (befindet sich in der Anwendung`CLASSPATH`) und behalten Sie die Verweise auf den jeweiligen Community-Treiber bei. Aktualisieren Sie das jeweilige Verbindungs-URL-Präfix wie folgt:
+ `jdbc:mysql://` auf `jdbc:aws-wrapper:mysql://`
+ `jdbc:mariadb://` auf `jdbc:aws-wrapper:mariadb://`
Weitere Informationen zum AWS JDBC-Treiber und vollständige Anweisungen zu seiner Verwendung finden Sie im [Amazon Web Services (AWS) JDBC-Treiber-Repository](https://github.com/awslabs/aws-advanced-jdbc-wrapper). GitHub
## Herstellen einer Verbindung mit dem Python-Treiber von Amazon Web Services (AWS) mit RDS für MariaDB
Der Amazon Web Services (AWS)-Python-Treiber ist als fortschrittlicher Python-Wrapper konzipiert. Dieser Wrapper ergänzt den Open-Source-Treiber Psycopg und erweitert dessen Funktionen. Der AWS -Python-Treiber unterstützt Python-Version 3.8 und höher. Sie können das Paket `aws-advanced-python-wrapper` zusammen mit den Open-Source-Paketen `psycopg` mithilfe des Befehls `pip` installieren.
Weitere Informationen zum AWS Python-Treiber und vollständige Anweisungen zu seiner Verwendung finden Sie im [ GitHub Python-Treiber-Repository von Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-python-wrapper).
# Fehlerbehebung bei Verbindungen zu Ihrer MariaDB-DB-Instance
Zwei häufige Ursachen für Fehler bei Verbindungen mit einer neuen DB-Instance sind die folgenden:
+ Die DB-Instance wurde mit einer Sicherheitsgruppe erstellt, die keine Verbindungen vom Gerät oder von der Amazon EC2-Instance zulässt, auf dem bzw. der die MariaDB-Anwendung oder das MariaDB-Hilfsprogramm ausgeführt wird. Die DB-Instance muss über eine VPC-Sicherheitsgruppe verfügen, die die Verbindungen zulässt. Weitere Informationen finden Sie unter [Amazon VPC und Amazon RDS](USER_VPC.md).
Sie können eine Regel für eingehenden Datenverkehr in der Sicherheitsgruppe hinzufügen oder ändern. Wählen Sie für **Source (Quelle)** die Option **My IP (Meine IP)** aus. Dies ermöglicht Zugriff auf die DB-Instance von der IP-Adresse, die in Ihrem Browser erkannt wird.
+ Die DB-Instance wurde mithilfe des Standard-Port 3306 erstellt; die Firewall Ihres Unternehmens blockiert jedoch Verbindungen zu diesem Port von Geräten aus Ihrem Unternehmensnetzwerk. Erstellen Sie die Instance erneut mit einem andern Port, um diesen Fehler zu beheben.
Weitere Informationen zu Verbindungsproblemen finden Sie unter [Verbindung zur Amazon-RDS-DB-Instance kann nicht hergestellt werden](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
# Sichern von Verbindungen von MariaDB-DB-Instances
Sie können die Sicherheit Ihrer DB-Instances von RDS für MariaDB verwalten.
**Topics**
+ [MariaDB-Sicherheit auf Amazon RDS](MariaDB.Concepts.UsersAndPrivileges.md)
+ [Verwenden des Passwortvalidierungs-Plugins für RDS für MariaDB](MariaDB.Concepts.PasswordValidationPlugins.md)
+ [Verschlüsselung von Client-Verbindungen mit MariaDB-DB-Instances SSL/TLS auf Amazon RDS](mariadb-ssl-connections.md)
+ [Aktualisierung von Anwendungen, um mithilfe neuer Zertifikate eine Verbindung zu MariaDB-Instanzen herzustellen SSL/TLS](ssl-certificate-rotation-mariadb.md)
# 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 für Amazon RDS](UsingWithRDS.IAM.md).
+ Beim Erstellen einer DB-Instance verwenden Sie eine VPC-Sicherheitsgruppe, um zu steuern, welche Geräte und Amazon-EC2-Instances Verbindungen mit dem Endpunkt und dem Port der DB-Instance öffnen können. Diese Verbindungen können mit Secure Sockets Layer (SSL) und Transport Layer Security (TLS) hergestellt werden. 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. Die Berechtigung gewährt keinen Zugriff auf die Vorgänge `FLUSH LOGS` oder `FLUSH TABLES WITH READ LOCK`.
+ `replication client`
+ `replication slave`
+ `select`
+ `show create routine`
Diese Berechtigung gilt nur für MariaDB-DB-Instances mit Version 11.4 und höher.
+ `show databases`
+ `show view`
+ `trigger`
+ `update`
Weitere Informationen zu diesen Berechtigungen finden Sie unter [Benutzerkontenmanagement](http://mariadb.com/kb/en/mariadb/grant/) 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 des Passwortvalidierungs-Plugins für RDS für MariaDB
Ab RDS für MariaDB Version 11.4 können Sie die folgenden Plugins für die Passwortvalidierung verwenden, um die Sicherheit Ihrer Datenbankverbindungen zu erhöhen:
+ [simple\$1password\$1check](https://mariadb.com/kb/en/simple-password-check-plugin/): Prüft, ob ein Passwort mindestens eine bestimmte Anzahl von Zeichen eines bestimmten Typs enthält.
+ [cracklib\$1password\$1check](https://mariadb.com/kb/en/cracklib_password_check/) — prüft, ob ein Passwort in einer Wörterbuchdatei der Bibliothek erscheint. [CrackLib](https://github.com/cracklib/cracklib)
Um diese Plugins zu aktivieren, legen Sie den Wert des Parameters `simple_password_check` oder `cracklib_password_check` in der DB-Parametergruppe, die der DB-Instance zugeordnet ist, auf `FORCE_PLUS_PERMANENT` fest. Wenn dieser Wert festgelegt wurde, kann das Plugin nicht mithilfe der Anweisung `UNINSTALL PLUGIN` zur Laufzeit deinstalliert werden.
Um diese Plugins zu deaktivieren, legen Sie den Wert des Parameters `simple_password_check` oder `cracklib_password_check` in der DB-Parametergruppe, die der DB-Instance zugeordnet ist, auf `OFF` fest. Wenn dieser Wert festgelegt wurde, gelten die Plugin-Validierungsregeln nicht mehr für neue Passwörter.
Informationen zum Festlegen der Parameterwerte in Parametergruppen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
# Verschlüsselung von Client-Verbindungen mit MariaDB-DB-Instances SSL/TLS auf Amazon RDS
Secure Sockets Layer (SSL) ist ein Branchen-Standardprotokoll, das für den Schutz von Netzwerkverbindungen zwischen Client und Server verwendet wird. Ab SSL-Version 3.0 wurde der Name in Transport Layer Security (TLS) geändert. Amazon RDS unterstützt SSL/TLS Verschlüsselung für MariaDB-DB-Instances. Die Nutzung des SSL/TLS, you can encrypt a connection between your application client and your MariaDB DB instance. SSL/TLS Supports ist für alle verfügbar. AWS-Regionen
Mit Amazon RDS können Sie Daten während der Übertragung sichern, indem Sie Client-Verbindungen zu MariaDB-DB-Instances mit SSL/TLS, requiring SSL/TLS for all connections to a MariaDB DB instance, and connecting from the MySQL command-line client with SSL/TLS (encrypted). The following sections provide guidance on configuring and utilizing SSL/TLS Verschlüsselung für MariaDB-DB-Instances auf Amazon RDS verschlüsseln.
**Topics**
+ [SSL/TLS-Unterstützung für MariaDB-DB-Instances in Amazon RDS](MariaDB.Concepts.SSLSupport.md)
+ [Bestimmte Benutzerkonten SSL/TLS für eine MariaDB-DB-Instance auf Amazon RDS erforderlich](MariaDB-ssl-connections.require-ssl-users.md)
+ [Erforderlich SSL/TLS für alle Verbindungen zu einer MariaDB-DB-Instance auf Amazon RDS](mariadb-ssl-connections.require-ssl.md)
+ [Herstellen einer Verbindung zu Ihrer MariaDB-DB-Instance auf Amazon RDS über SSL/TLS den MySQL-Befehlszeilenclient (verschlüsselt)](USER_ConnectToMariaDBInstanceSSL.CLI.md)
# SSL/TLS-Unterstützung für MariaDB-DB-Instances in Amazon RDS
Amazon RDS erstellt ein SSL/TLS Zertifikat und installiert das Zertifikat auf der DB-Instance, wenn Amazon RDS die Instance bereitstellt. Diese Zertifikate werden von einer Zertifizierungsstelle signiert. Das SSL/TLS Zertifikat enthält den DB-Instance-Endpunkt als Common Name (CN) für das SSL/TLS Zertifikat zum Schutz vor Spoofing-Angriffen.
Ein von Amazon RDS erstelltes SSL/TLS Zertifikat ist die vertrauenswürdige Root-Entität und sollte in den meisten Fällen funktionieren, kann aber fehlschlagen, wenn Ihre Anwendung keine Zertifikatsketten akzeptiert. Wenn Ihre Anwendung keine Zertifikatsketten akzeptiert, müssen Sie eventuell ein Zwischenzertifikat verwenden, um eine Verbindung mit Ihrer AWS-Region herzustellen. Sie müssen beispielsweise ein Zwischenzertifikat verwenden, um eine Verbindung zu den AWS GovCloud (US) Regionen mit SSL/TLS herzustellen.
Informationen zum Herunterladen von Zertifikaten finden Sie unter [](UsingWithRDS.SSL.md). Weitere Hinweise zur Verwendung SSL/TLS mit MySQL finden Sie unter[Aktualisierung von Anwendungen, um mithilfe neuer Zertifikate eine Verbindung zu MariaDB-Instanzen herzustellen SSL/TLS](ssl-certificate-rotation-mariadb.md).
Amazon RDS für MariaDB unterstützt die Transport Layer Security (TLS) Versionen 1.3, 1.2, 1.1 und 1.0. Die TLS-Unterstützung hängt von der MariaDB-Unterversion ab. In der folgenden Tabelle ist die TLS-Unterstützung für MariaDB-Unterversionen angegeben.
| TLS-Version | MariaDB 11.8 | MariaDB 11.4 | MariaDB 10.11 | MariaDB 10.6 | MariaDB 10.5 | MariaDB 10.4 |
| --- | --- | --- | --- | --- | --- | --- |
| TLS 1.3 | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen |
| TLS 1.2 | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen | Alle Unterversionen |
| TLS 1.1 | Nicht unterstützt | Nicht unterstützt | Nicht unterstützt | 10.6.16 und niedriger | 10.5.23 und niedriger | 10.4.32 und niedriger |
| TLS 1.0 | Nicht unterstützt | Nicht unterstützt | Nicht unterstützt | 10.6.16 und niedriger | 10.5.23 und niedriger | 10.4.32 und niedriger |
# Bestimmte Benutzerkonten SSL/TLS für eine MariaDB-DB-Instance auf Amazon RDS erforderlich
Sie können für bestimmte Benutzerkontenverbindungen zu Ihren MariaDB-DB-Instances auf Amazon RDS eine SSL/TLS Verschlüsselung verlangen. Der Schutz vertraulicher Informationen vor unbefugtem Zugriff oder Abfangangriffen ist entscheidend für die Durchsetzung von Sicherheitsrichtlinien, wenn es um die Vertraulichkeit von Daten geht.
Um SSL/TLS Verbindungen für bestimmte Benutzerkonten zu verlangen, verwenden Sie je nach Ihrer MySQL-Version eine der folgenden Anweisungen, um SSL/TLS Verbindungen für das Benutzerkonto zu verlangen`encrypted_user`.
Verwenden Sie dazu die folgende Anweisung.
```
ALTER USER 'encrypted_user'@'%' REQUIRE SSL;
```
Weitere Informationen zu SSL/TLS Verbindungen mit MariaDB finden Sie unter [Securing Connections for Client and Server](https://mariadb.com/kb/en/securing-connections-for-client-and-server/) in der MariaDB-Dokumentation.
# Erforderlich SSL/TLS für alle Verbindungen zu einer MariaDB-DB-Instance auf Amazon RDS
Verwenden Sie den Parameter `require_secure_transport`, um zu verlangen, dass alle Benutzerverbindungen mit Ihrer MariaDB-DB-Instance SSL/TLS verwenden. Für Version 11.4 und ältere Versionen ist der Parameter `require_secure_transport` standardmäßig auf `OFF` festgelegt. Für 11.8 und spätere Versionen ist der Standardwert auf gesetzt, was SSL/TLS für Verbindungen zu `ON` Ihrer DB-Instance gilt. Sie können den Parameter `require_secure_transport` auf `OFF` ändern, wenn unsichere Verbindungen benötigt werden.
**Anmerkung**
Der Parameter `require_secure_transport` wird nur für MariaDB Version 10.5 und höher unterstützt.
Sie können den Parameterwert `require_secure_transport` festlegen, indem Sie die DB-Parametergruppe für Ihre DB-Instance aktualisieren. Sie müssen Ihre DB-Instance nicht neu starten, damit die Änderung wirksam wird.
Wenn der `require_secure_transport`-Parameter auf `ON` für eine DB-Instance festgelegt ist, kann ein Datenbank-Client eine Verbindung zu ihr herstellen, wenn er eine verschlüsselte Verbindung aufbauen kann. Andernfalls wird eine Fehlermeldung ähnlich der folgenden an den Client zurückgegeben:
```
ERROR 1045 (28000): Access denied for user 'USER'@'localhost' (using password: YES | NO)
```
Weitere Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Weitere Informationen zum Parameter `require_secure_transport` finden Sie in der [MariaDB-Dokumentation](https://mariadb.com/docs/ent/ref/mdb/system-variables/require_secure_transport/).
# Herstellen einer Verbindung zu Ihrer MariaDB-DB-Instance auf Amazon RDS über SSL/TLS den MySQL-Befehlszeilenclient (verschlüsselt)
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 Sie`mysql`-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 die`mysql`Version in ihnen ist von MariaDB.
Führen Sie die folgenden Schritte aus, um mithilfe von SSL/TLS eine Verbindung mit Ihrer DB-Instance herzustellen:
**So stellen Sie SSL/TLS mithilfe des MySQL-Befehlszeilenclients eine Verbindung zu einer DB-Instance her**
1. Laden Sie ein Stammzertifikat herunter, das für alle funktioniert. AWS-Regionen
Informationen zum Herunterladen von Zertifikaten finden Sie unter [](UsingWithRDS.SSL.md).
1. Verwenden Sie einen MySQL-Befehlszeilen-Client, um eine Verbindung zu einer DB-Instance mit SSL/TLS-Verschlüsselung herzustellen. Ersetzen Sie für den `-h`-Parameter den DNS-Namen (Endpunkt) für Ihre primäre DB-Instance. Ersetzen Sie den `--ssl-ca` Parameter durch den Namen der SSL/TLS Zertifikatsdatei. Ersetzen Sie für den `-P`-Parameter den Port für Ihre DB-Instance. Ersetzen Sie für den `-u`-Parameter den Benutzernamen eines gültigen Datenbankbenutzers, z. B. des Masterbenutzers. Geben Sie bei Aufforderung das Passwort für den Masterbenutzer ein.
Im folgenden Beispiel sehen Sie für MariaDB, wie der Client mit dem Parameter `--ssl-ca` gestartet wird.
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl -P 3306 -u myadmin -p
```
Geben Sie den folgenden Befehl ein, um zu verlangen, dass die SSL/TLS Verbindung den DB-Instance-Endpunkt mit dem Endpunkt im SSL/TLS Zertifikat vergleicht:
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-verify-server-cert -P 3306 -u myadmin -p
```
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 mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=REQUIRED -P 3306 -u myadmin -p
```
1. Geben Sie bei Aufforderung das Passwort für den Masterbenutzer ein.
Die Ausgabe sollte in etwa wie folgt aussehen:
```
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 10.6.10-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
```
# Aktualisierung von Anwendungen, um mithilfe neuer Zertifikate eine Verbindung zu MariaDB-Instanzen herzustellen SSL/TLS
Am 13. Januar 2023 veröffentlichte Amazon RDS neue Zertifizierungsstellen-Zertifikate (Certificate Authority, CA) zum Herstellen von Verbindungen mit Ihren RDS-DB-Instances mithilfe von Secure Socket Layer oder Transport Layer Security (SSL/TLS). Im Folgenden finden Sie Informationen dazu, wie Sie Ihre Anwendungen aktualisieren, um die neuen Zertifikate verwenden zu können.
In diesem Thema finden Sie Informationen dazu, wie Sie ermitteln, ob Ihre Anwendungen für die Herstellung von Verbindungen mit Ihren DB-Instances eine Zertifikatverifizierung erfordern.
**Anmerkung**
Einige Anwendungen sind so konfiguriert, dass sie nur dann Verbindungen mit MariaDB nur herstellen, wenn sie das Zertifikat auf dem Server erfolgreich identifizieren können. Für solche Anwendungen müssen Sie die Trust Stores Ihrer Client-Anwendung aktualisieren, damit diese die neuen CA-Zertifikate enthalten.
Sie können die folgenden SSL-Modi angeben: `disabled`, `preferred` und `required`. Wenn Sie den`preferred` SSL-Modus verwenden und das CA-Zertifikat nicht vorhanden ist oder nicht auf dem neuesten Stand ist, verwendet die Verbindung nicht SSL und stellt weiterhin eine Verbindung erfolgreich her.
Wir empfehlen den `preferred`-Modus zu vermeiden Wenn die Verbindung im `preferred`-Modus auf ein ungültiges Zertifikat stößt, wird die Verschlüsselung beendet und unverschlüsselt fortgesetzt.
Nach der Aktualisierung der CA-Zertifikate in den Trust Stores Ihrer Client-Anwendung können Sie die Zertifikate auf Ihren DB-Instances rotieren. Es wird nachdrücklich empfohlen, diese Verfahren vor der Implementierung in Produktionsumgebungen in einer Entwicklungs- oder Testumgebung zu testen.
Weitere Informationen zur Zertifikatrotation finden Sie unter [Ihr SSL/TLS Zertifikat rotieren](UsingWithRDS.SSL-certificate-rotation.md). Weitere Informationen zum Herunterladen von Zertifikaten finden Sie unter [](UsingWithRDS.SSL.md). Hinweise zur Verwendung SSL/TLS mit MariaDB-DB-Instances finden Sie unter. [SSL/TLS-Unterstützung für MariaDB-DB-Instances in Amazon RDS](MariaDB.Concepts.SSLSupport.md)
**Topics**
+ [Ermitteln, ob ein Client zum Herstellen von Verbindungen Zertifikatverifizierungen erfordert](#ssl-certificate-rotation-mariadb.determining)
+ [Aktualisieren des Trust Stores Ihrer Anwendung](#ssl-certificate-rotation-mariadb.updating-trust-store)
+ [Java-Beispielcode für die Herstellung von SSL-Verbindungen](#ssl-certificate-rotation-mariadb.java-example)
## Ermitteln, ob ein Client zum Herstellen von Verbindungen Zertifikatverifizierungen erfordert
Sie können überprüfen, ob JDBC-Clients und MySQL-Clients zum Herstellen von Verbindungen Zertifikatverifizierungen erfordern.
### JDBC
Das folgende Beispiel mit MySQL Connector/J 8.0 zeigt eine Möglichkeit, die JDBC-Verbindungseigenschaften einer Anwendung zu überprüfen, um festzustellen, ob erfolgreiche Verbindungen ein gültiges Zertifikat erfordern. Weitere Informationen zu allen JDBC-Verbindungsoptionen für MySQL finden Sie unter [Configuration Properties](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html) in der MySQL-Dokumentation.
Wenn Sie MySQL Connector/J 8.0 verwenden, erfordert eine SSL-Verbindung eine Überprüfung anhand des CA-Zertifikats des Servers, wenn Ihre Verbindungseigenschaften auf `VERIFY_CA` oder `sslMode` gesetzt sind`VERIFY_IDENTITY`, wie im folgenden Beispiel.
```
Properties properties = new Properties();
properties.setProperty("sslMode", "VERIFY_IDENTITY");
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
```
**Anmerkung**
Wenn Sie entweder den MySQL Java Connector v5.1.38 oder höher oder den MySQL Java Connector v8.0.9 oder höher verwenden, um eine Verbindung zu Ihren Datenbanken herzustellen, auch wenn Sie Ihre Anwendungen nicht explizit so konfiguriert haben, dass sie SSL/TLS beim Herstellen einer Verbindung zu Ihren Datenbanken verwendet werden, verwenden diese Clienttreiber standardmäßigSSL/TLS. In addition, when using SSL/TLS, sie führen eine teilweise Zertifikatsüberprüfung durch und können keine Verbindung herstellen, wenn das Datenbankserverzertifikat abgelaufen ist.
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
### MySQL
Die folgenden Beispiele mit dem MySQL-Client zeigen zwei Möglichkeiten, wie Sie die MySQL-Verbindung eines Skripts überprüfen, um zu ermitteln, ob zum Herstellen von Verbindungen ein gültiges Zertifikat erforderlich ist. Weitere Informationen zu allen Verbindungsoptionen mit dem MySQL-Client finden Sie unter [Client-Side Configuration for Encrypted Connections](https://dev.mysql.com/doc/refman/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration) in der MySQL-Dokumentation.
Wenn der MySQL 5.7- oder MySQL 8.0-Client verwendet wird, erfordert eine SSL-Verbindung die Verifizierung anhand des CA-Serverzertifikats, wenn Sie für die Option `--ssl-mode` den Wert `VERIFY_CA` oder `VERIFY_IDENTITY` angeben wie im folgenden Beispiel gezeigt.
```
mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-mode=VERIFY_CA
```
Wenn der MySQL 5.6-Client verwendet wird, erfordert eine SSL-Verbindung die Verifizierung anhand des CA-Serverzertifikats, wenn Sie die Option `--ssl-verify-server-cert` angeben wie im folgenden Beispiel gezeigt.
```
mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-verify-server-cert
```
## Aktualisieren des Trust Stores Ihrer Anwendung
Informationen zur Aktualisierung des Trust Store für MySQL-Anwendungen finden Sie unter [Using TLS/SSL with MariaDB Connector/J](https://mariadb.com/kb/en/library/using-tls-ssl-with-mariadb-java-connector/) in der MariaDB-Dokumentation.
Informationen zum Herunterladen des Stammverzeichnisses finden Sie unter [](UsingWithRDS.SSL.md).
Beispiele für Skripte, die Zertifikate importieren, finden Sie unter [Beispielskript für den Import von Zertifikaten in Ihren Trust Store](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**Anmerkung**
Wenn Sie den Trust Store aktualisieren, können Sie ältere Zertifikate beibehalten und die neuen Zertifikate einfach hinzufügen.
Wenn Sie den Connector/J MariaDB-JDBC-Treiber in einer Anwendung verwenden, legen Sie die folgenden Eigenschaften in der Anwendung fest.
```
System.setProperty("javax.net.ssl.trustStore", certs);
System.setProperty("javax.net.ssl.trustStorePassword", "password");
```
Legen Sie während des Startens der Anwendung die folgenden Eigenschaften fest.
```
java -Djavax.net.ssl.trustStore=/path_to_truststore/MyTruststore.jks -Djavax.net.ssl.trustStorePassword=my_truststore_password com.companyName.MyApplication
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen andere Passwörter als hier angegeben an.
## Java-Beispielcode für die Herstellung von SSL-Verbindungen
Das folgende Code-Beispiel zeigt, wie die SSL-Verbindung mit JDBC eingerichtet wird.
```
private static final String DB_USER = "admin";
private static final String DB_USER = "user name";
private static final String DB_PASSWORD = "password";
// This key store has only the prod root ca.
private static final String KEY_STORE_FILE_PATH = "file-path-to-keystore";
private static final String KEY_STORE_PASS = "keystore-password";
public static void main(String[] args) throws Exception {
Class.forName("org.mariadb.jdbc.Driver");
System.setProperty("javax.net.ssl.trustStore", KEY_STORE_FILE_PATH);
System.setProperty("javax.net.ssl.trustStorePassword", KEY_STORE_PASS);
Properties properties = new Properties();
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
Connection connection = DriverManager.getConnection("jdbc:mysql://ssl-mariadb-public.cni62e2e7kwh.us-east-1.rds.amazonaws.com:3306?useSSL=true",properties);
Statement stmt=connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 1 from dual");
return;
}
```
**Wichtig**
Nachdem Sie festgestellt haben, dass Ihre Datenbankverbindungen Ihren Anwendungs-Truststore verwenden, SSL/TLS und Ihren Anwendungs-Truststore aktualisiert haben, können Sie Ihre Datenbank so aktualisieren, dass sie die 2048-g1-Zertifikate verwendet. rds-ca-rsa Anleitungen hierzu finden Sie in Schritt 3 unter [Aktualisieren des CA-Zertifikats durch Ändern der DB-Instanceoder des DB-Clusters](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
# Verbesserung der Abfrageleistung für RDS für MariaDB mit Amazon RDS Optimized Reads
Mit Amazon RDS Optimized Reads können Sie eine schnellere Abfrageverarbeitung für RDS für MariaDB erreichen. Eine DB-Instance von RDS für MariaDB, die RDS Optimized Reads verwendet, kann eine doppelt so schnelle Abfrageverarbeitung erreichen als eine DB-Instance, die diese Funktion nicht verwendet.
**Topics**
+ [Übersicht über RDS Optimized Reads](#rds-optimized-reads-mariadb-overview)
+ [Anwendungsfälle für RDS Optimized Reads](#rds-optimized-reads-mariadb-use-cases)
+ [Bewährte Methoden für RDS Optimized Reads](#rds-optimized-reads-mariadb-best-practices)
+ [Verwenden von RDS Optimized Reads](#rds-optimized-reads-mariadb-using)
+ [Überwachen von DB-Instances, die RDS Optimized Reads verwenden](#rds-optimized-reads-mariadb-monitoring)
+ [Einschränkungen für RDS Optimized Reads](#rds-optimized-reads-mariadb-limitations)
## Übersicht über RDS Optimized Reads
Wenn Sie eine DB-Instance von RDS für MariaDB verwenden, für die RDS Optimized Reads aktiviert ist, erreicht Ihre DB-Instance durch die Verwendung eines Instance-Speichers eine schnellere Abfrageleistung. Ein *Instance-Speicher* stellt für Ihre DB-Instance temporären Speicher auf Blockebene bereit. Der Speicher befindet sich auf Non-Volatile Memory Express (NVMe) Solid-State-Laufwerken (SSDs), die physisch an den Hostserver angeschlossen sind. Dieser Speicher ist für niedrige Latenz, hohe I/O Zufallsleistung und hohen sequentiellen Lesedurchsatz optimiert.
RDS Optimized Reads ist standardmäßig aktiviert, wenn eine DB-Instance eine DB-Instance-Klasse mit einem Instance-Speicher wie db.m5d oder db.m6gd verwendet. Mit RDS Optimized Reads werden einige temporäre Objekte im Instance-Speicher abgelegt. Zu diesen temporären Objekten gehören interne temporäre Dateien, interne temporäre Tabellen auf der Festplatte, Speicherzuordnungsdateien und Binärprotokolldateien (binlog) im Cache. Weitere Informationen zum Instance-Store finden Sie unter [Amazon EC2 Instance Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) im *Amazon Elastic Compute Cloud-Benutzerhandbuch für Linux-Instances*.
Die Workloads, die temporäre Objekte in MariaDB für die Abfrageverarbeitung generieren, können den Instance-Speicher für eine schnellere Abfrageverarbeitung nutzen. Diese Art von Workload umfasst Abfragen mit Sortierungen, Hash-Aggregationen, High-Load-Joins, Common Table Expressions (CTEs) und Abfragen in nicht indizierten Spalten. Diese Instance-Speicher-Volumes bieten höhere IOPS und eine höhere Leistung, unabhängig von den Speicherkonfigurationen, die für persistenten Amazon EBS-Speicher verwendet werden. Da RDS Optimized Reads Operationen an temporären Objekten in den Instance-Speicher auslagert, können die input/output Operationen pro Sekunde (IOPS) oder der Durchsatz des persistenten Speichers (Amazon EBS) jetzt für Operationen mit persistenten Objekten verwendet werden. Zu diesen Vorgängen gehören reguläre Lese- und Schreibvorgänge von Datendateien sowie Engine-Operationen im Hintergrund, wie das Leeren und Zusammenführen von Puffern zum Einfügen.
**Anmerkung**
Sowohl manuelle als auch automatisierte RDS-Snapshots enthalten nur die Engine-Dateien für persistente Objekte. Die im Instance-Speicher erstellten temporären Objekte sind nicht in RDS-Snapshots enthalten.
## Anwendungsfälle für RDS Optimized Reads
Wenn Sie Workloads haben, deren Abfrageausführung stark auf temporäre Objekte wie interne Tabellen oder Dateien angewiesen ist, können Sie von der Aktivierung von RDS Optimized Reads profitieren. Die folgenden Anwendungsfälle eignen sich für RDS Optimized Reads:
+ Anwendungen, die analytische Abfragen mit komplexen allgemeinen Tabellenausdrücken (CTEs), abgeleiteten Tabellen und Gruppierungsoperationen ausführen
+ Lesereplikate, die einen hohen Leseverkehr mit nicht optimierten Abfragen bewältigen
+ Anwendungen, die auf Abruf laufen oder dynamische Berichtsabfragen ausführen, die komplexe Operationen beinhalten, z. B. Abfragen mit `GROUP BY`- und `ORDER BY`-Klauseln
+ Workloads, die interne temporäre Tabellen für die Abfrageverarbeitung verwenden
Sie können die Engine-Statusvariable `created_tmp_disk_tables` überwachen, um die Anzahl der festplattenbasierten temporären Tabellen zu ermitteln, die auf Ihrer DB-Instance erstellt wurden.
+ Anwendungen, die direkt oder in Prozeduren große temporäre Tabellen zum Speichern von Zwischenergebnissen erstellen
+ Datenbankabfragen, die das Gruppieren oder Sortieren von nicht indizierten Spalten durchführen
## Bewährte Methoden für RDS Optimized Reads
Nutzen Sie die folgenden bewährten Methoden für RDS Optimized Reads:
+ Fügen Sie Wiederholungslogik für schreibgeschützte Abfragen hinzu, falls diese aufgrund eines Fehlers wegen eines vollen Instance-Speichers während der Ausführung fehlschlagen.
+ Überwachen Sie anhand der CloudWatch Metrik `FreeLocalStorage` den im Instance-Speicher verfügbaren Speicherplatz. Wenn der Instance-Speicher aufgrund der Workload der DB-Instance sein Limit erreicht, ändern Sie die DB-Instance, um eine größere DB-Instance-Klasse zu verwenden.
+ Wenn Ihre DB-Instance über ausreichend Speicher verfügt, aber immer noch das Speicherlimit für den Instance-Speicher erreicht, erhöhen Sie den `binlog_cache_size`-Wert, um die sitzungsspezifischen Binlog-Einträge im Speicher zu behalten. Diese Konfiguration verhindert, dass die Binlog-Einträge in temporäre Binlog-Cache-Dateien auf der Festplatte geschrieben werden.
Der `binlog_cache_size`-Parameter ist sitzungsspezifisch. Sie können den Wert für jede neue Sitzung ändern. Die Einstellung für diesen Parameter kann die Speicherauslastung der DB-Instance bei Spitzenauslastung erhöhen. Erwägen Sie daher, den Parameterwert auf der Grundlage des Workload-Musters Ihrer Anwendung und des verfügbaren Speichers in der DB-Instance zu erhöhen.
+ Verwenden Sie den Standardwert `MIXED` für `binlog_format`. Abhängig von der Größe der Transaktionen kann die Einstellung von `binlog_format` auf `ROW` zu großen Binlog-Cache-Dateien im Instance-Speicher führen.
+ Vermeiden Sie es, Massenänderungen in einer einzigen Transaktion durchzuführen. Diese Arten von Transaktionen können große Binlog-Cache-Dateien im Instance-Speicher generieren und Probleme verursachen, wenn der Instance-Speicher voll ist. Erwägen Sie, Schreibvorgänge in mehrere kleine Transaktionen aufzuteilen, um den Speicherverbrauch für Binlog-Cache-Dateien zu minimieren.
## Verwenden von RDS Optimized Reads
Wenn Sie eine DB-Instance von RDS für MariaDB mit einer der folgenden DB-Instance-Klassen in einer Single-AZ-Bereitstellung oder einer Multi-AZ-Bereitstellung der DB-Instance bereitstellen, verwendet die DB-Instance automatisch RDS Optimized Reads.
Führen Sie einen der folgenden Schritte aus, um RDS Optimized Reads zu aktivieren:
+ Erstellen Sie eine DB-Instance von RDS für MariaDB mit einer dieser DB-Instance-Klassen. Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
+ Ändern Sie eine vorhandene DB-Instance von RDS für MariaDB so, dass sie eine dieser DB-Instance-Klassen verwendet. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
RDS Optimized Reads ist überall verfügbar AWS-Regionen , wo eine oder mehrere DB-Instance-Klassen mit lokalem NVMe SSD-Speicher unterstützt werden. Weitere Informationen zu DB-Instance-Klassen finden Sie unter [](Concepts.DBInstanceClass.md).
Die Verfügbarkeit der DB-Instance-Klassen unterscheidet sich für AWS-Regionen. Informationen darüber, ob eine DB-Instance-Klasse in einer bestimmten Klasse unterstützt wird AWS-Region, finden Sie unter[Ermitteln der Unterstützung für DB-Instance-Klassen in AWS-Regionen](Concepts.DBInstanceClass.RegionSupport.md).
Wenn Sie RDS Optimized Reads nicht verwenden möchten, ändern Sie Ihre DB-Instance so, dass sie keine DB-Instance-Klasse verwendet, die die Funktion unterstützt.
## Überwachen von DB-Instances, die RDS Optimized Reads verwenden
Sie können DB-Instances, die RDS-optimierte Lesevorgänge verwenden, anhand der folgenden CloudWatch Metriken überwachen:
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Diese Metriken liefern Daten über den verfügbaren Instance-Speicher, die IOPS und den Durchsatz. Weitere Informationen zu diesen Metriken finden Sie unter [Metriken CloudWatch auf Amazon-Instanzebene für Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
## Einschränkungen für RDS Optimized Reads
Für RDS Optimized Reads gelten die folgenden Einschränkungen:
+ RDS Optimized Reads wird für die folgenden Versionen von RDS für MariaDB unterstützt:
+ Alle verfügbaren Unterversionen von Version 11.4 und höheren Hauptversionen
+ 10.11.4 und höhere 10.11-Versionen
+ 10.6.7 und höhere 10.6-Versionen
+ 10.5.16 und höhere 10.5-Versionen
+ 10.4.25 und höhere 10.4-Versionen
Informationen zu den Versionen von RDS für MariaDB finden Sie unter [MariaDB auf Amazon-RDS-Versionen](MariaDB.Concepts.VersionMgmt.md).
+ Sie können den Speicherort temporärer Objekte in den DB-Instance-Klassen, die RDS Optimized Reads unterstützen, nicht auf persistenten Speicher (Amazon EBS) ändern.
+ Wenn die binäre Protokollierung auf einer DB-Instance aktiviert ist, ist die maximale Transaktionsgröße durch die Größe des Instance-Speichers begrenzt. Bei MariaDB schreibt jede Sitzung, die mehr Speicherplatz als den Wert `binlog_cache_size` benötigt, Transaktionsänderungen in temporäre Binlog-Cache-Dateien, die im Instance-Speicher erstellt werden.
+ Transaktionen können fehlschlagen, wenn der Instance-Speicher voll ist.
# Verbesserung der Schreibleistung mit Amazon-RDS-optimierten Schreibvorgängen für MariaDB
Sie können die Leistung von Schreibtransaktionen mit RDS-optimierten Schreibvorgängen für MariaDB verbessern. Wenn Ihre Datenbank von RDS für MariaDB RDS-optimierte Schreibvorgänge verwendet, kann sie einen bis zu zweimal höheren Durchsatz für Schreibtransaktionen erreichen.
**Topics**
+ [Übersicht über RDS Optimized Writes](#rds-optimized-writes-overview)
+ [Verwenden von RDS Optimized Writes](#rds-optimized-writes-using-mariadb)
+ [Aktivieren von RDS-optimierten Schreibvorgängen in einer vorhandenen Datenbank](#rds-optimized-writes-modify-enable-mariadb)
+ [Einschränkungen für RDS Optimized Writes](#rds-optimized-writes-limitations-mariadb)
## Übersicht über RDS Optimized Writes
Wenn Sie RDS-optimierte Schreibvorgänge aktivieren, führen Ihre Datenbanken von RDS für MariaDB beim Leeren von Daten in einen dauerhaften Speicher nur einen Schreibvorgang aus, ohne dass der Doublewrite-Puffer erforderlich ist. Die Datenbanken bieten weiterhin ACID-Eigentumsschutzvorkehrungen für zuverlässige Datenbanktransaktionen sowie eine verbesserte Leistung.
Relationale Datenbanken wie MariaDB bieten die *ACID-Eigenschaften* Atomizität, Konsistenz, Isolation und Beständigkeit für zuverlässige Datenbanktransaktionen. Um diese Eigenschaften bereitzustellen, verwendet MariaDB einen Datenspeicherbereich, den sogenannten *Doublewrite-Puffer*, der teilweise Schreibfehler von Seiten verhindert. Diese Fehler treten bei einem Hardwarefehler auf, während die Datenbank eine Seite aktualisiert, z. B. bei einem Stromausfall. Eine MariaDB-Datenbank kann teilweise Schreibvorgänge von Seiten erkennen und diese mit einer Kopie der Seite im Doublewrite-Puffer wiederherstellen. Diese Technik bietet zwar Schutz, führt aber auch zu zusätzlichen Schreiboperationen. Weitere Informationen zum Doublewrite-Puffer von MariaDB finden Sie unter [InnoDB-Doublewrite-Puffer](https://mariadb.com/kb/en/innodb-doublewrite-buffer/) in der MariaDB-Dokumentation.
Wenn Amazon-RDS-optimierte Schreibvorgänge aktiviert sind, schreiben Ihre Datenbanken von RDS für MariaDB beim Leeren von Daten in einen dauerhaften Speicher nur einmal, ohne den Doublewrite-Puffer zu verwenden. RDS-optimierte Schreibvorgänge sind nützlich, wenn Sie schreibintensive Workloads in Ihren Datenbanken von RDS für MariaDB ausführen. Zu den Datenbanken mit schreibintensiven Workloads gehören Datenbanken, die digitale Zahlungen, Finanzhandel und Spieleanwendungen unterstützen.
Diese Datenbanken laufen auf DB-Instance-Klassen, die das AWS Nitro-System verwenden. Aufgrund der Hardwarekonfiguration in diesen Systemen kann die Datenbank in einem Schritt zuverlässig und dauerhaft Seiten mit 16 KiB direkt in Datendateien schreiben. Das AWS Nitro-System ermöglicht RDS-optimierte Schreibvorgänge.
Sie können den neuen Datenbankparameter `rds.optimized_writes` festlegen, um die Funktion RDS-optimierte Schreibvorgänge für Datenbanken von RDS für MariaDB zu steuern. Greifen Sie auf diesen Parameter in den DB-Parametergruppen von RDS für MariaDB für die folgenden Versionen zu:
+ Alle verfügbaren Unterversionen von Version 11.8 und höheren Hauptversionen
+ 11.4.3 und höhere 11.4-Versionen
+ 10.11.4 und höhere 10.11-Versionen
+ 10.6.10 und höhere 10.6-Versionen
Legen Sie den Parameter anhand der folgenden Werte fest:
+ `AUTO` – Aktivieren Sie RDS Optimized Writes, wenn die Datenbank diese Funktion unterstützt. Deaktivieren Sie RDS Optimized Writes, wenn die Datenbank diese Funktion nicht unterstützt. Dies ist die Standardeinstellung.
+ `OFF` – Deaktivieren Sie RDS Optimized Writes, auch wenn die Datenbank diese Funktion unterstützt.
Wenn Sie eine Datenbank von RDS für MariaDB, die für die Verwendung von RDS-optimierten Schreibvorgängen konfiguriert ist, zu einer DB-Instance-Klasse migrieren, die die Funktion nicht unterstützt, deaktiviert RDS die Funktion RDS-optimierte Schreibvorgänge für die Datenbank automatisch.
Wenn RDS-optimierte Schreibvorgänge deaktiviert sind, verwendet die Datenbank den MariaDB-Doublewrite-Puffer.
Um festzustellen, ob eine Datenbank von RDS für MariaDB die Funktion RDS-optimierte Schreibvorgänge verwendet, sehen Sie sich den aktuellen Wert des `innodb_doublewrite`-Parameters für die Datenbank an. Wenn die Datenbank RDS Optimized Writes verwendet, ist dieser Parameter auf `FALSE` (`0`) eingestellt.
## Verwenden von RDS Optimized Writes
Sie können RDS-optimierte Schreibvorgänge aktivieren, wenn Sie eine RDS for MariaDB-Datenbank mit der RDS-Konsole AWS CLI, der oder der RDS-API erstellen. RDS Optimized Writes wird automatisch aktiviert, wenn bei der Datenbankerstellung die beiden folgenden Bedingungen zutreffen:
+ Sie geben eine DB-Engine-Version und eine DB-Instance-Klasse an, die RDS Optimized Writes unterstützt.
+ RDS Optimized Writes wird für die folgenden Versionen von RDS für MariaDB unterstützt:
+ Alle verfügbaren Unterversionen von Version 11.8 und höheren Hauptversionen
+ 11.4.3 und höhere 11.4-Versionen
+ 10.11.4 und höhere 10.11-Versionen
+ 10.6.10 und höhere 10.6-Versionen
Informationen zu den Versionen von RDS für MariaDB finden Sie unter [MariaDB auf Amazon-RDS-Versionen](MariaDB.Concepts.VersionMgmt.md).
+ RDS-optimierte Schreibvorgänge werden für Datenbanken von RDS für MariaDB unterstützt, die die folgenden DB-Instance-Klassen verwenden:
+ db.m7i
+ db.m7g
+ db.m6g
+ db.m6gd
+ db.m6i
+ db.m5
+ db.m5d
+ db.r7i
+ db.r7g
+ db.r6g
+ db.r6gd
+ db.r6i
+ db.r5
+ db.r5b
+ db.r5d
+ db.x2idn
+ db.x2iedn
Weitere Informationen zu DB-Instance-Klassen finden Sie unter [](Concepts.DBInstanceClass.md).
Die Verfügbarkeit der DB-Instance-Klassen unterscheidet sich für. AWS-Regionen Informationen darüber, ob eine DB-Instance-Klasse in einer bestimmten Klasse unterstützt wird AWS-Region, finden Sie unter[Ermitteln der Unterstützung für DB-Instance-Klassen in AWS-Regionen](Concepts.DBInstanceClass.RegionSupport.md).
+ In der Parametergruppe, die der Datenbank zugeordnet ist, ist der `rds.optimized_writes`-Parameter auf `AUTO` eingestellt. In Standardparametergruppen ist dieser Parameter immer auf `AUTO` festgelegt.
Wenn Sie eine DB-Engine-Version und eine DB-Instance-Klasse verwenden möchten, die RDS-optimierte Schreibvorgänge unterstützen, geben Sie beim Erstellen der Datenbank eine benutzerdefinierte Parametergruppe an. Legen Sie den Parameter `rds.optimized_writes` in dieser Parametergruppe auf `OFF` fest. Wenn Sie möchten, dass die Datenbank später RDS Optimized Writes verwendet, können Sie den Parameter auf `AUTO` einstellen, um ihn zu aktivieren. Weitere Informationen über das Erstellen von benutzerdefinierten DB-Parametergruppen und das Festlegen von Parametern finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Weitere Informationen zum Erstellen einer DB-Instance finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
### Konsole
Wenn Sie die RDS-Konsole verwenden, um eine Datenbank von RDS für MariaDB zu erstellen, können Sie nach den Versionen der DB-Engine und den DB-Instance-Klassen filtern, die RDS-optimierte Schreibvorgänge unterstützen. Nachdem Sie die Filter aktiviert haben, können Sie aus den verfügbaren DB-Engine-Versionen und DB-Instance-Klassen auswählen.
Wenn Sie eine DB-Engine-Version auswählen möchten, die RDS-optimierte Schreibvorgänge unterstützt, filtern Sie in **Engine-Version** nach den DB-Engine-Versionen von RDS für MariaDB, die dies unterstützen, und wählen Sie dann eine Version aus.
![\[Der Abschnitt Engine-Optionen, in dem der Filter Amazon RDS Optimized Writes für Engine-Version aktiviert ist.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-version-filter-mariadb.png)
Filtern Sie im Abschnitt **Instance configuration** (Instance-Konfiguration) nach den DB-Instance-Klassen, die RDS Optimized Writes unterstützen, und wählen Sie dann eine DB-Instance-Klasse aus.
![\[Der Abschnitt Instance-Konfiguration, in dem der Filter Amazon RDS Optimized Writes für die DB-Instance-Klasse aktiviert ist.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-class-filter.png)
Nachdem Sie diese Auswahl getroffen haben, können Sie andere Einstellungen auswählen, die Ihren Anforderungen entsprechen, und die Erstellung der Datenbank von RDS für MariaDB mit der Konsole abschließen.
### AWS CLI
Um eine DB-Instance mit dem zu erstellen AWS CLI, führen Sie den [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)Befehl aus. Stellen Sie sicher, dass die Werte `--engine-version` und `--db-instance-class` RDS Optimized Writes unterstützen. Stellen Sie außerdem sicher, dass der `rds.optimized_writes`-Parameter für die Parametergruppe, die der DB-Instance zugeordnet ist, auf `AUTO` festgelegt ist. Im folgenden Beispiel wird die Standardparametergruppe mit der DB-Instance verknüpft.
**Example Erstellen einer DB-Instance, die RDS Optimized Writes verwendet**
Für Linux, macOS oder Unix:
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --engine mariadb \
4. --engine-version 10.6.10 \
5. --db-instance-class db.r5b.large \
6. --manage-master-user-password \
7. --master-username admin \
8. --allocated-storage 200
```
Für Windows:
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --engine mariadb ^
4. --engine-version 10.6.10 ^
5. --db-instance-class db.r5b.large ^
6. --manage-master-user-password ^
7. --master-username admin ^
8. --allocated-storage 200
```
### RDS-API
Sie können eine DB-Instance mithilfe der DBInstance Operation [Create erstellen](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Wenn Sie diese Operation verwenden, stellen Sie sicher, dass die Werte `EngineVersion` und `DBInstanceClass` RDS Optimized Writes unterstützen. Stellen Sie außerdem sicher, dass der `rds.optimized_writes`-Parameter für die Parametergruppe, die der DB-Instance zugeordnet ist, auf `AUTO` festgelegt ist.
## Aktivieren von RDS-optimierten Schreibvorgängen in einer vorhandenen Datenbank
Um eine vorhandene Datenbank von RDS für MariaDB zu ändern und RDS-optimierte Schreibvorgänge zu aktivieren, muss die Datenbank mit einer unterstützten DB-Engine-Version und DB-Instance-Klasse erstellt worden sein. Darüber hinaus muss die Datenbank *nach* der Veröffentlichung der RDS-optimierten Schreibvorgänge am 7. März 2023 erstellt worden sein, da die erforderliche zugrunde liegende Dateisystemkonfiguration nicht mit derjenigen von Datenbanken kompatibel ist, die vor der Veröffentlichung erstellt wurden. Wenn diese Bedingungen erfüllt sind, können Sie RDS-optimierte Schreibvorgänge aktivieren, indem Sie den Parameter `rds.optimized_writes` auf `AUTO` setzen.
Wenn Ihre Datenbank *nicht* mit einer unterstützten Engine-Version, Instance-Klasse oder Dateisystemkonfiguration erstellt wurde, können Sie Blue/Green RDS-Bereitstellungen verwenden, um zu einer unterstützten Konfiguration zu migrieren. Gehen Sie beim Erstellen der blue/green Bereitstellung wie folgt vor:
+ Wählen Sie **Optimierte Schreibvorgänge in grüner Datenbank aktivieren** aus und geben Sie dann eine Engine-Version und eine DB-Instance-Klasse an, die RDS-optimierte Schreibvorgänge unterstützt. Eine Liste der unterstützten Engine-Versionen und Instance-Klassen finden Sie unter [Verwenden von RDS Optimized Writes](#rds-optimized-writes-using-mariadb).
+ Wählen Sie unter **Speicher** die Option **Speicherdatei-Systemkonfiguration aktualisieren** aus. Mit dieser Option wird die Datenbank auf eine kompatible zugrunde liegende Dateisystemkonfiguration aktualisiert.
Wenn Sie die blue/green Bereitstellung erstellen und der `rds.optimized_writes` Parameter auf gesetzt ist`AUTO`, werden RDS-optimierte Schreibvorgänge in der grünen Umgebung automatisch aktiviert. Sie können dann zur blue/green Bereitstellung wechseln, wodurch die grüne Umgebung zur neuen Produktionsumgebung wird.
Weitere Informationen finden Sie unter [Eine blue/green Bereitstellung in Amazon RDS — erstellen](blue-green-deployments-creating.md).
## Einschränkungen für RDS Optimized Writes
Wenn Sie eine Datenbank von RDS für MariaDB aus einem Snapshot wiederherstellen, können Sie RDS-optimierte Schreibvorgänge für die Datenbank nur aktivieren, wenn alle nachfolgenden Bedingungen zutreffen:
+ Der Snapshot wurde aus einer Datenbank erstellt, die RDS Optimized Writes unterstützt.
+ Der Snapshot wurde aus einer Datenbank erstellt, die *nach* der Veröffentlichung von RDS-optimierten Schreibvorgängen erstellt wurde.
+ Der Snapshot wird in einer Datenbank wiederhergestellt, die RDS Optimized Writes unterstützt.
+ Die wiederhergestellte Datenbank ist einer Parametergruppe zugeordnet, deren `rds.optimized_writes`-Parameter auf `AUTO` eingestellt ist.
# Upgrades der MariaDB-DB-Engine
Sofern Amazon RDS eine neue Version der Datenbank-Engine unterstützt, können Sie Ihre DB-Instances auf die neue Version aktualisieren. Es gibt zwei Arten von Upgrades für MariaDB-DB-Instances: Hauptversionsupgrades und Unterversionsupgrades.
*Hauptversions-Upgrades* können Datenbankänderungen enthalten, die nicht mit vorhandenen Anwendungen rückwärts kompatibel sind. Daher müssen Sie Hauptversion-Upgrades Ihrer DB-Instances manuell durchführen. Sie können ein Hauptversions-Upgrade starten, indem Sie Ihre DB-Instance ändern. Bevor Sie ein Hauptversions-Upgrade durchführen, wird jedoch das Befolgen der Schritte unter [Hauptversion-Upgrades für RDS für MariaDB](USER_UpgradeDBInstance.MariaDB.Major.md) empfohlen.
*Nebenversions-Upgrades* enthalten dagegen nur Änderungen, die mit vorhandenen Anwendungen abwärtskompatibel sind. Sie können ein Nebenversions-Upgrade manuell starten, indem Sie Ihre DB-Instance ändern. Alternativ können Sie auch beim Erstellen oder Ändern einer DB-Instance die Option **Auto minor version upgrade (Automatisches Nebenversions-Upgrade)** aktivieren. Hierdurch wird Ihre DB-Instance automatisch aktualisiert, nachdem die neue Version von Amazon RDS getestet und genehmigt wurde. Weitere Informationen zum Ausführen eines Upgrades finden Sie unter [Upgrade der Engine-Version für eine DB-Instance ](USER_UpgradeDBInstance.Upgrading.md).
Wenn Ihre MariaDB-DB-Instance Lesereplikate verwendet, müssen Sie alle Lesereplikate aktualisieren, bevor Sie die Quell-Instance aktualisieren. Wenn sich Ihre DB-Instance in einer Multi-AZ-Bereitstellung befindet, werden sowohl die Writer- als auch die Standby-Replikate aktualisiert. Ihre DB-Instance ist möglicherweise erst verfügbar, wenn das Upgrade abgeschlossen ist.
Weitere Informationen über die unterstützten MariaDB-Versionen und zur Versionsverwaltung finden Sie unter [MariaDB auf Amazon-RDS-Versionen](MariaDB.Concepts.VersionMgmt.md).
Datenbank-Engine-Upgrades erfordern Ausfallzeiten. Die Dauer des Nutzungsausfalls ist von der Größe Ihrer DB-Instance abhängig.
Amazon RDS unterstützt auch Upgrade-Rollout-Richtlinien zur Verwaltung automatischer Upgrades kleinerer Versionen für mehrere Datenbankressourcen und AWS-Konten. Weitere Informationen finden Sie unter [Verwendung der AWS Organizations Upgrade-Rollout-Richtlinie für automatische Upgrades kleinerer Versionen](RDS.Maintenance.AMVU.UpgradeRollout.md).
**Tipp**
Sie können die für das DB-Instance-Upgrade erforderlichen Ausfallzeiten minimieren, indem Sie eine blue/green Bereitstellung verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon RDS Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md).
**Topics**
+ [Überlegungen zu MariaDB-Upgrades](#USER_UpgradeDBInstance.MariaDB.Considerations)
+ [Finden gültiger Upgrade-Ziele](#USER_UpgradeDBInstance.MariaDB.FindingTargets)
+ [MariaDB-Versionsnummern](USER_UpgradeDBInstance.MariaDB.VersionID.md)
+ [RDS-Versionsnummern in RDS für MariaDB](USER_UpgradeDBInstance.MariaDB.rds.version.md)
+ [Hauptversion-Upgrades für RDS für MariaDB](USER_UpgradeDBInstance.MariaDB.Major.md)
+ [Upgraden einer MariaDB-DB-Instance](#USER_UpgradeDBInstance.MariaDB.Upgrading)
+ [Automatische Unterversion-Upgrades für RDS für MariaDB](USER_UpgradeDBInstance.MariaDB.Minor.md)
+ [Verwenden eines Lesereplikats, um Ausfallzeiten beim Upgrade einer Datenbank in RDS für MariaDB zu reduzieren](USER_UpgradeDBInstance.MariaDB.ReducedDowntime.md)
+ [Überwachung von RDS für MariaDB-DB-Engine-Upgrades mit Ereignissen](USER_UpgradeDBInstance.MariaDB.Monitoring.md)
## Überlegungen zu MariaDB-Upgrades
Amazon RDS erstellt zwei oder mehr DB-Snapshots während des Upgrades. Amazon RDS erstellt bis zu zwei Snapshots der DB-Instance, *bevor* Upgrade-Änderungen vorgenommen werden. Wenn das Upgrade bei Ihren Datenbanken nicht funktioniert, können Sie einen dieser Snapshots wiederherstellen, um eine DB-Instance zu erstellen, auf der die alte Version ausgeführt wird. Amazon RDS erstellt einen weiteren Snapshot der DB-Instance, wenn das Upgrade abgeschlossen ist. Amazon RDS erstellt diese Snapshots unabhängig davon, ob die Backups für die DB-Instance AWS Backup verwaltet werden.
**Anmerkung**
Amazon RDS nimmt nur DB-Snapshots auf, wenn Sie den Sicherungsaufbewahrungszeitraum für Ihre DB-Instance auf eine Zahl größer als 0 festgelegt haben. Informationen über das Ändern Ihres Aufbewahrungszeitraums für Backups finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
Nachdem das Upgrade abgeschlossen ist, können Sie nicht zur vorherigen Version der Datenbank-Engine zurückkehren. Wenn Sie zur vorherigen Version zurückkehren möchten, stellen Sie den ersten DB-Snapshot wieder her, um eine neue DB-Instance zu erstellen.
Sie steuern, wann Ihre DB-Instance auf eine neue Version aktualisiert werden soll, die von Amazon RDS unterstützt wird. Diese Kontrollebene hilft Ihnen, die Kompatibilität mit bestimmten Datenbankversionen aufrechtzuerhalten und neue Versionen mit Ihrer Anwendung zu testen, bevor sie produktiv bereitgestellt werden. Wenn Sie bereit sind, können Sie Versions-Upgrades zu den Zeiten durchführen, die am besten zu Ihrem Zeitplan passen.
Wenn Ihre DB-Instance die Lesereplikation verwendet, müssen Sie alle Read Replicas aktualisieren, bevor Sie die Quell-Instance aktualisieren.
Wenn sich die DB-Instance in einer Multi-AZ-Bereitstellung befindet, erfolgt das Upgrade sowohl für die primären als auch Standby-DB-Instances. Die primären und die Standby-DB-Instances werden gleichzeitig aktualisiert, und es kommt zu einem Ausfall, bis das Upgrade abgeschlossen ist. Die Dauer des Nutzungsausfalls ist von Ihrer Datenbank-Engine-Version und der Größe Ihrer DB-Instance abhängig.
## Finden gültiger Upgrade-Ziele
Wenn Sie das verwenden AWS-Managementkonsole , um eine DB-Instance zu aktualisieren, werden die gültigen Upgrade-Ziele für die DB-Instance angezeigt. Sie können auch den folgenden AWS CLI Befehl ausführen, um die gültigen Upgrade-Ziele für eine DB-Instance zu identifizieren:
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version version_number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version version_number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Um beispielsweise die gültigen Upgrade-Ziele für eine MariaDB-DB-Instance der Version 10.5.17 zu identifizieren, führen Sie den folgenden Befehl aus: AWS CLI
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version 10.5.17 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version 10.5.17 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# MariaDB-Versionsnummern
Die Versionsnummerierungssequenz für die Datenbank-Engine von RDS für MariaDB hat entweder die Form *Hauptversion.Unterversion.Patch.JJJJMMTT* oder *Hauptversion.Unterversion.Patch*, zum Beispiel 10.11.5.R2.20231201 oder 10.4.30. Das Format hängt von der Version der MariaDB-Engine ab.
**Hauptversion**
Die Hauptversionsnummer ist sowohl die Ganzzahl als auch der erste Nachkommateil der Versionsnummer, z. B. 10.11. Ein Upgrade der Hauptversion erhöht den Hauptteil der Versionsnummer. Beispielsweise ist ein Upgrade von *10.5*.20 auf 10.6.12 ein Hauptversion-Upgrade, wobei *10.5* und *10.6* die Hauptversionsnummern sind.
**Unterversion**
Die Unterversionsnummer ist der dritte Teil der Versionsnummer, z. B. die 5 in 10.11.5.
**Patch**
Der Patch ist der vierte Teil der Versionsnummer, zum Beispiel R2 in 10.11.5.R2. Eine RDS-Patch-Version enthält wichtige Korrekturen, die einer Nebenversion nach ihrer Veröffentlichung hinzugefügt werden.
**JJJJMMTT**
Das Datum ist der fünfte Teil der Versionsnummer, zum Beispiel 20231201 in 10.11.5.R2.20231201. Eine RDS-Datumsversion ist ein Sicherheits-Patch, das wichtige Korrekturen enthält, die einer Unterversion nach ihrer Veröffentlichung hinzugefügt werden. Es enthält keine Korrekturen, die das Verhalten einer Engine ändern könnten.
In der folgenden Tabelle wird das Benennungsschema für Version 10.11 von RDS für MariaDB erklärt.
| Unterversion 10.11 | Benennungsschema |
| --- | --- |
| ≥ 5 | Neue DB-Instances verwenden das Format *Hauptversion.Unterversion.Patch.JJMMTT*, z. B. 10.11.5.R2.20231201. Bestehende DB-Instances verwenden möglicherweise *Hauptversion.Unterversion.Patch*, z. B. 10.11.5.R2, bis Sie Ihr nächstes Haupt- oder Unterversion-Upgrade durchführen. |
| < 5 | Bestehende DB-Instances verwenden *Hauptversion.Unterversion.Patch*, z. B. 10.11.4.R2. |
In der folgenden Tabelle wird das Benennungsschema für Version 10.6 von RDS für MariaDB erklärt.
| Unterversion 10.6 | Benennungsschema |
| --- | --- |
| ≥ 14 | Neue DB-Instances verwenden das Format *Hauptversion.Unterversion.Patch.JJMMTT*, z. B. 10.6.14.R2.20231201. Bestehende DB-Instances verwenden möglicherweise *Hauptversion.Unterversion.Patch*, z. B. 10.6.14.R2, bis Sie Ihr nächstes Haupt- oder Unterversion-Upgrade durchführen. |
| < 14 | Bestehende DB-Instances verwenden *Hauptversion.Unterversion.Patch*, z. B. 10.6.13.R2. |
In der folgenden Tabelle wird das Benennungsschema für Version 10.5 von RDS für MariaDB erklärt.
| Unterversion 10.5 | Benennungsschema |
| --- | --- |
| ≥ 21 | Neue DB-Instances verwenden das Format *Hauptversion.Unterversion.Patch.JJMMTT*, z. B. 10.5.21.R2.20231201. Bestehende DB-Instances verwenden möglicherweise *Hauptversion.Unterversion.Patch*, z. B. 10.5.21.R2, bis Sie Ihr nächstes Haupt- oder Unterversion-Upgrade durchführen. |
| < 21 | Bestehende DB-Instances verwenden *Hauptversion.Unterversion.Patch*, z. B. 10.5.20.R2. |
In der folgenden Tabelle wird das Benennungsschema für Version 10.4 von RDS für MariaDB erklärt.
| Unterversion 10.4 | Benennungsschema |
| --- | --- |
| ≥ 30 | Neue DB-Instances verwenden das Format *Hauptversion.Unterversion.Patch.JJMMTT*, z. B. 10.4.30.R2.20231201. Bestehende DB-Instances verwenden möglicherweise *Hauptversion.Unterversion.Patch*, z. B. 10.4.30.R2, bis Sie Ihr nächstes Haupt- oder Unterversion-Upgrade durchführen. |
| < 30 | Bestehende DB-Instances verwenden *Hauptversion.Unterversion.Patch*, z. B. 10.4.29.R2. |
# RDS-Versionsnummern in RDS für MariaDB
RDS-Versionsnummern verwenden das Benennungsschema `major.minor.patch` oder `major.minor.patch.YYYYMMDD`. Eine RDS-Patch-Version enthält wichtige Korrekturen, die einer Nebenversion nach ihrer Veröffentlichung hinzugefügt werden. Eine RDS-Datumsversion (*JJMMTT*) ist ein Sicherheits-Patch. Ein Sicherheits-Patch enthält keine Korrekturen, die das Verhalten der Engine ändern könnten.
Wenn Sie die Amazon-RDS-Versionsnummer Ihrer Datenbank ermitteln möchten, müssen Sie zunächst die `rds_tools`-Erweiterung mit folgendem Befehl erstellen:
```
CREATE EXTENSION rds_tools;
```
Sie können die RDS-Versionsnummer Ihrer Datenbank von RDS für MariaDB mit der folgenden SQL-Abfrage herausfinden:
```
mysql> select mysql.rds_version();
```
Wenn Sie beispielsweise eine Datenbank von RDS für MariaDB 10.6.14 abfragen, wird Folgendes zurückgegeben:
```
+---------------------+
| mysql.rds_version() |
+---------------------+
| 10.6.14.R2.20231201 |
+---------------------+
1 row in set (0.01 sec)
```
# Hauptversion-Upgrades für RDS für MariaDB
Hauptversions-Upgrades können Datenbankänderungen enthalten, die nicht mit vorhandenen Anwendungen rückwärts kompatibel sind. Dies hat zur Folge, dass Amazon RDS Hauptversions-Upgrades nicht automatisch anwendet. Sie müssen Ihre DB-Instance manuell ändern. Sie sollten jedes Upgrade gründlich testen, bevor Sie es auf Ihre Produktions-Instances anwenden.
**Anmerkung**
In MariaDB 11.8 `require_secure_transport` ist der Standardwert für now`1`, was sichere Verbindungen erfordert. SSL/TLS Dieser Wert wird auf `0` festgelegt, wenn unsichere Verbindungen benötigt werden.
Amazon RDS unterstützt die folgenden direkten Upgrades für Hauptversionen der MariaDB-Datenbank-Engine:
+ Jede MariaDB-Version auf MariaDB 11.8
+ Jede MariaDB-Version auf MariaDB 11.4
+ Jede MariaDB-Version auf MariaDB 10.11
+ Jede MariaDB-Version zu MariaDB 10.6
+ MariaDB 10.4 zu MariaDB 10.5
Wenn Sie eine benutzerdefinierte Parametergruppe verwenden und ein Upgrade auf eine Hauptversion durchführen, müssen Sie entweder eine Standardparametergruppe für die neue DB-Engine-Version angeben oder eine eigene benutzerdefinierte Parametergruppe für die neue DB-Engine-Version erstellen. Die Zuordnung der neuen Parametergruppe zu DB-Instance erfordert einen vom Kunden initiierten Neustart der Datenbank nach Abschluss des Upgrades. Der Parametergruppenstatus der Instance zeigt an, `pending-reboot` ob die Instance neu gestartet werden muss, um die Änderungen der Parametergruppe zu übernehmen. Der Parametergruppenstatus einer Instance kann in der AWS-Managementkonsole oder über einen „Beschreiben“-Aufruf erfolgen, z. B. `describe-db-instances`.
## Upgraden einer MariaDB-DB-Instance
Informationen über das manuelle oder automatische Upgraden einer MariaDB-DB-Instance finden Sie unter [Upgrade der Engine-Version für eine DB-Instance ](USER_UpgradeDBInstance.Upgrading.md).
# Automatische Unterversion-Upgrades für RDS für MariaDB
Wenn Sie beim Erstellen oder Ändern einer DB-Instance die folgenden Einstellungen angeben, können Sie Ihre DB-Instance automatisch aktualisieren lassen.
+ Die Einstellung **Automatisches Upgrade der Nebenversion** ist aktiviert.
+ Die Einstellung **Aufbewahrungszeitraum für Sicherungen** beträgt mehr als 0.
Im AWS-Managementkonsole befinden sich diese Einstellungen unter **Zusätzliche Konfiguration**. Die folgende Abbildung zeigt die **Auto minor version upgrade** (Upgrade einer Unterversion automatisch durchführen)-Einstellung.
![\[Auto minor version upgrade (Upgrade einer Unterversion automatisch durchführen)-Einstellung\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/amvu.png)
Weitere Informationen zu diesen Einstellungen finden Sie unter [Einstellungen für DB-Instances](USER_ModifyInstance.Settings.md).
Bei einigen Hauptversionen von RDS für MariaDB in einigen AWS-Regionen wird eine Nebenversion von RDS als automatische Upgrade-Version festgelegt. Nachdem eine Minor-Version von Amazon RDS getestet und freigegeben wurde, erfolgt das Upgrade der Minor-Version automatisch während Ihres Wartungsfensters. RDS legt nicht automatisch neuere freigegebene Minor-Versionen als die automatische Upgradeversion fest. Bevor RDS eine neuere automatische Upgradeversion bestimmt, werden mehrere Kriterien berücksichtigt, wie beispielsweise die folgenden:
+ Bekannte Sicherheitsprobleme
+ Fehler in der MariaDB-Community-Version
+ Gesamtflottenstabilität seit Erscheinen der Minor-Version
**Anmerkung**
Die Unterstützung für die Verwendung von TLS-Version 1.0 und 1.1 wurde ab bestimmten Unterversionen von MariaDB entfernt. Informationen über unterstützte Unterversionen für MariaDB finden Sie unter [SSL/TLS-Unterstützung für MariaDB-DB-Instances in Amazon RDS](MariaDB.Concepts.SSLSupport.md).
Sie können den folgenden AWS CLI-Befehl verwenden, um die aktuelle automatische Upgrade-Ziel-Unterversion für eine bestimmte MariaDB-Unterversion in einer bestimmten AWS-Region festzulegen.
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version minor_version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version minor_version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Der folgende AWS CLI-Befehl legt beispielsweise das automatische Ziel für die Aktualisierung der Nebenversion für die MariaDB-Nebenversion 10.5.16 in der AWS-Region USA Ost (Ohio) (us-east-2) fest.
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version 10.5.16 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version 10.5.16 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
Ihre Ausgabe sieht Folgendem ähnlich.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| True | 10.5.17 |
| False | 10.5.18 |
| False | 10.5.19 |
| False | 10.6.5 |
| False | 10.6.7 |
| False | 10.6.8 |
| False | 10.6.10 |
| False | 10.6.11 |
| False | 10.6.12 |
+--------------+-----------------+
```
In diesem Beispiel ist der `AutoUpgrade`-Wert `True` für MariaDB-Version 10.5.17. Das automatische Nebenversions-Upgrade-Ziel ist daher die MariaDB-Version 10.5.17, die in der Ausgabe hervorgehoben wird.
Eine MariaDB-DB-Instance wird während Ihres Wartungsfensters automatisch aktualisiert, wenn die folgenden Kriterien erfüllt sind:
+ Die Einstellung **Automatisches Upgrade der Nebenversion** ist aktiviert.
+ Die Einstellung **Aufbewahrungszeitraum für Sicherungen** beträgt mehr als 0.
+ Die DB-Instance führt eine Minor-Version der DB-Engine aus, die niedriger ist als die aktuelle Minor-Version des automatischen Upgrades.
Weitere Informationen finden Sie unter [Automatisches Upgraden der Engine-Unterversion](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
# Verwenden eines Lesereplikats, um Ausfallzeiten beim Upgrade einer Datenbank in RDS für MariaDB zu reduzieren
In den meisten Fällen ist eine Blau/Grün-Bereitstellung die beste Option, um Ausfallzeiten beim Upgrade einer MariaDB-DB-Instance zu reduzieren. Weitere Informationen finden Sie unter [Verwenden von Amazon RDS Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md).
Wenn Sie keine Blau/Grün-Bereitstellung verwenden können und Ihre MariaDB-DB-Instance aktuell von einer Produktionsanwendung genutzt wird, können Sie mit dem folgenden Verfahren die Datenbankversion Ihrer DB-Instance aktualisieren. Dieses Verfahren kann die Ausfallzeiten Ihrer Anwendung reduzieren.
Mithilfe einer Read Replica können Sie die meisten Wartungsschritte im Voraus durchführen und die erforderlichen Änderungen während des tatsächlichen Ausfalls minimieren. Mit dieser Technik können Sie die neue DB-Instance testen und vorbereiten, ohne Änderungen an Ihrer bestehenden DB-Instance vorzunehmen.
Im Folgenden wird ein Beispiel für ein Upgrade von MariaDB Version 10.5 auf MariaDB Version 10.6 gezeigt. Sie können die gleichen allgemeinen Schritte für Upgrades auf andere Hauptversionen durchführen.
**So führen Sie ein Upgrade einer MariaDB-Datenbank durch, während eine DB-Instance verwendet wird**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Erstellen Sie ein Lesereplikat Ihrer DB-Instance von MariaDB 10.5. Dieser Prozess erstellt eine aktualisierbare Kopie Ihrer Datenbank. Andere Read Replicas der DB-Instance könnten ebenfalls vorhanden sein.
1. Wählen Sie in der Konsole **Datenbanken** und dann die DB-Instance aus, die Sie upgraden möchten.
1. Wählen Sie unter **Aktionen** **Create read replica (Read Replica erstellen)** aus.
1. Geben Sie für das Lesereplikat einen Wert im Feld **DB instance identifier** (DB-Instance-Kennung) ein und stellen Sie sicher, dass der Eintrag unter **DB instance class** (DB-Instance-Klasse) und die anderen Einstellungen mit Ihrer DB-Instance von MariaDB 10.5 übereinstimmen.
1. Wählen Sie **Read Replica erstellen** aus.
1. (Optional) Wenn die Read Replica erstellt wurde und der **Status** **Verfügbar** anzeigt, konvertieren Sie die Read Replica in eine Multi-AZ-Bereitstellung und aktivieren Sie Sicherungen.
Standardmäßig wird ein Lesereplikat als Single-AZ-Bereitstellung mit deaktivierten Backups erstellt. Da das Lesereplikat letztendlich zur DB-Produktions-Instance wird, ist es eine bewährte Methode, eine Multi-AZ-Bereitstellung zu konfigurieren und Backups jetzt zu aktivieren.
1. Wählen Sie in der Konsole **Datenbanken** und dann die Read Replica aus, die Sie gerade erstellt haben.
1. Wählen Sie **Ändern** aus.
1. Für die **Multi-AZ-Bereitstellung**wählen Sie **Standby-Instance erstellen**.
1. Wählen Sie unter **Backup Retention Period** (Aufbewahrungszeitraum für Backups) einen positiven Wert größer als null aus, z. B. 3 Tage. Klicken Sie anschließend auf **Continue** (Weiter).
1. Wählen Sie für **Scheduling of modifications (Einplanung von Änderungen)** die Option **Apply immediately (Sofort anwenden)** aus.
1. Wählen Sie **Modify DB Instance (DB-Instance ändern)** aus.
1. Wenn der **Status** des Lesereplikats **Available** (Verfügbar) anzeigt, aktualisieren Sie das Lesereplikat auf MariaDB 10.6.
1. Wählen Sie in der Konsole **Datenbanken** und dann die Read Replica aus, die Sie gerade erstellt haben.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie im Feld **DB engine version** (DB-Engine-Version) die gewünschte Version von MariaDB 10.6 für das Upgrade aus und klicken Sie auf **Continue** (Weiter).
1. Wählen Sie für **Scheduling of modifications (Einplanung von Änderungen)** die Option **Apply immediately (Sofort anwenden)** aus.
1. Wählen Sie **Modify DB instance** (DB-Instance ändern) aus, um das Upgrade zu starten.
1. Wenn das Upgrade abgeschlossen ist und für **Status** **Available** (Verfügbar) angezeigt wird, überprüfen Sie, ob das aktualisierte Lesereplikat mit der Quell-DB-Instance von MariaDB 10.5 auf dem neuesten Stand ist. Stellen Sie zur Überprüfung eine Verbindung mit dem Lesereplikat her und führen Sie den Befehl `SHOW REPLICA STATUS` aus. Wenn das `Seconds_Behind_Master`-Feld `0` ist, ist die Replikation auf dem neuesten Stand.
**Anmerkung**
Frühere Versionen von MariaDB wurden`SHOW SLAVE STATUS` anstelle von verwendet`SHOW REPLICA STATUS`. Wenn Sie eine ältere MariaDB-Version nutzen als 10.6, verwenden Sie `SHOW SLAVE STATUS`.
1. (Optional) Erstellen Sie eine Read Replica Ihrer Read Replica.
Wenn Sie möchten, dass die DB-Instance eine Read Replica hat, nachdem sie auf eine eigenständige DB-Instance hochgestuft wurde, können Sie jetzt die Read Replica erstellen.
1. Wählen Sie auf der Konsole **Datenbanken** und dann die Read Replica aus, die Sie gerade aktualisiert haben.
1. Wählen Sie unter **Aktionen** **Create read replica (Read Replica erstellen)** aus.
1. Geben Sie für das Lesereplikat einen Wert im Feld **DB instance identifier** (DB-Instance-Kennung) ein und stellen Sie sicher, dass der Eintrag unter **DB instance class** (DB-Instance-Klasse) und die anderen Einstellungen mit Ihrer DB-Instance von MariaDB 10.5 übereinstimmen.
1. Wählen Sie **Read Replica erstellen** aus.
1. (Optional) Konfigurieren Sie eine benutzerdefinierte DB-Parametergruppe für die Read Replica.
Wenn Sie möchten, dass die DB-Instance eine benutzerdefinierte Parametergruppe verwendet, nachdem sie zu einer eigenständigen DB-Instance hochgestuft wurde, können Sie die DB-Parametergruppe erstellen und sie jetzt dem Lesereplikat zuordnen kann.
1. Erstellen Sie eine benutzerdefinierte DB-Parametergruppe für MariaDB 10.6. Detaillierte Anweisungen finden Sie unter [Erstellen einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Creating.md).
1. Ändern Sie die Parameter, die Sie in der gerade erstellten DB-Parametergruppe ändern möchten. Detaillierte Anweisungen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Wählen Sie in der Konsole **Datenbanken**und dann die Read Replica aus.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie für **DB parameter group** (DB-Parametergruppe) die soeben erstellte DB-Parametergruppe von MariaDB 10.6 aus, und klicken Sie dann auf **Continue** (Weiter).
1. Wählen Sie für **Scheduling of modifications (Einplanung von Änderungen)** die Option **Apply immediately (Sofort anwenden)** aus.
1. Wählen Sie **Modify DB instance** (DB-Instance ändern) aus, um das Upgrade zu starten.
1. Machen Sie Ihr Lesereplikat von MariaDB 10.6 zu einer eigenständigen DB-Instance.
**Wichtig**
Wenn Sie Ihr Lesereplikat von MariaDB 10.6 zu einer eigenständigen DB-Instance hochstufen, handelt es sich nicht mehr um ein Replikat der DB-Instance von MariaDB 10.5. Wir empfehlen, dass Sie Ihr Lesereplikat von MariaDB 10.6 während eines Wartungsfensters hochstufen, wenn sich Ihre Quell-DB-Instance von MariaDB 10.5 im schreibgeschützten Modus befindet und alle Schreiboperationen ausgesetzt sind. Wenn das Hochstufen abgeschlossen ist, können Sie Ihre Schreiboperationen an die aktualisierte DB-Instance von MariaDB 10.6 weiterleiten, um sicherzustellen, dass keine Schreiboperationen verloren gehen.
Zusätzlich empfehlen wir, dass Sie vor dem Hochstufen des Lesereplikats von MariaDB 10.6 alle erforderlichen Data Definition Language (DDL)-Operationen auf Ihrem Lesereplikat von MariaDB 10.6 ausführen. Ein Beispiel hierfür ist das Erstellen von Indizes. Mit diesem Ansatz werden negative Auswirkungen auf die Leistung des Lesereplikats von MariaDB 10.6 vermieden, nachdem es hochgestuft wurde. Gehen Sie folgendermaßen vor, um ein Lesereplikat hochzustufen.
1. Wählen Sie auf der Konsole **Datenbanken** und dann die Read Replica aus, die Sie gerade aktualisiert haben.
1. Wählen Sie für **Actions (Aktionen)** **Promote (Hochstufen)** aus.
1. Klicken Sie auf **Yes (Ja)**, um automatische Sicherungen für die Lesereplikat-Instance zu aktivieren. Weitere Informationen finden Sie unter [Einführung in Backups](USER_WorkingWithAutomatedBackups.md).
1. Klicken Sie auf **Weiter**.
1. Klicken Sie auf **Read Replica hochstufen**.
1. Sie haben jetzt eine aktualisierte Version Ihrer MariaDB-Datenbank vorliegen. An dieser Stelle können Sie Ihre Anwendungen auf die neue DB-Instance von MariaDB 10.6 umleiten.
# Überwachung von RDS für MariaDB-DB-Engine-Upgrades mit Ereignissen
Wenn Sie die Engine-Version einer RDS for MariaDB-Datenbank aktualisieren, gibt Amazon RDS in jeder Phase des Prozesses ein bestimmtes Ereignis aus. Um den Fortschritt eines Upgrades zu verfolgen, können Sie sich diese Ereignisse ansehen oder abonnieren.
Weitere Informationen zu RDS-Ereignissen finden Sie unter[Überwachung von Amazon-RDS-Ereignissen](working-with-events.md).
Ausführliche Informationen zu einem bestimmten Amazon RDS-Ereignis, das während Ihres Engine-Upgrades auftritt, finden Sie unter[Amazon RDS-Ereigniskategorien und Ereignisnachrichten ](USER_Events.Messages.md).
# Aktualisieren einer Engine-Version für MariaDB-DB-Snapshots
Mit Amazon RDS können Sie einen DB-Snapshot für das Speicher-Volume der MariaDB-DB-Instance erstellen. Wenn Sie einen DB-Snapshot erstellen, basiert dieser auf der Engine-Version, die von der DB-Instance verwendet wird. Sie können die Engine-Version für Ihre DB-Snapshots aktualisieren.
Für RDS für MariaDB können Sie auf alle verfügbaren Engine-Versionen ein Upgrade durchführen. Sie können verschlüsselte oder unverschlüsselte DB-Snapshots aktualisieren.
Verwenden Sie das folgende AWS CLI -Beispiel, um die verfügbaren Engine-Versionen für den DB-Snapshot von RDS für MariaDB anzuzeigen.
```
aws rds describe-db-engine-versions --engine mariadb --include-all --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Wenn keine Ergebnisse für den Snapshot angezeigt werden, ist die Engine-Version möglicherweise veraltet. Wenn die Engine-Version veraltet ist, empfehlen wir Ihnen, auf das Upgrade-Ziel der neuesten Hauptversion oder auf eines der anderen verfügbaren Upgrade-Ziele für diese Version zu aktualisieren. Weitere Informationen finden Sie unter [Upgrade-Optionen für DB-Snapshots mit nicht unterstützten Engine-Versionen für RDS für MariaDB](mariadb-upgrade-snapshot.upgrade-options.md).
Wenn Sie einen DB-Snapshot wiederherstellen, der auf eine neue Engine-Version aktualisiert wurde, sollten Sie prüfen, ob das Upgrade erfolgreich durchgeführt wurde. Weitere Informationen zu größeren Versionsaktualisierungen finden Sie unter [Upgrades der MariaDB-DB-Engine](USER_UpgradeDBInstance.MariaDB.md). Informationen zum Wiederherstellen eines DB-Snapshots finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md).
**Anmerkung**
Sie können keine Upgrades für automatische DB-Snapshots durchführen, die während automatischer Backup-Vorgänge erstellt wurden.
Sie können einen DB-Snapshot mithilfe der AWS-Managementkonsole AWS CLI, oder RDS-API aktualisieren.
------
#### [ Console ]
Gehen Sie wie folgt vor AWS-Managementkonsole, um eine DB-Snapshot-Engine-Version mithilfe von zu aktualisieren.
**So führen Sie ein Upgrade eines DB-Snapshots durch**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich die Option **Snapshots**.
1. Wählen Sie den Snapshot für die Aktualisierung aus.
1. Wählen Sie unter **Actions (Aktionen)** die Option **Upgrade Snapshot (Snapshot aktualisieren)**. Die Seite **Upgrade snapshot (Snapshot aktualisieren)** erscheint.
1. Wählen Sie zum Aktualisieren **New engine version (Neue Engine-Version)**.
1. Wählen Sie **Save changes (Änderungen speichern)**, um den Snapshot zu aktualisieren.
Während des Upgrades werden alle Snapshot-Aktionen für diesen DB-Snapshot deaktiviert. Außerdem wird der Status des DB-Snapshots von **Verfügbar** in **Wird upgegradet** geändert. Nach Abschluss des Vorgangs wird der Status in **Aktiv** geändert. Wenn das Upgrade für den DB-Snapshot aufgrund einer Beschädigung des Snapshots nicht durchgeführt werden kann, wird der Status in **Nicht verfügbar** geändert. Sie können den Snapshot aus diesem Zustand nicht wiederherstellen.
**Anmerkung**
Wenn die Aktualisierung des DB-Snapshots fehlschlägt, wird der Snapshot wieder in seinen ursprünglichen Zustand zurückgebracht.
------
#### [ AWS CLI ]
Um einen DB-Snapshot auf eine neue Version der Datenbank-Engine zu aktualisieren, führen Sie den AWS CLI [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html)Befehl aus.
**Optionen**
+ `--db-snapshot-identifier`: die Kennung des DB-Snapshots, für den das Upgrade durchgeführt werden soll Die Kennung muss ein eindeutiger Amazon-Ressourcenname (ARN) sein. Weitere Informationen finden Sie unter [Amazon-Ressourcennamen (ARN) in Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version`: Die Engine-Version, auf die das Upgrade des DB-Snapshots durchgeführt werden soll
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds modify-db-snapshot \
2.
3. --db-snapshot-identifier my_db_snapshot \
4. --engine-version new_version
```
Für Windows:
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
------
#### [ Amazon RDS API ]
Um einen DB-Snapshot auf eine neue Version der Datenbank-Engine zu aktualisieren, rufen Sie den DBSnapshot RDS-API-Vorgang [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) auf.
**Parameters**
+ `DBSnapshotIdentifier`: die Kennung des DB-Snapshots, für den das Upgrade durchgeführt werden soll Die Kennung muss ein eindeutiger Amazon-Ressourcenname (ARN) sein. Weitere Informationen finden Sie unter [Amazon-Ressourcennamen (ARN) in Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion`: Die Engine-Version, auf die das Upgrade des DB-Snapshots durchgeführt werden soll
------
# Upgrade-Optionen für DB-Snapshots mit nicht unterstützten Engine-Versionen für RDS für MariaDB
In der folgenden Tabelle ist angegeben, auf welche Engine-Versionen Sie von einer nicht unterstützten Engine-Version für DB-Snapshots von RDS für MariaDB ein Upgrade durchführen können.
**Anmerkung**
Möglicherweise müssen Sie den DB-Snapshot mehrmals aktualisieren, um auf die von Ihnen gewählte Engine-Version ein Upgrade durchzuführen.
| Engine-Version für DB-Snapshots | Für ein Upgrade verfügbare Engine-Versionen |
| --- | --- |
| 10.0.17, 10.0.24, 10.0.28, 10.0.31, 10.0.32, 10.0.34, 10.0.35 | 10.0.38, 10.1.48, 10.6.19, 10.6.20, 10.11.9, 10.11.10, 11.4.3, 11.4.4, 11.8.3 |
| 10.1.14, 10.1.16, 10.1.19, 10.1.23, 10.1.26, 10.1.31, 10.1.34 | 10.1.48, 10.2.44, 10.6.19, 10.6.20, 10.11.9, 10.11.10, 11.4.3, 11.4.4, 11.8.3 |
| 10.2.11, 10.2.12, 10.2.15, 10.2.21, 10.2.32, 10.2.37, 10.2.39, 10.2.40, 10.2.41, 10.2.43 | 10.2.44, 10.3.39, 10.6.19, 10.6.20, 10.6.21, 10.11.9, 10.11.10, 10.11.11, 11.4.3, 11.4.4, 11.8.3 |
| 10.3.8, 10.3.13, 10.3.20, 10.3.23, 10.3.28, 10.3.31, 10.3.32 | 10.3.39, 10.4.34, 10.6.19, 10.6.20 10.6.21, 10.11.9, 10.11.10, 10.11.11, 11.4.3, 11.4.4, 11.8.3 |
| 10.4.8 | 10.4.34, 10.5.16, 10.5.17, 10.5.18, 10.5.20, 10.5.21, 10.5.22, 10.5.23, 10.5.24, 10.5.25, 10.5.26, 10.5.27, 10.5.28, 10.6.8, 10.6.10, 10.6.11, 10.6.13, 10.6.14, 10.6.15, 10.6.16, 10.6.18, 10.6.19, 10.6.20, 10.6.21, 10.11.4, 10.6.17, 10.11.5, 10.11.6, 10.11.7, 10.11.8, 10.11.9, 10.11.10, 10.11.11 |
# Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB
Für den Import von Daten in eine DB-Instance von RDS für MariaDB stehen verschiedene Techniken zur Verfügung. Die beste Methode hängt von einer Reihe von Faktoren ab:
+ Datenquelle
+ Datenmenge
+ Einmaliger oder kontinuierlicher Import
+ Dauer der Ausfallzeit
Wenn Sie auch eine Anwendung mit den Daten migrieren, müssen Sie zudem die Ausfallzeit berücksichtigen.
In der folgenden Tabelle sind Methoden zum Importieren von Daten in eine DB-Instance von RDS für MariaDB angegeben:
**Anmerkung**
Amazon RDS unterstützt nicht `mariadb-backup` oder den Import aus Amazon S3 für MariaDB.
| Quelle | Datenmenge | Einmalig oder kontinuierlich | Ausfallzeit der Anwendung | Technik | Weitere Informationen |
| --- | --- | --- | --- | --- | --- |
| Vorhandene On-Premises-MariaDB-Datenbank oder auf Amazon EC2 | Beliebig | Kontinuierlich | Minimal | Konfigurieren Sie die Replikation mit einer vorhandenen MariaDB-Datenbank als Replikationsquelle. Sie können die Replikation in eine MariaDB-DB-Instance mithilfe von MariaDB Global Transaction Identifiers (GTIDs) konfigurieren, wenn die externe Instance MariaDB-Version 10.0.24 oder höher ist, oder mithilfe binärer Protokollkoordinaten für MariaDB-Instances in früheren Versionen als 10.0.24. MariaDB GTIDs werden anders implementiert als MySQL GTIDs, die von Amazon RDS nicht unterstützt werden. | [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.ReplMariaDB.md) [Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB mit reduzierter Ausfallzeit](mariadb-importing-data-reduced-downtime.md) |
| Alle vorhandenen Datenbanken | Alle | Einmalig oder kontinuierlich | Minimal | Wird verwendet AWS Database Migration Service , um die Datenbank mit minimalen Ausfallzeiten zu migrieren und bei vielen Datenbank-DB-Engines die fortlaufende Replikation fortzusetzen. | [Was ist AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) und [Verwenden einer MySQL-kompatiblen Datenbank als Ziel für AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) im *AWS Database Migration Service -Benutzerhandbuch* |
| Vorhandene MariaDB-DB-Instance | Beliebig | Einmalig oder kontinuierlich | Minimal | Erstellen Sie eine Read Replica für die laufende Replikation. Stufen Sie die Read Replica für die einmalige Erstellung einer neuen DB-Instance hoch. | [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md) |
| Vorhandene MariaDB-Datenbank | Small | Einmalig | Etwas | Kopieren Sie die Daten mit einem Befehlszeilen-Dienstprogramm direkt in die MariaDB-DB-Instance. | [Importieren von Daten aus einer externen MariaDB-Datenbank in eine DB-Instance von Amazon RDS für MariaDB](mariadb-importing-data-external-database.md) |
| Nicht in einer vorhandenen Datenbank gespeicherte Daten | Medium | Einmalig | Etwas | Erstellen Sie Flatfiles und importieren Sie diese mithilfe von MariaDB-`LOAD DATA LOCAL INFILE`-Anweisungen. | [Importieren von Daten aus einer beliebigen Quelle zu einer DB-Instance von Amazon RDS für MariaDB](mariadb-importing-data-any-source.md) |
**Anmerkung**
Die Systemdatenbank `mysql` enthält Authentifizierungs- und Autorisierungsinformationen, die für die Anmeldung bei der DB-Instance und für den Zugriff auf die Daten erforderlich sind. Das Verwerfen, Verändern, Umbenennen oder Verkürzen von Tabellen, Daten oder anderen Inhalten der `mysql`-Datenbank in der DB-Instance kann zu Fehlern führen und den Zugriff auf die DB-Instance und die Daten verhindern. In diesem Fall können Sie die DB-Instance mithilfe des AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)Befehls aus einem Snapshot wiederherstellen. Sie können die DB-Instance mit dem Befehl [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) wiederherstellen.
# Überlegungen zum Importieren von Daten für MariaDB
Der folgende Inhalt enthält technische Informationen zum Laden von Daten in MariaDB. Dieser Inhalt richtet sich an Benutzer, die mit der MariaDB-Serverarchitektur vertraut sind.
## Binärprotokollierung
Durch die Aktivierung der Binärprotokollierung wird die Leistung beim Laden von Daten reduziert und bis zu viermal mehr zusätzlicher Speicherplatz als bei deaktivierter Protokollierung benötigt. Die zum Laden der Daten verwendete Transaktionsgröße wirkt sich direkt auf die Systemleistung und den Speicherplatzbedarf aus. Größere Transaktionen erfordern mehr Ressourcen.
## Transaktionsgröße
Die Transaktionsgröße beeinflusst die folgenden Aspekte bei MariaDB-Datenladevorgängen:
+ Ressourcennutzung
+ Auslastung des Festplattenspeichers
+ Fortsetzen des Vorgangs
+ Zeit für die Wiederherstellung
+ Eingabeformat (Flatfiles oder SQL)
In diesem Abschnitt wird beschrieben, wie sich die Transaktionsgröße auf die binäre Protokollierung auswirkt, und verdeutlicht, welche Vorteile das Deaktivieren der binären Protokollierung bei umfangreichen Datenladevorgängen mit sich bringen kann. Die binäre Protokollierung kann durch die Festlegung des automatischen Aufbewahrungszeitraums für Backups in Amazon RDS aktiviert und deaktiviert werden. Nicht-Null-Werte aktivieren die binäre Protokollierung und Null deaktiviert diese. Weitere Informationen finden Sie unter [Aufbewahrungszeitraum für Backups](USER_WorkingWithAutomatedBackups.BackupRetention.md).
In diesem Abschnitt wird auch die Auswirkung von großen Transaktionen auf InnoDB beschrieben und warum es so wichtig ist, die Transaktionsgröße klein zu halten.
### Kleine Transaktionen
Bei kleinen Transaktionen sorgt die binäre Protokollierung für eine Verdopplung der Schreibvorgänge auf der Festplatte, die für das Laden der Daten erforderlich sind. Dieser Effekt kann die Leistung für andere Datenbanksitzungen signifikant herabsetzen und die zum Laden der Daten erforderliche Zeit erhöhen. Wie stark die Leistungseinbuße ist, hängt teilweise von folgenden Faktoren ab:
+ Upload-Rate
+ Andere Datenbankaktivitäten während des Ladevorgangs
+ Kapazität der Amazon-RDS-DB-Instance
Die binären Protokolle benötigen zudem fast genau soviel Speicherplatz wie die Datenladevorgänge, bis sie gesichert und entfernt wurden. Amazon RDS minimiert dies durch häufige Backup-Vorgänge und Löschen von Binärprotokollen.
### Große Transaktionen
Bei großen Transaktionen verdreifacht die binäre Protokollierung die IOPS (Ein-/Ausgabe pro Sekunde) und die Festplattennutzung aus den folgenden Gründen:
+ Der Binärprotokoll-Cache speichert Transaktionsdaten vorübergehend auf der Festplatte.
+ Dieser Cache wächst mit der Transaktionsgröße an, wodurch Speicherplatz belegt wird.
+ Wenn die Transaktion (Commit oder Rollback) abgeschlossen ist, wird der Cache vom System in das Binärprotokoll kopiert.
Bei diesem Vorgang werden drei Kopien von Daten erstellt:
+ Originaldaten
+ Cache auf der Festplatte
+ Letzter binärer Protokolleintrag
Jeder Schreibvorgang verursacht zusätzliche E/A-Vorgänge, was sich weiter auf die Leistung auswirkt.
Aus diesem Grund benötigt die binäre Protokollierung dreimal so viel Speicherplatz wie die deaktivierte Protokollierung. Wenn Sie beispielsweise 10 GiB Daten als eine einzelne Transaktion laden, werden drei Kopien erstellt:
+ 10 GiB für die Tabellendaten
+ 10 GiB für den Binärprotokoll-Cache
+ 10 GiB für die Binärprotokolldatei
Der gesamte benötigte temporäre Speicherplatz beträgt 30 GiB.
Wichtige Überlegungen zum Speicherplatz:
+ Die Cache-Datei wird so lange beibehalten, bis die Sitzung endet oder durch eine neue Transaktion ein weiterer Cache erstellt wird.
+ Das Binärprotokoll wird so lange beibehalten, bis es gesichert wurde, und kann über einen längeren Zeitraum möglicherweise 20 GiB (Cache und Protokoll) enthalten.
Wenn Sie `LOAD DATA LOCAL INFILE` zum Laden der Daten verwenden, wird bei der Datenwiederherstellung eine vierte Kopie für den Fall erstellt, dass die Datenbank aus einem vor dem Ladevorgang durchgeführten Backup wiederhergestellt werden muss. Während der Wiederherstellung extrahiert MariaDB die Daten aus dem Binärprotokoll in eine Flatfile. MariaDB führt dann `LOAD DATA LOCAL INFILE` aus. Basierend auf dem vorherigen Beispiel benötigt diese Wiederherstellung insgesamt einen temporären Speicherplatz von 40 GiB bzw. jeweils 10 GiB für Tabellen, Caches, Protokolle und lokale Dateien. Wenn nicht mindestens 40 GiB freier Speicherplatz zur Verfügung steht, schlägt die Wiederherstellung fehl.
### Optimieren von großen Datenladevorgängen
Deaktivieren Sie die Binärprotokollierung bei großen Datenladevorgängen, um den Aufwand und Speicherplatzbedarf zu reduzieren. Sie können die Binärprotokollierung deaktivieren, indem Sie den Aufbewahrungszeitraum für Backups auf Null festlegen. Setzen Sie den Wert für den Aufbewahrungszeitraum für Backups auf den entsprechenden Nicht-Null-Wert zurück, nachdem der Ladevorgang abgeschlossen wurde. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md) und [Aufbewahrungszeitraum für Backups](USER_ModifyInstance.Settings.md) in der Einstellungstabelle.
**Anmerkung**
Sie können den Aufbewahrungszeitraum für Backups nicht auf Null festlegen, wenn es sich bei der DB-Instance um eine Quell-DB-Instance für Lesereplikate handelt.
Vor dem Laden von Daten empfehlen wir Ihnen, einen DB-Snapshot zu erstellen. Weitere Informationen finden Sie unter [Verwalten manueller Backups](USER_ManagingManualBackups.md).
## InnoDB
Die folgenden Informationen zu der Undo-Protokollierung und den Wiederherstellungsoptionen helfen Ihnen dabei, InnoDB-Transaktionen klein zu halten, um die Datenbankleistung zu optimieren.
### Grundlagen zur Undo-Protokollierung in InnoDB
Undo ist ein Protokollierungsmechanismus, der die Rücksetzung von Transaktionen ermöglicht und MVCC (Multi-Version Concurrency Control, Parallelitätskontrolle für mehrere Versionen) unterstützt.
Bei MariaDB 10.11 und älteren Versionen werden Undo-Protokolle im InnoDB-System-Tablespace (normalerweise ibdata1) gespeichert und so lange beibehalten, bis sie vom Bereinigungs-Thread entfernt werden. Daher können große Datenladetransaktionen dazu führen, dass der System-Tablespace sehr groß wird und Speicherplatz belegt, der erst zurückgewonnen werden kann, wenn die Datenbank neu erstellt wird.
Bei allen MariaDB-Versionen muss der Bereinigungs-Thread auf das Löschen der Undo-Protokolle warten, bis die älteste aktive Transaktion entweder festgeschrieben oder zurückgesetzt wurde. Wenn die Datenbank während des Ladevorgangs andere Transaktionen verarbeitet, sammeln sich auch ihre Undo-Protokolle an, die nicht entfernt werden können, selbst wenn die Transaktionen festgeschrieben wurden und keine andere Transaktion die Undo-Protokolle für MVCC benötigt. In dieser Situation werden alle Transaktionen langsamer, auch schreibgeschützte Transaktionen. Diese Verlangsamung ist darauf zurückzuführen, dass alle Transaktionen auf alle Zeilen zugreifen, die von jeder Transaktion und nicht nur von der Ladetransaktion geändert werden. Tatsächlich müssen Transaktionen Undo-Protokolle durchsuchen, deren Löschung durch lang andauernde Ladetransaktionen während einer Bereinigung von Undo-Protokollen verhindert wurde. Dies beeinträchtigt die Leistung aller Vorgänge, die auf geänderte Zeilen zugreifen.
### Optionen zur Wiederherstellung von Transaktionen in InnoDB
Obwohl InnoDB Commit-Vorgänge optimiert, sind große Transaktions-Rollbacks langsam. Führen Sie für eine schnellere Wiederherstellung eine point-in-time Wiederherstellung durch oder stellen Sie einen DB-Snapshot wieder her. Weitere Informationen erhalten Sie unter [Point-in-time Erholung](USER_PIT.md) und [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md).
## Datenimportformate
MariaDB unterstützt zwei Datenimportformate: Flatfiles und SQL. Lesen Sie die Informationen zum jeweiligen Format, um die beste Option für Ihre Anforderungen zu ermitteln.
### Flache Dateien
Laden Sie Flatfiles für kleine Transaktionen mithilfe von `LOAD DATA LOCAL INFILE`. Dieses Datenimportformat bietet die folgenden Vorteile gegenüber der Verwendung von SQL:
+ Weniger Netzwerkverkehr
+ Niedrigere Datenübertragungskosten
+ Geringerer Aufwand für die Verarbeitung von Datenbanken
+ Schnellere Verarbeitung
`LOAD DATA LOCAL INFILE` lädt die gesamte Flatfile als eine Transaktion. Halten Sie die Größe der einzelnen Dateien klein, um die folgenden Vorteile zu erzielen:
+ **Fortgesetzte Leistungsfähigkeit**: Sie können nachverfolgen, welche Dateien geladen wurden. Wenn während des Ladevorgangs ein Problem auftritt, können Sie dort fortfahren, wo Sie aufgehört haben. Einige Daten müssen eventuell erneut an Amazon RDS übertragen werden. Bei kleinen Dateien ist die Menge der erneut zu übertragenden Daten allerdings minimal.
+ **Paralleles Laden der Daten**: Wenn Sie genügend IOPS und die erforderliche Netzwerkbandbreite für das Laden einer einzelnen Datei haben, können parallele Ladevorgänge Zeit sparen.
+ **Steuerung der Laderate**: Wenn sich der Datenladevorgang negativ auf andere Prozesse auswirkt, können Sie die Laderate steuern, indem Sie das Intervall zwischen den Dateien verlängern.
Große Transaktionen verringern die Vorteile, die sich aus der Verwendung von `LOAD DATA LOCAL INFILE` zum Importieren der Daten ergeben. Wenn Sie eine große Datenmenge nicht in kleinere Dateien aufteilen können, sollten Sie SQL verwenden.
### SQL
SQL hat einen Hauptvorteil gegenüber Flatfiles: Damit ist es einfach, Transaktionen klein zu halten. Jedoch kann ein Ladevorgang mit SQL deutlich länger dauern als mit Flatfiles. Außerdem kann es nach einem Fehler schwierig sein, zu ermitteln, wo der Ladevorgang fortgesetzt werden soll, da mariadb-dump-Dateien nicht neu gestartet werden können. Wenn während des Ladens einer mariadb-dump-Datei ein Fehler auftritt, müssen Sie die Datei ändern oder ersetzen, damit der Ladevorgang fortgesetzt werden kann. Alternativ können Sie auch nach dem Beheben der Fehlerursache eine Wiederherstellung auf einen Zeitpunkt vor dem Ladevorgang durchführen und die Datei erneut senden. Weitere Informationen finden Sie unter [Point-in-time Erholung](USER_PIT.md).
## Verwenden von Amazon-RDS-DB-Snapshots für Datenbankprüfpunkte
Wenn Sie Daten über lange Zeiträume, z. B Stunden oder Tage, ohne die Binärprotokollierung laden, verwenden Sie DB-Snapshots, um regelmäßige Prüfpunkte für die Datensicherheit bereitzustellen. Jeder DB-Snapshot erstellt eine konsistente Kopie Ihrer Datenbank-Instance, die bei Systemausfällen oder Datenbeschädigungen als Wiederherstellungspunkt dient. Da DB-Snapshots schnell erstellt werden, hat das Festlegen häufiger Prüfpunkte nur minimale Auswirkungen auf die Ladeleistung. Sie können vorherige DB-Snapshots löschen, ohne die Dauerhaftigkeit der Datenbank oder die Wiederherstellungsfunktionen zu beeinträchtigen. Weitere Informationen zu DB-Snapshots finden Sie unter [Verwalten manueller Backups](USER_ManagingManualBackups.md).
## Verkürzen der Ladezeit von Datenbanken
Im Folgenden sind zusätzliche Tipps zum Verringern der Ladezeit aufgeführt:
+ Erstellen Sie alle sekundären Indizes, bevor Sie Daten in MariaDB-Datenbanken laden. Im Gegensatz zu anderen Datenbanksystemen erstellt MariaDB die gesamte Tabelle neu, wenn sekundäre Indizes hinzugefügt oder geändert werden. Dieser Prozess erstellt eine neue Tabelle mit Indexänderungen, kopiert alle Daten und löscht die Originaltabelle.
+ Laden Sie Daten in der Reihenfolge der Primärschlüssel. Für InnoDB-Tabellen kann hierdurch die Ladezeit um 75 bis 80 % und die Datendateigröße um 50 % reduziert werden.
+ Deaktivieren Sie Fremdschlüsselbeschränkungen, indem Sie `foreign_key_checks` auf `0` festlegen. Dies ist häufig für Flatfiles erforderlich, die mit `LOAD DATA LOCAL INFILE` geladen werden. Durch Deaktivieren von Fremdschlüsselprüfungen werden jegliche Datenladevorgänge beschleunigt. Aktivieren Sie nach Abschluss des Ladevorgangs die Einschränkungen erneut, indem Sie `foreign_key_checks` auf `1` festlegen, und überprüfen Sie die Daten.
+ Laden Sie Daten parallel, es sei denn, Sie nähern sich einer Ressourcenbegrenzung. Verwenden Sie gegebenenfalls partitionierte Tabellen, um gleichzeitige Ladevorgänge über mehrere Tabellensegmente hinweg zu ermöglichen.
+ Um den Aufwand bei der SQL-Ausführung zu reduzieren, kombinieren Sie mehrere `INSERT`-Anweisungen in einzelne `INSERT`-Vorgänge mit mehreren Werten. `mariadb-dump`implementiert diese Optimierung automatisch.
+ Verringern Sie InnoDB-Protokoll-E/A-Vorgänge, indem Sie `innodb_flush_log_at_trx_commit` auf `0` festlegen. Setzen Sie `innodb_flush_log_at_trx_commit` nach Abschluss des Ladevorgangs wieder auf `1` zurück.
**Warnung**
Wenn `innodb_flush_log_at_trx_commit` auf `0` festgelegt wird, führt dies dazu, dass die Protokolle in InnoDB jede Sekunde anstatt bei jedem Commit bereinigt werden. Diese Einstellung erhöht zwar die Leistung, kann jedoch bei Systemausfällen zu Transaktionsverlusten führen.
+ Wenn Sie Daten in eine DB-Instance laden, in der keine Lesereplikate vorhanden sind, legen Sie `sync_binlog` auf `0` fest. Setzen Sie `sync_binlog parameter` nach Abschluss des Ladevorgangs wieder auf `1` zurück.
+ Laden Sie die Daten in eine Single-AZ-DB-Instance, bevor Sie die DB-Instance in eine Multi-AZ-Bereitstellung konvertieren. Wenn die DB-Instance bereits eine Multi-AZ-Bereitstellung verwendet, empfehlen wir Ihnen nicht, zwecks Laden von Daten zu einer Single-AZ-Bereitstellung zu wechseln. Dies führt nur zu geringfügigen Verbesserungen.
# Importieren von Daten aus einer externen MariaDB-Datenbank in eine DB-Instance von Amazon RDS für MariaDB
Sie können Daten aus einer vorhandenen MariaDB-Datenbank in eine DB-Instance von RDS für MariaDB importieren. Zu diesem Zweck kopieren Sie die Datenbank mit [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) oder [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) und importieren Sie sie direkt in die DB-Instance von RDS für MariaDB. Das Befehlszeilen-Dienstprogramm `mysqldump` oder `mariadb-dump` wird üblicherweise verwendet, um Backups zu erstellen und Daten von einem MariaDB-Server zu einem anderen zu übertragen. Dieses Dienstprogramm ist in der MariaDB-Clientsoftware enthalten.
Ab MariaDB 11.0.1 müssen Sie `mariadb-dump` anstelle von `mysqldump` verwenden.
Ein typischer `mysqldump`-Befehl für das Verschieben von Daten aus externen Datenbanken in eine Amazon-RDS-DB-Instance ähnelt dem folgenden Beispiel. Ersetzen Sie die Werte durch Ihre Angaben. Ersetzen Sie für MariaDB 11.0.1 und höhere Versionen `mysqldump` durch `mariadb-dump`.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**Wichtig**
Lassen Sie ein Leerzeichen zwischen der Option `-p` und dem eingegeben Passwort.
Geben Sie als bewährte Sicherheitsmethode andere Anmeldeinformationen als die in diesem Beispiel angegebenen Prompts an.
Stellen Sie sicher, dass Sie die folgenden Empfehlungen und Überlegungen kennen:
+ Schließen Sie die folgenden Schemas aus der Dump-Datei aus:
+ `sys`
+ `performance_schema`
+ `information_schema`
Die Dienstprogramme `mysqldump` und `mariadb-dump` schließen diese Schemas standardmäßig aus.
+ Wenn Sie Benutzer und Rechte migrieren müssen, sollten Sie in Erwägung ziehen, ein Tool zu verwenden, das die Data Control Language (DCL) generiert, um sie neu zu erstellen, z. B. das [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)Hilfsprogramm.
+ Um den Import durchzuführen, stellen Sie sicher, dass der Benutzer Zugriff auf die DB-Instance hat. Weitere Informationen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md).
Die folgenden Parameter werden verwendet:
+ `-u local_user` – für die Angabe eines Benutzernamens. Beim ersten Gebrauch dieses Parameters geben Sie den Namen eines Benutzerkontos in der lokalen MariaDB-Datenbank an, die durch den Parameter `--databases` identifiziert wird.
+ `--databases database_name`: für die Angabe des Namens der Datenbank in der lokalen MariaDB-Instance, die Sie in Amazon RDS importieren möchten.
+ `--single-transaction`: zur Sicherstellung, dass alle aus der lokalen Datenbank geladenen Daten mit einem einzelnen Zeitpunkt übereinstimmen Wenn andere Prozesse die Daten ändern, während diese von `mysqldump` oder `mariadb-dump` gelesen werden, kann durch die Verwendung dieses Parameters die Datenintegrität erhalten bleiben.
+ `--compress`: für die Reduzierung des Verbrauchs der Netzwerkbandbreite, indem Daten vor dem Sendevorgang aus der lokalen Datenbank an Amazon RDS komprimiert werden.
+ `--order-by-primary`: für die Reduzierung der Ladezeit durch Sortieren der Daten jeder Tabelle nach entsprechendem Primärschlüssel
+ `--routines`: Verwenden Sie diese Option, wenn Routinen wie gespeicherte Prozeduren oder Funktionen in der Datenbank vorhanden sind, die Sie kopieren. Legen Sie den Parameter auf `0` fest, wodurch die Routinen während des Importvorgangs ausgeschlossen werden. Erstellen Sie die Routinen dann später manuell in der Amazon-RDS-Datenbank neu.
+ `--triggers`: Verwenden Sie diese Option, wenn in der Datenbank, die Sie kopieren, Auslöser vorhanden sind. Legen Sie den Parameter auf `0` fest, wodurch die Auslöser während des Importvorgangs ausgeschlossen werden. Erstellen Sie die Auslöser dann später manuell in der Amazon-RDS-Datenbank neu.
+ `--events`: Verwenden Sie diese Option, wenn in der Datenbank, die Sie kopieren, Ereignisse vorhanden sind. Legen Sie den Parameter auf `0` fest, wodurch die Ereignisse während des Importvorgangs ausgeschlossen werden. Erstellen Sie die Ereignisse dann später manuell in der Amazon-RDS-Datenbank neu.
+ `-plocal_password` – für die Angabe eines Passworts. Beim ersten Gebrauch dieses Parameters geben Sie das Passwort für das Benutzerkonto an, das durch den ersten Parameter `-u` gekennzeichnet ist.
+ `-u RDS_user` – für die Angabe eines Benutzernamens. Beim zweiten Gebrauch dieses Parameters geben Sie den Namen eines Benutzerkontos in der Standarddatenbank für die MariaDB-DB-Instance an, die durch den Parameter `--host` gekennzeichnet ist.
+ `--port port_number` – für die Angabe des Ports für die MariaDB-DB-Instance. Standardmäßig ist dieser Wert auf 3306 festgelegt, außer Sie haben ihn beim Erstellen der DB-Instance geändert.
+ `--host host_name` – für die Angabe des Domain-Name-System(DNS)-Namens aus dem Endpunkt der Amazon-RDS-DB-Instance, zum Beispiel, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Sie finden den Endpunktwert in den DB-Instance-Details in der Amazon-RDS-Konsole.
+ `-pRDS_password` – für die Angabe eines Passworts. Beim zweiten Gebrauch dieses Parameters geben Sie den Namen eines Passworts einer lokalen MySQL- oder MariaDB-Datenbank an, die durch den zweiten Parameter `-u` bezeichnet wird.
Stellen Sie sicher, dass Sie alle gespeicherten Prozeduren, Auslöser, Funktionen oder Ereignisse manuell in Ihrer Amazon-RDS-Datenbank erstellen. Wenn sich eines dieser Objekte in der Datenbank befindet, die Sie kopieren, schließen Sie sie beim Ausführen von `mysqldump` oder `mariadb-dump` aus. Fügen Sie dazu die folgenden Parameter in den Befehl `mysqldump` oder `mariadb-dump` ein.
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**Beispiel**
Im folgenden Beispiel wird die Beispieldatenbank `world` im lokalen Host in eine DB-Instance von RDS für MariaDB kopiert. Ersetzen Sie die Werte durch Ihre Angaben.
Für Linux, macOS oder Unix:
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Für Windows:
Führen Sie den folgenden Befehl in einem Eingabeaufforderungsfenster aus, das per Rechtsklick auf **Eingabeaufforderung** im Windows-Menü und anschließender Auswahl von **Als Administrator ausführen** geöffnet wird. Ersetzen Sie die Werte durch Ihre Angaben.
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**Anmerkung**
Geben Sie als bewährte Sicherheitsmethode andere Anmeldeinformationen als die in diesem Beispiel angegebenen Prompts an.
# Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB mit reduzierter Ausfallzeit
In einigen Situationen müssen Sie möglicherweise Daten aus einer externen MariaDB-Datenbank importieren, die eine Live-Anwendung für eine DB-Instance von RDS für MariaDB unterstützt. Nutzen Sie das folgende Verfahren, um die Auswirkungen auf die Verfügbarkeit der Anwendung zu minimieren. Dieses Verfahren kann außerdem hilfreich sein, wenn Sie mit einer sehr großen Datenbank arbeiten. Mit diesem Verfahren können Sie die Importkosten senken, indem Sie die Datenmenge reduzieren, die über das Netzwerk an übertragen wird AWS.
Im Rahmen dieses Verfahrens übertragen Sie eine Kopie Ihrer Datenbankdaten an eine Amazon-EC2-Instance und importieren die Daten in eine neue Amazon-RDS-Datenbank. Anschließend verwenden Sie die Replikation, um die Amazon RDS-Datenbank up-to-date mit Ihrer externen Live-Instance zu verknüpfen, bevor Sie Ihre Anwendung auf die Amazon RDS-Datenbank umleiten. Wenn die externe Instance MariaDB 10.0.24 oder höher ist und die Zielinstanz RDS for MariaDB ist, konfigurieren Sie die MariaDB-Replikation basierend auf globalen Transaktions-Identifikatoren (). GTIDs Andernfalls konfigurieren Sie die Replikation basierend auf den Binärprotokollkoordinaten. Wir empfehlen die GTID-basierte Replikation, wenn Ihre externe Datenbank diese unterstützt, da diese Methode zuverlässiger ist. Weitere Informationen finden Sie unter [Global Transaction ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/) in der MariaDB-Dokumentation.
Im folgenden Diagramm ist der Import einer externen MariaDB-Datenbank in eine MariaDB-Datenbank auf Amazon RDS veranschaulicht.
![\[Workflow, der den Import einer externen MariaDB-Datenbank in eine MariaDB-Datenbank auf Amazon RDS darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_1.png)
## Aufgabe 1: Erstellen einer Kopie Ihrer bestehenden Datenbank
Der erste Schritt bei der Migration von großen Datenmengen in eine Datenbank von RDS für MariaDB mit minimaler Ausfallzeit besteht darin, eine Kopie der Quelldaten zu erstellen.
Das folgende Diagramm veranschaulicht die Erstellung eines Backups der MariaDB-Datenbank.
![\[Workflow, der das Erstellen eines Backups der MariaDB-Datenbank darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
Sie können das Dienstprogramm `mysqldump` oder `mariadb-dump` verwenden, um ein Datenbank-Backup im SQL-Format oder im separierten Textformat zu erstellen. [In MariaDB 10.5 heißt der Client mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/). Ab MariaDB 11.0.1 müssen Sie `mariadb-dump` anstelle von `mysqldump` verwenden. Es wird empfohlen, mit jedem Format in einer Nichtproduktionsumgebung einen Testlauf durchzuführen, um festzustellen, welche Methode die Ausführungsdauer von `mysqldump` oder `mariadb-dump` minimiert.
Wir empfehlen auch, dass Sie die Leistung von `mysqldump` oder `mariadb-dump` gegenüber den Vorteilen einer Verwendung von separiertem Textformat beim Laden abwägen. Ein Backup, das ein separiertes Textformat verwendet, erstellt eine tabulatorseparierte Textdatei für jede verworfene Tabelle. Um den Zeitaufwand für den Import Ihrer Datenbank zu reduzieren, können Sie diese Dateien mit dem Befehl `LOAD DATA LOCAL INFILE` parallel laden. Weitere Informationen finden Sie unter [Schritt 5: Laden der Daten](mariadb-importing-data-any-source.md#mariadb-importing-data-any-source-load-data) im Verfahren zum Importieren von Daten aus einer beliebigen Quelle.
Bevor Sie mit dem Backup-Vorgang beginnen, müssen Sie die Optionen für die Replikation in der nach Amazon RDS zu kopierenden MariaDB-Datenbank festlegen. Die Optionen für die Replikation schließen die Aktivierung der Binärprotokollierung und das Einstellen einer eindeutigen Server-ID mit ein. Das Einstellen dieser Optionen veranlasst den Server, mit der Protokollierung Ihrer Datenbanktransaktionen zu beginnen, und bereitet ihn darauf vor, später im Vorgang als Quellreplikationsinstance zu agieren.
Stellen Sie sicher, dass Sie die folgenden Empfehlungen und Überlegungen kennen:
+ Verwenden Sie die Option `--single-transaction` mit `mysqldump` oder `mariadb-dump`, da sie einen einheitlichen Zustand der Datenbank speichert. Um für eine gültige Dump-Datei zu sorgen, führen Sie beim Ausführen von `mysqldump` oder `mariadb-dump` keine DDL-Anweisungen (Data Definition Language) aus. Sie können ein Wartungsfenster für diese Abläufe planen.
+ Schließen Sie die folgenden Schemas aus der Dump-Datei aus:
+ `sys`
+ `performance_schema`
+ `information_schema`
Die Dienstprogramme `mysqldump` und `mariadb-dump` schließen diese Schemas standardmäßig aus.
+ Wenn Sie Benutzer und Rechte migrieren müssen, sollten Sie in Erwägung ziehen, ein Tool zu verwenden, das die Data Control Language (DCL) generiert, um sie neu zu erstellen, z. B. das Utility. [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)
### So stellen Sie Optionen für die Replikation ein:
1. Bearbeiten Sie die `my.cnf`-Datei. Diese Datei befindet sich normalerweise in `/etc`.
```
sudo vi /etc/my.cnf
```
Fügen Sie die Optionen `log_bin` und `server_id` zum Abschnitt `[mysqld]` hinzu. Die Option `log_bin` bietet eine Dateinamenkennung für Binärprotokolldateien. Die Option `server_id` stellt eine eindeutige Kennung für den Server für Quelle-Replica-Beziehungen bereit.
Im folgenden Beispiel ist der aktualisierte `[mariadb]`-Abschnitt einer `my.cnf`-Datei angegeben:
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
Weitere Informationen finden Sie unter [Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication) in der MariaDB-Dokumentation.
1. Aktivieren Sie `gtid_strict_mode` für die Replikation mit einem Multi-AZ-DB-Cluster. Weitere Informationen finden Sie unter [gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode) in der MariaDB-Dokumentation.
Eine Aktivierung von `gtid_strict_mode` ist für die Replikation mit einer DB-Instance nicht erforderlich.
1. Den Service `mariadb` neu starten.
```
sudo service mariadb restart
```
### So erstellen Sie eine Sicherungskopie für Ihre bestehende Datenbank:
1. Erstellen Sie ein Backup für Ihre Daten mithilfe des Dienstprogramms `mysqldump` oder `mariadb-dump`, indem Sie es im SQL-Format oder im separierten Textformat festlegen.
Verwenden Sie die Optionen `--order-by-primary` und `--single-transaction` für `mysqldump` und `mariadb-dump`, um die Leistung zu verbessern und die Datenintegrität zu sichern.
Verwenden Sie die Option `--all-databases` nicht mit `mysqldump` oder `mariadb-dump`, um die Einbindung der MySQL-Systemdatenbank im Backup zu vermeiden. Weitere Informationen finden Sie unter [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) in der MySQL-Dokumentation.
Verwenden Sie bei Bedarf `chmod`, um sicherzustellen, dass das Verzeichnis beschreibbar ist, in dem die Backup-Datei erstellt wird.
**Wichtig**
Führen Sie unter Windows die Eingabeaufforderung als Administrator aus.
+ Verwenden Sie den folgenden Befehl, um eine SQL-Ausgabe zu erstellen. Ersetzen Sie für MariaDB 10.11 und ältere Versionen `mariadb-dump` durch `mysqldump`.
Für Linux, macOS oder Unix:
```
sudo mariadb-dump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**Anmerkung**
Geben Sie als bewährte Sicherheitsmethode andere Anmeldeinformationen als die in diesem Beispiel angegebenen Prompts an.
Für Windows:
```
mariadb-dump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**Anmerkung**
Geben Sie als bewährte Sicherheitsmethode andere Anmeldeinformationen als die in diesem Beispiel angegebenen Prompts an.
+ Verwenden Sie den folgenden Befehl, um eine separierte Textausgabe zu erstellen. Ersetzen Sie für MariaDB 11.01 und höhere Versionen `mysqldump` durch `mariadb-dump`.
Für Linux, macOS oder Unix:
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Für Windows:
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**Anmerkung**
Geben Sie als bewährte Sicherheitsmethode andere Anmeldeinformationen als die in diesem Beispiel angegebenen Prompts an.
Stellen Sie sicher, dass Sie alle gespeicherten Prozeduren, Auslöser, Funktionen oder Ereignisse manuell in Ihrer Amazon-RDS-Datenbank erstellen. Wenn sich eines dieser Objekte in der Datenbank befindet, die Sie kopieren, schließen Sie sie beim Ausführen von `mysqldump` oder `mariadb-dump` aus. Fügen Sie dazu die folgenden Argumente in den Befehl `mysqldump` oder `mariadb-dump` ein:
`--routines=0`
`--triggers=0`
`--events=0`
Wenn Sie `mysqldump` ausführen und das separierte Textformat verwenden, wird ein `CHANGE MASTER TO`-Kommentar zurückgegeben. Dieser Kommentar beinhaltet den Namen und die Position der Hauptprotokolldatei. Wenn es sich bei der externen Instance um MariaDB 10.0.23 oder eine ältere Version handelt, notieren Sie die Werte für `MASTER_LOG_FILE` und `MASTER_LOG_POS`. Sie benötigen diese Werte beim Einrichten der Replikation.
Die folgende Ausgabe wird für MariaDB-Versionen zurückgegeben.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. Wenn die verwendete externe Instance MariaDB 10.0.24 oder höher ist, nutzen Sie die GTID-basierte Replikation. Führen Sie `SHOW MASTER STATUS` in der externen MariaDB-Instance aus, um den Namen und die Position der Binärprotokolldatei zu erhalten. Konvertieren Sie dann die Werte in GTID, indem Sie `BINLOG_GTID_POS` in der externen MariaDB-Instance ausführen.
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
Notieren Sie die zurückgegebene GTID. Sie benötigen sie für die Konfiguration der Replikation.
1. Komprimieren Sie die kopierten Daten, um die Menge der Netzwerkressourcen zu reduzieren, die benötigt werden, um Ihre Daten in eine Amazon-RDS-Datenbank zu kopieren. Notieren Sie sich die Größe der Backup-Datei. Diese Informationen benötigen Sie, um die Größe der zu erstellenden Amazon-EC2-Instance zu bestimmen. Wenn Sie fertig sind, komprimieren Sie die Sicherungsdatei mithilfe von GZIP oder Ihrem bevorzugten Komprimierungsprogramm.
+ Verwenden Sie den folgenden Befehl, um eine SQL-Ausgabe zu komprimieren:
```
gzip backup.sql
```
+ Verwenden Sie den folgenden Befehl, um eine separierte Textausgabe zu komprimieren:
```
tar -zcvf backup.tar.gz target_directory
```
## Aufgabe 2: Erstellen einer Amazon EC2-Instance und Kopieren der komprimierten Datenbank
Das Kopieren Ihrer komprimierten Datenbank-Sicherungsdatei in eine Amazon EC2-Instance verbraucht weniger Netzwerkressourcen als eine direkte Kopie von unkomprimierten Daten zwischen Datenbank-Instances. Sobald sich die Daten in Amazon EC2 befinden, können Sie diese von dort direkt in die MariaDB-Datenbank kopieren. Damit Sie Kosten für Netzwerkressourcen sparen können, muss sich Ihre Amazon EC2 EC2-Instance in derselben Konfiguration AWS-Region wie Ihre Amazon RDS-DB-Instance befinden. Wenn sich die Amazon EC2 EC2-Instance in derselben Datenbank AWS-Region wie Ihre Amazon RDS-Datenbank befindet, wird auch die Netzwerklatenz während des Imports reduziert.
Das folgende Diagramm veranschaulicht den Kopiervorgang des Datenbank-Backups in eine Amazon EC2-Instance.
![\[Workflow, der den Kopiervorgang des Datenbank-Backups in eine Amazon EC2-Instance darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_3.png)
### So erstellen Sie eine Amazon EC2-Instance und kopieren Ihre Daten:
1. Erstellen Sie in AWS-Region dem Bereich, in dem Sie die Amazon RDS-Datenbank erstellen möchten, eine Virtual Private Cloud (VPC), eine VPC-Sicherheitsgruppe und ein VPC-Subnetz. Stellen Sie sicher, dass die eingehenden Regeln für Ihre VPC-Sicherheitsgruppe IP-Adressen zulassen, die für eine Verbindung Ihrer Anwendung mit erforderlich sin AWS. Sie können einen IP-Adressbereich (z. B. `203.0.113.0/24`) oder eine andere VPC-Sicherheitsgruppe festlegen. Sie können die [Amazon VPC-Konsole](https://console.aws.amazon.com/vpc) verwenden VPCs, um Subnetze und Sicherheitsgruppen zu erstellen und zu verwalten. Weitere Informationen finden Sie unter [Erste Schritte mit Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) im *Amazon Virtual Private Cloud-Benutzerhandbuch*.
1. Öffnen Sie die [Amazon EC2 EC2-Konsole](https://console.aws.amazon.com/ec2) und wählen Sie die aus AWS-Region , die sowohl Ihre Amazon EC2 EC2-Instance als auch Ihre Amazon RDS-Datenbank enthalten soll. Starten Sie eine Amazon EC2-Instance unter Verwendung der VPC, dem Subnetz und der Sicherheitsgruppe, die Sie in Schritt 1 erstellt haben. Stellen Sie sicher, dass Sie einen Instance-Typ mit genügend Speicherplatz für Ihre unkomprimierte Datenbank-Sicherungsdatei ausgewählt haben. Weitere Informationen zu Amazon EC2-Instances finden Sie unter [Erste Schritte mit Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) im *Amazon Elastic Compute Cloud-Benutzerhandbuch*.
1. Wenn Sie sich von Ihrer Amazon-EC2-Instance mit Ihrer Amazon-RDS-Datenbank verbinden möchten, bearbeiten Sie Ihre VPC-Sicherheitsgruppe. Fügen Sie eine Regel für eingehenden Datenverkehr hinzu, in der die private IP-Adresse Ihrer EC2-Instance angegeben ist. Die private IP-Adresse finden Sie auf der Registerkarte **Details** im Bereich **Instance** des EC2-Konsolenfensters. Wählen Sie zuerst **Sicherheitsgruppen** im Navigationsbereich der EC2-Konsole und dann Ihre Sicherheitsgruppe aus und fügen Sie anschließend eine Regel für eingehenden Datenverkehr für MySQL oder Aurora hinzu, die die private IP-Adresse Ihrer EC2-Instance angibt, um Ihre VPC-Sicherheitsgruppe zu bearbeiten und eine Regel für eingehenden Datenverkehr hinzuzufügen. Weitere Informationen zum Hinzufügen einer Regel für eingehenden Datenverkehr zu einer VPC-Sicherheitsgruppe finden Sie unter [Sicherheitsgruppenregeln](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) im *Amazon Virtual Private Cloud-Benutzerhandbuch*.
1. Kopieren Sie Ihre komprimierte Datenbank-Sicherungsdatei aus Ihrem lokalen System in Ihre Amazon EC2-Instance. Verwenden Sie bei Bedarf `chmod`, um sicherzustellen, dass Sie Schreibrechte für das Zielverzeichnis der Amazon EC2-Instance besitzen. Sie können `scp` oder einen Secure-Shell(SSH)-Client verwenden, um die Datei zu kopieren. Nachfolgend finden Sie ein Beispiel für einen `scp`-Befehl:
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**Wichtig**
Vergewissern Sie sich beim Kopieren von sensiblen Daten, dass Sie ein sicheres Netzwerk-Übertragungsprotokoll verwenden.
1. Stellen Sie eine Verbindung mit der Amazon EC2-Instance her und installieren Sie die neusten Updates und MariaDB-Client-Tools mithilfe der folgenden Befehle:
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -y
```
Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) für Linux-Instances im *Amazon Elastic Compute Cloud-Benutzerhandbuch* und [MariaDB Connectors](https://mariadb.com/docs/connectors) in der MariaDB-Dokumentation.
1. Solange Sie mit Ihrer Amazon EC2-Instance verbunden sind, dekomprimieren Sie Ihre Datenbank-Sicherungsdatei. Die folgenden Befehle sind Beispiele.
+ Verwenden Sie den folgenden Befehl, um eine SQL-Ausgabe zu extrahieren:
```
gzip backup.sql.gz -d
```
+ Verwenden Sie den folgenden Befehl, um eine separierte Textausgabe zu extrahieren:
```
tar xzvf backup.tar.gz
```
## Aufgabe 3: Erstellen einer MariaDB-Datenbank und Importieren von Daten aus der Amazon EC2-Instance
Indem Sie eine RDS for MariaDB-DB-Instance in derselben Weise AWS-Region wie Ihre Amazon EC2-Instance erstellen, können Sie die Datenbank-Backup-Datei schneller als über das Internet aus Amazon EC2 importieren.
Das folgende Diagramm veranschaulicht den Importvorgang der Backup-Datei von einer Amazon EC2-Instance in eine MariaDB-Datenbank.
![\[Workflow, der den Importvorgang der Backup-Datei von der EC2-Instance in die MariaDB-Datenbank darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### Erstellen einer MariaDB-Datenbank und Importieren der Daten
1. Bestimmen Sie, welche DB-Instance-Klasse und wie viel Speicherplatz erforderlich sind, um den erwarteten Workload für diese Amazon-RDS-Datenbank unterstützen zu können. Bei diesem Vorgang sollten Sie auch entscheiden, wie viel Speicherplatz und Verarbeitungskapazität für Ihre Datenladevorgänge ausreichen. Entscheiden Sie auch, was für den Umgang mit dem Produktions-Workload erforderlich ist. Sie können diese Faktoren anhand der Größe und der Ressourcen der Quell-MariaDB-Datenbank einschätzen. Weitere Informationen finden Sie unter [](Concepts.DBInstanceClass.md).
1. Erstellen Sie eine DB-Instance in der AWS-Region , die Ihre Amazon EC2 EC2-Instance enthält. Folgen Sie den Anweisungen unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md) und verwenden Sie die folgenden Richtlinien:
+ Geben Sie eine DB-Engine-Version an, die mit Ihrer Quell-DB-Instance kompatibel ist.
+ Geben Sie dieselbe Virtual Private Cloud (VPC) und VPC-Sicherheitsgruppe an, die Sie auch für die Amazon-EC2-Instance ausgewählt haben. Durch diesen Ansatz wird sichergestellt, dass Ihre Amazon EC2-Instance und Ihre Amazon-RDS-Instance im Netzwerk gegenseitig füreinander sichtbar sind. Stellen Sie sicher, dass Ihre DB-Instance öffentlich zugänglich ist. Ihre DB-Instance muss öffentlich zugänglich sein, um eine Replikation für Ihre Quelldatenbank einzurichten, wie in einem späteren Abschnitt beschrieben wird.
+ Konfigurieren Sie nicht mehrere Availability Zones, Backup-Aufbewahrungen oder Lesereplikate, nachdem Sie das Datenbank-Backup importiert haben. Wenn dieser Importvorgang abgeschlossen ist, können Sie Multi-AZ und Backup-Aufbewahrung für die Produktions-Instance konfigurieren.
1. Überprüfen Sie die Optionen der Standardkonfiguration für die Amazon-RDS-Datenbank. Wenn in der Standardparametergruppe für die Datenbank die von Ihnen gewünschten Optionen nicht konfiguriert sind, wählen Sie eine andere aus, die die entsprechenden Konfigurationsoptionen enthält, oder erstellen Sie eine neue Parametergruppe. Weitere Informationen zum Erstellen einer Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
1. Stellen Sie als Hauptbenutzer eine Verbindung mit der neuen Amazon-RDS-Datenbank her. Erstellen Sie die Benutzer, die erforderlich sind, um die Administratoren, Anwendungen und Services zu unterstützen, die auf die DB-Instance zugreifen müssen. Der Hostname für die Amazon-RDS-Datenbank ist ihr **Endpunktwert** für diese DB-Instance ohne die Portnummer, z. B. `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Sie finden den Endpunktwert in den Datenbankdetails der Amazon-RDS-Konsole.
1. Stellen Sie eine Verbindung zu Ihrer Amazon-EC2-Instance her. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) für Linux-Instances im *Amazon Elastic Compute Cloud-Benutzerhandbuch*.
1. Stellen Sie als Remote-Host eine Verbindung mit Ihrer Amazon-RDS-Datenbank von Ihrer Amazon-EC2-Instance aus mithilfe des Befehls `mysql` her. Der folgende Befehl ist ein Beispiel:
```
mysql -h host_name -P 3306 -u db_master_user -p
```
Das *host\$1name* ist der Amazon RDS-Datenbank-Endpunkt.
1. Führen Sie an der Eingabeaufforderung `mysql` den Befehl `source` aus und tragen Sie den Namen der Datenbank-Dumpdatei ein. Mit diesem Befehl werden die Daten in die Amazon-RDS-DB-Instance geladen.
+ Verwenden Sie für das SQL-Format den folgenden Befehl:
```
MariaDB [(none)]> source backup.sql;
```
+ Für das separierte Textformat erstellen Sie zuerst die Datenbank, wenn es sich nicht um die Standarddatenbank handelt, die Sie bei der Einrichtung der Amazon-RDS-Datenbank erstellt haben.
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
Erstellen Sie anschließend die Tabellen.
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
Importieren Sie dann die Daten.
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
Zur Verbesserung der Leistung können Sie diese Operationen parallel aus mehreren Verbindungen ausführen, damit alle Ihre Tabellen erstellt und die Daten anschließend gleichzeitig geladen werden.
**Anmerkung**
Wenn Sie Optionen für eine Datenformatierung mit `mysqldump` oder `mariadb-dump` beim ersten Verwerfen der Tabelle verwendet haben, müssen Sie nun dieselben Optionen mit `LOAD DATA LOCAL INFILE` verwenden, um eine richtige Interpretation der Datendateiinhalte sicherzustellen.
1. Führen Sie eine einfache `SELECT`-Abfrage anhand einer oder zwei der Tabellen in der importierten Datenbank durch, um zu prüfen, ob der Importvorgang erfolgreich abgeschlossen wurde.
Wenn Sie die in diesem Verfahren verwendete Amazon EC2 EC2-Instance nicht mehr benötigen, beenden Sie die EC2-Instance, um Ihren AWS Ressourcenverbrauch zu reduzieren. Weitere Informationen zum Beenden einer EC2-Instance finden Sie unter [Beenden einer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) im *Amazon Elastic Compute Cloud-Benutzerhandbuch*.
## Aufgabe 4: Replizieren von Daten aus der externen Datenbank in die neue Amazon-RDS-Datenbank
Die Quelldatenbank wurde in der Zeit, in der die Daten in die MariaDB-Datenbank kopiert und übertragen wurden, wahrscheinlich aktualisiert. Sie können die Replikation verwenden, um die kopierte Datenbank up-to-date mit der Quelldatenbank zu verbinden.
![\[Workflow, der die Replikation von Daten aus der externen MariaDB-Datenbank in die Datenbank in Amazon RDS darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_5.png)
Die erforderlichen Berechtigungen für das Starten einer Replikation in einer Amazon-RDS-Datenbank sind beschränkt und für den Amazon-RDS-Hauptbenutzer nicht verfügbar. Verwenden Sie daher die entsprechende gespeicherte Amazon-RDS-Prozedur:
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) zum Konfigurieren der Replikation und [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) zum Starten der Replikation
### So starten Sie eine Replikation:
In Aufgabe 1 [haben Sie bei der Festlegung der Replikationsoptionen](#mariadb-importing-data-reduced-downtime-set-replication-options) die Binärprotokollierung aktiviert und eine eindeutige Server-ID für die Quelldatenbank festgelegt. Jetzt können Sie Ihre Amazon-RDS-Datenbank als Replikat mit Ihrer Live-Datenbank als Quellreplikations-Instance einrichten.
1. Fügen Sie in der Amazon-RDS-Konsole die IP-Adresse des Servers, der die Quelldatenbank hostet, zur VPC-Sicherheitsgruppe dieser Amazon-RDS-Datenbank hinzu. Weitere Informationen zum Konfigurieren einer VPC-Sicherheitsgruppe finden Sie unter [Konfigurieren von Sicherheitsgruppenregeln](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) im *Amazon Virtual Private Cloud-Benutzerhandbuch*.
Möglicherweise müssen Sie Ihr lokales Netzwerk so konfigurieren, dass es Verbindungen von der IP-Adresse Ihrer Amazon-RDS-Datenbank zulässt, damit es mit Ihrer Quell-Instance kommunizieren kann. Verwenden Sie den Befehl `host`, um die IP-Adresse der Amazon-RDS-Datenbank zu ermitteln.
```
host host_name
```
Das *host\$1name* ist zum Beispiel der DNS-Name vom Amazon RDS-Datenbank-Endpunkt`myinstance.123456789012.us-east-1.rds.amazonaws.com`. Sie finden den Endpunktwert in den DB-Instance-Details in der Amazon-RDS-Konsole.
1. Verbinden Sie sich mithilfe eines Clients Ihrer Wahl mit der Quell-Instance und erstellen Sie einen Benutzer, der für die Replikation verwendet werden soll. Dieses Konto wird ausschließlich für die Replikation verwendet und muss auf Ihre Domäne beschränkt sein, um die Sicherheit zu erhöhen. Der folgende Befehl ist ein Beispiel:
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen andere Anmeldeinformationen als hier angegeben an.
1. Erteilen Sie für die Quell-Instance die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE` für Ihren Replikationsbenutzer. Erteilen Sie beispielsweise die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE` in allen Datenbanken für den `repl_user`-Benutzer für Ihre Domäne, mit dem folgenden Befehl:
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Wenn Sie das SQL-Format zum Erstellen der Backup-Datei verwendet haben und auf der externen Instance nicht MariaDB 10.0.24 oder höher ausgeführt wird, schauen Sie sich den Inhalt dieser Datei an, indem Sie den folgenden Befehl ausführen:
```
cat backup.sql
```
Die Datei beinhaltet einen `CHANGE MASTER TO`-Kommentar, der den Namen und die Position der Hauptprotokolldatei beinhaltet. Dieser Kommentar ist in der Sicherungsdatei enthalten, wenn Sie die Option `--master-data` mit `mysqldump` verwenden. Beachten Sie die Werte für `MASTER_LOG_FILE` und `MASTER_LOG_POS`.
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
Wenn Sie ein separiertes Textformat zum Erstellen der Backup-Datei verwendet haben und auf der externen Instance nicht MariaDB 10.0.24 oder höher ausgeführt wird, sollten Sie bereits über Binärprotokollkoordinaten aus Schritt 1 in Aufgabe 1 verfügen, [in dem Sie eine Backup-Kopie Ihrer vorhandenen Datenbank erstellt haben](#mariadb-importing-data-reduced-downtime-create-backup).
Wenn auf der externen Instance MariaDB 10.0.24 oder höher ausgeführt wird, sollten Sie bereits über die GTID verfügen, von der aus Sie die Replikation in Schritt 2 in Aufgabe 1 begonnen haben, [in dem Sie eine Backup-Kopie Ihrer vorhandenen Datenbank erstellt haben](#mariadb-importing-data-reduced-downtime-create-backup).
1. Konfigurieren Sie die Amazon-RDS-Datenbank als Replikat. Wenn auf der externen Instance nicht MariaDB 10.0.24 oder höher ausgeführt wird, stellen Sie als Masterbenutzer eine Verbindung mit der Amazon-RDS-Datenbank her und identifizieren Sie die Quelldatenbank mithilfe der gespeicherten Prozedur [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) als Quellreplikations-Instance.
Wenn Sie über eine Backup-Datei im SQL-Format verfügen, verwenden Sie den Namen der Hauptprotokolldatei und die Position des Hauptprotokolls, die Sie beide in Schritt 4 ermittelt haben. Wenn Sie das separierte Textformat genutzt haben, verwenden Sie den Namen und die Position, die Sie beide beim Erstellen der Backup-Dateien ermittelt haben. Der folgende Befehl ist ein Beispiel:
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen andere Anmeldeinformationen als hier angegeben an.
Wenn auf der externen Instance MariaDB 10.0.24 oder höher ausgeführt wird, stellen Sie eine Verbindung mit der Amazon-RDS-Datenbank als Masterbenutzer her und identifizieren Sie die Quelldatenbank mithilfe der gespeicherten Prozedur [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) als Quellreplikations-Instance. Verwenden Sie die GTID, die Sie in Schritt 2 in Aufgabe 1 ermittelt haben, [in dem Sie eine Backup-Kopie Ihrer vorhandenen Datenbank erstellt haben](#mariadb-importing-data-reduced-downtime-create-backup). Der folgende Befehl ist ein Beispiel:
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
Die `source_server_ip_address` ist die IP-Adresse der Quellreplikationsinstance. Eine private DNS-Adresse für EC2 wird derzeit nicht unterstützt.
**Anmerkung**
Geben Sie aus Sicherheitsgründen andere Anmeldeinformationen als hier angegeben an.
1. Um die Replikation in der Amazon-RDS-Datenbank zu starten, führen Sie den folgenden Befehl aus, der die gespeicherte Prozedur [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) verwendet:
```
CALL mysql.rds_start_replication;
```
1. Um in der Amazon RDS-Datenbank zu ermitteln, wann sich das Replikat up-to-date bei der Quellreplikationsinstanz befindet, führen Sie den Befehl [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) aus. Zu den Ergebnissen des `SHOW REPLICA STATUS`-Befehls gehört das Feld `Seconds_Behind_Master`. Wenn das `Seconds_Behind_Master` Feld 0 zurückgibt, befindet sich das Replikat up-to-date bei der Quellreplikationsinstanz.
Bei einer DB-Instance von MariaDB 10.5, 10.6, 10.11, 11.4 oder 11.8 verwenden Sie die gespeicherte Prozedur [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md), anstatt den MySQL-Befehl auszuführen.
1. Nachdem die Amazon RDS-Datenbank eingerichtet wurde up-to-date, aktivieren Sie automatische Backups, damit Sie diese Datenbank bei Bedarf wiederherstellen können. Sie können automatische Backups für die Amazon-RDS-Datenbank mithilfe der [Amazon-RDS-Konsole](https://console.aws.amazon.com/rds/) aktivieren oder ändern. Weitere Informationen finden Sie unter [Einführung in Backups](USER_WorkingWithAutomatedBackups.md).
## Aufgabe 5: Weiterleiten der Live-Anwendung an die Amazon-RDS-Instance
Nachdem die MariaDB-Datenbank up-to-date mit der Quellreplikationsinstanz verbunden ist, können Sie jetzt Ihre Live-Anwendung aktualisieren, um die Amazon RDS-Instance zu verwenden.
![\[Workflow, der die Beendigung der Replikation und die Weiterleitung der Live-Anwendung an die Datenbank in Amazon RDS darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_6.png)
### So leiten Sie die Live-Anwendung an die MariaDB-Datenbank weiter und halten die Replikation an
1. Fügen Sie die IP-Adresse des Host-Servers der Anwendung hinzu, um die VPC-Sicherheitsgruppe für Ihre Amazon-RDS-Datenbank hinzuzufügen. Weitere Informationen zum Ändern einer VPC-Sicherheitsgruppe finden Sie unter [Konfigurieren von Sicherheitsgruppenregeln](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) im *Amazon Virtual Private Cloud-Benutzerhandbuch*.
1. Stellen Sie sicher, dass das `Seconds_Behind_Master` Feld in den Ergebnissen des Befehls [SHOW REPLICA STATUS den](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) Wert 0 hat, was bedeutet, dass sich das Replikat up-to-date bei der Quellreplikationsinstanz befindet.
```
SHOW REPLICA STATUS;
```
Bei einer DB-Instance von MariaDB 10.5, 10.6, 10.11, 11.4 oder 11.8 verwenden Sie die Prozedur [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md), anstatt den MySQL-Befehl auszuführen.
1. Schließen Sie alle Verbindungen zur Quelle, nachdem ihre Transaktionen abgeschlossen sind.
1. Aktualisieren Sie Ihre Anwendung, um die Amazon-RDS-Datenbank zu nutzen. Dieses Update ändert die Verbindungseinstellungen, um den Hostnamen und den Port der Amazon-RDS-Datenbank, das Benutzerkonto und Passwort für die Verbindung und die zu verwendende Datenbank zu bestimmen.
1. Stellen Sie eine Verbindung mit der DB-Instance her.
1. Halten Sie die Replikation für die Amazon-RDS-Instance an, indem Sie den folgenden Befehl ausführen, der die gespeicherte Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) verwendet:
```
CALL mysql.rds_stop_replication;
```
1. Setzen Sie die Replikationskonfiguration zurück, damit diese Instance nicht mehr als Replikat identifiziert wird, indem Sie den folgenden Befehl ausführen, der die gespeicherte Prozedur [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) in der Amazon-RDS-Datenbank verwendet:
```
CALL mysql.rds_reset_external_master;
```
1. Aktivieren Sie zusätzliche Amazon-RDS-Funktionen, wie Multi-AZ-Unterstützung und Lesereplikate. Weitere Informationen erhalten Sie unter [Konfigurieren und Verwalten einer Multi-AZ-Bereitstellung für Amazon RDS](Concepts.MultiAZ.md) und [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md).
# Importieren von Daten aus einer beliebigen Quelle zu einer DB-Instance von Amazon RDS für MariaDB
Mit Amazon RDS können Sie vorhandene MariaDB-Daten von einer beliebigen Quelle zu einer DB-Instance von RDS für MariaDB migrieren. Sie können Daten von lokalen Datenbanken, anderen Cloud-Anbietern oder vorhandenen DB-Instances von RDS für MariaDB auf Ihre Ziel-DB-Instance von RDS für MariaDB übertragen. Mit dieser Funktion können Sie Datenbanken konsolidieren, Lösungen für eine Notfallwiederherstellung implementieren oder von selbstverwalteten Datenbanken umsteigen. Zu den gängigen Szenarien gehören der Wechsel von selbst gehosteten MariaDB-Servern zu vollständig verwalteten Amazon-RDS-DB-Instances, die Konsolidierung mehrerer MariaDB-Datenbanken in eine einzige DB-Instance oder die Erstellung von Testumgebungen mit Produktionsdaten. Die folgenden Abschnitte enthalten step-by-step Anweisungen zum Importieren Ihrer MariaDB-Daten mithilfe von Methoden wie `mariadb-dump` Sicherungsdateien oder Replikation.
## Schritt 1: Erstellen von Flatfiles, die die zu ladenden Daten enthalten
Verwenden Sie ein gängiges Format, z. B. kommagetrennte Werte (CSV), um die zu ladenden Daten zu speichern. Jede Tabelle muss über eine eigene Datei verfügen. Sie können keine Daten für mehrere Tabellen in derselben Datei kombinieren. Geben Sie jeder Datei denselben Namen wie der zugehörigen Tabelle. Die Dateierweiterung können Sie benennen, wie Sie möchten. Wenn der Tabellenname beispielsweise `sales` lautet, kann der Dateiname `sales.csv` oder `sales.txt` lauten.
Ordnen Sie die Daten nach Primärschlüssel der ladenden Tabelle, sofern möglich. Dadurch werden die Ladezeiten drastisch verbessert und die Anforderungen an den Festplattenspeicher minimiert.
Die optimale Geschwindigkeit und Effizienz dieser Prozedur ist auf kleine Dateigrößen ausgelegt. Wenn die Größe einer einzelnen unkomprimierten Datei mehr als 1 GiB beträgt, teilen Sie diese in mehrere Dateien auf, die danach separat geladen werden können.
Verwenden Sie auf Unix-ähnlichen Systemen (einschließlich Linux) den `split`-Befehl. Der folgende Befehl teilt beispielsweise die Datei `sales.csv` in mehrere Dateien auf, die kleiner als 1 GiB sind. Die Teilung findet nur an Zeilenumbrüchen statt (-C 1024m). Die Namen der neuen Dateien enthalten numerische Suffixe in aufsteigender Reihenfolge. Mit dem folgenden Befehl werden beispielsweise Dateien mit Namen wie `sales.part_00` und `sales.part_01` erzeugt.
```
split -C 1024m -d sales.csv sales.part_
```
Ähnliche Hilfsprogramme sind auch für andere Betriebssysteme verfügbar.
Sie können die Flatfiles überall speichern. Wenn Sie die Daten in [Schritt 5](#mariadb-importing-data-any-source-load-data) laden, müssen Sie die `mysql`-Shell jedoch von demselben Speicherort aufrufen, an dem sich die Dateien befinden, oder beim Ausführen von `LOAD DATA LOCAL INFILE` den absoluten Pfad für die Dateien verwenden.
## Schritt 2: Verhindern des Zugriffs von Anwendungen auf die Ziel-DB-Instance
Unterbinden Sie vor dem Starten eines großen Ladevorgangs den Zugriff jeglicher Anwendungsaktivitäten auf die Ziel-DB-Instance, in die die Daten geladen werden sollen. Wir empfehlen dies insbesondere, wenn andere Sitzungen die zu ladenden Tabellen oder die in diesen Tabellen referenzierten Tabellen verändern. Dadurch wird die Gefahr von Verstößen gegen Einschränkungen während des Ladens reduziert und zugleich die Ausführungsgeschwindigkeit des Ladevorgangs erhöht. Zudem wird es möglich, die DB-Instance im Zustand unmittelbar vor dem Ladevorgang wiederherzustellen, ohne die Änderungen durch Prozesse zu verlieren, die nicht am Ladevorgang beteiligt sind.
Unter Umständen ist dies jedoch nicht möglich oder nicht praktikabel. Wenn Sie vor dem Ladevorgang den Zugriff von Anwendungen auf die DB-Instance nicht stoppen können, führen Sie die erforderlichen Schritte aus, um die Verfügbarkeit und Integrität der Daten sicherzustellen. Die jeweiligen erforderlichen Schritte können sich stark unterscheiden, je nachdem welche besonderen Verwendungsfälle der Standortanforderungen vorliegen.
## Schritt 3: Erstellen Sie einen DB-Snapshot
Wenn Sie Daten in eine neue DB-Instance laden wollen, die keine Daten enthält, können Sie diesen Schritt überspringen. Andernfalls empfehlen wir, dass Sie vor und nach dem Datenladevorgang DB-Snapshots für die Ziel-DB-Instance von Amazon RDS erstellen. Amazon-RDS-DB-Snapshots sind vollständige Backups der DB-Instance, die Sie für eine Wiederherstellung der DB-Instance auf einen bekannten Zustand verwenden können. Wenn Sie einen DB-Snapshot initiieren, werden die I/O Operationen an Ihrer DB-Instance vorübergehend unterbrochen, während Ihre Datenbank gesichert wird.
Wenn Sie einen DB-Snapshot unmittelbar vor dem Laden erstellen, können Sie die Datenbank bei Bedarf in ihrem Zustand vor dem Laden wiederherstellen. Ein DB-Snapshot, der sofort nach einem Ladevorgang erstellt wird, bewahrt Sie davor, die Daten bei einem Fehler erneut laden zu müssen. Sie können DB-Snapshots auch nach dem Laden verwenden, um Daten in die neuen Datenbank-Instances zu importieren.
Im folgenden Beispiel wird der AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html)Befehl ausgeführt, um einen DB-Snapshot der `AcmeRDS` Instance zu erstellen und dem DB-Snapshot die Kennung `"preload"` zuzuweisen.
Für Linux, macOS oder Unix:
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Für Windows:
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
Sie können auch die Wiederherstellung aus der DB-Snapshot-Funktionalität verwenden, um Test-DB-Instances für Testversuche zu erstellen, oder, um die Änderungen während eines Ladevorgangs rückgängig zu machen.
Bedenken Sie, dass die Wiederherstellung einer Datenbank aus einem DB-Snapshot eine neue DB-Instance erstellt, die wie alle DB-Instances über eine eindeutige Kennung und einen Endpunkt verfügt. Um die DB-Instance wiederherzustellen, ohne den Endpunkt zu ändern, löschen Sie zuerst die DB-Instance, damit Sie den Endpunkt wiederverwenden können.
Um beispielsweise eine DB-Instance für einen Testlauf oder andere Testzwecke zu erstellen, weisen Sie der DB-Instance eine eigene Kennung zu. Im Beispiel ist `AcmeRDS-2`" die Kennung. Das Beispiel stellt über den Endpunkt, der `AcmeRDS-2` zugeordnet ist, eine Verbindung mit der DB-Instance her. Weitere Informationen finden Sie unter [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html).
Für Linux, macOS oder Unix:
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Für Windows:
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
Um einen bestehenden Endpunkt erneut zu verwenden, löschen Sie zuerst die DB-Instance und weisen Sie dann der wiederhergestellten Datenbank dieselbe Kennung zu. Weitere Informationen finden Sie unter [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html).
Im folgenden Beispiel wird auch ein letzter DB-Snapshot der DB-Instance erstellt, bevor sie gelöscht wird. Dies ist zwar optional, wird aber empfohlen.
Für Linux, macOS oder Unix:
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Für Windows:
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## Schritt 4 (optional): Deaktivieren von automatischen Backups für Amazon RDS
**Warnung**
Schalten Sie automatische Backups nicht aus, wenn Sie eine Wiederherstellung durchführen müssen. point-in-time
Das Deaktivieren von automatischen Backups ist eine Leistungsoptimierung und ist für Datenladevorgänge nicht erforderlich. Durch das Deaktivieren von automatischen Backups werden alle vorhandenen Backups gelöscht. Daher ist eine point-in-time Wiederherstellung nicht möglich, nachdem Sie automatische Backups deaktiviert haben. Beachten Sie, dass manuelle DB-Snapshots nicht von der Deaktivierung automatischer Backups betroffen sind. Alle bestehenden manuellen DB-Snapshots bleiben für eine Wiederherstellung verfügbar.
Das Deaktivieren von automatischen Backups reduziert die Ladezeit um 25 % und verringert zugleich den während des Ladevorgangs erforderlichen Speicherplatz. Wenn Sie Daten in eine neue DB-Instance laden wollen, die keine Daten enthält, ist das Deaktivieren von Backups eine einfache Möglichkeit, die Übertragungsgeschwindigkeit zu erhöhen und zusätzlichen Speicherverbrauch zu vermeiden. In einigen Fällen können Sie jedoch in eine DB-Instance laden, die bereits Daten enthält. Wenn ja, sollten Sie die Vorteile der Deaktivierung von Backups gegen die Auswirkungen eines Verlusts der Leistungsfähigkeit abwägen point-in-time-recovery.
In DB-Instances ist die Funktion für automatische Backups standardmäßig aktiviert (mit einem Aufbewahrungszeitraum von 1 Tag). Setzen Sie den Wert des Aufbewahrungszeitraums für Backups auf 0, um automatische Backups zu deaktivieren. Nach dem Ladevorgang können Sie Backups erneut aktivieren, indem Sie den Aufbewahrungszeitraum für Backups auf einen Nicht-Null-Wert setzen. Um Backups zu aktivieren oder zu deaktivieren, fährt Amazon RDS die DB-Instance herunter und startet sie dann neu, um die Protokollierung in MariaDB zu aktivieren oder zu deaktivieren.
Führen Sie den AWS CLI `modify-db-instance` Befehl aus, um die Backup-Aufbewahrung auf Null zu setzen und die Änderung sofort zu übernehmen. Das Setzen des Aufbewahrungszeitraums für Backups auf Null erfordert den Neustart einer DB-Instance. Warten Sie daher bitte, bis der Neustart abgeschlossen wurde, bevor Sie fortfahren. Weitere Informationen finden Sie unter [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html).
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
Sie können den Status Ihrer DB-Instance mit dem AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)Befehl überprüfen. Das folgende Beispiel zeigt den DB-Instance-Status der DB-Instance `AcmeRDS`.
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
Wenn der Status der DB-Instance `available` ist, können Sie mit dem nächsten Schritt fortfahren.
## Schritt 5: Laden der Daten
Verwenden Sie die MariaDB-Anweisung `LOAD DATA LOCAL INFILE`, um Zeilen aus den Flatfiles in die Datenbanktabellen einzulesen.
**Anmerkung**
Sie müssen die `mariadb`-Shell von demselben Speicherort aufrufen, an dem sich die Flatfiles befinden, oder beim Ausführen von `LOAD DATA LOCAL INFILE` den absoluten Pfad für die Dateien verwenden.
Das folgende Beispiel zeigt, wie Daten aus der Datei `sales.txt` in die Tabelle `Sales` in der Datenbank geladen werden:
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
Weitere Informationen zur Anweisung `LOAD DATA` finden Sie unter [LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile) in der MariaDB-Dokumentation.
## Schritt 6: Reaktivieren von automatischen Backups für Amazon RDS
Wenn Sie die automatischen Backups für Amazon RDS in [Schritt 4](#mariadb-importing-data-any-source-turn-off-automated-backups) deaktiviert haben, aktivieren Sie sie nach Abschluss des Ladevorgangs erneut, indem Sie den Aufbewahrungszeitraum für Backups auf seinen ursprünglichen Wert vor dem Ladevorgang setzen. Wie bereits in Schritt 4 erwähnt, startet Amazon RDS die DB-Instance neu. Es kommt also zu einem kurzen Ausfall.
Im folgenden Beispiel wird der AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)Befehl ausgeführt, um automatische Backups für die `AcmeRDS` DB-Instance zu aktivieren und die Aufbewahrungsfrist auf einen Tag festzulegen:
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```
# Arbeiten mit der MariaDB-Replikation in Amazon RDS
Sie verwenden Lesereplikate üblicherweise, um die Replikation zwischen Amazon-RDS-DB-Instances zu konfigurieren. Allgemeine Informationen zu Lesereplikaten finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Spezifische Informationen zum Arbeiten mit Lesereplikaten unter Amazon RDS für MariaDB finden Sie unter [Arbeiten mit MariaDB Read Replicas](USER_MariaDB.Replication.ReadReplicas.md).
Sie können die Replikation auch basierend auf den Binärprotokollkoordinaten für eine MariaDB-Instance konfigurieren. Für MariaDB-Instances können Sie die Replikation auch auf der Grundlage der globalen Transaktion IDs (GTIDs) konfigurieren, was eine bessere Absturzsicherheit bietet. Weitere Informationen finden Sie unter [Konfigurieren der GTID-basierten Replikation einer externen Quell-Instance](MariaDB.Procedural.Replication.GTID.md).
Nachfolgend finden Sie weitere Replikationsoptionen, die mit RDS für MariaDB verfügbar sind:
+ Sie können eine Replikation zwischen einer RDS-for-MariaDB-DB-Instance und einer MySQL- oder MariaDB-Instance, die außerhalb von Amazon RDS ausgeführt wird, einrichten. Informationen zum Konfigurieren der Replikation mit einer externen Quelle finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.ReplMariaDB.md).
+ Sie können die Replikation zum Importieren von Datenbanken aus einer MySQL- oder MariaDB-Instance, die außerhalb von Amazon RDS ausgeführt wird, oder zum Exportieren von Datenbanken in solche Instances konfigurieren. Weitere Informationen erhalten Sie unter [Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB mit reduzierter Ausfallzeit](mariadb-importing-data-reduced-downtime.md) und [Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation](MySQL.Procedural.Exporting.NonRDSRepl.md).
Für jede dieser Replikationsoptionen können Sie die Replikation vom Typ „row-based“, „statement-based“ oder „mixed“ verwenden. Die Replikation vom Typ „row-based“ repliziert nur die geänderten Zeilen, die sich aus einer SQL-Anweisung ergeben. Die Replikation vom Typ „statement-based“ repliziert die gesamte SQL-Anweisung. Die Replikation vom Typ „mixed“ verwendet nach Möglichkeit Replikation vom Typ „statement-based“, wechselt aber auf Replikation vom Typ „row-based“, wenn SQL-Anweisungen ausgeführt werden, die bei der Replikation vom Typ „statement-based“ nicht sicher sind. In den meisten Fällen wird eine Replikation vom Typ „mixed“ empfohlen. Das binäre Protokollformat der DB-Instance bestimmt, ob die Replikation vom Typ „row-based“, „statement-based“ oder „mixed“ ist. Weitere Informationen zum Einrichten des binären Protokollformats finden Sie unter [Konfigurieren der Binärprotokollierung für MariaDB](USER_LogAccess.MariaDB.BinaryFormat.md).
Informationen zur Replikationskompatibilität zwischen MariaDB-Versionen finden Sie unter [Replication Compatibility](https://mariadb.com/kb/en/mariadb-vs-mysql-compatibility/#replication-compatibility) in der MariaDB-Dokumentation.
**Topics**
+ [Arbeiten mit MariaDB Read Replicas](USER_MariaDB.Replication.ReadReplicas.md)
+ [Konfigurieren der GTID-basierten Replikation einer externen Quell-Instance](MariaDB.Procedural.Replication.GTID.md)
+ [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.ReplMariaDB.md)
# Arbeiten mit MariaDB Read Replicas
Im Folgenden finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten in Amazon RDS für MariaDB. Allgemeine Informationen zu Lesereplikaten und Anleitungen zu ihrer Verwendung finden Sie in [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md).
+ [Konfigurieren von Replikationsfiltern mit MariaDB](USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.md)
+ [Konfigurieren der verzögerten Replikation mit MariaDB](USER_MariaDB.Replication.ReadReplicas.DelayReplication.md)
+ [Löschen von Lesereplikaten bei MariaDB](USER_MariaDB.Replication.ReadReplicas.Updates.md)
+ [Arbeiten mit Bereitstellungen von Multi-AZ-Lesereplikaten mit MariaDB](USER_MariaDB.Replication.ReadReplicas.MultiAZ.md)
+ [Verwendung von kaskadierenden Lesereplikaten mit RDS für MariaDB](USER_MariaDB.Replication.ReadReplicas.Cascading.md)
+ [Überwachung von MariaDB Read Replicas](USER_MariaDB.Replication.ReadReplicas.Monitor.md)
+ [Starten und Stoppen der Replikation mit MariaDB Read Replicas](USER_MariaDB.Replication.ReadReplicas.StartStop.md)
+ [Fehlerbehebung bei Problemen mit einer MariaDB Read Replica](USER_ReadRepl.Troubleshooting.MariaDB.md)
## Konfigurieren von Lesereplikaten mit MariaDB
Bevor eine MariaDB-DB-Instance als Replikationsquelle eingesetzt werden kann, müssen Sie automatische Backups für die Quell-DB-Instance aktivieren, indem Sie den Aufbewahrungszeitraum für Backups auf einen anderen Wert als 0 festlegen. Diese Erfordernis gilt auch für ein Lesereplikat, das die Quell-DB-Instance für ein anderes Lesereplikat ist.
Sie können bis zu 15 Lesereplikate von einer DB-Instance innerhalb derselben Region erstellen. Damit die Replikation effektiv durchgeführt werden kann, sollte jedes Lesereplikat über dieselbe Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance verfügen. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie auch die Lesereplikate.
RDS für MariaDB unterstützt kaskadierende Lesereplikate. Informationen zum Konfigurieren von kaskadierenden Lesereplikaten finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für MariaDB](USER_MariaDB.Replication.ReadReplicas.Cascading.md).
Sie können mehrere Erstellungs- und Löschaktionen für Lesereplikate gleichzeitig ausführen, die auf die gleiche Quell-DB-Instance verweisen. Halten Sie sich bei der Ausführung dieser Aktionen an die Grenze von 15 Lesereplikaten für jede Quell-Instance.
# Konfigurieren von Replikationsfiltern mit MariaDB
Sie können Replikationsfilter verwenden, um anzugeben, welche Datenbanken und Tabellen mit einem Lesereplikat repliziert werden. Replikationsfilter können Datenbanken und Tabellen in die Replikation einbeziehen oder sie von der Replikation ausschließen.
Im Folgenden finden Sie einige Anwendungsfälle für Replikationsfilter:
+ Reduzieren der Größe eines Lesereplikats. Mit Replikationsfiltern können Sie die Datenbanken und Tabellen ausschließen, die für das Lesereplikat nicht benötigt werden.
+ Ausschließen von Datenbanken und Tabellen von Lesereplikaten aus Sicherheitsgründen.
+ Replizieren verschiedener Datenbanken und Tabellen für spezifische Anwendungsfälle bei verschiedenen Lesereplikaten. Beispielsweise könnten Sie bestimmte Lesereplikate für Analysen oder Sharding verwenden.
+ Für eine DB-Instance mit Read Replicas in verschiedenen AWS-Regionen, um unterschiedliche Datenbanken oder Tabellen in verschiedenen AWS-Regionen zu replizieren.
**Anmerkung**
Sie können Replikationsfilter verwenden, um anzugeben, welche Datenbanken und Tabellen mit einer primären MariaDB-Instance repliziert werden, die als Replikat in einer eingehenden Replikationstopologie konfiguriert ist. Weitere Informationen zu dieser Konfiguration finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md).
**Topics**
+ [Einstellen der Parameter der Replikationsfilter bei RDS für MariaDB](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Configuring)
+ [Einschränkungen der Replikationsfilter bei RDS für MariaDB](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Limitations)
+ [Beispiele für Replikationsfilter bei RDS für MariaDB](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Examples)
+ [Anzeigen der Replikationsfilter für ein Lesereplikat](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Viewing)
## Einstellen der Parameter der Replikationsfilter bei RDS für MariaDB
Um Replikationsfilter zu konfigurieren, legen Sie die folgenden Filterparameter für die Replikation fest:
+ `replicate-do-db` – Repliziert Änderungen der angegebenen Datenbanken. Wenn Sie diesen Parameter für ein Lesereplikat festlegen, werden nur die im Parameter angegebenen Datenbanken repliziert.
+ `replicate-ignore-db` – Repliziert keine Änderungen der angegebenen Datenbanken. Wenn der Parameter `replicate-do-db` für ein Lesereplikat festgelegt ist, wird dieser Parameter nicht ausgewertet.
+ `replicate-do-table` – Repliziert Änderungen der angegebenen Tabellen. Wenn Sie diesen Parameter für ein Lesereplikat festlegen, werden nur die im Parameter angegebenen Tabellen repliziert. Wenn der Parameter `replicate-do-db` oder `replicate-ignore-db` festgelegt ist, muss die Datenbank, die die angegebenen Tabellen enthält, in die Replikation mit dem Lesereplikat einbezogen werden.
+ `replicate-ignore-table` – Repliziert keine Änderungen der angegebenen Tabellen. Wenn der Parameter `replicate-do-table` für ein Lesereplikat festgelegt ist, wird dieser Parameter nicht ausgewertet.
+ `replicate-wild-do-table` – Repliziert Tabellen basierend auf den angegebenen Namensmustern für Datenbanken und Tabellen. Die Platzhalterzeichen `%` und `_` werden unterstützt. Wenn der Parameter `replicate-do-db` oder `replicate-ignore-db` festgelegt ist, müssen Sie die Datenbank, welche die angegebenen Tabellen enthält, in die Replikation mit dem Lesereplikat einbeziehen.
+ `replicate-wild-ignore-table` – Repliziert keine Tabellen basierend auf den angegebenen Namensmustern für Datenbanken und Tabellen. Die Platzhalterzeichen `%` und `_` werden unterstützt. Wenn die Parameter `replicate-do-table` oder `replicate-wild-do-table` für ein Lesereplikat festgelegt sind, wird dieser Parameter nicht ausgewertet.
Die Parameter werden in der angegebenen Reihenfolge ausgewertet. Weitere Informationen darüber, wie diese Parameter funktionieren, finden Sie in der [Dokumentation für MariaDB](https://mariadb.com/kb/en/replication-filters/#replication-filters-for-replication-slaves).
Standardmäßig hat jeder dieser Parameter einen leeren Wert. Sie können diese Parameter auf jedem Lesereplikat verwenden, um Replikationsfilter festzulegen, zu ändern und zu löschen. Wenn Sie einen dieser Parameter festlegen, trennen Sie die einzelnen Filter durch ein Komma voneinander.
Sie können die Platzhalterzeichen `%` und `_` in den Parametern `replicate-wild-do-table` und `replicate-wild-ignore-table` verwenden. Der Platzhalter `%` entspricht einer beliebigen Anzahl von Zeichen, und der Platzhalter `_` entspricht nur einem Zeichen.
Das binäre Protokollierungsformat der Quell-DB-Instance ist wichtig für die Replikation, da es den Datensatz der Datenänderungen bestimmt. Die Einstellung des Parameters `binlog_format` bestimmt, ob die Replikation zeilenbasiert oder anweisungsbasiert ist. Weitere Informationen finden Sie unter [Konfigurieren der Binärprotokollierung für MariaDB](USER_LogAccess.MariaDB.BinaryFormat.md).
**Anmerkung**
Alle DDL-Anweisungen (Data Definition Language) werden unabhängig von der Einstellung `binlog_format` für die Quell-DB-Instance als Anweisungen repliziert.
## Einschränkungen der Replikationsfilter bei RDS für MariaDB
Folgende Einschränkungen gelten für Replikationsfilter bei RDS für MariaDB:
+ Jeder Filterparameter für die Replikation hat ein Limit von 2 000 Zeichen.
+ Kommas werden in Replikationsfiltern nicht unterstützt.
+ Die Optionen `binlog_do_db` und `binlog_ignore_db` von MariaDB für binäre Protokollfilter werden nicht unterstützt.
+ Die Replikationsfilterung unterstützt keine XA-Transaktionen.
Weitere Informationen finden Sie unter [Einschränkungen bei XA-Transaktionen](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) in der MySQL-Dokumentation.
+ Die Replikationsfilterung wird für RDS für MariaDB Version 10.2 nicht unterstützt.
## Beispiele für Replikationsfilter bei RDS für MariaDB
Um die Replikationsfilter für ein Lesereplikat zu konfigurieren, ändern Sie die Parameter der Replikationsfilter in der Parametergruppe, die dem Lesereplikat zugeordnet ist.
**Anmerkung**
Eine Standard-Parametergruppe kann nicht modifiziert werden. Erstellen Sie eine neue Parametergruppe und ordnen Sie diese der Lesereplika zu, wenn die Lesereplika eine Standardparametergruppe verwendet. Weitere Informationen zu DB-Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Sie können Parameter in einer Parametergruppe mithilfe von AWS-Managementkonsole, AWS CLI oder der RDS-API festlegen. Weitere Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Wenn Sie Parameter in einer Parametergruppe festlegen, verwenden alle DB-Instances, die der Parametergruppe zugeordnet sind, diese Parametereinstellungen. Wenn Sie Parameter der Replikationsfilter in einer Parametergruppe festlegen, stellen Sie sicher, dass die Parametergruppe nur Lesereplikaten zugeordnet ist. Lassen Sie die Parameter der Replikationsfilter für Quell-DB-Instances leer.
In den folgenden Beispielen werden die Parameter mithilfe von festgeleg AWS CLI. Diese Beispiele legen `ApplyMethod` auf `immediate` fest, sodass die Parameteränderungen unmittelbar nach Abschluss des CLI-Befehls erfolgen. Wenn Sie möchten, dass eine ausstehende Änderung nach dem Neustart des Lesereplikats angewendet wird, legen Sie `ApplyMethod` auf `pending-reboot` fest.
In den folgenden Beispielen werden Replikationsfilter festgelegt:
+ [Including databases in replication](#rep-filter-in-dbs-mariadb)
+ [Including tables in replication](#rep-filter-in-tables-mariadb)
+ [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mariadb)
+ [Escaping wildcard characters in names](#rep-filter-escape-wildcards-mariadb)
+ [Excluding databases from replication](#rep-filter-ex-dbs-mariadb)
+ [Excluding tables from replication](#rep-filter-ex-tables-mariadb)
+ [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mariadb)
**Example Einschließen von Datenbanken in die Replikation**
Das folgende Beispiel schließt die Datenbanken `mydb1` und `mydb2` in die Replikation ein. Wenn Sie `replicate-do-db` für ein Lesereplikat festlegen, werden nur die im Parameter angegebenen Datenbanken repliziert.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example Einschließen von Tabellen in die Replikation**
Das folgende Beispiel schließt die Tabellen `table1` und `table2` in der Datenbank `mydb1` in die Replikation ein.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example Einschließen von Tabellen in die Replikation mit Platzhalterzeichen**
Das folgende Beispiel schließt Tabellen mit Namen, die mit `orders` und `returns` beginnen, in Datenbank `mydb` in die Replikation ein.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
**Example Escape-Platzhalterzeichen in Namen**
Das folgende Beispiel zeigt, wie Sie das Escapezeichen `\` verwenden, um ein Platzhalterzeichen zu umgehen, das Teil eines Namens ist.
Angenommen, Sie haben mehrere Tabellennamen in der Datenbank `mydb1`, die mit `my_table` beginnen, und Sie möchten diese Tabellen in die Replikation einschließen. Die Tabellennamen enthalten einen Unterstrich, der auch ein Platzhalterzeichen darstellt, sodass in dem Beispiel Unterstriche in den Tabellennamen mit Escapezeichen versehen sind.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
**Example Ausschließen von Datenbanken von der Replikation**
Das folgende Beispiel schließt die Datenbanken `mydb1` und `mydb2` von der Replikation aus.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example Ausschließen von Tabellen von der Replikation**
Das folgende Beispiel schließt die Tabellen `table1` und `table2` in der Datenbank `mydb1` von der Replikation aus.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example Ausschließen von Tabellen von der Replikation mit Platzhalterzeichen**
Das folgende Beispiel schließt Tabellen mit Namen, die mit `orders` und `returns` beginnen, in Datenbank `mydb` von der Replikation aus.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
## Anzeigen der Replikationsfilter für ein Lesereplikat
Sie können die Replikationsfilter für ein Lesereplikat wie folgt anzeigen:
+ Überprüfen Sie die Einstellungen der Parameter der Replikationsfilter in der dem Lesereplikat zugeordneten Parametergruppe.
Detaillierte Anweisungen finden Sie unter [Anzeigen von Parameterwerten für eine DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
+ Stellen Sie in einem MariaDB-Client eine Verbindung zum Read-Replikat her und führen Sie die`SHOW REPLICA STATUS` Anweisung aus.
In der Ausgabe werden in den folgenden Feldern die Replikationsfilter für das Lesereplikat angezeigt:
+ `Replicate_Do_DB`
+ `Replicate_Ignore_DB`
+ `Replicate_Do_Table`
+ `Replicate_Ignore_Table`
+ `Replicate_Wild_Do_Table`
+ `Replicate_Wild_Ignore_Table`
Weitere Informationen zu diesen Feldern finden Sie unter [Überprüfen des Replikationsstatus](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) in der MySQL-Dokumentation.
**Anmerkung**
Frühere Versionen von MariaDB wurden`SHOW SLAVE STATUS` anstelle von verwendet`SHOW REPLICA STATUS`. Wenn Sie vor 10.5 eine MariaDB-Version verwenden, verwenden Si `SHOW SLAVE STATUS`.
# Konfigurieren der verzögerten Replikation mit MariaDB
Sie können die verzögerte Replikation als Strategie für die Notfallwiederherstellung einsetzen. Für die verzögerte Replikation geben Sie die Mindestanzahl von Sekunden an, um welche die Replikation von der Quelle in das Lesereplikat verzögert werden soll. Wenn es zu einem Notfall kommt, weil beispielsweise eine Tabelle versehentlich gelöscht wurde, können Sie das Problem mit den folgenden Schritten schnell beheben:
+ Beenden Sie die Replikation im Lesereplikat, bevor die Änderung, die den Notfall verursacht hat, an das Lesereplikat gesendet wird.
Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication), um die Replikation zu stoppen.
+ Stufen Sie das Lesereplikat zur neuen Quell-DB-Instance hoch, indem Sie der Anleitung unter folge [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
**Anmerkung**
Die verzögerte Replikation wird für MariaDB 10.6 und höher unterstützt.
Verwenden Sie gespeicherte Prozeduren, um die verzögerte Replikation zu konfigurieren. Sie können die verzögerte Replikation nicht mit der AWS-Managementkonsole, der AWS CLI oder der Amazon-RDS-API konfigurieren.
Sie können die Replikation basierend auf globalen Transaktionskennungen (GTIDs) in einer verzögerten Replikationskonfiguration verwenden.
**Topics**
+ [Konfigurieren der verzögerten Replikation während der Erstellung von Read Replicas](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ReplicaCreation)
+ [Ändern der verzögerten Replikation einer vorhandenen Read Replica](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ExistingReplica)
+ [Hochstufen eines Lesereplikats](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.Promote)
## Konfigurieren der verzögerten Replikation während der Erstellung von Read Replicas
Um die verzögerte Replikation für zukünftig aus einer DB-Instance erstellte Lesereplikate zu konfigurieren, führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) mit dem Parameter `target delay` aus.
**Konfigurieren Sie die verzögerte Replikation während der Lesereplikat-Erstellung wie folgt:**
1. Stellen Sie als Master-Benutzer mit einem MariaDB-Client eine Verbindung zu der MariaDB-DB-Instance her, die als Quelle für Lesereplikate verwendet werden soll.
1. Führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) mit dem Parameter `target delay` aus.
Führen Sie beispielsweise die folgende gespeicherte Prozedur aus, um anzugeben, dass die Replikation um mindestens eine Stunde (3.600 Sekunden) für jedes Lesereplikat verzögert werden soll, das aus der aktuellen DB-Instance erstellt wird.
```
call mysql.rds_set_configuration('target delay', 3600);
```
**Anmerkung**
Nach dem Ausführen dieser gespeicherten Prozedur wird jedes Lesereplikat, das Sie mit der AWS CLI oder der Amazon-RDS-API erstellen, mit einer um die angegebene Anzahl Sekunden verzögerten Replikation konfiguriert.
## Ändern der verzögerten Replikation einer vorhandenen Read Replica
Führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) aus, um die verzögerte Replikation eines vorhandenen Lesereplikats zu ändern.
**Ändern Sie die verzögerte Replikation eines existierenden Lesereplikats wie folgt:**
1. Verwenden Sie einen MariaDB-Client, um als Master-Benutzer eine Verbindung zum Lesereplikat herzustellen.
1. Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication), um die Replikation zu stoppen.
1. Führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) aus.
Führen Sie beispielsweise die folgende gespeicherte Prozedur aus, um anzugeben, dass die Replikation für das Lesereplikat um mindestens eine Stunde (3600 Sekunden) verzögert werden soll.
```
call mysql.rds_set_source_delay(3600);
```
1. Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication), um die Replikation zu starten.
## Hochstufen eines Lesereplikats
Nachdem die Replikation gestoppt wurde, können Sie in einem Szenario der Notfallwiederherstellung ein Lesereplikat zur neuen Quell-DB-Instance hochstufen. Weitere Informationen zum Hochstufen eines Lesereplikats finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
# Löschen von Lesereplikaten bei MariaDB
Lesereplikate wurden zur Unterstützung von Leseabfragen entwickelt. Jedoch könnten gelegentliche Updates notwendig sein. Sie könnten beispielsweise einen Index hinzufügen, um die spezifischen Abfragetypen beim Zugriff auf das Replica zu beschleunigen. Sie können Updates aktivieren, indem Sie den Parameter `read_only` in der DB-Parametergruppe für das Lesereplikat auf **0** setzen.
# Arbeiten mit Bereitstellungen von Multi-AZ-Lesereplikaten mit MariaDB
Sie können ein Lesereplikat aus Single-AZ- oder Multi-AZ-DB-Instance-Bereitstellungen erstellen. Sie können Multi-AZ-Bereitstellungen verwenden, um die Haltbarkeit und Verfügbarkeit kritischer Daten zu verbessern, aber Sie können Multi-AZ nicht zweitranging noch für schreibgeschützte Abfragen verwenden. Stattdessen können Sie Lesereplikate aus Multi-AZ-DB-Instances mit hohem Datenverkehr erstellen, um schreibgeschützte Abfragen auslagern zu können. Wenn die Quell-Instance einer Multi-AZ-Bereitstellung ein Failover zur sekundären Instance durchführt, werden alle zugehörigen Lesereplikate automatisch auf die Verwendung der sekundären (jetzt primären) Instance als Replikationsquelle umgeschaltet. Weitere Informationen finden Sie unter [Konfigurieren und Verwalten einer Multi-AZ-Bereitstellung für Amazon RDS](Concepts.MultiAZ.md).
Sie können ein Lesereplikat als Multi-AZ-DB-Instance erstellen. Amazon RDS erstellt eine Standby-Version des Replikats in einer anderen Availability Zone, um ein Failover für das Replikat zu unterstützen. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.
# Verwendung von kaskadierenden Lesereplikaten mit RDS für MariaDB
RDS für MariaDB unterstützt kaskadierende Lesereplikate. Mit *kaskadierenden Lesereplikaten* können Sie Lesevorgänge skalieren, ohne dass Sie zusätzlichen Overhead für Ihre Quell-DB-Instance von RDS für MariaDB verursachen.
Bei kaskadierenden Lesereplikaten sendet Ihre DB-Instance von RDS für MariaDB Daten an das erste Lesereplikat in der Kette. Dieses Lesereplikat sendet dann Daten an das zweite Replikat in der Kette usw. Das Endergebnis ist, dass alle Lesereplikate in der Kette die Änderungen von der DB-Instance von RDS für MariaDB aufweisen, jedoch ohne Overhead ausschließlich auf der Quell-DB-Instance zu verursachen.
Sie können eine Reihe von bis zu drei Lesereplikaten in einer Kette von einer Quell-DB-Instance von RDS für MariaDB erstellen. Angenommen, Sie haben eine DB-Instance von RDS für MariaDB, `mariadb-main`. Sie haben die folgenden Möglichkeiten:
+ Beginnend mit `mariadb-main` erstellen Sie das erste Lesereplikat in der Kette `read-replica-1`.
+ Als Nächstes erstellen Sie ab `read-replica-1` das nächste Lesereplikat in der Kette `read-replica-2`.
+ Schließlich erstellen Sie ab `read-replica-2` das nächste Lesereplikat in der Kette `read-replica-3`.
Sie können kein weiteres Lesereplikat über dieses dritte kaskadierende Lesereplikat hinaus in der Reihe für `mariadb-main` erstellen. Eine vollständige Reihe von Instances aus einer Quell-DB-Instance von RDS für MariaDB bis zum Ende einer Reihe kaskadierender Lesereplikate kann aus höchstens vier DB-Instances bestehen.
Damit die Kaskadierung von Lesereplikaten funktioniert, müssen automatische Backups für jede Quell-DB-Instance von RDS für MariaDB aktiviert sein. Erstellen Sie zuerst das Lesereplikat und ändern Sie es dann, um automatische Backups für das Lesereplikat für zu aktivieren. Weitere Informationen finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md).
Wie bei jedem Lesereplikat können Sie ein Lesereplikat, das Teil einer Kaskade ist, hochstufen. Wenn Sie ein Lesereplikat aus einer Kette von Lesereplikaten hochstufen, wird dieses Replikat aus der Kette entfernt. Angenommen, Sie möchten einen Teil der Workload von Ihrer `mariadb-main`-DB-Instance zu einer neuen Instance verschieben, die nur von der Buchhaltung verwendet wird. Ausgehend von der Kette von drei Lesereplikaten aus dem Beispiel entscheiden Sie sich, `read-replica-2` hochzustufen. Die Kette ist wie folgt betroffen:
+ Durch Hochstufen von `read-replica-2` wird es aus der Replikationskette entfernt.
+ Es ist jetzt eine vollständige DB-Instance mit Lese-/Schreibzugriff.
+ Die Replizierung auf `read-replica-3` wird fortgesetzt wie vor der Hochstufung.
+ Ihre `mariadb-main` setzt die Replizierung auf `read-replica-1` fort.
Weitere Informationen über das Hochstufen von Lesereplikaten finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
# Überwachung von MariaDB Read Replicas
Für MariaDB-Lesereplikate können Sie die Replikationsverzögerung in Amazon CloudWatch überwachen, indem Sie die Amazon-RDS-Metrik `ReplicaLag` anzeigen. Die Kennzahl `ReplicaLag` meldet den Wert des Feldes `Seconds_Behind_Master` des Befehls `SHOW REPLICA STATUS`.
**Anmerkung**
Frühere Versionen von MariaDB wurden`SHOW SLAVE STATUS` anstelle von verwendet`SHOW REPLICA STATUS`. Wenn Sie vor 10.5 eine MariaDB-Version verwenden, verwenden Si `SHOW SLAVE STATUS`.
Häufige Ursachen für Replikationsverzögerung in MariaDB:
+ Ein Netzwerkausfall.
+ Schreibvorgänge auf Tabellen mit Indizes auf einem Lesereplikat. Wenn der Parameter `read_only` im Lesereplikat nicht auf 0 gesetzt ist, kann es die Replikation unterbrechen.
+ Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Die Replikation wird nur für die InnoDB-Speicher-Engine für MariaDB unterstützt.
Wenn die Metrik `ReplicaLag` 0 erreicht, hat das Replica den Stand der Quell-DB-Instance erreicht. Wenn die Metrik `ReplicaLag` -1 zurückgibt, ist die Replikation aktuell nicht aktiv. `ReplicaLag` = -1 ist gleich `Seconds_Behind_Master` = `NULL`.
# Starten und Stoppen der Replikation mit MariaDB Read Replicas
Sie können den Replikationsvorgang für eine Amazon-RDS-DB-Instance anhalten oder neustarten, indem Sie die gespeicherten Systemprozeduren [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) und [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) aufrufen. Dies können Sie tun, wenn Sie eine Replikation zwischen Amazon-RDS-Instances für langandauernde Operationen, wie dem Erstellen von großen Indexen, durchführen. Sie müssen Replikation auch anhalten und starten, wenn Sie Datenbanken importieren oder exportieren. Weitere Informationen erhalten Sie unter [Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB mit reduzierter Ausfallzeit](mariadb-importing-data-reduced-downtime.md) und [Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation](MySQL.Procedural.Exporting.NonRDSRepl.md).
Wenn eine Replikation für mehr als 30 aufeinanderfolgende Tage manuell oder aufgrund eines Replikationsfehlers gestoppt wird, beendet Amazon RDS die Replikation zwischen der Quell-DB-Instance und allen Lesereplikaten. um erhöhten Speicheranforderungen in der Quell-DB-Instance vorzubeugen und lange Failover-Zeiten zu vermeiden. Die Lesereplikat-DB-Instance ist weiterhin verfügbar. Die Replikation kann jedoch nicht fortgesetzt werden, da die vom Lesereplikat benötigten Binärprotokolle aus der Quell-DB-Instance nach Beendigung der Replikation gelöscht wurden. Sie können ein neues Lesereplikat für die Quell-DB-Instance erstellen, um die Replikation erneut aufzunehmen.
# Fehlerbehebung bei Problemen mit einer MariaDB Read Replica
Die Replikationstechnologien für MariaDB arbeiten asynchron. Da sie asynchron sind, steigt gelegentlich `BinLogDiskUsage` in der Quell-DB-Instance an und `ReplicaLag` ist im Lesereplikat zu erwarten. Beispielsweise kann auf der Quell-DB-Instance eine große Anzahl von Schreibvorgängen gleichzeitig ausgeführt werden. Dagegen werden Schreibvorgänge zum Lesereplikat über einen einzigen I/O-Thread seriell abgearbeitet. Dies kann zu einer Verzögerung zwischen der Quell-DB-Instance und dem Lesereplikat führen. Weitere Informationen über schreibgeschützte Replikate in der MariaDB-Dokumentation finden Sie unter [Replikation - Übersicht](http://mariadb.com/kb/en/mariadb/replication-overview/).
Sie können folgende Dinge tun, um die Verzögerungszeit zwischen Aktualisierungen einer Quell-DB-Instance und der nachfolgenden Aktualisierung des Lesereplikats zu reduzieren:
+ Passen Sie die Speichergröße und die DB-Instance-Klasse eines Lesereplikats an die der Quell-DB-Instance an.
+ Stellen Sie sicher, dass Parametereinstellungen in den DB-Parametergruppen, die von der Quell-DB-Instance und den Lesereplikaten verwendet werden, kompatibel sind. Weitere Informationen und ein Beispiel finden Sie in der Beschreibung des `max_allowed_packet`-Parameters weiter unten in diesem Abschnitt.
Amazon RDS überwacht den Replikationsstatus Ihrer Lesereplikate und setzt den `Replication State` der Lesereplikat-Instance auf `Error`, wenn die Replikation aus irgendeinem Grund beendet wird. Ein Beispiel wären auf Ihrem Lesereplikat ausgeführte DML-Abfragen, die mit den Aktualisierungen auf der Quell-DB-Instance in Konflikt treten.
Sie können die Details des von der MariaDB-Engine zurückgegebenen Fehlers im Feld `Replication Error` überprüfen. Ereignisse, die den Status des Lesereplikats angeben, werden ebenfalls generiert, einschließlich [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) und [RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047). Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md). Wenn eine MariaDB-Fehlermeldung zurückgegeben wird, überprüfen Sie den Fehler in der [MariaDB error message documentation](http://mariadb.com/kb/en/mariadb/mariadb-error-codes/).
Ein häufiges Problem, das Replikationsfehler verursachen kann, besteht, wenn der Wert für den `max_allowed_packet`-Parameter eines Lesereplikats niedriger ist als der Wert für den `max_allowed_packet`-Parameter der Quell-DB-Instance. Der `max_allowed_packet`-Parameter ist ein benutzerdefinierter Parameter, den Sie in einer DB-Parametergruppe festlegen können, mit der die maximale Größe des auf der Datenbank ausführbaren DML-Codes angegeben wird. In einigen Fällen ist der Parameterwert `max_allowed_packet` in der mit einer Quell-DB-Instance verknüpften DB-Parametergruppe kleiner als der Parameterwert `max_allowed_packet` in der mit dem Lesereplikat der Quelle verknüpften DB-Parametergruppe. In diesen Fällen kann der Replikationsvorgang einen Fehler zurückgeben (Paket größer als "max\$1allowed\$1packet" Bytes) und die Replikation anhalten. 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.
Weitere Situationen, bei denen Replikationsfehler auftreten können, sind die Folgenden:
+ 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 dem Lesereplikat in Tabellen schreiben, kann die Replikation unterbrochen werden.
+ Bei Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM, erfordern Lesereplikate eine transaktionale Speicher-Engine. Die Replikation wird nur für die InnoDB-Speicher-Engine für MariaDB unterstützt.
+ Verwenden von nicht-deterministischen Abfragen wie `SYSDATE()`. Weitere Informationen finden Sie unter [Erkennen sicherer und nicht sicherer Anweisungen in der binären Protokollierung](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html).
Wenn Sie entscheiden, dass Sie einen Fehler problemlos überspringen können, folgen Sie den Schritten in [Überspringen des aktuellen Replikationsfehlers für RDS für MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Andernfalls können Sie das Lesereplikat löschen und eine Instance mit derselben DB-Instance-Kennung erstellen, sodass der Endpunkt mit dem alten Lesereplikat übereinstimmt. Wird ein Replikationsfehler behoben, ändert sich das Feld `Replication State` zu *Replicating*.
Bei MariaDB-DB-Instances kann in manchen Fällen nicht auf sekundäre Lesereplikate umgestellt werden, wenn während des Fehlers nicht alle Binärprotokollereignisse (binlog) bereinigt wurden. In diesen Fällen müssen Sie die Lesereplikate manuell löschen und neu erstellen. Sie können das Risiko minimieren, indem Sie die folgenden Parameterwerte einstellen: `sync_binlog=1` und `innodb_flush_log_at_trx_commit=1`. Diese Einstellungen könnten die Leistung reduzieren, daher ist es ratsam, sie vor der Implementierung in einer Produktionsumgebung ausgiebig zu testen.
# Konfigurieren der GTID-basierten Replikation einer externen Quell-Instance
Sie können die Replikation basierend auf globalen Transaktions-Identifikatoren (GTIDs) von einer externen MariaDB-Instance der Version 10.0.24 oder höher in eine RDS for MariaDB-DB-Instance einrichten. Befolgen Sie diese Richtlinien, wenn Sie eine externe Quellinstance und ein Replikat auf Amazon RDS einrichten:
+ Überwachen Sie Failover-Ereignisse für die RDS-for-MariaDB-DB-Instance, die Ihr Replikat ist. Tritt ein Failover auf, kann die DB-Instance, die Ihr Replikat ist, auf einem neuen Host mit einer anderen Netzwerkadresse wiederhergestellt werden. Weitere Informationen zum Überwachen von Failover-Ereignissen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
+ Behalten Sie die Binärprotokolle auf Ihrer Quell-Instance, bis sichergestellt ist, dass sie auf das Replikat angewendet wurden. Durch das Aufbewahren können Sie sicherstellen, dass Sie Ihre Quell-Instance im Fall eines Ausfalls wiederherstellen können.
+ Schalten Sie automatische Backups in Ihrer MariaDB-DB-Instance auf Amazon RDS ein. Das Einschalten automatischer Backups stellt sicher, dass Sie Ihr Replikat zu einem bestimmten Zeitpunkt wiederherstellen können, wenn Sie den Master und das Replikat neu synchronisieren müssen. Informationen zu Backups und Restore finden Sie unter. Point-In-Time [Sichern, Wiederherstellen und Exportieren von Daten](CHAP_CommonTasks.BackupRestore.md)
**Anmerkung**
Die erforderlichen Berechtigungen für das Starten einer Replikation in einer MariaDB-DB-instance sind beschränkt und für die Amazon-RDS-Hauptbenutzer nicht verfügbar. Aus diesem Grund müssen Sie die Amazon-RDS-Befehle [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) und [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) verwenden, um eine Replikation zwischen der Live-Datenbank und der RDS-for-MariaDB-Datenbank einzurichten.
Um die Replikation zwischen einer externen Quell-Instance und einer MariaDB DB-Instance auf Amazon RDS zu starten, gehen Sie wie folgt vor.
**So starten Sie eine Replikation:**
1. Legen Sie die Quell-MariaDB-Instance als schreibgeschützt fest:
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. Rufen Sie die aktuelle GTID der externen MariaDB-Instance ab. Sie können dies mithilfe von `mysql` oder mithilfe des Query Editors Ihrer Wahl tun, um `SELECT @@gtid_current_pos;` auszuführen.
Das GTID-Format sieht folgendermaßen aus: `--`. Eine GTID sieht typischerweise so aus **0-1234510749-1728**. Weitere Informationen zu GTIDs und ihren Bestandteilen finden Sie unter [Global Transaction ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/) in der MariaDB-Dokumentation.
1. Kopieren Sie die Datenbank mithilfe von von der externen MariaDB-Instance in die MariaDB-DB-Instanc `mysqldump`. Für große Datenbanken empfiehlt es sich, die Prozedur in zu verwende [Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB mit reduzierter Ausfallzeit](mariadb-importing-data-reduced-downtime.md).
Für Linux, macOS oder Unix:
```
mysqldump \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Für Windows:
```
mysqldump ^
--databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary \
-u local_user \
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**Anmerkung**
Zwischen der Option `-p` und dem eingegebenen Passwort darf kein Leerzeichen vorhanden sein.
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
Verwenden Sie die Optionen `--host`, `--user (-u)`, `--port` und `-p` im Befehl `mysql`, um Hostnamen, Benutzernamen, Port und Passwort für die Verbindung mit Ihrer MariaDB-DB-Instance festzulegen. Der Hostname ist der DNS-Name aus dem Endpunkt der MariaDB-DB-Instance, z. B. `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Sie finden den Endpunktwert in den Instance-Details in der Amazon-RDS-Managementkonsole.
1. Legen Sie die Quell-MariaDB-Instance als wieder beschreibbar fest.
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
1. Fügen Sie in der Amazon-RDS-Managementkonsole die IP-Adresse des Servers, der die externe MariaDB-Datenbank hostet, zu der VPC-Sicherheitsgruppe dieser MariaDB-DB-Instance hinzu. Weitere Informationen zum Modifizieren einer VPC-Sicherheitsgruppe finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) im *Amazon Virtual Private Cloud-Benutzerhandbuch*.
Die IP-Adresse kann sich ändern, wenn die folgenden Bedingungen erfüllt sind:
+ Sie verwenden eine öffentliche IP-Adresse für die Kommunikation zwischen der externen Quell-Instance und der DB-Instance.
+ Die externe Quell-Instance wurde gestoppt und neu gestartet.
Wenn diese Bedingungen erfüllt sind, überprüfen Sie die IP-Adresse, bevor Sie sie hinzufügen.
Es könnte sein, dass Sie Ihr lokales Netzwerk so konfigurieren müssen, dass es Verbindungen von der IP-Adresse Ihrer MariaDB-DB-Instance zulässt, damit es mit Ihrer externen MariaDB-Instance kommunizieren kann. Verwenden Sie den Befehl `host`, um die IP-Adresse Ihrer MariaDB-DB-Instance zu herauszufinden.
```
host db_instance_endpoint
```
Der Host-Name ist der DNS-Name aus dem Endpunkt der MariaDB-DB-Instance.
1. Verbinden Sie sich mithilfe eines Clients Ihrer Wahl mit der externen MariaDB-Instance und erstellen Sie einen MariaDB-Benutzer, der für die Replikation verwendet werden soll. Dieses Konto wird ausschließlich für die Replikation verwendet und muss auf Ihre Domäne beschränkt sein, um die Sicherheit zu erhöhen. Im Folgenden wird ein -Beispiel gezeigt.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
1. Erteilen Sie für die externe MariaDB-Instance die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für Ihren Replikationsbenutzer. Erteilen Sie beispielsweise die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE` in allen Datenbank für den '`repl_user`'-Benutzer für Ihre Domäne, mit dem folgenden Befehl.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Machen Sie die MariaDB-DB-Instance zum Replikat. Verbinden Sie sich als Masterbenutzer mit der MariaDB-DB-Instance und bestimmen Sie die externe MariaDB-Datenbank mithilfe des Befehls [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) als Quell-Instance. Verwenden Sie die GTID, die Sie in Schritt 2 festgelegt haben. Im Folgenden wird ein -Beispiel gezeigt.
```
CALL mysql.rds_set_external_master_gtid ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'GTID', 1);
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
1. Verwenden Sie auf der MariaDB-DB-Instance den Befehl [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication), um die Replikation zu starten:
```
CALL mysql.rds_start_replication;
```
# Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance
Sie können eine Replikation zwischen einer RDS für MySQL- oder MariaDB-DB-Instance und einer MySQL- oder MariaDB-Instance, die außerhalb von Amazon RDS ausgeführt wird, mit der Binärprotokolldatei-Replikation einrichten.
**Topics**
+ [Bevor Sie beginnen](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin)
+ [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](#MySQL.Procedural.Importing.External.Repl.Procedure)
## Bevor Sie beginnen
Sie konfigurieren die Replikation mithilfe der Position der Binärprotokolldatei von replizierten Transaktionen.
Die erforderlichen Berechtigungen für das Starten einer Replikation in einer Amazon-RDS-DB-Instance sind beschränkt und für Ihre Amazon-RDS-Hauptbenutzer nicht verfügbar. Achten Sie daher darauf, dass Sie die Amazon-RDS-Befehle [mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) oder [mysql.rds\$1set\$1external\$1source (RDS-für-MySQL-Hauptversionen 8.4 und höher)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) und [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) verwenden, um eine Replikation zwischen Ihrer Live-Datenbank und Ihrer Amazon-RDS-Datenbank einzurichten.
Aktualisieren Sie den Parameter `binlog_format`, um das binäre Protokollierungsformat für eine MySQL- oder MariaDB-Datenbank festzulegen. Wenn Ihre DB-Instance die standardmäßige DB-Instance-Parametergruppe verwendet, erstellen Sie eine neue DB-Parametergruppe, um den Parameter `binlog_format` zu ändern. In MariaDB sowie MySQL 8.0 und früheren Versionen ist `binlog_format` standardmäßig auf `MIXED` festgelegt. Sie können `binlog_format` jedoch auch auf `ROW` oder `STATEMENT` einstellen, wenn Sie ein spezifisches Format des Binärprotokolls (binlog) benötigen. Starten Sie Ihre DB-Instance neu, damit die Änderungen übernommen werden. In MySQL 8.4 und höheren Versionen ist `binlog_format` standardmäßig auf `ROW` festgelegt.
Informationen zum Einstellen des Parameters `binlog_format` erhalten Sie unter [Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken](USER_LogAccess.MySQL.BinaryFormat.md). Informationen über die Auswirkungen der Verwendung unterschiedlicher MySQL-Replikationstypen finden Sie unter [Vor- und Nachteile einer auf Anweisungen und einer auf Zeilen basierenden Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) in der MySQL-Dokumentation.
## Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance
Befolgen Sie diese Richtlinien, wenn Sie eine externe Quellinstance und ein Replikat auf Amazon RDS einrichten:
+ Überwachen Sie Failover-Ereignisse für die Amazon-RDS-DB-Instance, die Ihr Replica ist. Tritt ein Failover auf, kann die DB-Instance, die Ihr Replikat ist, auf einem neuen Host mit einer anderen Netzwerkadresse wiederhergestellt werden. Weitere Informationen zum Überwachen von Failover-Ereignissen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
+ Bewahren Sie die Binärprotokolle auf Ihrer Quell-Instance auf, bis Sie sichergestellt haben, dass sie auf das Replikat angewendet wurden. Durch das Aufbewahren können Sie sicherstellen, dass Sie Ihre Quell-Instance im Fall eines Ausfalls wiederherstellen können.
+ Schalten Sie automatische Backups in Ihrer Amazon-RDS-DB-Instance ein. Das Einschalten automatischer Sicherungen stellt sicher, dass Sie Ihr Replikat zu einem bestimmten Zeitpunkt wiederherstellen können, wenn Sie die Quell-Instance und das Replikat neu synchronisieren müssen. Informationen zu Sicherungen und point-in-time Wiederherstellungen finden Sie unter[Sichern, Wiederherstellen und Exportieren von Daten](CHAP_CommonTasks.BackupRestore.md).
**Konfigurieren Sie die Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance wie folgt:**
1. Legen Sie die Quell-MySQL- oder MariaDB-Instance als schreibgeschützt fest.
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. Führen Sie den Befehl `SHOW MASTER STATUS` in der MySQL- oder MariaDB-Quell-Instance aus, um die Position des Binärprotokolls zu ermitteln.
Sie erhalten eine Ausgabe, ähnlich der im folgenden Beispiel.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. Kopieren Sie die Datenbank aus der externen Instance in die Amazon-RDS-DB-Instance mithilfe von `mysqldump`. Für große Datenbanken empfiehlt es sich, die Prozedur in zu verwende [Importieren von Daten in eine Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-importing-data-reduced-downtime.md).
Für Linux, macOS oder Unix:
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Für Windows:
```
mysqldump --databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**Anmerkung**
Zwischen der Option `-p` und dem eingegebenen Passwort darf kein Leerzeichen vorhanden sein.
Zum Festlegen von Host-Name, Benutzername, Port und Passwort für die Verbindung mit Ihrer Amazon-RDS-DB-Instance verwenden Sie die Optionen `--host`, `--user (-u)`, `--port` und `-p` im Befehl `mysql`. Der Hostname ist der DNS-Name (Domain Name Service) aus dem Endpunkt der Amazon-RDS-DB-Instance, z. B `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Sie finden den Endpunktwert in den Instance-Details in der AWS-Managementkonsole.
1. Legen Sie die Quell-MySQL- oder MariaDB-Instance als wieder beschreibbar fest.
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
Weitere Informationen zum Erstellen von Backups zur Verwendung mit der Replikation finden Sie unter [in der MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html).
1. Fügen Sie im die IP-Adresse des Servers AWS-Managementkonsole, der die externe Datenbank hostet, der Sicherheitsgruppe Virtual Private Cloud (VPC) für die Amazon RDS-DB-Instance hinzu. Weitere Informationen zum Ändern einer VPC-Sicherheitsgruppe finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) im *Amazon Virtual Private Cloud-Benutzerhandbuch*.
Die IP-Adresse kann sich ändern, wenn die folgenden Bedingungen erfüllt sind:
+ Sie verwenden eine öffentliche IP-Adresse für die Kommunikation zwischen der externen Quell-Instance und der DB-Instance.
+ Die externe Quell-Instance wurde gestoppt und neu gestartet.
Wenn diese Bedingungen erfüllt sind, überprüfen Sie die IP-Adresse, bevor Sie sie hinzufügen.
Es könnte sein, dass Sie Ihr lokales Netzwerk so konfigurieren müssen, dass es Verbindungen von der IP-Adresse Ihrer Amazon-RDS-DB-Instance zulässt. Sie tun dies, damit Ihr lokales Netzwerk mit Ihrer externen MySQL- oder MariaDB-Instance kommunizieren kann. Verwenden Sie den Befehl `host`, um die IP-Adresse Ihrer Amazon-RDS-DB-Instance herauszufinden.
```
host db_instance_endpoint
```
Der Hostname ist der DNS-Name aus dem Endpunkt der Amazon-RDS-DB-Instance.
1. Stellen Sie mit einem Client Ihrer Wahl eine Verbindung zur Quell-Instance her und erstellen Sie den für die Replikation zu verwendenden Benutzer. Verwenden Sie dieses Konto ausschließlich für die Replikation und beschränken Sie es auf Ihre Domäne, um die Sicherheit zu erhöhen. Im Folgenden wird ein -Beispiel gezeigt.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
1. Erteilen Sie für die externe Instance die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE` für Ihren Replikationsbenutzer. Erteilen Sie beispielsweise die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE` in allen Datenbank für den '`repl_user`'-Benutzer für Ihre Domäne, mit dem folgenden Befehl.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Machen Sie die Amazon-RDS-DB-Instance zum Replica. Stellen Sie dazu zunächst als Master-Benutzer eine Verbindung zur Amazon-RDS-DB-Instance her. Identifizieren Sie dann die externe MySQL- oder MariaDB-Datenbank mithilfe des Befehls [mysql.rds\$1set\$1external\$1source (RDS-für-MySQL-Hauptversionen 8.4 und höher)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) oder [mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) als Quell-Instance. Verwenden Sie den Namen und die Position der Protokolldatei, die Sie in Schritt 2 festgelegt haben. Die folgenden Befehle sind Beispiele.
**MySQL 8.4**
```
CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MariaDB und MySQL 8.0 und 5.7**
```
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Anmerkung**
Unter RDS für MySQL können Sie stattdessen die verzögerte Replikation wählen, indem Sie die gespeicherte Prozedur [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS-für-MySQL-Hauptversionen 8.4 und höher)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) oder [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay) ausführen. Unter RDS für MySQL besteht ein Grund für die Verwendung einer verzögerten Replikation darin, die Notfallwiederherstellung mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) zu aktivieren. Derzeit unterstützt RDS für MariaDB verzögerte Replikation, aber nicht die `mysql.rds_start_replication_until`-Prozedur.
1. Verwenden Sie für die Amazon-RDS-DB-Instance den Befehl [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication), um die Replikation zu starten.
```
CALL mysql.rds_start_replication;
```
# Optionen für MariaDB-Datenbank-Engine
Im Folgenden finden Sie eine Beschreibung der Optionen oder zusätzlichen Funktionen, die für Amazon-RDS-Instances verfügbar sind, auf denen die MariaDB-DB-Engine ausgeführt wird. Zum Aktivieren dieser Optionen können Sie diese einer benutzerdefinierten Optionsgruppe hinzufügen und anschließend der Optionsgruppe für Ihre DB-Instance zuordnen. Weitere Informationen über das Arbeiten mit Optionsgruppen finden Sie unter [Arbeiten mit Optionsgruppen](USER_WorkingWithOptionGroups.md).
Amazon RDS unterstützt die folgenden Optionen für MariaDB:
| Options-ID | Engine-Versionen |
| --- | --- |
| `MARIADB_AUDIT_PLUGIN` | MariaDB 10.3 und höher |
## MariaDB Audit-Plugin-Support
Amazon RDS unterstützt die Verwendung des MariaDB Steuerungs-Plugins in MariaDB-Datenbank-Instances. Das MariaDB-Audit-Plugin zeichnet Datenbank-Aktivitäten auf, z. B. Benutzer, die sich bei der Datenbank anmelden, Abfragen in der Datenbank ausführen und vieles mehr. Der Datensatz der Datenbankaktivität wird in einer Protokolldatei gespeichert.
### Audit-Plugin-Optionseinstellungen
Amazon RDS unterstützt die folgenden Einstellungen für die MariaDB-Audit-Plugin-Option.
**Anmerkung**
Wenn Sie in der RDS-Konsole keine Optionseinstellung konfigurieren, verwendet RDS die Standardeinstellung.
| Optionseinstellung | Zulässige Werte | Standardwert | Beschreibung |
| --- | --- | --- | --- |
| `SERVER_AUDIT_FILE_PATH` | `/rdsdbdata/log/audit/` | `/rdsdbdata/log/audit/` | Der Speicherort der Protokolldatei. Die Protokolldatei beinhaltet den Datensatz der Aktivitäten die in festgelegt wurde `SERVER_AUDIT_EVENTS`. Weitere Informationen erhalten Sie unter [Anzeigen und Auflisten von Datenbank-Protokolldateien](USER_LogAccess.Procedural.Viewing.md) und [MariaDB-Datenbank-Protokolldateien](USER_LogAccess.Concepts.MariaDB.md). |
| `SERVER_AUDIT_FILE_ROTATE_SIZE` | 1 – 1000000000 | 1000000 | Die Größe in Bytes, die bei Erreichen der Datei dazu führt, dass die Datei rotiert. Weitere Informationen finden Sie unter [Protokollrotation und -aufbewahrung für MariaDB](USER_LogAccess.MariaDB.LogFileSize.md). |
| `SERVER_AUDIT_FILE_ROTATIONS` | 0 – 100 | 9 | Die Anzahl der zu speichernden Protokollrotationen, wenn `server_audit_output_type=file`. Wenn der Wert auf 0 festgelegt ist, rotiert die Protokolldatei niemals. Weitere Informationen erhalten Sie unter [Protokollrotation und -aufbewahrung für MariaDB](USER_LogAccess.MariaDB.LogFileSize.md) und [Herunterladen einer Datenbank-Protokolldatei](USER_LogAccess.Procedural.Downloading.md). |
| `SERVER_AUDIT_EVENTS` | `CONNECT`, `QUERY`, `TABLE`, `QUERY_DDL`, `QUERY_DML`, `QUERY_DML_NO_SELECT`, `QUERY_DCL` | `CONNECT`, `QUERY` | Die Arten von Aktivitäten, die im Protokoll aufgezeichnet werden sollen. Die Installation des MariaDB Audit Plugins ist selbst protokolliert. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.MariaDB.Options.html) |
| `SERVER_AUDIT_INCL_USERS` | Mehrere kommaseparierte Werte | Keine | Füge nur Aktivität von den angegebenen Benutzern ein. Standardmäßig werden Aktivitäten für alle Benutzer aufgezeichnet. `SERVER_AUDIT_INCL_USERS` und schließen `SERVER_AUDIT_EXCL_USERS` sich gegenseitig aus. Wenn Sie Werte hinzufügen `SERVER_AUDIT_INCL_USERS`, stellen Sie sicher, dass keine Werte hinzugefügt werden `SERVER_AUDIT_EXCL_USERS`. |
| `SERVER_AUDIT_EXCL_USERS` | Mehrere kommaseparierte Werte | Keine | Aktivität von den angegebenen Benutzern ausschließen. Standardmäßig werden Aktivitäten für alle Benutzer aufgezeichnet. `SERVER_AUDIT_INCL_USERS` und schließen `SERVER_AUDIT_EXCL_USERS` sich gegenseitig aus. Wenn Sie Werte hinzufügen `SERVER_AUDIT_EXCL_USERS`, stellen Sie sicher, dass keine Werte hinzugefügt werden `SERVER_AUDIT_INCL_USERS`. Der `rdsadmin`-Benutzer fragt die Datenbank jede Sekunde ab, um den Zustand der Datenbank zu überprüfen. Abhängig von Ihren anderen Einstellungen kann diese Aktivität dazu führen, dass die Größe Ihrer Protokolldatei sehr schnell sehr groß wird. Wenn Sie diese Aktivität nicht aufzeichnen müssen, fügen Sie den Benutzer `rdsadmin` zur Liste `SERVER_AUDIT_EXCL_USERS` hinzu. `CONNECT`Die Aktivität wird stets für alle Benutzer erfasst, auch wenn ein Benutzer für diese Optionseinstellung angegeben ist. |
| `SERVER_AUDIT_LOGGING` | `ON` | `ON` | Die Protokollierung ist aktiv. Der einzige gültige Wert ist `ON`. Amazon RDS unterstützt die Deaktivierung der Protokollierung nicht. Wenn Sie die Protokollierung deaktivieren möchten, entfernen Sie das MariaDB-Audit-Plugin. Weitere Informationen finden Sie unter [Entfernen des MariaDB-Audit-Plugins](#Appendix.MariaDB.Options.AuditPlugin.Remove). |
| `SERVER_AUDIT_QUERY_LOG_LIMIT` | 0 – 2147483647 | 1024 | Die Längenbegrenzung der Abfragezeichenfolge in einem Datensatz. |
### Hinzufüge des MariaDB-Audit-Plugins
Der allgemeine Vorgang zum Hinzufügen des MariaDB-Audit-Plugins zu einer DB-Instance ist wie folgt:
1. Erstellen Sie eine neue Optionsgruppe oder kopieren oder ändern Sie eine bestehende Optionsgruppe.
1. Hinzufügen der Option zur Optionsgruppe.
1. Ordnen Sie die Optionsgruppe der DB-Instance zu.
Nachdem Sie das MariaDB-Audit-Plugin hinzugefügt haben, müssen Sie Ihre DB-Instance nicht neu starten. Sobald die Optionsgruppe aktiv ist, beginnt sofort die Überwachung.
**So fügen Sie das MariaDB-Audit-Plugin hinzu**
1. Bestimmen Sie die zu verwendende Optionsgruppe. Sie können eine Optionsgruppe erstellen oder eine bestehende Optionsgruppe verwenden. Wenn Sie eine bestehende Optionsgruppe verwenden möchten, fahren Sie mit dem nächsten Schritt fort. Erstellen Sie andernfalls eine benutzerdefinierte DB-Optionsgruppe. Wählen Sie zuerst **mariadb** für **Engine** und dann **10.3** oder höher für **Major engine version** (Engine-Hauptversion) aus. Weitere Informationen finden Sie unter [Erstellen einer Optionsgruppe](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create).
1. Fügen Sie der Optionsgruppe die Option **MARIADB\$1AUDIT\$1PLUGIN** hinzu und konfigurieren Sie die Optionseinstellungen. Weitere Informationen über das Hinzufügen von Optionen finden Sie unter [Hinzufügen einer Option zu einer Optionsgruppe](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). Weitere Informationen zu den einzelnen Einstellungen finden Sie unter [Audit-Plugin-Optionseinstellungen](#Appendix.MariaDB.Options.AuditPlugin.Options).
1. Wenden Sie die Optionsgruppe auf eine neue oder vorhandene DB-Instance an.
+ Einer neuen DB-Instance wird die Optionsgruppe beim Starten der Instance zugewiesen. Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
+ Bei einer bestehenden DB-Instance weisen Sie die Optionsgruppe zu, indem Sie die DB-Instance ändern und die neue Optionsgruppe anhängen. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
### Anzeigen und Herunterladen des MariaDB-Audit-Plugin-Protokolls
Nachdem Sie das MariaDB Audit-Plugin aktiviert haben, greifen Sie auf die Ergebnisse in den Protokolldateien genauso zu, wie auf andere textbasierte Protokolldateien. Die Auditprotokolldateien werden unter gespeicher `/rdsdbdata/log/audit/`. Weitere Informationen zum Anzeigen einer Protokolldatei in der Konsole finden Sie unter [Anzeigen und Auflisten von Datenbank-Protokolldateien](USER_LogAccess.Procedural.Viewing.md). Weitere Informationen zum Herunterladen der Protokolldatei finden Sie unter [Herunterladen einer Datenbank-Protokolldatei](USER_LogAccess.Procedural.Downloading.md).
### Ändern der Einstellungen für das MariaDB-Audit-Plugin
Nachdem Sie das MariaDB-Audit-Plugin aktiviert haben, können Sie die Einstellungen für das Plugin ändern. Weitere Informationen über das Ändern von Optionseinstellungen finden Sie unter [Ändern einer Optionseinstellung](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). Weitere Informationen zu den einzelnen Einstellungen finden Sie unter [Audit-Plugin-Optionseinstellungen](#Appendix.MariaDB.Options.AuditPlugin.Options).
### Entfernen des MariaDB-Audit-Plugins
Amazon RDS unterstützt das Deaktivieren der Protokollierung im MariaDB-Audit-Plugin nicht. Sie können das Plugin jedoch aus einer DB-Instance entfernen. Wenn Sie das MariaDB-Audit-Plugin entfernen, wird die DB-Instance automatisch erneut gestartet, um die Überwachung zu beenden.
Führen Sie einen der folgenden Schritte aus, um das MariaDB-Audit-Plugin aus einer DB-Instance zu entfernen:
+ Entfernen Sie das MariaDB-Audit-Plugin aus ihrer zugehörigen Optionsgruppe wie folgt: Diese Änderung wirkt sich auf alle DB-Instances aus, die die betreffende Optionsgruppe verwenden. Weitere Informationen finden Sie unter [Entfernen einer Option aus einer Optionsgruppe](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)
+ Ändern Sie die DB-Instance und legen sie eine andere Optionsgruppe fest, die im Plugin nicht enthalten ist. Diese Änderung betrifft eine einzelne DB-Instance. Sie können die (leere) Standardoptionsgruppe oder eine andere benutzerdefinierte Optionsgruppe angeben. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
# Parameter 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 zum Arbeiten mit Parametergruppen und zum Festlegen von Parametern finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
## MariaDB-Parameter anzeigen
RDS für MariaDB-Parameter werden auf die Standardwerte der von Ihnen ausgewählten Speicher-Engine gesetzt. Weitere Informationen zu MariaDB-Parametern finden Sie in der [MariaDB-Dokumentation](http://mariadb.com/kb/en/mariadb/documentation/). Weitere Informationen über MariaDB-Speicher-Engines finden Sie unter [Unterstützte Speicher-Engines für MariaDB auf Amazon RDS](MariaDB.Concepts.Storage.md).
Sie können die für eine bestimmte RDS-for-MariaDB-Version verfügbaren Parameter mithilfe der RDS-Konsole oder des AWS CLI anzeigen. Weitere Informationen zum Anzeigen von Parametern in einer MariaDB-Parametergruppe in der RDS-Konsole finden Sie unter [Anzeigen von Parameterwerten für eine DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
Mit dem AWS CLI können Sie die Parameter für eine RDS for MariaDB-Version anzeigen, indem Sie den [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html)Befehl ausführen. Geben Sie einen der folgenden Werte für die Option `--db-parameter-group-family` an:
+ `mariadb11.8`
+ `mariadb11.4`
+ `mariadb10.11`
+ `mariadb10.6`
+ `mariadb10.5`
+ `mariadb10.4`
+ `mariadb10.3`
Um beispielsweise die Parameter für RDS für MariaDB Version 10.6 anzuzeigen, führen Sie den folgenden Befehl aus.
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6
```
Die Ausgabe sieht folgendermaßen oder ähnlich aus.
```
{
"EngineDefaults": {
"Parameters": [
{
"ParameterName": "alter_algorithm",
"Description": "Specify the alter table algorithm.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "string",
"AllowedValues": "DEFAULT,COPY,INPLACE,NOCOPY,INSTANT",
"IsModifiable": true
},
{
"ParameterName": "analyze_sample_percentage",
"Description": "Percentage of rows from the table ANALYZE TABLE will sample to collect table statistics.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "float",
"AllowedValues": "0-100",
"IsModifiable": true
},
{
"ParameterName": "aria_block_size",
"Description": "Block size to be used for Aria index pages.",
"Source": "engine-default",
"ApplyType": "static",
"DataType": "integer",
"AllowedValues": "1024-32768",
"IsModifiable": false
},
{
"ParameterName": "aria_checkpoint_interval",
"Description": "Interval in seconds between automatic checkpoints.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "integer",
"AllowedValues": "0-4294967295",
"IsModifiable": true
},
...
```
Führen Sie den folgenden Befehl aus, um nur die änderbaren Parameter für RDS für MariaDB Version 10.6 aufzulisten.
Für Linux, macOS oder Unix:
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6 \
--query 'EngineDefaults.Parameters[?IsModifiable==`true`]'
```
Für Windows:
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6 ^
--query "EngineDefaults.Parameters[?IsModifiable==`true`]"
```
## MySQL-Parameter, die nicht verfügbar sind
Die folgenden MySQL-Parameter sind in MariaDB-spezifischen DB-Parametergruppen nicht verfügbar:
+ bind\$1address
+ binlog\$1error\$1action
+ binlog\$1gtid\$1simple\$1recovery
+ binlog\$1max\$1flush\$1queue\$1time
+ binlog\$1order\$1commits
+ binlog\$1row\$1image
+ binlog\$1rows\$1query\$1log\$1events
+ binlogging\$1impossible\$1mode
+ block\$1encryption\$1mode
+ core\$1file
+ default\$1tmp\$1storage\$1engine
+ div\$1precision\$1increment
+ end\$1markers\$1in\$1json
+ enforce\$1gtid\$1consistency
+ eq\$1range\$1index\$1dive\$1limit
+ explicit\$1defaults\$1for\$1timestamp
+ gtid\$1executed
+ gtid-mode
+ gtid\$1next
+ gtid\$1owned
+ gtid\$1purged
+ log\$1bin\$1basename
+ log\$1bin\$1index
+ log\$1bin\$1use\$1v1\$1row\$1events
+ log\$1slow\$1admin\$1statements
+ log\$1slow\$1slave\$1statements
+ log\$1throttle\$1queries\$1not\$1using\$1indexes
+ master-info-repository
+ optimizer\$1trace
+ optimizer\$1trace\$1features
+ optimizer\$1trace\$1limit
+ optimizer\$1trace\$1max\$1mem\$1size
+ optimizer\$1trace\$1offset
+ relay\$1log\$1info\$1repository
+ rpl\$1stop\$1slave\$1timeout
+ slave\$1parallel\$1workers
+ slave\$1pending\$1jobs\$1size\$1max
+ slave\$1rows\$1search\$1algorithms
+ storage\$1engine
+ table\$1open\$1cache\$1instances
+ timed\$1mutexes
+ transaction\$1allow\$1batching
+ validate-password
+ validate\$1password\$1dictionary\$1file
+ validate\$1password\$1length
+ validate\$1password\$1mixed\$1case\$1count
+ validate\$1password\$1number\$1count
+ validate\$1password\$1policy
+ validate\$1password\$1special\$1char\$1count
Weitere Informationen zu MySQL-Parametern finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/).
# Migrieren von Daten aus einem MySQL-DB-Snapshot in eine MariaDB-DB-Instance
Sie können mithilfe der AWS-Managementkonsole, der AWS CLI oder Amazon-RDS-API einen RDS für MySQL-DB-Snapshot zu einer neuen DB-Instance migrieren, die MariaDB ausführt. Sie müssen einen DB-Snapshot verwenden, der von einer Amazon-RDS-DB-Instance erstellt wurde, die MySQL 5.6 oder 5.7 ausführt. Informationen zum Erstellen eines RDS für MySQL-DB-Snapshots finden Sie unter [Erstellen eines DB-Snapshots für eine DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md).
Die Migration des Snapshots wirkt sich nicht auf die ursprüngliche DB-Instance aus, von der der Snapshot entnommen wurde. Sie können die neue DB-Instance testen und validieren, bevor Sie den Datenverkehr als Ersatz für die ursprüngliche DB-Instance darauf umleiten.
Nach dem Migrieren von MySQL zu MariaDB wird die MariaDB-DB-Instance der standardmäßigen DB-Parametergruppe und Optionsgruppe zugeordnet. Nach dem Wiederherstellen des DB-Snapshots können Sie eine benutzerdefinierte DB-Parametergruppe mit der neuen DB-Instance zuordnen. Eine MariaDB-Parametergruppe hat jedoch einen anderen Satz konfigurierbarer Systemvariablen. Informationen zu den Unterschieden zwischen MySQL- und MariaDB-Systemvariablen finden Sie unter [Unterschiede der Systemvariablen zwischen MariaDB und MySQL](https://mariadb.com/kb/en/system-variable-differences-between-mariadb-and-mysql/). Informationen über DB-Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Informationen über Optionsgruppen finden Sie unter [Arbeiten mit Optionsgruppen](USER_WorkingWithOptionGroups.md).
## Durchführen der Migration
Sie können einen RDS für MySQL DB-Snapshot mit der AWS-Managementkonsole, der AWS CLI oder RDS-API zu einer neuen MariaDB DB-Instance migrieren.
### Konsole
**So migrieren Sie Daten aus einem MySQL-DB-Snapshot in eine MariaDB-DB-Instance**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich die Option **Snapshots** und dann den zu migrierenden MySQL-DB-Snapshot aus.
1. Wählen Sie unter **Aktionen** die Option **Migrate Snapshot (Snapshot migrieren)**. Die Seite **Datenbank migrieren** wird angezeigt.
1. Wählen Sie unter **In DB-Engine migrieren** den Eintrag **mariadb** aus.
Amazon RDS wählt die **DB-Engine-Version** automatisch. Sie können die Version der DB-Engine nicht ändern.
![\[Die Seite Datenbank migrieren für die Migration von MySQL zu MariaDB in der Amazon-RDS-Konsole.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMariaDB.png)
1. Geben Sie für die restlichen Abschnitte die gewünschten Einstellungen für die DB-Instance an. Weitere Informationen zu den einzelnen Einstellungen finden Sie unter [Einstellungen für DB-Instances](USER_CreateDBInstance.Settings.md).
1. Wählen Sie **Migrate (Migrieren)**.
### AWS CLI
Zum Migrieren von Daten von einem MySQL-DB-Snapshot zu einer MariaDB-DB-Instance führen Sie den AWS CLI-Befehl [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) mit den folgenden Optionen aus:
+ --db-instance-identifier – Name der DB-Instance, die aus dem DB-Snapshot erstellt werden soll.
+ --db-snapshot-identifier – Kennung für den DB-Snapshot, der zur Wiederherstellung verwendet werden soll.
+ --engine – Datenbank-Engine, die für die neue Instance verwendet werden soll.
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds restore-db-instance-from-db-snapshot \
2. --db-instance-identifier newmariadbinstance \
3. --db-snapshot-identifier mysqlsnapshot \
4. --engine mariadb
```
Für Windows:
```
1. aws rds restore-db-instance-from-db-snapshot ^
2. --db-instance-identifier newmariadbinstance ^
3. --db-snapshot-identifier mysqlsnapshot ^
4. --engine mariadb
```
### API
Zum Migrieren von Daten aus einem MySQL-DB-Snapshot zu einer MariaDB-DB-Instance rufen Sie die Amazon-RDS-API-Operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) auf.
## Kompatibilitätseinschränkungen zwischen MariaDB und MySQL
Kompatibilitätseinschränkungen zwischen MySQL und MariaDB beinhalten Folgendes:
+ Sie können keinen DB-Snapshot zu MariaDB migrieren, der mit MySQL 8.0 erstellt wurde.
+ Falls die MySQL-Quelldatenbank einen SHA256-Passwort-Hash verwendet, müssen Sie mit SHA256 gehashte Benutzerpasswörter zurücksetzen, ehe Sie eine Verbindung zur MariaDB-Datenbank herstellen können. Der folgende Code zeigt, wie Sie ein Passwort zurücksetzen, das SHA256-gehasht wurde.
```
SET old_passwords = 0;
UPDATE mysql.user SET plugin = 'mysql_native_password',
Password = PASSWORD('new_password')
WHERE (User, Host) = ('master_user_name', %);
FLUSH PRIVILEGES;
```
+ Wenn Ihr RDS-Master-Benutzerkonto den SHA-256-Passwort-Hash verwendet, müssen Sie das Kennwort mithilfe von AWS-Managementkonsole, des [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) Befehls AWS CLI oder der [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)-RDS-API-Operation zurücksetzen. Informationen zum Ändern einer DB-Instance finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
+ MariaDB unterstützt das Memcached-Plugin nicht. Die vom Memcached-Plugin verwendeten Daten werden jedoch als InnoDB-Tabellen gespeichert. Nach der Migration eines MySQL-DB-Snapshots können Sie mithilfe von SQL die Daten aufrufen, die vom Memcached-Plugin verwendet werden. Weitere Informationen über die innodb\$1memcache-Datenbank finden Sie unter [InnoDB memcached Plugin Internals](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-internals.html).
# MariaDB auf Amazon RDS – SQL-Referenz
Im Folgenden werden gespeicherte Prozeduren beschrieben, die für Amazon RDS-Instances verfügbar sind, auf denen die MariaDB-DB-Engine ausgeführt wird.
Sie können die im System gespeicherten Prozeduren verwenden, die für MySQL-DB-Instances und für MariaDB-DB-Instances verfügbar sind. Die gespeicherten Prozeduren sind in dokumentier [Referenz für gespeicherte RDS-für-MySQL-Verfahren](Appendix.MySQL.SQLRef.md). MariaDB-DB-Instances unterstützen alle der gespeicherten Prozeduren, mit Ausnahme von `mysql.rds_start_replication_until` und `mysql.rds_start_replication_until_gtid`.
Darüber hinaus werden die folgenden gespeicherten Systemprozeduren nur für Amazon RDS-DB-Instances unterstützt, auf denen die MariaDB ausgeführt wird:
+ [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md)
+ [mysql.rds\$1kill\$1query\$1id](mysql_rds_kill_query_id.md)
+ [mysql.rds\$1execute\$1operation](mysql_rds_execute_operation.md)
# mysql.rds\$1replica\$1status
Zeigt den Replikationsstatus einer MariaDB-Read Replica an.
Rufen Sie dieses Verfahren im Read Replica auf, um Statusinformationen zu wesentlichen Parametern der Replikat-Threads anzuzeigen
## Syntax
```
CALL mysql.rds_replica_status;
```
## Nutzungshinweise
Dieses Verfahren wird nur für MariaDB-DB-Instances unterstützt, auf denen MariaDB Version 10.5 und höher ausgeführt wird.
Dieses Verfahren entspricht dem Befehl `SHOW REPLICA STATUS`. Dieser Befehl wird für DB-Instances der MariaDB-Version 10.5 und höher nicht unterstützt.
In früheren Versionen von MariaDB benötigte der äquivalente Befehl `SHOW SLAVE STATUS` die Berechtigung `REPLICATION SLAVE`. In MariaDB Version 10.5 und höher benötigt er die Berechtigung `REPLICATION REPLICA ADMIN`. Um das RDS-Management von MariaDB 10.5 und höher DB-Instances zu schützen, wird dieses neue Privileg dem RDS-Master-Benutzer nicht gewährt.
## Beispiele
Das folgende Beispiel zeigt den Status einer MariaDB Read Replica:
```
call mysql.rds_replica_status;
```
Die Antwort ähnelt dem folgenden Beispiel:
```
*************************** 1. row ***************************
Replica_IO_State: Waiting for master to send event
Source_Host: XX.XX.XX.XXX
Source_User: rdsrepladmin
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin-changelog.003988
Read_Source_Log_Pos: 405
Relay_Log_File: relaylog.011024
Relay_Log_Pos: 657
Relay_Source_Log_File: mysql-bin-changelog.003988
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table: mysql.rds_sysinfo,mysql.rds_history,mysql.rds_replication_status
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 405
Relay_Log_Space: 1016
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: 0
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 807509301
Source_SSL_Crl:
Source_SSL_Crlpath:
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-807509301-3980
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: optimistic
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Replica_SQL_Running_State: Reading event from the relay log
Replica_DDL_Groups: 15
Replica_Non_Transactional_Groups: 0
Replica_Transactional_Groups: 3658
1 row in set (0.000 sec)
Query OK, 0 rows affected (0.000 sec)
```
# mysql.rds\$1set\$1external\$1master\$1gtid
Konfiguriert die GTID-basierte Replikation einer MariaDB-Instance, die außerhalb von Amazon RDS ausgeführt wird, zu einer MariaDB-DB-Instance. Diese gespeicherte Prozedur wird nur unterstützt, wenn die externe MariaDB-Instance Version 10.0.24 oder höher ist. Wenn Sie die Replikation einrichten, bei der eine oder beide Instances keine globalen Transaktionskennungen (GTIDs) von MariaDB unterstützen, verwenden Sie [mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master).
Durch die Verwendung von GTIDs für die Replikation werden Absturzsicherheitsfunktionen bereitgestellt, die von der binären Protokollreplikation nicht angeboten werden. Daher empfehlen wir es in den Fällen, in denen die Replikations-Instances dies unterstützen.
## Syntax
```
CALL mysql.rds_set_external_master_gtid(
host_name
, host_port
, replication_user_name
, replication_user_password
, gtid
, ssl_encryption
);
```
## Parameter
*host\$1name*
Zeichenfolge. Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MariaDB-Instance, die als Quell-Instance festgelegt werden soll.
*host\$1port*
Ganzzahl. Der Port, der von der außerhalb von Amazon RDS ausgeführten MariaDB-Instance verwendet wird, die als Quell-Instance konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation von SSH-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an.
*replication\$1user\$1name*
Zeichenfolge. Die Kennung eines Benutzers mit `REPLICATION SLAVE`-Berechtigungen in der MariaDB-DB-Instance, die als Lesereplikat konfiguriert werden soll.
*replication\$1user\$1password*
Zeichenfolge. Das zu der für den Parameter angegebenen Benutzer-Kennung gehörige Passwor `replication_user_name`.
*gtid*
Zeichenfolge. Die globale Transaktionskennung für die Quell-Instance, von der aus die Replikation gestartet werden soll.
Sie können `@@gtid_current_pos` verwenden, um die aktuelle GTID zu erhalten, wenn die Quell-Instance gesperrt wurde, während Sie die Replikation konfigurieren. Das Binärprotokoll ändert sich also nicht zwischen den Punkten, wenn Sie die GTID erhalten und wenn die Replikation startet.
Andernfalls können Sie, wenn Sie `mysqldump`-Version 10.0.13 oder neuer für das Befüllen der Replikat-Instance vor der Replikation verwenden, die GTID-Position in der Ausgabe erhalten, indem Sie die Optionen `--master-data` oder `--dump-slave` verwenden. Wenn Sie `mysqldump`-Version 10.0.13 oder neuer verwenden, können Sie `SHOW MASTER STATUS` ausführen oder dieselben `mysqldump`-Optionen verwenden, um den Namen und die Position der Binärprotokolldatei zu erhalten und diese anschließend in eine GTID konvertieren, indem Sie `BINLOG_GTID_POS` auf der externen MariaDB-Instance ausführen:
```
SELECT BINLOG_GTID_POS('', );
```
Weitere Informationen über die Implementierung von GTIDs in MariaDB finden Sie unter [Global Transaction ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/) in der MariaDB-Dokumentation.
*ssl\$1encryption*
Ein Wert, der angibt, ob die SSL-Verschlüsselung (Secure Socket Layer) für die Replikationsverbindung verwendet wird. 1 = SSL-Verschlüsselung, 0 = keine Verschlüsselung. Der Standardwert ist 0.
Die Option `MASTER_SSL_VERIFY_SERVER_CERT` wird nicht unterstützt. Diese Option ist auf 0 gesetzt, was bedeutet, dass die Verbindung verschlüsselt ist, aber die Zertifikate nicht überprüft werden.
## Nutzungshinweise
Die Prozedur `mysql.rds_set_external_master_gtid` muss vom Hauptbenutzer ausgeführt werden. Sie muss auf der MariaDB-DB-Instance ausgeführt werden, die Sie als Replikat einer MariaDB-Instance konfigurieren, die extern zu Amazon RDS ausgeführt wird. Bevor Sie `mysql.rds_set_external_master_gtid` ausführen, müssen Sie die Instance von MariaDB, die außerhalb von Amazon RDS ausgeführt wird, als Quell-Instance konfiguriert haben. Weitere Informationen finden Sie unter [Importieren von Daten in eine DB-Instance von Amazon RDS für MariaDB](MariaDB.Procedural.Importing.md).
**Warnung**
Verwenden Sie nicht `mysql.rds_set_external_master_gtid`, um Replikation zwischen zwei Amazon RDS-DB-Instances zu verwalten. Verwenden Sie diese Option nur, wenn Sie mit einer MariaDB-Instance replizieren, die extern zu RDS ausgeführt wird. Informationen zur Verwaltung der Replikation zwischen Amazon RDS-DB-Instances finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md).
Nachdem Sie `mysql.rds_set_external_master_gtid` aufgerufen haben, um eine Amazon RDS-DB-Instance zum Verwenden als Lesereplikat zu konfigurieren, starten Sie durch Aufrufen von [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) den Replikationsvorgang für das Replikat. Zudem haben Sie die Möglichkeit, mit einem Aufruf von [mysql.rds\$1next\$1master\$1log (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) die Lesereplikat-Konfiguration zu entfernen.
Beim Aufrufen von `mysql.rds_set_external_master_gtid` werden Uhrzeit, Benutzer und eine „set master“-Aktion von Amazon RDS in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` protokolliert.
## Beispiele
Bei der Ausführung auf einer MariaDB-DB-Instance wird das folgende Beispiel als Replikat einer Instance von MariaDB konfiguriert, die extern zu Amazon RDS ausgeführt wird.
```
call mysql.rds_set_external_master_gtid ('Sourcedb.some.com',3306,'ReplicationUser','SomePassW0rd','0-123-456',0);
```
# mysql.rds\$1kill\$1query\$1id
Beendet eine an den MariaDB-Server übermittelte Abfrage, um lang andauernde oder problematische Abfragen zu beenden. Sie können die Abfrage-ID identifizieren und eine bestimmte Abfrage effektiv beenden, um Leistungsprobleme zu beheben und einen optimalen Datenbankbetrieb aufrechtzuerhalten.
## Syntax
```
CALL mysql.rds_kill_query_id(queryID);
```
## Parameter
*queryID*
Ganzzahl. Die Identität der zu beendenden Abfrage.
## Nutzungshinweise
Um eine an den MariaDB-Server übermittelte Abfrage zu beenden, verwenden Sie die Prozedur `mysql.rds_kill_query_id` und übergeben ihr als Parameter die Kennung der Abfrage. Führen Sie eine Abfrage an die MariaDB-[Informationsschema-PROCESSLIST-Tabelle](http://mariadb.com/kb/en/mariadb/information-schema-processlist-table/) durch, um die Abfrage-ID zu erhalten, wie im Folgenden gezeigt:
```
SELECT USER, HOST, COMMAND, TIME, STATE, INFO, QUERY_ID FROM
INFORMATION_SCHEMA.PROCESSLIST WHERE USER = '';
```
Die Verbindung zum MariaDB-Server bleibt bestehen.
## Beispiele
Im folgenden Beispiel wird eine Abfrage mit der Abfrage-Kennung 230040 beendet:
```
call mysql.rds_kill_query_id(230040);
```
# mysql.rds\$1execute\$1operation
Führt InnoDB-Vorgänge aus, um Pufferpoolstatus und temporäre Tablespaces zu verwalten. Dieses Verfahren kann verwendet werden, um InnoDB-Vorgänge wie z. B. Auslesen und Laden von Pufferpoolstatus oder Kürzen temporärer Tablespaces dynamisch zu steuern.
## Syntax
```
CALL mysql.rds_execute_operation(operation);
```
## Parameter
*Operation beschleunigen*
Zeichenfolge. Die auszuführenden InnoDB-Vorgänge. Folgende sind gültige Werte:
+ *innodb\$1buffer\$1pool\$1dump\$1now*: Vorgang, bei dem der aktuelle Status des Pufferpools ausgelesen wird.
+ *innodb\$1buffer\$1pool\$1load\$1now*: Vorgang, bei dem der gespeicherte Pufferpoolstatus geladen wird.
+ *innodb\$1buffer\$1pool\$1load\$1abort*: Vorgang, bei dem ein Ladevorgang des Pufferpools abgebrochen wird.
+ *innodb\$1truncate\$1temporary\$1tablespace\$1now*: Vorgang, bei dem der temporäre Tablespace gekürzt wird.
## Nutzungshinweise
Dieses Verfahren wird nur für MariaDB-DB-Instances unterstützt, auf denen MariaDB 11.8 und höher ausgeführt wird.
Während der Ausführung ist die Binärprotokollierung vorübergehend deaktiviert, um die Replikation dieser administrativen Befehle zu verhindern.
Mit diesem Verfahren wird ein Audit Trail verwaltet, indem alle Vorgänge in der Tabelle [https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/securing-connections-for-client-and-server#requiring-tls](https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/securing-connections-for-client-and-server#requiring-tls) protokolliert werden.
## Beispiele
Im folgenden Beispiel ist die Kürzung temporärer Tablespaces mithilfe von `mysql.rds_execute_operation` angegeben:
Führen Sie die folgende Abfrage aus, um die aktuelle Größe des temporären Tablespace zu überprüfen:
```
SELECT FILE_SIZE FROM information_schema.innodb_sys_tablespaces WHERE name LIKE 'innodb_temporary';
+------------+
| FILE_SIZE |
+------------+
| 6723469312 | -- 6.3 GB
+------------+
```
Durch Löschen temporärer Tabellen wird die Speichernutzung im globalen Tablespace nicht reduziert. Um die Größe des globalen Tablespace zu reduzieren, führen Sie den Befehl `mysql.rds_execute_operation` zum Verkleinern des temporären Tablespace aus.
```
CALL mysql.rds_execute_operation('innodb_truncate_temporary_tablespace_now');
Query OK, 2 rows affected (0.004 sec)
```
Überprüfen Sie nach dem Verfahren, ob der Speicherplatz zurückgewonnen wurde.
```
SELECT FILE_SIZE FROM information_schema.innodb_sys_tablespaces WHERE name LIKE 'innodb_temporary';
+-----------+
| FILE_SIZE |
+-----------+
| 12582912 | -- 12 MB
+-----------+
```
**Anmerkung**
Der Verkleinerungsvorgang kann je nach Größe des temporären Tablespace und aktuellem Workload einige Zeit in Anspruch nehmen.
**Wichtig**
Der temporäre Tablespace wird nur verkleinert, wenn alle temporären Tabellen, durch die die Größe zugenommen hat, nicht mehr verwendet werden. Es wird empfohlen, dieses Verfahren auszuführen, wenn auf der Instance keine aktiven temporären Tablespaces vorhanden sind.
# 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 [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
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 Read Replica unterschiedliche Parametergruppen (Parametergruppen sind für eine AWS-Region eindeutig). 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.
Die Internet Assigned Numbers Authority (IANA) veröffentlicht mehrmals im Jahr neue Zeitzonen unter [https://www.iana.org/time-zones](https://www.iana.org/time-zones). Jedes Mal, wenn RDS eine neue Wartungsnebenversion von MariaDB veröffentlicht, wird diese mit den neuesten Zeitzonendaten zum Zeitpunkt der Veröffentlichung ausgeliefert. Wenn Sie die neuesten Versionen von RDS für MariaDB verwenden, verfügen Sie über aktuelle Zeitzonendaten von RDS. Wenn Sie sichergehen möchten, dass Ihre DB-Instance über aktuelle Zeitzonendaten verfügt, empfehlen wir ein Upgrade auf eine höhere DB-Engine-Version. Alternativ können Sie die Zeitzonentabellen in MariaDB-DB-Instances manuell ändern. Dazu können Sie SQL-Befehle verwenden oder das [Tool mysql\$1tzinfo\$1to\$1sql](https://mariadb.com/kb/en/mysql_tzinfo_to_sql/) in einem SQL-Client ausführen. Starten Sie nach der manuellen Aktualisierung der Zeitzonendaten Ihre DB-Instance neu, damit die Änderungen wirksam werden. Die Zeitzonendaten laufender DB-Instances werden von RDS nicht geändert oder zurückgesetzt. Neue Zeitzonendaten werden nur installiert, wenn Sie ein Upgrade der Datenbank-Engine-Version durchführen.
Sie können Ihre lokale Zeitzone auf die folgenden Werte einstellen.
| Bereich | Zeitzone |
| --- | --- |
| Afrika | Africa/Cairo, Africa/Casablanca, Africa/Harare, Africa/Monrovia, Africa/Nairobi, Africa/Tripoli, Africa/Windhoek |
| Amerika | America/Araguaina, America/Asuncion, America/Bogota, America/Buenos\$1Aires, America/Caracas, America/Chihuahua, America/Cuiaba, America/Denver, America/Fortaleza, America/Guatemala, America/Halifax, America/Manaus, America/Matamoros, America/Monterrey, America/Montevideo, America/Phoenix, America/Santiago, America/Tijuana |
| Asien | Asia/Amman, Asia/Ashgabat, Asia/Baghdad, Asia/Baku, Asia/Bangkok, Asia/Beirut, Asia/Calcutta, Asia/Damascus, Asia/Dhaka, Asia/Irkutsk, Asia/Jerusalem, Asia/Kabul, Asia/Karachi, Asia/Kathmandu, Asia/Krasnoyarsk, Asia/Magadan, Asia/Muscat, Asia/Novosibirsk, Asia/Riyadh, Asia/Seoul, Asia/Shanghai, Asia/Singapore, Asia/Taipei, Asia/Tehran, Asia/Tokyo, Asia/Ulaanbaatar, Asia/Vladivostok, Asia/Yakutsk, Asia/Yerevan |
| Atlantik | Atlantic/Azores |
| Australien | Australia/Adelaide, Australia/Brisbane, Australia/Darwin, Australia/Hobart, Australia/Perth, Australia/Sydney |
| Brasilien | Brazil/DeNoronha, Brazil/East |
| Kanada | Canada/Newfoundland, Canada/Saskatchewan, Canada/Yukon |
| Europa | Europe/Amsterdam, Europe/Athens, Europe/Dublin, Europe/Helsinki, Europe/Istanbul, Europe/Kaliningrad Europe/Moscow, Europe/Paris, Europe/Prague, Europe/Sarajevo |
| Pazifik | Pacific/Auckland, Pacific/Fiji, Pacific/Guam, Pacific/Honolulu, Pacific/Samoa |
| USA | US/Alaska, US/Central, US/East-Indiana, US/Eastern, US/Pacific |
| UTC | UTC |
# Bekannte Probleme und Einschränkungen für RDS für MariaDB
Die folgenden Punkte sind bekannte Probleme und Einschränkungen bei der Verwendung von RDS für MariaDB.
**Anmerkung**
Diese Liste ist nicht umfassend.
**Topics**
+ [MariaDB-Dateigrößenlimits in Amazon RDS](#RDS_Limits.FileSize.MariaDB)
+ [Reserviertes Wort InnoDB](#MariaDB.Concepts.InnodbDatabaseName)
+ [Benutzerdefinierte Ports](#MariaDB.Concepts.CustomPorts)
+ [Performance Insights](#MariaDB.Concepts.PerformanceInsights)
## 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](CHAP_Storage.md).
Die Option der InnoDB-Tabellenräumen (innodb\$1file\$1per\$1table) 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-file-per-table-tablespaces.html) 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](https://dev.mysql.com/doc/refman/5.7/en/partitioning.html) in der MySQL-Dokumentation.
**So ermitteln Sie die Größe aller InnoDB-Tabellenräume**
+ Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Tabellen zu groß ist und evtl. partitioniert werden sollte.
**Anmerkung**
Für MariaDB 10.6 und höher gibt diese Abfrage auch die Größe des Tabellenraums des InnoDB-Systems zurück.
Bei MariaDB-Versionen vor 10.6 können Sie die Größe des Tabellenraums des InnoDB-Systems nicht ermitteln, indem Sie die Systemtabellen abfragen. Es wird empfohlen, ein Upgrade auf eine neuere Version durchzuführen.
```
1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2)
2. as "Tablespace Size (GB)"
3. FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC;
```
**So ermitteln Sie die Größe von Nicht-InnoDB-Benutzertabellen**
+ Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Nicht-InnoDB-Benutzertabellen zu groß ist.
```
SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE)
/ 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')
and ENGINE<>'InnoDB';
```
**So aktivieren Sie InnoDB-Datei-pro-Tabelle-Tabellenräume**
+ Setzen Sie den `innodb_file_per_table`-Parameter in der Parametergruppe für die DB-Instance auf `1`.
**So deaktivieren Sie InnoDB-Datei-pro-Tabelle-Tabellenräume**
+ Setzen Sie den `innodb_file_per_table`-Parameter in der Parametergruppe für die DB-Instance auf `0`.
Weitere Informationen über das Updaten von Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
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.
```
1. ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=COPY;
```
## 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.
## Benutzerdefinierte Ports
Amazon RDS blockiert Verbindungen zum benutzerdefinierten Port 33060 für die MariaDB-Engine. Wählen Sie einen anderen Port für Ihre MariaDB-Engine.
## Performance Insights
InnoDB-Zähler sind in Performance Insights for RDS für MariaDB Version 10.11 nicht sichtbar, da sie von der MariaDB-Community nicht mehr unterstützt werden.