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 MySQL Amazon RDS unterstützt mehrere Versionen von MySQL für DB-Instances. Weitere Informationen zu unterstützten Versionen finden Sie unter [MySQL in Amazon-RDS-Versionen](MySQL.Concepts.VersionMgmt.md). Verwenden Sie die Amazon-RDS-Management-Tools bzw. -Schnittstellen zum Erstellen einer DB-Instance von Amazon RDS für MySQL. Sie können dann Folgendes durchführen: + Ändern der Größe Ihrer DB-Instance + Autorisieren von Verbindungen mit Ihrer 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. Amazon RDS für MySQL ist konform zu vielen Industriestandards. Sie können RDS-für-MySQL-Datenbanken für die Erstellung von HIPAA-kompatiblen Anwendungen verwenden. Mit RDS-für-MySQL-Datenbanken können Sie Gesundheitsdaten, darunter geschützte patientenbezogene Daten (Protected Health Information, PHI), im Rahmen eines Geschäftspartnervertrags (Business Associate Agreement, BAA) in AWS speichern. Amazon RDS für MySQL erfüllt auch die Sicherheitsanforderungen des Federal Risk and Authorization Management Program (FedRAMP). Darüber hinaus verfügt Amazon RDS für MySQL über eine FedRAMP Joint Authorization Board (JAB) Provisional Authority to Operate (P-ATO) bei der FedRAMP HIGH Baseline innerhalb der AWS GovCloud (US)-Regionen. Weitere Informationen über unterstützte Compliance-Standards finden Sie unter [AWSCloud-Compliance](https://aws.amazon.com/compliance/). Weitere Informationen zu den Funktionen in den einzelnen MySQL-Versionen finden Sie unter [The Main Features of MySQL](https://dev.mysql.com/doc/refman/8.0/en/features.html) in der MySQL-Dokumentation. 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 MySQL in einer Virtual Private Cloud (VPC) auf der Basis von Amazon VPC ausgeführt wird. Sie können auch Funktionen zu Ihrer MySQL-DB-Instance hinzufügen, indem Sie verschiedene Optionen aktivieren. Amazon RDS unterstützt Multi-AZ-Bereitstellungen für MySQL 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** + [ # Unterstützung von MySQL-Funktionen in Amazon RDS ](MySQL.Concepts.FeatureSupport.md) + [ # MySQL in Amazon-RDS-Versionen ](MySQL.Concepts.VersionMgmt.md) + [ # Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance ](USER_ConnectToInstance.md) + [ # Sichern von MySQL-DB-Instance-Verbindungen ](securing-mysql-connections.md) + [ # Verbesserung der Abfrageleistung für RDS für MySQL mit Amazon RDS Optimized Reads ](rds-optimized-reads.md) + [ # Verbesserung der Schreibleistung mit RDS-optimierten Schreibvorgängen für MySQL ](rds-optimized-writes.md) + [ # Upgrades der DB-Engine von RDS für MySQL ](USER_UpgradeDBInstance.MySQL.md) + [ # Aktualisieren einer Engine-Version für MySQL-DB-Snapshots ](mysql-upgrade-snapshot.md) + [ # Importieren von Daten in eine DB-Instance von Amazon RDS für MySQL ](MySQL.Procedural.Importing.Other.md) + [ # Arbeiten mit MySQL-Replikation in Amazon RDS ](USER_MySQL.Replication.md) + [ # Konfigurieren von Aktiv/Aktiv-Clustern von RDS für MySQL ](mysql-active-active-clusters.md) + [ # Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation ](MySQL.Procedural.Exporting.NonRDSRepl.md) + [ # Optionen für MySQL-DB-Instances ](Appendix.MySQL.Options.md) + [ # Parameter für MySQL ](Appendix.MySQL.Parameters.md) + [ # Geläufige DBA-Aufgaben für MySQL-DB-Instances ](Appendix.MySQL.CommonDBATasks.md) + [ # Lokale Zeitzone für MySQL-DB-Instances ](MySQL.Concepts.LocalTimeZone.md) + [ # Bekannte Probleme und Einschränkungen für Amazon RDS für MySQL ](MySQL.KnownIssuesAndLimitations.md) + [ # Referenz für gespeicherte RDS-für-MySQL-Verfahren ](Appendix.MySQL.SQLRef.md) # Unterstützung von MySQL-Funktionen in Amazon RDS RDS für MySQL unterstützt die meisten Funktionen von MySQL. 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 **MySQL 2022**. **Anmerkung** Die folgenden Listen sind nicht vollständig. **Topics** + [ ## Unterstützung von MySQL-Funktionen für die Hauptversionen von Amazon RDS für MySQL ](#MySQL.Concepts.FeatureSupport.MajorVersions) + [ ## Unterstützte Speicher-Engines für RDS für MySQL ](#MySQL.Concepts.Storage) + [ ## Verwenden von memcached und anderen Optionen mit MySQL in Amazon RDS ](#MySQL.Concepts.General.Options) + [ ## InnoDB-Cache-Warming für MySQL in Amazon RDS ](#MySQL.Concepts.InnoDBCacheWarming) + [ ## Inklusive Sprachänderungen für RDS für MySQL 8.4 ](#mysql-8-4-inclusive-language-changes) + [ ## MySQL-Funktionen, die nicht von Amazon RDS unterstützt werden ](#MySQL.Concepts.Features) ## Unterstützung von MySQL-Funktionen für die Hauptversionen von Amazon RDS für MySQL Den folgenden Abschnitten können Sie Informationen zur Unterstützung von MySQL-Funktionen für die Hauptversionen von Amazon RDS für MySQL entnehmen: **Topics** + [ ### Unterstützung von MySQL 8.4 in Amazon RDS ](#MySQL.Concepts.FeatureSupport.8-4) Informationen zu den unterstützten Nebenversionen von Amazon RDS für MySQL finden Sie unter [Unterstützte MySQL-Nebenversionen in Amazon RDS](MySQL.Concepts.VersionMgmt.md#MySQL.Concepts.VersionMgmt.Supported). ### Unterstützung von MySQL 8.4 in Amazon RDS Amazon RDS unterstützt die folgenden neuen Funktionen für DB-Instances, auf denen MySQL 8.4 oder höher ausgeführt wird. + **Kryptografische Bibliothek** — RDS for MySQL ersetzte OpenSSL durch AWS Libcrypto (AWS-LC), das FIPS 140-3-zertifiziert ist. Weitere Informationen finden Sie im Repository unter. AWS-LC GitHub [https://github.com/aws/aws-lc](https://github.com/aws/aws-lc) + **TLS Änderungen**: RDS für MySQL unterstützt nur TLS 1.2 und TLS 1.3. Weitere Informationen finden Sie unter [SSL/TLS-Unterstützung für MySQL-DB-Instances in Amazon RDS](MySQL.Concepts.SSLSupport.md). + **Memcached-Unterstützung**: Die Memcached-Benutzeroberfläche ist in MySQL 8.4 nicht mehr verfügbar. Weitere Informationen finden Sie unter [Unterstützung für MySQL-memcached](Appendix.MySQL.Options.memcached.md). + **Standard-Authentifizierungs-Plugin**: Das Standard-Authentifizierungs-Plugin ist `caching_sha2_password`. Weitere Informationen finden Sie unter [Standardauthentifizierungs-Plugin für MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin). + **Client-Dienstprogramm `mysqlpump`**: Das Client-Dienstprogramm `mysqlpump` ist in MySQL 8.4 nicht mehr verfügbar. Weitere Informationen finden Sie unter [Rollenbasiertes Berechtigungsmodell für RDS für MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md) und [mysqldump und mysqlpump](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/mysqldump-and-mysqlpump.html) in der *AWS Prescriptive Guidance*. + **Gespeicherte Prozeduren für verwaltete Replikation**: Wenn Sie gespeicherte Prozeduren verwenden, um die Replikation mit einem mit `caching_sha2_password` konfigurierten Replikationsbenutzer zu verwalten, müssen Sie TLS konfigurieren, indem Sie `SOURCE_SSL=1` festlegen. `caching_sha2_password` ist das Standard-Authentifizierungs-Plugin für RDS für MySQL 8.4. + **Änderungen des Parameterverhaltens**: Die folgenden Parameter wurden für MySQL 8.4 geändert. + `innodb_dedicated_server`: Dieser Parameter ist nun standardmäßig aktiviert. Weitere Informationen finden Sie unter [Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + `innodb_buffer_pool`: Die Datenbank-Engine berechnet nun diesen Parameter, Sie können diese Einstellung jedoch überschreiben. Weitere Informationen finden Sie unter [Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + `innodb_redo_log_capacity`: Dieser Parameter steuert nun die Größe der Redo-Protokolldateien. Die Datenbank-Engine berechnet nun diesen Parameter, Sie können diese Einstellung jedoch überschreiben. Weitere Informationen finden Sie unter [Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + **Veraltete oder entfernte Parameter**: Die folgenden Parameter der Parametergruppen für DB-Instances von MySQL 8.4 wurden in RDS für MySQL entfernt. Der Parameter `innodb_redo_log_capacity` steuert nun die Größe der Redo-Protokolldateien. + `innodb_log_file_size` + `innodb_log_files_in_group` + **Neue Standardwerte für Parameter**: Die folgenden Parameter haben neue Standardwerte für DB-Instances von MySQL 8.4: + Verschiedene leistungsbezogene Parameter der MySQL-Community wurden geändert. Weitere Informationen finden Sie unter [Neue Funktionen in MySQL 8.4 ab MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html). Wir empfehlen Ihnen, die Leistung Ihrer Anwendung in RDS für MySQL 8.4 zu testen, bevor Sie eine Produktions-Instance migrieren. + `innodb_purge_threads`: Der Standardwert ist auf die Formel `LEAST({DBInstanceVCPU/2},4)` festgelegt, um zu verhindern, dass die Länge der InnoDB-Verlaufsliste zu umfangreich wird. + `group_replication_exit_state_action`: Der Standardwert ist `OFFLINE_MODE`, was dem Standardwert in der MySQL-Community entspricht. Weitere Informationen finden Sie unter [Überlegungen und bewährte Methoden für Aktiv/Aktiv-Cluster von RDS für MySQL](mysql-active-active-clusters-considerations-limitations.md#mysql-active-active-clusters-considerations). + `binlog_format`: Der Standardwert ist `ROW`, was dem Standardwert in der MySQL-Community entspricht. Sie können den Parameter für Single-AZ-DB-Instances oder Multi-AZ-DB-Instances ändern, jedoch nicht für Multi-AZ-DB-Cluster. Multi-AZ-DB-Cluster verwenden eine halbsynchrone Replikation und wenn `binlog_format` auf `MIXED` oder `STATEMENT` festgelegt ist, schlägt die Replikation fehl. + **Inklusive Sprachänderungen**: RDS für MySQL 8.4 enthält Änderungen von RDS für MySQL 8.0 in Bezug auf Schlüsselwörter und Systemschemas für inklusive Sprache. Weitere Informationen finden Sie unter [Inklusive Sprachänderungen für RDS für MySQL 8.4](#mysql-8-4-inclusive-language-changes). Eine Liste aller Funktionen und Änderungen in MySQL 8.4 finden Sie unter [Neue Funktionen in MySQL 8.4 ab MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) in der MySQL-Dokumentation. Eine Liste der nicht unterstützten Funktionen finden Sie unter [MySQL-Funktionen, die nicht von Amazon RDS unterstützt werden](#MySQL.Concepts.Features). ## Unterstützte Speicher-Engines für RDS für MySQL Während MySQL mehrere Speicher-Engines mit unterschiedlichen Fähigkeiten unterstützt, sind nicht alle von ihnen für die Wiederherstellung und Langlebigkeit von Daten optimiert. Amazon RDS unterstützt die InnoDB-Speicher-Engine für MySQL-DB-Instances vollständig. Amazon RDS-Funktionen wie Point-In-Time Wiederherstellung und Snapshot-Wiederherstellung erfordern eine wiederherstellbare Speicher-Engine und werden nur für die InnoDB-Speicher-Engine unterstützt. Weitere Informationen finden Sie unter [Unterstützung für MySQL-memcached](Appendix.MySQL.Options.memcached.md). Die verbündete Speicher-Engine wird aktuell von Amazon RDS für MySQL nicht unterstützt. Bei vom Benutzer erstellten Schemas unterstützt die MyISAM-Speicher-Engine keine zuverlässige Wiederherstellung und kann zu Datenverlust oder Beschädigung führen, wenn MySQL nach einer Wiederherstellung neu gestartet wird, wodurch verhindert wird, dass die Wiederherstellung oder Point-In-Time Snapshot-Wiederherstellung wie vorgesehen funktioniert. Wenn Sie trotzdem MyISAM mit Amazon-RDS-Snapshots verwenden möchten, kann dies unter Umständen hilfreich sein. **Anmerkung** Systemtabellen im `mysql`-Schema können sich im MyISAM-Speicher befinden. Wenn Sie vorhandene MyISAM-Tabellen in InnoDB-Tabellen konvertieren möchten, können Sie den Befehl `ALTER TABLE` verwenden (z. B. `alter table TABLE_NAME engine=innodb;`). Vergessen Sie nicht, dass MyISAM und InnoDB verschiedene Stärken und Schwächen haben, also sollten Sie eine vollständige Bewertung der Auswirkungen vornehmen, bevor Sie Ihre Anwendungen umstellen. MySQL 5.1, 5.5 und 5.6 werden in Amazon RDS nicht mehr unterstützt. Sie können jedoch bestehende MySQL 5.1-, 5.5- und 5.6-Snapshots bei Bedarf wiederherstellen. Wenn Sie einen MySQL-5.1-, 5.5- oder 5.6-Snapshot wiederherstellen, wird die DB-Instance automatisch auf MySQL 5.7 aktualisiert. ## Verwenden von memcached und anderen Optionen mit MySQL in Amazon RDS Die meisten Amazon-RDS-DB-Engines unterstützen Optionsgruppen, die Ihnen ermöglichen, zusätzliche Funktionen für Ihre DB-Instance auszuwählen. DB-Instances von RDS für MySQL unterstützen die Option `memcached`, einen einfachen schlüsselbasierten Cache. Weitere Informationen über `memcached` und andere Optionen finden Sie unter [Optionen für MySQL-DB-Instances](Appendix.MySQL.Options.md). Weitere Informationen über das Arbeiten mit Optionsgruppen finden Sie unter [Arbeiten mit Optionsgruppen](USER_WorkingWithOptionGroups.md). ## InnoDB-Cache-Warming für MySQL in Amazon RDS Die InnoDB-Cache-Warnung kann zu Leistungssteigerungen Ihrer MySQL-DB-Instance führen, indem der aktuelle Zustand des Bufferpools gespeichert wird, wenn die DB-Instance heruntergefahren wird, und beim Hochfahren der DB-Instance der Bufferpool erneut aus den gespeicherten Informationen geladen wird. Dies überbrückt die ansonsten notwendige "Aufwärmphase" des Bufferpools bei normaler Verwendung von Datenbanken und lädt den Bufferpool vorab mit den Seiten für bereits bekannte Anfragen. Die Datei, die den gespeicherten Bufferpool abspeichert, speichert nur Metadaten für die Seite ab, die sich in dem Bufferpool befinden, nicht die Seiten selbst. Dadurch benötigt die Datei nur wenig Speicherplatz. Die Dateigröße beträgt nur 0,2 % der Cachegröße. So beträgt beispielsweise bei einem 64 GiB großen Cache die Größe der Cache-Initialisierungsdatei 128 MiB. Weitere Informationen zur InnoDB-Cache-Initialisierung finden Sie unter [Saving and Restoring the Buffer Pool State](https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html) in der MySQL-Dokumentation. DB-Instances von RDS für MySQL unterstützen InnoDB-Cache-Warming. Um InnoDB-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. Die Änderung dieser Parameterwerte in einer Parametergruppe wirkt sich auf alle MySQL-DB-Instances aus, die diese Parametergruppe verwenden. Sie müssen möglicherweise eine neue Parametergruppe für diese Instances erstellen, um InnoDB-Cache-Initialisierung für bestimmte MySQL-DB-Instances zu aktivieren. Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). InnoDB-Cache-Initialisierung bringt vor allem einen Leistungsvorteil für DB-Instances, die den Standardspeicher verwenden. Wenn Sie PIOPS-Speicher verwenden, findet in der Regel keine signifikante Leistungssteigerung statt. **Wichtig** Wenn Ihre MySQL-DB-Instance nicht ordnungsgemäß herunterfährt, wie beispielsweise während eines Failovers, dann wird der Bufferpool nicht auf der Festplatte gespeichert. In diesem Fall lädt MySQL eine verfügbare Bufferpool-Datei, wenn die DB-Instance neu gestartet wurde. 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 InnoDB haben. Sie können ein Ereignis erstellen, das den Bufferpool in regelmäßigen Abständen automatisch verwirft. 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 zu MySQL-Ereignissen finden Sie unter [Event Syntax](https://dev.mysql.com/doc/refman/8.0/en/events-syntax.html) in der MySQL-Dokumentation. ### Entladen und Laden des Zwischenspeicher-Pools auf Abruf Sie können den InnoDB-Cache „nach Bedarf“ 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. ## Inklusive Sprachänderungen für RDS für MySQL 8.4 RDS für MySQL 8.4 enthält Änderungen von MySQL 8.4 in Bezug auf Schlüsselwörter und Systemschemas für inklusive Sprache. Beispielsweise wird der Befehl `SHOW REPLICA STATUS` durch `SHOW SLAVE STATUS` ersetzt. **Topics** + [ ### Änderungen des Namens von Konfigurationsparametern ](#mysql-8-4-inclusive-language-changes-params) + [ ### Änderungen des Namens von gespeicherten Prozeduren ](#mysql-8-4-inclusive-language-changes-sp) ### Änderungen des Namens von Konfigurationsparametern Die folgenden Konfigurationsparameter haben neue Namen in RDS für MySQL 8.4. Aus Kompatibilitätsgründen können Sie die Parameternamen im Client `mysql` unter Verwendung eines der beiden Namen überprüfen. Beim Ändern der Werte in einer benutzerdefinierten MySQL 8.4-Parametergruppe können Sie nur die neuen Namen verwenden. Weitere Informationen finden Sie unter [Standard- und benutzerdefinierte Parametergruppen](parameter-groups-overview.md#parameter-groups-overview.custom). | Name, der entfernt werden soll | Neuer oder bevorzugter Name | | --- | --- | | `init_slave` | `init_replica` | | `log_slave_updates` | `log_replica_updates` | | `log_slow_slave_statements` | `log_slow_replica_statements` | | `rpl_stop_slave_timeout` | `rpl_stop_replica_timeout` | | `skip_slave_start` | `skip_replica_start` | | `slave_checkpoint_group` | `replica_checkpoint_group` | | `slave_checkpoint_period` | `replica_checkpoint_period` | | `slave_compressed_protocol` | `replica_compressed_protocol` | | `slave_exec_mode` | `replica_exec_mode` | | `slave_load_tmpdir` | `replica_load_tmpdir` | | `slave_max_allowed_packet` | `replica_max_allowed_packet` | | `slave_net_timeout` | `replica_net_timeout` | | `slave_parallel_type` | `replica_parallel_type` | | `slave_parallel_workers` | `replica_parallel_workers` | | `slave_pending_jobs_size_max` | `replica_pending_jobs_size_max` | | `slave_preserve_commit_order` | `replica_preserve_commit_order` | | `slave_skip_errors` | `replica_skip_errors` | | `slave_sql_verify_checksum` | `replica_sql_verify_checksum` | | `slave_transaction_retries` | `replica_transaction_retries` | | `slave_type_conversions` | `replica_type_conversions` | | `sql_slave_skip_counter` | `sql_replica_skip_counter` | **Anmerkung** Der Parameter `replica_allow_batching` ist nicht verfügbar, da Amazon RDS keine NDB-Cluster unterstützt. ### Änderungen des Namens von gespeicherten Prozeduren Die folgenden gespeicherten Prozeduren haben neue Namen in RDS für MySQL 8.4. Aus Kompatibilitätsgründen können Sie beide Namen in der ersten Version von RDS für MySQL 8.4 verwenden. Die alten Prozedurnamen sollen in einer zukünftigen Version entfernt werden. Weitere Informationen finden Sie unter [Konfigurieren, Starten und Beenden der Binärprotokollreplikation (binlog)](mysql-stored-proc-replicating.md). | Name, der entfernt werden soll | Neuer oder bevorzugter Name | | --- | --- | | `mysql.rds_next_master_log` | `mysql.rds_next_source_log ` | | `mysql.rds_reset_external_master` | `mysql.rds_reset_external_source` | | `mysql.rds_set_external_master` | `mysql.rds_set_external_source` | | `mysql.rds_set_external_master_with_auto_position` | `mysql.rds_set_external_source_with_auto_position` | | `mysql.rds_set_external_master_with_delay` | `mysql.rds_set_external_source_with_delay` | | `mysql.rds_set_master_auto_position` | `mysql.rds_set_source_auto_position` | ## MySQL-Funktionen, die nicht von Amazon RDS unterstützt werden Amazon RDS bietet zurzeit keine Unterstützung für die folgenden MySQL-Funktionen: + Authentifizierungs-Plugin + Fehlerprotokollierung im Systemprotokoll + InnoDB-Tablespace-Verschlüsselung + NDB-Cluster + Passwortstärke-Plugin + Persistente Systemvariablen + Plugin für das Umschreiben von Abfragen + Semi-synchrone Replikation, außer für Multi-AZ-DB-Cluster + Transportierbarer Tablespace + X-Plugin 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. Amazon RDS unterstützt den Zugriff auf Datenbanken in 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. Wenn Sie eine DB-Instance erstellen, wird Ihnen die Rolle *db\$1owner* für alle Datenbanken in dieser Instance zugewiesen und Sie verfügen über die Berechtigungen für alle Datenbankebenen, außer für jene, die für Backups verwendet werden. Amazon RDS verwaltet Backups für Sie. # MySQL in Amazon-RDS-Versionen In MySQL werden 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 5.7 auf 8.0. Eine Versionsänderung gilt als geringfügig, wenn sich nur die Nummer der Nebenversion ändert, z. B. von Version 8.0.32 auf 8.0.34. **Topics** + [ ## Unterstützte MySQL-Nebenversionen in Amazon RDS ](#MySQL.Concepts.VersionMgmt.Supported) + [ ## Unterstützte MySQL-Hauptversionen in Amazon RDS ](#MySQL.Concepts.VersionMgmt.ReleaseCalendar) + [ ## Extended-Support-Versionen von Amazon RDS für RDS für MySQL ](#mysql-extended-support-releases) + [ ## Arbeiten mit der Datenbank-Vorschauumgebung ](#mysql-working-with-the-database-preview-environment) + [ ## MySQL Version 9.5 in der Database Preview-Umgebung ](#mysql-preview-environment-version-9-5) + [ ## MySQL Version 9.4 in der Database Preview-Umgebung ](#mysql-preview-environment-version-9-4) + [ ## MySQL Version 9.3 in der Database Preview-Umgebung ](#mysql-preview-environment-version-9-3) + [ ## Veraltete Versionen für Amazon RDS für MySQL ](#MySQL.Concepts.DeprecatedVersions) ## Unterstützte MySQL-Nebenversionen in Amazon RDS Amazon RDS unterstützt derzeit die folgenden MySQL-Nebenversionen. **Anmerkung** Amazon RDS Extended Support ist für Nebenversionen nicht verfügbar. In der folgenden Tabelle sind die Nebenversionen von MySQL 8.4 angegeben, die von Amazon RDS derzeit unterstützt werden. | MySQL-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS-Ende des Standard-Supportdatums | | --- | --- | --- | --- | | 8.4.8 | 20. Januar 2026 | 3. Februar 2026 | 3. Februar 2027 | | 8.4.7 | 21. Oktober 2025 | 13. November 2025 | 30. November 2026 | | 8.4.6 | 22. Juli 2025 | 1. August 2025 | 30. September 2026 | | 8.4.5 | 15. April 2025 | 29. April 2025 | 30. September 2026 | | 8.4.4 | 21. Januar 2025 | 19. Februar 2025 | 31. Mai 2026 | | 8.4.3 | 15. Oktober 2024 | 21. November 2024 | 31. Mai 2026 | In der folgenden Tabelle sind die Nebenversionen von MySQL 8.0 angegeben, die von Amazon RDS derzeit unterstützt werden. **Anmerkung** Bei Nebenversionen kann es sein, dass der Standardsupport vor den Hauptversionen ausläuft. Beispielsweise hat die Nebenversion 8.0.28 das Ende des Standardsupports am 28. März 2024 erreicht, während der Standardsupport für die Hauptversion 8.0 erst am 31. Juli 2026 ausläuft. RDS unterstützt weitere 8.0.\$1-Nebenversionen, die die MySQL-Community zwischen diesen Datumsangaben veröffentlicht. Es wird empfohlen, für alle Hauptversionen so oft wie möglich ein Upgrade auf die neueste verfügbare Nebenversion durchzuführen. | MySQL-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS-Ende des Standard-Supportdatums | | --- | --- | --- | --- | | 8.0.45 | 20. Januar 2026 | 3. Februar 2026 | 31. Juli 2026 | | 8.0.44 | 21. Oktober 2025 | 13. November 2025 | 31. Juli 2026 | | 8.0.43 | 22. Juli 2025 | 1. August 2025 | 31. Juli 2026 | | 8,0,42 | 15. April 2025 | 29. April 2025 | 31. Juli 2026 | | 8,0,41 | 21. Januar 2025 | 19. Februar 2025 | 31. Mai 2026 | | 8.0.40 | 15. Oktober 2024 | 13. November 2024 | 31. Mai 2026 | In der folgenden Tabelle sind die Nebenversionen von MySQL 5.7 angegeben, die für Amazon RDS Extended Support derzeit verfügbar sind. **Anmerkung** Bei Nebenversionen kann es sein, dass der erweiterte Support vor den Hauptversionen ausläuft. Beispielsweise erreicht die Nebenversion 5.7.44-RDS.20240529 das Ende des erweiterten Supports im September 2025, während der erweiterte Support für die Hauptversion 5.7 erst 28. Februar 2027 ausläuft. RDS generiert und veröffentlicht weitere 5.7.44-RDS.xxyyzz-Nebenversionen zwischen diesen Datumsangaben. Es wird empfohlen, für alle Hauptversionen so oft wie möglich ein Upgrade auf die neueste verfügbare Nebenversion durchzuführen. | MySQL-Engine-Version | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | RDS: Ende des Extended Support | | --- | --- | --- | --- | | 5.7.44-RDS.20260212\$1 | Nicht zutreffend | 26. Februar 2026 | 28. Februar 2027 | | 5.7.44-RDS.20251212\$1 | Nicht zutreffend | 12. Dezember 2025 | 30. Dezember 2026 | | 5.7.44-RDS.20250818\$1 | Nicht zutreffend | 15. September 2025 | 30. September 2026 | | 5.7.44-RDS.20250508\$1 | Nicht zutreffend | 20. Mai 2025 | 30. September 2026 | | 5.7.44-RDS.20250213\$1 | Nicht zutreffend | 12. März 2025 | 30. September 2026 | | 5.7.44-RDS.20250103\$1 | Nicht zutreffend | 13. Februar 2025 | 31. Mai 2026 | \$1 Die MySQL Community hat die Hauptversion 5.7 eingestellt und veröffentlicht keine neuen Nebenversionen mehr. Dies ist eine Nebenversion, die Amazon RDS mit wichtigen Sicherheitspatches und Bugfixes für MySQL 5.7-Datenbanken veröffentlicht hat, die vom RDS Extended Support abgedeckt werden. Weitere Informationen zu diesen Nebenversionen finden Sie unter [Extended-Support-Versionen von Amazon RDS für RDS für MySQL](#mysql-extended-support-releases). Weitere Informationen zum RDS Extended Support finden Sie unter [Amazon RDS Extended Support mit Amazon RDS](extended-support.md). Sie können eine beliebige aktuell unterstützte MySQL-Version festlegen, wenn Sie eine DB-Instance erstellen. Sie können die Hauptversionen (wie z. B. MySQL 5.7) 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. Führen Sie den Befehl aus, 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 MySQL aufzulisten, führen Sie den folgenden CLI-Befehl aus: ``` aws rds describe-db-engine-versions --engine mysql --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` Die standardmäßige MySQL-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 standardmäßige 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 mysql --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 MySQL-Nebenengine für die Hauptversion 5.7 und die USA West (Oregon) AWS-Region (us-west-2) zurück: ``` aws rds describe-db-engine-versions --default-only --engine mysql --engine-version 5.7 --region us-west-2 --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` Mit Amazon RDS können Sie steuern, wann Ihre MySQL-Instance auf eine neue Amazon-RDS-unterstützte Hauptversion aktualisiert wird. Sie können die Kompatibilität mit bestimmten MySQL-Versionen aufrechterhalten, neue Versionen mit Ihrer Anwendung testen, bevor Sie diese für die Produktion bereitstellen, und Hauptversions-Upgrades zu ausgewählten Zeiten durchführen lassen. Wenn das automatische Upgrade der Nebenversion aktiviert ist, wird Ihre DB-Instance automatisch auf neue MySQL-Nebenversionen aktualisiert, da diese von Amazon RDS unterstützt werden. Dieser Patch tritt während Ihres geplanten Wartungsfensters auf. Sie können eine DB-Instance ändern, um automatische Upgrades der Nebenversion zu aktivieren oder zu deaktivieren. Wenn Sie sich von automatisch geplanten Upgrades abmelden, können Sie ein manuelles Upgrade auf eine der unterstützten Unterversionen durchführen, indem Sie die selben Schritte befolgen, wie bei einem Update auf eine Hauptversion. Weitere Informationen finden Sie unter [Upgrade der Engine-Version für eine DB-Instance ](USER_UpgradeDBInstance.Upgrading.md). Amazon RDS unterstützt derzeit die folgenden Upgrades für Hauptversionen der MySQL-Datenbank-Engine: + MySQL 5.7 auf MySQL 8.0 + MySQL 8.0 auf MySQL 8.4 Da Hauptversionsaktualisierungen Kompatibilitätsrisiken bergen, werden sie nicht automatisch ausgeführt. Sie müssen für das Ändern der DB-Instance eine Anfrage stellen. Sie sollten alle Upgrades gründlich testen, bevor Sie Ihre Produktions-Instances aktualisieren. Weitere Informationen über das Upgraden einer MySQL-DB-Instance finden Sie unter [Upgrades der DB-Engine von RDS für MySQL](USER_UpgradeDBInstance.MySQL.md). Sie können vor dem Aktualisieren eine DB-Instance gegen eine neue Version testen, indem Sie einen DB-Snapshot Ihrer bestehenden DB-Instance erstellen, von diesem DB-Snapshot eine neue DB-Instance wiederherstellen und dann eine Versions-Upgrade für die neue DB-Instance durchführen. Sie können dann sicher mit dem aktualisierten Klon Ihrer DB-Instance experimentieren, bevor Sie entscheiden, Ihre originale DB-Instance zu aktualisieren. ### MySQL-Nebenversionen in Amazon RDS Informationen zu den Änderungen, die die MySQL-Community an den Nebenversionen vorgenommen hat, finden Sie unter [Critical Patch Updates, Security Alerts and Bulletins](https://www.oracle.com/security-alerts/) auf der Oracle-Website. Wählen Sie unter **Wichtige Patch-Aktualisierung** den Monat aus, in dem Oracle die Nebenversion veröffentlicht hat. Wählen Sie dann unter **Betroffene Produkte und Versionen** die MySQL-Nebenversion aus. **Topics** + [ #### MySQL versie 8.4.8 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.8) + [ #### MySQL versie 8.4.7 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.7) + [ #### MySQL-Version 8.4.6 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.6) + [ #### MySQL-Version 8.4.5 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.5) + [ #### MySQL-Version 8.4.4 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.4) + [ #### MySQL versie 8.0.45 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.45) + [ #### MySQL versie 8.0.44 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.44) + [ #### MySQL-Version 8.0.43 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.43) + [ #### MySQL-Version 8.0.42 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.42) + [ #### MySQL-Version 8.0.41 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.41) + [ #### MySQL-Version 8.0.40 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.40) + [ #### MySQL-Version 8.0.39 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.39) + [ #### MySQL-Version 8.0.37 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.37) #### MySQL versie 8.4.8 MySQL Version 8.4.8 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-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. #### MySQL versie 8.4.7 MySQL Version 8.4.7 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. #### MySQL-Version 8.4.6 MySQL-Version 8.4.6 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. #### MySQL-Version 8.4.5 MySQL-Version 8.4.5 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. **Neue Features und Verbesserungen** + Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025b` basieren. #### MySQL-Version 8.4.4 MySQL-Version 8.4.4 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. **Neue Features und Verbesserungen** + Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025a` basieren. + Es wurde ein Fehler behoben, der bei der Ausführung der gespeicherten Amazon-RDS-Prozeduren `mysql.rds_set_configuration` und `mysql.rds_kill` zu einem Kollationsfehler führte. #### MySQL versie 8.0.45 MySQL Version 8.0.45 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-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. #### MySQL versie 8.0.44 MySQL Version 8.0.44 ist jetzt auf Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. #### MySQL-Version 8.0.43 MySQL-Version 8.0.43 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. #### MySQL-Version 8.0.42 MySQL-Version 8.0.42 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. **Neue Features und Verbesserungen** + Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025b` basieren. #### MySQL-Version 8.0.41 MySQL-Version 8.0.41 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. **Neue Features und Verbesserungen** + Die Zeitzonenangaben wurden so aktualisiert, dass sie auf `tzdata2025a` basieren. + Es wurde ein Fehler behoben, der bei der Ausführung der gespeicherten Amazon-RDS-Prozeduren `mysql.rds_set_configuration` und `mysql.rds_kill` zu einem Kollationsfehler führte. #### MySQL-Version 8.0.40 MySQL-Version 8.0.40 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. **Neue Features und Verbesserungen** + Es wurde ein Fehler behoben, der bei Datenbank-Upgrades zu nicht übereinstimmenden Zeichensätzen führte. #### MySQL-Version 8.0.39 MySQL-Version 8.0.39 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. **Neue Features und Verbesserungen** + Es wurde ein Fehler behoben, der dazu führte, dass `sql_log_off` mit der Berechtigung `SESSION_VARIABLES_ADMIN` nicht ordnungsgemäß funktionierte. + Es wurde ein Fehler behoben, der dazu führte, dass der Hauptbenutzer die Berechtigung `SESSION_VARIABLE_ADMIN` anderen Datenbankbenutzern nicht gewähren konnte. + Es wurde ein Fehler behoben, der bei der Ausführung der von RDS bereitgestellten gespeicherten Prozeduren zu einer ungültigen Sortierungsmischung führte. #### MySQL-Version 8.0.37 MySQL-Version 8.0.37 ist jetzt für Amazon RDS verfügbar. Diese Version enthält Korrekturen und Verbesserungen, die von der MySQL-Community und in Amazon RDS hinzugefügt wurden. **Neue Features und Verbesserungen** + Ein Fehler bei der Ausführung einer sofortigen DDL-Anweisung gefolgt von einem UPDATE, das einen Assert-Fehler verursachte, wurde behoben. ## Unterstützte MySQL-Hauptversionen in Amazon RDS Die Hauptversionen von RDS für MySQL stehen mindestens bis zum Ende des Lebenszyklus der Community für die entsprechende Community-Version unter Standard-Support zur Verfügung. Gegen eine Gebühr können Sie eine Hauptversion auch nach Ablauf des Standard-Supports von RDS weiter ausführen. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon RDS](extended-support.md) und [Amazon RDS für MySQL – Preise](https://aws.amazon.com/rds/mysql/pricing/). Sie können die folgenden Daten verwenden, um Ihre Test- und Upgrade-Zyklen zu planen. **Anmerkung** Mithilfe der AWS CLI oder der RDS-API können Sie sich auch Informationen zu den Support-Daten für wichtige Engine-Versionen anzeigen lassen. Weitere Informationen finden Sie unter [Anzeigen der Support-Daten für Engine-Versionen in Amazon RDS Extended Support](extended-support-viewing-support-dates.md). | MySQL Hauptversion | Datum der Community-Veröffentlichung | Datum der Veröffentlichung von RDS | Datum des Lebensendes der Gemeinschaft | RDS-Ende des Standard-Supportdatums | RDS: Beginn des Extended Support, Jahr 1, Preisdatum | RDS: Beginn des Extended Support, Jahr 3, Preisdatum | RDS: Ende des Extended Support | | --- | --- | --- | --- | --- | --- | --- | --- | | MySQL 8.4 | 30. April 2024 | 21. November 2024 | 30. April 2029 | 31. Juli 2029 | 1. August 2029 | 1. August 2031 | 31. Juli 2032 | | MySQL 8.0 | 19. April 2018 | 23. Oktober 2018 | 30. April 2026 | 31. Juli 2026 | 1. August 2026 | 1. August 2028 | 31. Juli 2029 | | MySQL 5.7\$1 | 21. Oktober 2015 | 22. Februar 2016 | 31. Oktober 2023 | 29. Februar 2024 | 1. März 2024 | 1. März 2026 | 28. Februar 2027 | \$1 MySQL 5.7 ist jetzt nur noch für RDS Extended Support verfügbar. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon RDS](extended-support.md). ## Extended-Support-Versionen von Amazon RDS für RDS für MySQL Im Folgenden werden alle Versionen von RDS Extended Support für RDS für MySQL aufgelistet. **Topics** + [ ### Erweiterte RDS-Unterstützung für RDS für MySQL Version 5.7.44-RDS.20260212 ](#mysql-extended-support-releases-version-5.7.44-RDS.20260212) + [ ### Erweiterte RDS-Unterstützung für RDS für MySQL Version 5.7.44-RDS.20251212 ](#mysql-extended-support-releases-version-5.7.44-RDS.20251212) + [ ### Erweiterte RDS-Unterstützung für RDS für MySQL Version 5.7.44-RDS.20250818 ](#mysql-extended-support-releases-version-5.7.44-RDS.20250818) + [ ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250508 ](#mysql-extended-support-releases-version-5.7.44-20250508) + [ ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250213 ](#mysql-extended-support-releases-version-5.7.44-20250213) + [ ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250103 ](#mysql-extended-support-releases-version-5.7.44-20250103) + [ ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240808 ](#mysql-extended-support-releases-version-5.7.44-20240808) + [ ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240529 ](#mysql-extended-support-releases-version-5.7.44-20240529) + [ ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240408 ](#mysql-extended-support-releases-version-5.7.44-20240408) ### Erweiterte RDS-Unterstützung für RDS für MySQL Version 5.7.44-RDS.20260212 RDS Extended Support für RDS for MySQL Version 5.7.44-RDS.20260212 ist verfügbar. **Behobene Fehler:** + Aktualisieren Sie das Testzertifikat, das zum Testen verwendet wurde, um den Fehler 22295186 zu beheben. + Behebt ein Speicherleck mit Präfixindex in BLOB-Spalten. **CVEs behoben:** + [CVE-2026-21936](https://nvd.nist.gov/vuln/detail/CVE-2026-21936) + [CVE-2026-21968](https://nvd.nist.gov/vuln/detail/CVE-2026-21968) + [CVE-2026-21941](https://nvd.nist.gov/vuln/detail/CVE-2026-21941) + [CVE-2026-21948](https://nvd.nist.gov/vuln/detail/CVE-2026-21948) ### Erweiterte RDS-Unterstützung für RDS für MySQL Version 5.7.44-RDS.20251212 RDS Extended Support für RDS for MySQL Version 5.7.44-RDS.20251212 ist verfügbar. **Behobene Fehler:** + Es wurde ein Problem beim Serverstart behoben, wenn die Größe des Pufferpools die Obergrenze überschritt. + Ein Fehler wurde behoben, der dazu führte`INFORMATION_SCHEMA.INNODB_LOCKS`, dass der Server nicht normal beendet wurde. + Ein Problem mit der JUnit Berichtsunterstützung in MySQL Test Run (MTR) wurde behoben. + Kompilierungsprobleme beim Erstellen mit `-DWITH_INNODB_MEMCACHED=ON` Option behoben. + Es wurde ein Problem mit der Ausführung von MySQL Test Run (MTR) für den Fehler 25182306 behoben. **CVEs behoben:** + [CVE-2025-53054](https://nvd.nist.gov/vuln/detail/CVE-2025-53054) + [CVE-2025-53044](https://nvd.nist.gov/vuln/detail/CVE-2025-53044) + [CVE-2025-53045](https://nvd.nist.gov/vuln/detail/CVE-2025-53045) + [CVE-2025-53062](https://nvd.nist.gov/vuln/detail/CVE-2025-53062) + [CVE-2025-53040](https://nvd.nist.gov/vuln/detail/CVE-2025-53040) + [CVE-2025-53042](https://nvd.nist.gov/vuln/detail/CVE-2025-53042) + [CVE-2025-53067](https://nvd.nist.gov/vuln/detail/CVE-2025-53067) ### Erweiterte RDS-Unterstützung für RDS für MySQL Version 5.7.44-RDS.20250818 RDS Extended Support für RDS for MySQL Version 5.7.44-RDS.20250818 ist verfügbar. **Behobene Fehler:** + Es wurde ein Problem behoben, bei dem das Plugin zum Umschreiben von Abfragen fehlschlug, wenn der Server mit betrieben wurde. `autocommit=OFF` + Es wurde ein Berechtigungsproblem behoben, das verhinderte, dass Debian- und Ubuntu-Builds im rootless-Modus ausgeführt wurden. + Fehlendes Update für Bug 30875669 behoben. **CVEs behoben:** + [CVE-2025-50082](https://nvd.nist.gov/vuln/detail/CVE-2025-50082) + [CVE-2025-50083](https://nvd.nist.gov/vuln/detail/CVE-2025-50083) + [CVE-2025-50079](https://nvd.nist.gov/vuln/detail/CVE-2025-50079) + [CVE-2025-50084](https://nvd.nist.gov/vuln/detail/CVE-2025-50084) + [CVE-2025-50087](https://nvd.nist.gov/vuln/detail/CVE-2025-50087) + [CVE-2025-50091](https://nvd.nist.gov/vuln/detail/CVE-2025-50091) + [CVE-2025-50101](https://nvd.nist.gov/vuln/detail/CVE-2025-50101) + [CVE-2025-50102](https://nvd.nist.gov/vuln/detail/CVE-2025-50102) + [CVE-2025-50098](https://nvd.nist.gov/vuln/detail/CVE-2025-50098) + [CVE-2025-53023](hhttps://nvd.nist.gov/vuln/detail/CVE-2025-53023) + [CVE-2025-50081](https://nvd.nist.gov/vuln/detail/CVE-2025-50081) + [CVE-2025-50085](https://nvd.nist.gov/vuln/detail/CVE-2025-50085) + [CVE-2025-50077](https://nvd.nist.gov/vuln/detail/CVE-2025-50077) + [CVE-2025-50088](https://nvd.nist.gov/vuln/detail/CVE-2025-50088) + [CVE-2025-50092](https://nvd.nist.gov/vuln/detail/CVE-2025-50092) + [CVE-2025-50099](https://nvd.nist.gov/vuln/detail/CVE-2025-50099) + [CVE-2025-50096](https://nvd.nist.gov/vuln/detail/CVE-2025-50096) ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250508 RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250508 ist verfügbar. **Behobene Fehler:** + Der Fehler, dass der virtuelle Index nach einem Rollback instabil war, wenn `index_id` größer als max. `uint32` ist, wurde behoben. + Der Fehler, dass Tests aufgrund eines Speicherproblems fehlschlagen, wurde behoben. + Der Fehler, dass `` für `Execute` leer ist, wurde behoben. + Fehler beim Kompilieren von MySQL mit GCC 14 [noclose 5.7] wurde behoben. **CVEs behoben:** + [CVE-2025-30682](https://nvd.nist.gov/vuln/detail/CVE-2025-30682) + [CVE-2025-30687](https://nvd.nist.gov/vuln/detail/CVE-2025-30687) + [CVE-2025-30688](https://nvd.nist.gov/vuln/detail/CVE-2025-30688) + [CVE-2025-21581](https://nvd.nist.gov/vuln/detail/CVE-2025-21581) + [CVE-2025-21585](https://nvd.nist.gov/vuln/detail/CVE-2025-21585) + [CVE-2025-30689](https://nvd.nist.gov/vuln/detail/CVE-2025-30689) + [CVE-2025-30722](https://nvd.nist.gov/vuln/detail/CVE-2025-30722) + [CVE-2025-21577](https://nvd.nist.gov/vuln/detail/CVE-2025-21577) + [CVE-2025-30693](https://nvd.nist.gov/vuln/detail/CVE-2025-30693) + [CVE-2025-30695](https://nvd.nist.gov/vuln/detail/CVE-2025-30695) + [CVE-2025-30703](https://nvd.nist.gov/vuln/detail/CVE-2025-30703) ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250213 RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250213 ist verfügbar. **Behobene Fehler:** + Die fehlgeschlagene InnoDB-Assertion `result != FTS_INVALID` wurde behoben. + Der Absturz und die weit verbreitete Beschädigung von räumlichen Indizes, nachdem der Vorgang `ALTER TABLE` die InnoDB-Tabelle mithilfe des Algorithmus `INPLACE` neu erstellt hat, wurde behoben. + Der Fehler, dass `ON DELETE CASCADE` mit generierter Spalte bei `innobase_get_computed_value` abstürzt, wurde behoben. + Assert-Fehler bei `row_MySQL_pad_col` wurde behoben. + Ein Fehler, bei dem eine Online-DDL die folgende Fehlermeldung verursacht, wurde behoben: `ERROR 1712 (HY000): Index PRIMARY is corrupted`. + Abstürze bei `Item_rollup_sum_switcher::current_arg` wurden behoben. + Ein Fehler, bei dem der Datenbank-Cache bei `DROP USER` nicht geleert wird, wurde behoben. + Ein Pufferüberlauf bei `my_print_help` wurde behoben. + Ein InnoDB-Fehler, bei dem der Index `FULLTEXT` den Wert `FTS_DOC_ID` auf den maximalen vorzeichenlosen 32-Bit-Wert beschränkt, wurde behoben. **CVEs behoben:** + [CVE-2025-21497](https://nvd.nist.gov/vuln/detail/CVE-2025-21497) + [CVE-2025-21555](https://nvd.nist.gov/vuln/detail/CVE-2025-21555) + [CVE-2025-21559](https://nvd.nist.gov/vuln/detail/CVE-2025-21559) + [CVE-2025-21490](https://nvd.nist.gov/vuln/detail/CVE-2025-21490) + [CVE-2025-21491](https://nvd.nist.gov/vuln/detail/CVE-2025-21491) + [CVE-2025-21500](https://nvd.nist.gov/vuln/detail/CVE-2025-21500) + [CVE-2025-21501](https://nvd.nist.gov/vuln/detail/CVE-2025-21501) + [CVE-2025-21540](https://nvd.nist.gov/vuln/detail/CVE-2025-21540) + [CVE-2025-21543](https://nvd.nist.gov/vuln/detail/CVE-2025-21543) + [CVE-2025-21520](https://nvd.nist.gov/vuln/detail/CVE-2025-21520) ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250103 RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20250103 ist verfügbar. **Behobene Fehler:** + Ein FTS-Bereinigungsproblem beim Löschen und Hinzufügen des Index `FULLTEXT` in derselben Transaktion wurde behoben. + Der Zeitpunkt der Speicherzuweisung im MySQL-Client wurde so optimiert, dass mögliche Datenlecks verhindert werden. + Die Kürzung der Ergebnisse bei Verwendung des Operators `UNION` auf 34 Byte wurde behoben. + Ein möglicher out-of-bounds Zugriff aufgrund `ulong bitmask` des Autorisierungscodes wurde behoben. **CVEs behoben:** + [CVE-2024-21230](https://nvd.nist.gov/vuln/detail/CVE-2024-21230) + [CVE-2024-21201](https://nvd.nist.gov/vuln/detail/CVE-2024-21201) + [CVE-2024-21241](https://nvd.nist.gov/vuln/detail/CVE-2024-21241) + [CVE-2024-21203](https://nvd.nist.gov/vuln/detail/CVE-2024-21203) ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240808 RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240808 ist verfügbar. **Behobene Fehler:** + Ein Assert-Fehler im Zusammenhang mit dem Index der Wörterbuchspalte wurde behoben. + Ein Problem mit der Funktion `is_binlog_cache_empty()` wurde behoben. + `heap-use-after-free`-Fehler in den Dateien `sql/item.cc` wurden behoben. + Mehrere Probleme mit dem räumlichen Index wurden behoben, indem sie für `index-only`-Lesevorgänge deaktiviert wurden. + Ein Instrumentierungsproblem mit dem Plugin `LOCK_ORDER: CONNECTION_CONTROL` wurde behoben. + Ein Problem, bei dem Threads mit dem Plugin `CONNECTION_CONTROL` hängen bleiben, wurde behoben. + Der Fehler, dass `PSI_THREAD_INFO` für `PREPARED STATEMENTS` nicht aktualisiert wird, wurde behoben. + Die doppelte Verarbeitung von FTS-Indexwörtern mit `innodb_optimize_fulltext_only` wurde behoben. **CVEs behoben:** + [CVE-2024-21177](https://nvd.nist.gov/vuln/detail/CVE-2024-21177) ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240529 RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240529 ist verfügbar. **Behobene Fehler:** + Der Assert-Fehler `field.cc` wurde durch Implementieren von `fix_after_pullout` behoben. + Ein Nullzeigerfehler beim Zurückgeben von Metadaten an den Client für bestimmte SQL-Abfragen wurde behoben. Diese Abfragen enthielten dynamische Parameter und Unterabfragen in `SELECT`-Klauseln. + Der Fehler, dass falsche Ergebnisse bei der Verwendung von `GROUP BY` für ungenaue Indexscans oder für Scans von nicht zusammenhängenden Indexbereichen zurückgegeben werden, wurde behoben. + Der Fehler, dass GTID-Informationen beim Absturz von MySQL während der Persistenz verloren gehen, wurde behoben. + Eine Race-Bedingung, die dazu führte, dass eine InnoDB-Transaktion auf unbestimmte Zeit hängen blieb, wurde korrigiert. + Eine Race-Bedingung bei der Bereinigung von Zertifizierungsinformationen der Gruppenreplikation wurde korrigiert. + Ein Problem mit dem Index-Rückwärtsscan bei gleichzeitigen Seitenvorgängen wurde behoben. + Es wurde ein Problem mit dem inkonsistenten Status der Volltextsuche (FTS) in gleichzeitigen Szenarien behoben. + Ein Assert-Fehler mit dem Änderungspuffer beim Löschen von Tabellen wurde behoben. + Das Verhalten beim Aufrufen der Funktion `deinit` für alle Plugin-Typen wurde vereinheitlicht. **CVEs behoben:** + [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963) + [CVE-2024-20993](https://nvd.nist.gov/vuln/detail/CVE-2024-20993) + [CVE-2024-20998](https://nvd.nist.gov/vuln/detail/CVE-2024-20998) + [CVE-2024-21009](https://nvd.nist.gov/vuln/detail/CVE-2024-21009) + [CVE-2024-21054](https://nvd.nist.gov/vuln/detail/CVE-2024-21054) + [CVE-2024-21055](https://nvd.nist.gov/vuln/detail/CVE-2024-21055) + [CVE-2024-21057](https://nvd.nist.gov/vuln/detail/CVE-2024-21057) + [CVE-2024-21062](https://nvd.nist.gov/vuln/detail/CVE-2024-21062) + [CVE-2024-21008](https://nvd.nist.gov/vuln/detail/CVE-2024-21008) + [CVE-2024-21013](https://nvd.nist.gov/vuln/detail/CVE-2024-21013) + [CVE-2024-21047](https://nvd.nist.gov/vuln/detail/CVE-2024-21047) + [CVE-2024-21087](https://nvd.nist.gov/vuln/detail/CVE-2024-21087) + [CVE-2024-21096](https://nvd.nist.gov/vuln/detail/CVE-2024-21096) ### RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240408 RDS Extended Support für RDS für MySQL Version 5.7.44-RDS.20240408 ist verfügbar. Diese Version enthält Patches für Folgendes CVEs: + [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963) ## Arbeiten mit der Datenbank-Vorschauumgebung Im Juli 2023 hat Oracle ein neues Release-Modell für MySQL angekündigt. Dieses Modell umfasst zwei Arten von Releases: Innovations-Releases und LTS-Releases. Amazon RDS stellt MySQL-Innovations-Releases in der RDS-Vorschauumgebung zur Verfügung. Weitere Informationen zu den MySQL-Innovations-Releases finden Sie unter [Introducing MySQL Innovation and Long-Term Support (LTS) versions](https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-longterm-support-lts-versions). DB-Instances von RDS für MySQL in der Datenbank-Vorschauumgebung funktionieren ähnlich wie andere DB-Instances von RDS für MySQL. 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 MySQL-Dump- und -Ladefunktionen verwenden, um Datenbanken aus 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. Wenn Sie die DB-Instance von RDS für MySQL erstellen möchten, 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 Datenbank-Vorschauumgebung über die AWS CLI zu erstellen. ``` rds-preview.us-east-2.amazonaws.com ``` Wenn Sie die DB-Instance von RDS für MySQL erstellen möchten, 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 ``` Wenn Sie die DB-Instance von RDS für MySQL erstellen möchten, 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). ## MySQL Version 9.5 in der Database Preview-Umgebung MySQL Version 9.5 ist jetzt in der Amazon RDS Database Preview-Umgebung verfügbar. MySQL Version 9.5 enthält mehrere Verbesserungen, die unter [Änderungen in MySQL 9.5.0](https://dev.mysql.com/doc/relnotes/mysql/9.5/en/news-9-5-0.html) beschrieben sind. Weitere Informationen zur Database-Vorschauumgebung finden Sie unter [Arbeiten mit der Datenbank-Vorschauumgebung](#mysql-working-with-the-database-preview-environment). Um von der Konsole aus auf die Vorschauumgebung zuzugreifen, wählen Sie [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/). ## MySQL Version 9.4 in der Database Preview-Umgebung MySQL Version 9.4 ist jetzt in der Amazon RDS Database Preview-Umgebung verfügbar. MySQL Version 9.4 enthält mehrere Verbesserungen, die unter [Änderungen in MySQL 9.4.0](https://dev.mysql.com/doc/relnotes/mysql/9.4/en/news-9-4-0.html) beschrieben sind. Weitere Informationen zur Database-Vorschauumgebung finden Sie unter [Arbeiten mit der Datenbank-Vorschauumgebung](#mysql-working-with-the-database-preview-environment). Um von der Konsole aus auf die Vorschauumgebung zuzugreifen, wählen Sie [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/). ## MySQL Version 9.3 in der Database Preview-Umgebung MySQL-Version 9.3 ist jetzt in der Datenbank-Vorschauumgebung in Amazon RDS verfügbar. MySQL-Version 9.3 enthält verschiedene Verbesserungen, die unter [Änderungen in MySQL 9.3.0](https://dev.mysql.com/doc/relnotes/mysql/9.3/en/news-9-3-0.html) beschrieben werden. Weitere Informationen zur Database-Vorschauumgebung finden Sie unter [Arbeiten mit der Datenbank-Vorschauumgebung](#mysql-working-with-the-database-preview-environment). Um von der Konsole aus auf die Vorschau-Umgebung zuzugreifen, wählen Sie [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/). ## Veraltete Versionen für Amazon RDS für MySQL Amazon RDS für MySQL Version 5.1, 5.5 und 5.6 sind veraltet. Die Versionen 9.1 und 9.2 von Amazon RDS for MySQL sind in der Database Preview-Umgebung veraltet. Informationen zur Amazon RDS-Richtlinie für MySQL zur Deprecation finden Sie unter [Amazon](https://aws.amazon.com/rds/faqs/) RDS. FAQs # Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance Bevor Sie eine Verbindung zu einer DB-Instance auf einer MySQL-Datenbank-Engine herstellen können, müssen Sie eine DB-Instance erstellen. Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md). Nachdem Amazon RDS Ihre DB-Instance bereitgestellt hat, können Sie jede beliebige Standard-MySQL-Client-Anwendung und jedes -Hilfsprogramm verwenden, um sich mit der Instance zu verbinden. Geben Sie in der Verbindungszeichenfolge die DNS-Adresse aus dem primären DB-Instance-Endpunkt als Host-Parameter an sowie die Portnummer vom Instance-Endpunkt als Port-Parameter. Um sich gegenüber der RDS DB-Instance zu authentifizieren, können Sie eine der Authentifizierungsmethoden für MySQL und die AWS Identity and Access Management (IAM)-Datenbank-Authentifizierung verwenden. + Weitere Informationen über das Authentifizieren gegenüber MySQL mithilfe einer der Authentifizierungsmethoden für MySQL finden Sie unter [ Authentication Method](https://dev.mysql.com/doc/internals/en/authentication-method.html) in der MySQL-Dokumentation. + Weitere Informationen über das Authentifizieren in MySQL mithilfe von IAM-Datenbank-Authentifizierung finden Sie unter [IAM-Datenbankauthentifizierungfür MariaDB, MySQL und PostgreSQL](UsingWithRDS.IAMDBAuth.md). Sie können sich mit einer MySQL-DB-Instance verbinden, indem Sie die MySQL-Befehlszeilenfunktion verwenden. Weitere Informationen zur Verwendung des MySQL-Clients finden Sie unter [mysql – The MySQL Command-Line Client](https://dev.mysql.com/doc/refman/8.0/en/mysql.html) in der MySQL-Dokumentation. Eine GUI-basierte Anwendung, die Sie zum Herstellen einer Verbindung verwenden können, ist MySQL Workbench. Weitere Informationen finden Sie auf der Seite [Download MySQL Workbench](http://dev.mysql.com/downloads/workbench/). 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). Um eine Verbindung zu einer DB-Instance von außerhalb ihrer Amazon VPC herzustellen, muss die DB-Instance öffentlich zugänglich sein und der Zugriff muss unter Anwendung der Regeln für den eingehenden Datenverkehr der Sicherheitsgruppe der DB-Instance gewährt werden. Darüber hinaus müssen weitere Anforderungen erfüllt werden. Weitere Informationen finden Sie unter [Verbindung zur Amazon-RDS-DB-Instance kann nicht hergestellt werden](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). Sie können Secure Socket Layer (SSL) oder Transport Layer Security (TLS) für die Verschlüsselung von Verbindungen mit einer MySQL-DB-Instance verwenden. Weitere Informationen finden Sie unter [SSL/TLS-Unterstützung für MySQL-DB-Instances in Amazon RDS](MySQL.Concepts.SSLSupport.md). Wenn Sie AWS Identity and Access Management (IAM)-Datenbank-Authentifizierung nutzen, stellen Sie sicher, dass Sie eine SSL/TLS-Verbindung verwenden. Weitere Informationen finden Sie unter [IAM-Datenbankauthentifizierungfür MariaDB, MySQL und PostgreSQL](UsingWithRDS.IAMDBAuth.md). Sie können auch eine Verbindung zu einer DB-Instance von einem Webserver herstellen. Weitere Informationen finden Sie unter [Tutorial: Erstellen eines Webservers und einer Amazon RDS-DB-Instance](TUT_WebAppWithRDS.md). **Anmerkung** Weitere Informationen zum Herstellen einer Verbindung mit einer MariaDB-DB-Instance finden Sie unter [Herstellen einer Verbindung mit Ihrer MariaDB-DB-Instance](USER_ConnectToMariaDBInstance.md). Informationen zum Suchen und Herstellen einer Verbindung mit einer DB-Instance von RDS für MySQL finden Sie in den folgenden Themen. **Topics** + [ # Finden der Verbindungsinformationen für eine DB-Instance von RDS für MySQL ](USER_ConnectToInstance.EndpointAndPort.md) + [ # Installieren des Befehlszeilenclients von MySQL ](mysql-install-cli.md) + [ # Herstellen einer Verbindung über den Befehlszeilen-Client von MySQL (unverschlüsselt) ](USER_ConnectToInstance.CLI.md) + [ # Herstellen einer Verbindung von MySQL Workbench ](USER_ConnectToInstance.MySQLWorkbench.md) + [ # Herstellen einer Verbindung zu RDS für MySQL mit dem AWS JDBC-Treiber, AWS Python-Treiber und AWS ODBC-Treiber für MySQL ](MySQL.Connecting.Drivers.md) + [ # Fehlerbehebung bei Verbindungen zu Ihrer MySQL-DB-Instance ](USER_ConnectToInstance.Troubleshooting.md) # Finden der Verbindungsinformationen für eine DB-Instance von RDS für MySQL 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 mit einer DB-Instance herzustellen, verwenden Sie einen beliebigen Client für eine 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 den Vorgang AWS-Managementkonsole, den AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)Befehl oder den Amazon DBInstances RDS-API-Vorgang [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) verwenden, um deren Details aufzulisten. ## Konsole **Die Verbindungsinformationen für eine DB-Instance finden Sie im AWS-Managementkonsole** 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. Klicken Sie im Navigationsbereich auf **Datenbanken**, um eine Liste Ihrer DB-Instances anzuzeigen. 1. Wählen Sie den Namen der MySQL-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 MySQL-DB-Instance mithilfe von zu finden AWS CLI, führen Sie den [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)Befehl 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=mysql" \ --query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]" ``` Für Windows: ``` aws rds describe-db-instances ^ --filters "Name=engine,Values=mysql" ^ --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 DBInstances Vorgang [Describe](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 ermitteln. Suchen Sie in der Ausgabe die Werte für die Endpunktadresse, den Endpunktport und den Masterbenutzernamen. # Installieren des Befehlszeilenclients von MySQL 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 Befehlszeilen-Clients 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 ``` # Herstellen einer Verbindung über den Befehlszeilen-Client von MySQL (unverschlüsselt) **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 Informationen zur Verwendung verschlüsselter Verbindungen finden Sie unter [Herstellen einer Verbindung zu Ihrer MySQL-DB-Instance auf Amazon RDS über den MySQL-Befehlszeilenclient (verschlüsselt) SSL/TLS](USER_ConnectToInstanceSSL.CLI.md). Um über den MySQL-Befehlszeilenclient eine Verbindung mit einer DB-Instance herzustellen, geben Sie den folgenden Befehl an der Eingabeaufforderung ein. Ersetzen Sie für den -h-Parameter den DNS-Namen (Endpunkt) für Ihre primäre DB-Instance. Ersetzen Sie den Parameter -P durch den Port Ihrer DB-Instance. Ersetzen Sie für den Parameter -u den Benutzernamen eines gültigen Datenbankbenutzers, z. B. des Masterbenutzers. Geben Sie bei Aufforderung das Passwort für den Masterbenutzer ein. ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com -P 3306 -u mymasteruser -p ``` Nachdem Sie das Passwort für den Benutzer eingegeben haben, sollte eine Ausgabe wie die folgende angezeigt werden. ``` Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9738 Server version: 8.0.28 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> ``` # Herstellen einer Verbindung von MySQL Workbench **So stellen Sie eine Verbindung von MySQL Workbench her** 1. Laden Sie MySQL Workbench unter [Download MySQL Workbench](http://dev.mysql.com/downloads/workbench/) herunter und installieren Sie es. 1. Öffnen Sie MySQL Workbench. ![\[Willkommensseite in MySQL Workbench.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/mysql-workbench-main.png) 1. Wählen Sie unter **Database** die Option **Manage Connections** aus. 1. Wählen Sie im Fenster **Manage Server Connections** **New** aus. 1. Geben Sie im Fenster **Connect to Database** die folgenden Informationen ein: + **Stored Connection** – Geben Sie einen Namen für die Verbindung ein, beispielsweise **MyDB**. + **Hostname** – Geben Sie den Endpunkt der DB-Instance ein. + **Port** – Geben Sie den von der DB-Instance verwendeten Port ein. + **Benutzername** – Geben Sie den Benutzernamen eines gültigen Datenbankbenutzers ein, beispielsweise den des Masterbenutzers. + **Password** – Wählen Sie optional **Store in Vault (In Vault speichern)** aus, geben Sie das Passwort des Benutzers ein und speichern Sie dieses. Das Fenster sieht in etwa wie folgt aus: ![\[Das Fenster „Serververbindungen verwalten“ in MySQL Workbench.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/mysql-workbench-connect.png) Sie können Verbindungen mit der Funktionen von MySQL Workbench anpassen. Beispielsweise können Sie SSL/TLS-Verbindungen mithilfe der Registerkarte **SSL** konfigurieren. Weitere Informationen zur Verwendung von MySQL Workbench finden Sie in der [MySQL Workbench-Dokumentation](https://dev.mysql.com/doc/workbench/en/). Informationen zum Verschlüsseln von Clientverbindungen mit MySQL-DB-Instances mithilfe von SSL/TLS finden Sie unter [Verschlüsselung von Client-Verbindungen mit SSL/TLS MySQL-DB-Instances auf Amazon RDS](mysql-ssl-connections.md). 1. Wählen Sie optional **Test Connection** aus, um zu prüfen, ob die Verbindung zur DB-Instance erfolgreich hergestellt wurde. 1. Klicken Sie auf **Schließen**. 1. Wählen Sie unter **Database** die Option **Connect to Database** aus. 1. Wählen Sie für **Stored Connection** Ihre Verbindung aus. 1. Wählen Sie **OK** aus. # Herstellen einer Verbindung zu RDS für MySQL mit dem AWS JDBC-Treiber, AWS Python-Treiber und AWS ODBC-Treiber für MySQL Stellen Sie mit dem AWS JDBC-Treiber, dem AWS Python-Treiber und dem AWS ODBC-Treiber für MySQL eine Connect zu RDS für MySQL-DB-Instances her. Weitere Informationen finden Sie unter den folgenden Themen. **Topics** + [ ## Herstellen einer Verbindung mit RDS für MySQL mithilfe des JDBC-Treibers von Amazon Web Services (AWS) ](#MySQL.Connecting.JDBCDriver) + [ ## Herstellen einer Verbindung mit RDS für MySQL mithilfe des Python-Treibers von Amazon Web Services (AWS) ](#MySQL.Connecting.PythonDriver) + [ ## Herstellen einer Verbindung mit RDS für MySQL mithilfe des ODBC-Treibers für MySQL von Amazon Web Services (AWS) ](#USER_ConnectToInstance.ODBCDriverMySQL) ## Herstellen einer Verbindung mit RDS für MySQL mithilfe des JDBC-Treibers von Amazon Web Services (AWS) 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 RDS für MySQL mithilfe des Python-Treibers von Amazon Web Services (AWS) 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). ## Herstellen einer Verbindung mit RDS für MySQL mithilfe des ODBC-Treibers für MySQL von Amazon Web Services (AWS) Der AWS ODBC-Treiber für MySQL ist ein Client-Treiber, der für die hohe Verfügbarkeit von RDS für MySQL entwickelt wurde. Der Treiber kann neben dem Connector/ODBC MySQL-Treiber existieren und ist mit denselben Workflows kompatibel. Weitere Informationen über den AWS ODBC-Treiber für MySQL und vollständige Anweisungen zu dessen Installation und Verwendung finden Sie im [Amazon Web Services (AWS) ODBC-Treiber für MySQL](https://github.com/aws/aws-mysql-odbc) GitHub . # Fehlerbehebung bei Verbindungen zu Ihrer MySQL-DB-Instance Zwei häufige Ursachen für Verbindungsfehler mit einer neuen DB-Instance sind folgende: + Die DB-Instance wurde mit einer Sicherheitsgruppe erstellt, die keine Verbindungen von dem Gerät oder der Amazon EC2-Instance zulässt, wo die MySQL-Anwendung oder das -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 MySQL-DB-Instance-Verbindungen Sie können zuverlässige Sicherheitsmaßnahmen implementieren, um MySQL-DB-Instances vor unbefugtem Zugriff und potenziellen Bedrohungen zu schützen. Sicherheitsgruppen, SSL/TLS-Verschlüsselung und IAM-Datenbankauthentifizierung funktionieren zusammen, um ein Höchstmaß an Verbindungssicherheit für Ihre MySQL-DB-Instances zu gewährleisten. Diese Sicherheitskontrollen helfen Ihnen dabei, Compliance-Anforderungen zu erfüllen, Datenschutzverletzungen zu verhindern und sichere Kommunikationskanäle zwischen Anwendungen und Datenbanken aufrechtzuerhalten. Sie können Ihre MySQL-DB-Instances schützen, indem Sie Daten während der Übertragung verschlüsseln, den Zugriff auf bestimmte IP-Bereiche einschränken und die Benutzerauthentifizierung mithilfe von IAM-Rollen statt Datenbankkennwörtern verwalten. Sicherheit für MySQL-DB-Instances 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 Socket 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. + Sie können eine der folgenden Methoden oder eine Kombination davon durchführen, um die Anmeldung und die Berechtigungen für eine MySQL-DB-Instance zu authentifizieren. + Sie können denselben Ansatz wie mit einer eigenständigen Instance in MySQL auswählen. Befehle wie `CREATE USER`, `RENAME USER`, `GRANT`, `REVOKE` und `SET PASSWORD` funktionieren genau wie auf lokalen Datenbanken, so wie auch das direkte Ändern von Datenbank-Schema-Tabellen. Die direkte Änderung der Datenbankschematabellen ist jedoch keine bewährte Methode. Ab RDS für MySQL Version 8.0.36 wird dies nicht mehr unterstützt. Weitere Informationen finden Sie unter [Access Control and Account Management](https://dev.mysql.com/doc/refman/8.0/en/access-control.html) in der MySQL-Dokumentation. + Sie können auch die IAM-Datenbank-Authentifizierung verwenden. Mit IAM-Datenbank-Authentifizierung, können Sie mithilfe eines IAM-Benutzers, einer IAM-Rolle oder eines Authentifizierungstokens Ihre DB-Instance bestätigen. Ein *Authentifizierungstoken* ist ein eindeutiger Wert, der mithilfe des Signatur-Version 4-Signiervorgangs erstellt wird. Durch das Verwenden der IAM-Datenbank-Authentifizierung können Sie dieselben Anmeldeinformationen verwenden, um den Zugang zu Ihren AWS-Ressourcen und Ihrer Datenbank zu steuern. Weitere Informationen finden Sie unter [IAM-Datenbankauthentifizierungfür MariaDB, MySQL und PostgreSQL](UsingWithRDS.IAMDBAuth.md). + Eine weitere Option ist die Kerberos-Authentifizierung für RDS für MySQL. Die DB-Instance arbeitet mit AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD), um die Kerberos-Authentifizierung zu unterstützen. Wenn Benutzer sich mit einer MySQL-DB-Instance authentifizieren, die mit der vertrauenswürdigen Domäne verbunden ist, werden Authentifizierungsanfragen weitergeleitet. Weitergeleitete Anfragen gehen an das Domänenverzeichnis, das Sie mit erstelle Directory Service. Weitere Informationen finden Sie unter [Verwenden der Kerberos-Authentifizierung von Amazon RDS für MySQL](mysql-kerberos.md). Wenn Sie eine Amazon RDS DB-Instance erstellen, hat der Master-Benutzer standardmäßig folgende Berechtigungen: | Engine-Version | Systemberechtigung | Datenbankrolle | | --- | --- | --- | | RDS für MySQL Version 8.4.3 und höher | `GRANT SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`,`INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `FLUSH_OPTIMIZER_COSTS`, `FLUSH_PRIVILEGES`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`, `ROLE_ADMIN`, `SENSITIVE_VARIABLES_OBSERVER`, `SESSION_VARIABLES_ADMIN`, `SET_ANY_DEFINER`, `SHOW_ROUTINE`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Mehr über `rds_superuser_role` erfahren Sie unter [Rollenbasiertes Berechtigungsmodell für RDS für MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). | | RDS für MySQL Version 8.0.36 und höher | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `ROLE_ADMIN`, `SET_USER_ID`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Mehr über `rds_superuser_role` erfahren Sie unter [Rollenbasiertes Berechtigungsmodell für RDS für MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). | | Versionen von RDS für MySQL unter 8.0.36 | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `REPLICATION SLAVE` | Keine | **Anmerkung** Obwohl es möglich ist, den Masterbenutzer in der DB-Instance zu löschen, wird dies nicht empfohlen. Um den Masterbenutzer neu zu erstellen, verwenden Sie den RDS-API-Vorgang [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) oder den AWS CLI-Befehl [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) und geben Sie ein neues Masterbenutzerpasswort mit dem entsprechenden Parameter an. 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. Der Versuch, das Passwort zu verwerfen, umzubenennen oder zu ändern, oder die Sonderrechte für das `rdsadmin`-Konto zu ändern, wird fehlschlagen. Um die Verwaltung der DB-Instance zu erlauben, wurden die Befehle `kill` und `kill_query` beschränkt. Die Amazon-RDS-Befehle `rds_kill` und `rds_kill_query` werden bereitgestellt, um Ihnen das Beenden von Benutzersitzungen oder Abfragen in DB-Instances zu ermöglichen. # Passwortvalidierung in RDS für MySQL MySQLstellt das `validate_password`-Plugin für eine verbesserte Sicherheit bereit. Das Plugin erzwingt Passwortrichtlinien durch Verwendung von Parametern in der DB-Parametergruppe für Ihre MySQL-DB-Instance. Das Plugin wird für DB-Instances unterstützt, auf denen die MySQL-Versionen 5.7, 8.0 und 8.4 ausgeführt werden. Weitere Informationen zum `validate_password`-Plugin finden Sie unter [The Password Validation Plugin](https://dev.mysql.com/doc/refman/5.7/en/validate-password.html) in der MySQL-Dokumentation. **So aktivieren Sie das Plugin `validate_password` für eine MySQL-DB-Instance** 1. Stellen Sie eine Verbindung zu Ihrer Instance her und führen Sie den folgenden Befehl aus: ``` INSTALL PLUGIN validate_password SONAME 'validate_password.so'; ``` 1. Konfigurieren Sie die Parameter für das Plugin in der DB-Parametergruppe, die von der DB-Instance verwendet wird. Weitere Informationen zu den Parametern finden Sie unter [Password Validation Plugin Options and Variables](https://dev.mysql.com/doc/refman/5.7/en/validate-password-options-variables.html) in der MySQL-Dokumentation. Weitere Informationen zum Ändern von DB-Instance-Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Starten Sie die DB-Instance neu. Nach dem Aktivieren des Plugins `validate_password` setzen Sie vorhandene Passwörter zurück, um die neuen Validierungsrichtlinien zu erfüllen. Ihre MySQL-DB-Instance übernimmt die Passwortvalidierung für Amazon RDS. Um ein Passwort zu ändern, reichen Sie zunächst eine Anfrage zur Kennwortaktualisierung über die AWS-Managementkonsole, den `modify-db-instance` CLI-Befehl oder den `ModifyDBInstance` API-Vorgang ein. RDS akzeptiert Ihre Anfrage zunächst, auch wenn das Passwort nicht Ihren Richtlinien entspricht. RDS verarbeitet die Anfrage dann asynchron. Es aktualisiert das Passwort in Ihrer MySQL-DB-Instance nur, wenn das Passwort Ihren definierten Richtlinien entspricht. Wenn das Passwort diesen Richtlinien nicht entspricht, behält RDS das bestehende Passwort bei und protokolliert ein Fehlerereignis. ``` Unable to reset your password. Error information: Password failed to meet validation rules. ``` Weitere Informationen über Amazon-RDS-Ereignisse finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md). # Verschlüsselung von Client-Verbindungen mit SSL/TLS MySQL-DB-Instances 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 die SSL/TLS Verschlüsselung für MySQL-DB-Instances. Die Nutzung der SSL/TLS, you can encrypt a connection between your application client and your MySQL DB instance. SSL/TLS Unterstützung ist in allen Bereichen AWS-Regionen für MySQL verfügbar. Mit Amazon RDS können Sie Daten während der Übertragung sichern, indem Sie Client-Verbindungen zu MySQL-DB-Instances mit SSL/TLS, requiring SSL/TLS for all connections to a MySQL 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 MySQL-DB-Instances auf Amazon RDS verschlüsseln. **Topics** + [ # SSL/TLS-Unterstützung für MySQL-DB-Instances in Amazon RDS ](MySQL.Concepts.SSLSupport.md) + [ # Erforderlich SSL/TLS für bestimmte Benutzerkonten für eine MySQL-DB-Instance auf Amazon RDS ](mysql-ssl-connections.require-ssl-users.md) + [ # Erforderlich SSL/TLS für alle Verbindungen zu einer MySQL-DB-Instance auf Amazon RDS ](mysql-ssl-connections.require-ssl.md) + [ # Herstellen einer Verbindung zu Ihrer MySQL-DB-Instance auf Amazon RDS über den MySQL-Befehlszeilenclient (verschlüsselt) SSL/TLS ](USER_ConnectToInstanceSSL.CLI.md) # SSL/TLS-Unterstützung für MySQL-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 für die Verbindung zu MySQL-DB-Instances mithilfe neuer SSL/TLS Zertifikate](ssl-certificate-rotation-mysql.md). Bei MySQL 8.0 und früheren Versionen wird in Amazon RDS für MySQL OpenSSL für sichere Verbindungen verwendet. Bei MySQL 8.4 und höheren Versionen verwendet Amazon RDS für MySQL AWS-LC. Die TLS-Unterstützung hängt von der MySQL-Version ab. In der folgenden Tabelle ist dargestellt, welche TLS-Versionen für die MySQL-Versionen unterstützt werden. | MySQL-Version | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | | --- | --- | --- | --- | --- | | MySQL 8.4 | Nicht unterstützt | Nicht unterstützt | Unterstützt | Unterstützt | | MySQL 8.0 | Nicht unterstützt | Nicht unterstützt | Unterstützt | Unterstützt | | MySQL 5.7 | Unterstützt | Unterstützt | Unterstützt | Nicht unterstützt | # Erforderlich SSL/TLS für bestimmte Benutzerkonten für eine MySQL-DB-Instance auf Amazon RDS Sie können für bestimmte Benutzerkontenverbindungen zu Ihren MySQL-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 MySQL finden Sie unter [Verschlüsselte Verbindungen verwenden](https://dev.mysql.com/doc/refman/8.0/en/encrypted-connections.html) in der MySQL-Dokumentation. # Erforderlich SSL/TLS für alle Verbindungen zu einer MySQL-DB-Instance auf Amazon RDS Verwenden Sie den Parameter `require_secure_transport`, um zu verlangen, dass alle Benutzerverbindungen mit Ihrer MySQL-DB-Instance SSL/TLS verwenden. Standardmäßig ist der `require_secure_transport`-Parameter auf `OFF` festgelegt. Sie können den `require_secure_transport` Parameter so einstellen, `ON` dass er SSL/TLS für Verbindungen zu Ihrer DB-Instance erforderlich ist. 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: ``` MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` 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 zu `require_secure_transport`-Parametern finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_require_secure_transport). # Herstellen einer Verbindung zu Ihrer MySQL-DB-Instance auf Amazon RDS über den MySQL-Befehlszeilenclient (verschlüsselt) SSL/TLS Die Parameter des `mysql`-Client-Programms unterscheiden sich geringfügig, je nachdem, welche Version von MySQL oder MariaDB Sie 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 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 ``` 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-mode=VERIFY_IDENTITY -P 3306 -u myadmin -p ``` 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 ``` 1. Geben Sie bei Aufforderung das Passwort für den Masterbenutzer ein. Die Ausgabe entspricht weitgehend der Folgenden. ``` Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9738 Server version: 8.0.28 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> ``` # Aktualisierung von Anwendungen für die Verbindung zu MySQL-DB-Instances mithilfe neuer SSL/TLS Zertifikate 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. Anhand dieses Themas können Sie ermitteln, ob Client-Anwendungen eine Verbindung SSL/TLS zu Ihren DB-Instances herstellen. Wenn dies der Fall ist, können Sie weiter überprüfen, ob diese Anwendungen zur Herstellung von Verbindungen Zertifikatverifizierungen erfordern. **Anmerkung** Einige Anwendungen sind so konfiguriert, dass sie nur dann Verbindungen mit MySQL-DB-Instances 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 oder nicht auf dem neuesten Stand ist, verwendet die Verbindung nicht SSL und stellt eine Verbindung ohne Verschlüsselung her. Wir empfehlenden `preferred`-Modus. 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 MySQL-DB-Instances finden Sie unter[SSL/TLS-Unterstützung für MySQL-DB-Instances in Amazon RDS](MySQL.Concepts.SSLSupport.md). **Topics** + [ ## Ermitteln, ob Anwendungen Verbindungen mit Ihrer MySQL-DB-Instance mithilfe von SSL herstellen ](#ssl-certificate-rotation-mysql.determining-server) + [ ## Ermitteln, ob ein Client zum Herstellen von Verbindungen Zertifikatverifizierungen erfordert ](#ssl-certificate-rotation-mysql.determining-client) + [ ## Aktualisieren des Trust Stores Ihrer Anwendung ](#ssl-certificate-rotation-mysql.updating-trust-store) + [ ## Java-Beispielcode für die Herstellung von SSL-Verbindungen ](#ssl-certificate-rotation-mysql.java-example) ## Ermitteln, ob Anwendungen Verbindungen mit Ihrer MySQL-DB-Instance mithilfe von SSL herstellen Wenn Sie Amazon RDS für MySQL Version 5.7, 8.0 oder 8.4 verwenden und das Leistungsschema aktiviert ist, können Sie die folgende Abfrage ausführen, um zu prüfen, ob Verbindungen SSL/TLS verwenden. Informationen zum Aktivieren des Performance-Schemas finden Sie unter [Performance Schema Quick Start](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-quick-start.html) in der MySQL-Dokumentation. ``` mysql> SELECT id, user, host, connection_type FROM performance_schema.threads pst INNER JOIN information_schema.processlist isp ON pst.processlist_id = isp.id; ``` In dieser Beispielausgabe können Sie sehen, dass sowohl Ihre eigene Sitzung (`admin`), als auch eine als `webapp1` angemeldete Anwendung SSL verwenden. ``` +----+-----------------+------------------+-----------------+ | id | user | host | connection_type | +----+-----------------+------------------+-----------------+ | 8 | admin | 10.0.4.249:42590 | SSL/TLS | | 4 | event_scheduler | localhost | NULL | | 10 | webapp1 | 159.28.1.1:42189 | SSL/TLS | +----+-----------------+------------------+-----------------+ 3 rows in set (0.00 sec) ``` ## 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 DB-Serverzertifikats, 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 Datenbankserver-Zertifikat abgelaufen ist. ### 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/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration) in der MySQL-Dokumentation. Wenn MySQL-Client-Version 5.7 oder höher 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 ``` ## Aktualisieren des Trust Stores Ihrer Anwendung Informationen zum Aktualisieren des Trust Stores für MySQL-Anwendungen finden Sie unter [Installing SSL Certificates](https://dev.mysql.com/doc/mysql-monitor/8.0/en/mem-ssl-installation.html) in der MySQL-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 JDBC-Treiber von MySQL in einer Anwendung verwenden, legen Sie in der Anwendung die folgenden Eigenschaften 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_trust_store/MyTruststore.jks -Djavax.net.ssl.trustStorePassword=my_trust_store_password com.companyName.MyApplication ``` **Anmerkung** Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an. ## Java-Beispielcode für die Herstellung von SSL-Verbindungen Im folgenden Codebeispiel wird gezeigt, wie Sie die SSL-Verbindung einrichten, die das Serverzertifikat mithilfe von JDBC validiert. ``` public class MySQLSSLTest { private static final String DB_USER = "username"; private static final String DB_PASSWORD = "password"; // This trust store has only the prod root ca. private static final String TRUST_STORE_FILE_PATH = "file-path-to-trust-store"; private static final String TRUST_STORE_PASS = "trust-store-password"; public static void test(String[] args) throws Exception { Class.forName("com.mysql.jdbc.Driver"); System.setProperty("javax.net.ssl.trustStore", TRUST_STORE_FILE_PATH); System.setProperty("javax.net.ssl.trustStorePassword", TRUST_STORE_PASS); Properties properties = new Properties(); properties.setProperty("sslMode", "VERIFY_IDENTITY"); properties.put("user", DB_USER); properties.put("password", DB_PASSWORD); Connection connection = null; Statement stmt = null; ResultSet rs = null; try { connection = DriverManager.getConnection("jdbc:mysql://mydatabase.123456789012.us-east-1.rds.amazonaws.com:3306",properties); stmt = connection.createStatement(); rs=stmt.executeQuery("SELECT 1 from dual"); } finally { if (rs != null) { try { rs.close(); } catch (SQLException e) { } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { } } if (connection != null) { try { connection.close(); } catch (SQLException e) { e.printStackTrace(); } } } return; } } ``` **Wichtig** Nachdem Sie festgestellt haben, dass Ihre Datenbankverbindungen Ihren Application Trust Store verwenden, SSL/TLS und Ihren Application Trust Store aktualisiert haben, können Sie Ihre Datenbank so aktualisieren, dass sie die rds-ca-rsa 2048-g1-Zertifikate verwendet. 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. # Verwenden der Kerberos-Authentifizierung von Amazon RDS für MySQL Sie können die Kerberos-Authentifizierung verwenden, um Benutzer zu authentifizieren, wenn sie sich mit Ihrer MySQL-DB-Instance verbinden. Die DB-Instance arbeitet mit AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD), um die Kerberos-Authentifizierung zu aktivieren. Wenn Benutzer sich mit einer MySQL-DB-Instance authentifizieren, die mit der vertrauenswürdigen Domäne verbunden ist, werden Authentifizierungsanfragen weitergeleitet. Weitergeleitete Anfragen werden in das Domänenverzeichnis geleitet, mit dem Sie sie erstellen. Directory Service Wenn Sie alle Ihre Anmeldeinformationen im selben Verzeichnis aufbewahren, können Sie Zeit und Mühe sparen. Mit diesem Ansatz haben Sie einen zentralen Ort für die Speicherung und Verwaltung von Anmeldedaten für mehrere DB-Instances. Die Verwendung eines Verzeichnisses kann auch Ihr allgemeines Sicherheitsprofil verbessern. ## Verfügbarkeit von Regionen und Versionen Die Verfügbarkeit von Funktionen und der Support variieren zwischen bestimmten Versionen der einzelnen Datenbank-Engines und in allen AWS-Regionen. Weitere Informationen zur Versions- und Regionsverfügbarkeit von Amazon RDS mit Kerberos-Authentifizierung finden Sie unter [Unterstützte Regionen und DB-Engines für die Kerberos-Authentifizierung in Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md). ## Übersicht über das Einrichten der Kerberos-Authentifizierung für MySQL-DB-Instances Um die Kerberos-Authentifizierung für eine MySQL-DB-Instance einzurichten, führen Sie die folgenden allgemeinen Schritte aus, die später näher beschrieben werden: 1. Wird verwendetAWS Managed Microsoft AD, um ein AWS Managed Microsoft AD Verzeichnis zu erstellen. Sie können dasAWS-Managementkonsole, das oder das verwendenAWS CLI, Directory Service um das Verzeichnis zu erstellen. Einzelheiten dazu finden Sie unter [AWS Managed Microsoft ADVerzeichnis erstellen](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html) im *AWS Directory ServiceAdministratorhandbuch*. 1. Erstellen Sie eine AWS Identity and Access Management (IAM-) Rolle, die die verwaltete IAM-Richtlinie verwendet. `AmazonRDSDirectoryServiceAccess` Die Rolle erlaubt, dass Amazon RDS Aufrufe an Ihr Verzeichnis schickt. Damit die Rolle Zugriff gewährt, muss der Endpunkt AWS -Security-Token-Service (AWS STS) im AWS-Region für Ihr AWS Konto aktiviert sein. AWS STSEndpunkte sind standardmäßig in allen aktivAWS-Regionen, und Sie können sie ohne weitere Aktionen verwenden. Weitere Informationen finden Sie unter [Aktivierung und Deaktivierung AWS STSAWS-Region im *IAM-Benutzerhandbuch*](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate). 1. Erstellen und konfigurieren Sie Benutzer im AWS Managed Microsoft AD Verzeichnis mithilfe der Microsoft Active Directory-Tools. Weitere Informationen zum Erstellen von Benutzern in Ihrem Active Directory finden Sie unter [Verwalten von Benutzern und Gruppen in AWS verwaltetem Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) im *AWS Directory ServiceAdministratorhandbuch*. 1. Erstellen oder ändern Sie eine MySQL DB-Instance. Wenn Sie entweder die CLI oder die RDS-API für die Erstellungsanforderung verwenden, geben Sie eine Domänen-ID mit dem Parameter `Domain` an. Verwenden Sie die `d-*`-ID, die bei der Erstellung Ihres Verzeichnisses generiert wurde, und den Namen der von Ihnen erstellten Rolle. Wenn Sie eine vorhandene MySQL-DB-Instance so ändern, dass sie die Kerberos-Authentifizierung verwendet, legen Sie die Parameter für die Domäne und die IAM-Rolle für die DB-Instance fest. Suchen Sie die DB-Instance in derselben VPC wie das Domänenverzeichnis. 1. Verwenden Sie die Amazon-RDS-Hauptbenutzer-Anmeldeinformationen, um sich mit der MySQL-DB-Instance zu verbinden. Erstellen Sie den Benutzer unter Verwendung der `CREATE USER`-Klausel `IDENTIFIED WITH 'auth_pam'` in MySQL. Benutzer, die Sie auf diese Weise anlegen, können sich mit der Kerberos-Authentifizierung an der MySQL-DB-Instance anmelden. ## Einrichten der Kerberos-Authentifizierung für MySQL-DB-Instances Sie verwendenAWS Managed Microsoft AD, um die Kerberos-Authentifizierung für eine MySQL-DB-Instance einzurichten. Um die Kerberos-Authentifizierung einzurichten, führen Sie die folgenden Schritte durch. ### Schritt 1: Erstellen Sie ein Verzeichnis mit AWS Managed Microsoft AD Directory Serviceerstellt ein vollständig verwaltetes Active Directory in der AWS Cloud. Wenn Sie ein AWS Managed Microsoft AD Verzeichnis erstellen, Directory Service erstellt in Ihrem Namen zwei Domänencontroller und DNS-Server (Domain Name System). Die Verzeichnisserver werden in verschiedenen Subnetzen in einer VPC erstellt. Diese Redundanz trägt dazu bei, dass Ihr Verzeichnis auch im Fehlerfall erreichbar bleibt. Wenn Sie ein AWS Managed Microsoft AD Verzeichnis erstellen, Directory Service führt er in Ihrem Namen die folgenden Aufgaben aus: + Einrichten eines Active Directory innerhalb der VPC. + Erstellt ein Verzeichnisadministratorkonto mit dem Benutzernamen Admin und dem angegebenen Passwort. Mit diesem Konto verwalten Sie das Verzeichnis. **Anmerkung** Achten Sie darauf, dieses Passwort zu speichern. Directory Servicespeichert es nicht. Sie können es zurücksetzen, aber Sie können es nicht abrufen. + Erstellt eine Sicherheitsgruppe für die Verzeichniscontroller. Wenn Sie eine startenAWS Managed Microsoft AD, AWS erstellt eine Organisationseinheit (OU), die alle Objekte Ihres Verzeichnisses enthält. Diese OU hat den NetBIOS-Namen, den Sie bei der Erstellung Ihres Verzeichnisses angegeben haben. Sie befindet sich im Domänenstamm. Der Domänenstamm gehört und wird von diesem verwaltetAWS. Das Administratorkonto, das mit Ihrem AWS Managed Microsoft AD Verzeichnis erstellt wurde, verfügt über Berechtigungen für die gängigsten Verwaltungsaktivitäten Ihrer Organisationseinheit: + Erstellen, Aktualisieren oder Löschen von Benutzern + Hinzufügen von Ressourcen zu Ihrer Domäne, etwa Datei- oder Druckserver, und anschließendes Gewähren der zugehörigen Ressourcenberechtigungen für Benutzer in der OU + Zusätzliche OUs Container erstellen + Delegieren von Befugnissen + Wiederherstellen von gelöschten Objekten aus dem Active Directory-Papierkorb + Führen Sie AD- und PowerShell DNS-Windows-Module im Active Directory-Webdienst aus Das Admin-Konto hat außerdem die Rechte zur Durchführung der folgenden domänenweiten Aktivitäten: + Verwalten von DNS-Konfigurationen (Hinzufügen, Entfernen oder Aktualisieren von Datensätzen, Zonen und Weiterleitungen) + Aufrufen von DNS-Ereignisprotokollen + Anzeigen von Sicherheitsereignisprotokollen **Um ein Verzeichnis zu erstellen mit AWS Managed Microsoft AD** 1. Melden Sie sich bei an AWS-Managementkonsole und öffnen Sie die Directory Service Konsole unter [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. Wählen Sie im Navigationsbereich **Directories (Verzeichnisse)** aus. Wählen Sie denn **Set up Directory (Verzeichnis einrichten)** aus. 1. Wähle **AWS Managed Microsoft AD**. AWS Managed Microsoft ADist die einzige Option, die Sie derzeit mit Amazon RDS verwenden können. 1. Geben Sie die folgenden Informationen ein: **DNS-Name des Verzeichnisses** Den vollständig qualifizierten Namen für das Verzeichnis, z. B. **corp.example.com**. **NetBIOS-Name des Verzeichnisses** Die kurzen Namen für das Verzeichnis, z. B. **CORP**. **Verzeichnisbeschreibung** (Optional) Eine Beschreibung für das Verzeichnis. **Administratorpasswort** Das Passwort für den Verzeichnisadministrator. Während des Verzeichniserstellungsprozesses wird ein Administratorkonto mit dem Benutzernamen Admin und diesem Passwort angelegt. Das Passwort für den Verzeichnisadministrator das nicht das Wort "admin" enthalten. Beachten Sie beim Passwort die Groß- und Kleinschreibung und es muss 8 bis 64 Zeichen lang sein. Zudem muss es mindestens ein Zeichen aus dreien der vier folgenden Kategorien enthalten: + Kleinbuchstaben (a–z) + Großbuchstaben (A–Z) + Zahlen (0–9) + Nicht-alphanumerische Zeichen (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/) **Passwort bestätigen** Das Administratorpasswort, das erneut eingegeben wurde. 1. Wählen Sie **Weiter** aus. 1. Geben Sie die folgenden Informationen in den Abschnitt **Networking** ein. Wählen Sie dann **Next (Weiter)** aus: **VPC** Die VPC für das Verzeichnis. Erstellen Sie die MySQL-DB-Instance in derselben VPC. **Subnetze** Subnetze für die Verzeichnisserver. Die beiden Subnetze müssen zu verschiedenen Availability-Zonen gehören. 1. Prüfen Sie die Verzeichnisinformationen und nehmen Sie ggf. Änderungen vor. Wenn die Informationen richtig sind, wählen Sie **Create directory (Verzeichnis erstellen)**. ![\[Das Fenster Überprüfen und erstellen während der Verzeichniserstellung in der Directory Service Konsole.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/WinAuth2.png) Es dauert einige Minuten, bis das Verzeichnis erstellt wurde. Wenn es erfolgreich erstellt wurde, ändert sich der Wert **Status** in **Active (Aktiv)**. Um Informationen über Ihr Verzeichnis anzuzeigen, wählen Sie den Verzeichnisnamen in der Verzeichnisliste aus. Beachten Sie den Wert **Directory ID (Verzeichnis-ID)**. Sie benötigen diesen Wert, wenn Sie Ihre MySQL-DB-Instance erstellen oder ändern. ![\[Der Abschnitt mit den Verzeichnisdetails mit der Verzeichnis-ID in der Directory Service Konsole.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/WinAuth3.png) ### Schritt 2: Erstellen der IAM-Rolle für die Verwendung durch Amazon RDS Damit Amazon RDS Directory Service für Sie anrufen kann, ist eine IAM-Rolle erforderlich, die die verwaltete IAM-Richtlinie `AmazonRDSDirectoryServiceAccess` verwendet. Diese Rolle ermöglicht es Amazon RDS, Aufrufe von Directory Service durchzuführen. Wenn eine DB-Instance mit dem erstellt wird AWS-Managementkonsole und der Konsolenbenutzer über die `iam:CreateRole` entsprechende Berechtigung verfügt, erstellt die Konsole diese Rolle automatisch. In diesem Fall lautet der Rollenname `rds-directoryservice-kerberos-access-role`. Andernfalls müssen Sie die IAM-Rolle manuell erstellen. Wenn Sie diese IAM-Rolle erstellen`Directory Service`, wählen Sie die AWS verwaltete Richtlinie aus und hängen Sie sie `AmazonRDSDirectoryServiceAccess` an. Weitere Informationen zum Erstellen von IAM-Rollen für einen Dienst finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS Dienst](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) im *IAM-Benutzerhandbuch*. **Anmerkung** Die für die Windows-Authentifizierung für RDS für SQL Server verwendete IAM-Rolle kann nicht für RDS für MySQL verwendet werden. Optional können Sie Richtlinien mit den erforderlichen Berechtigungen erstellen, anstatt die verwaltete IAM-Richtlinie zu verwende `AmazonRDSDirectoryServiceAccess`. In diesem Fall muss die IAM-Rolle die folgende IAM-Vertrauensrichtlinie haben. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": [ "directoryservice.rds.amazonaws.com", "rds.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ Die Rolle muss auch über die folgende IAM-Rollenrichtlinie verfügen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ds:DescribeDirectories", "ds:AuthorizeApplication", "ds:UnauthorizeApplication", "ds:GetAuthorizedApplicationDetails" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ ### Schritt 3: Anlegen und konfigurieren von Benutzern Sie können Benutzer mit dem Tool "Active Directory-Benutzer und -Computer" erstellen. Dieses Tool ist Teil der Tools Active Directory Domain Services und Active Directory Lightweight Directory Services. „Benutzer“ sind Einzelpersonen oder Entitäten, die Zugriff auf Ihr Verzeichnis haben. Um Benutzer in einem Directory Service Verzeichnis zu erstellen, müssen Sie mit einer EC2 Amazon-Instance verbunden sein, die auf Microsoft Windows basiert. Diese Instance muss Mitglied des Directory Service Verzeichnisses sein und als Benutzer angemeldet sein, der über die Rechte zum Erstellen von Benutzern verfügt. Weitere Informationen finden Sie unter[ Verwalten von Benutzern und GruppenAWS Managed Microsoft AD imAWS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/creating_ad_users_and_groups.html)* Directory-Service-Administrationshandbuch*. ### Schritt 4: Erstellen oder Ändern einer MySQL-DB-Instance Erstellen oder ändern Sie eine MySQL-DB-Instance zur Verwendung mit Ihrem Verzeichnis. Sie können die Konsole, CLI oder RDS-API verwenden, um eine DB-Instance einem Verzeichnis zuzuordnen. Sie können dafür eine der folgenden Möglichkeiten auswählen: + Erstellen Sie eine neue MySQL-DB-Instance mit der Konsole, dem [ create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI-Befehl oder dem Vorgang [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API. Detaillierte Anweisungen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md). + Ändern Sie eine bestehende MySQL-DB-Instance mithilfe der Konsole, des [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI-Befehls oder der Operation [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API. Detaillierte Anweisungen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). + Stellen Sie mithilfe der Konsole, des CLI-Befehls -db-snapshot oder des API-Vorgangs Restore From DBSnapshot RDS eine [ restore-db-instance-fromMySQL-DB-Instance DBInstance aus einem DB-Snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) [wieder her](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html). Detaillierte Anweisungen finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md). + Stellen Sie eine MySQL-DB-Instance point-in-time mithilfe der Konsole, des Befehls [ restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI oder der Operation [Restore DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API in a wieder her. Detaillierte Anweisungen finden Sie unter [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md). Die Kerberos-Authentifizierung wird nur für MySQL-DB-Instances in einer VPC unterstützt. Die DB-Instance kann sich in derselben VPC wie das Verzeichnis oder in einer anderen VPC befinden. Die DB-Instance muss eine Sicherheitsgruppe verwenden, die ausgehenden Datenverkehr innerhalb der VPC des Verzeichnisses ermöglicht, damit die DB-Instance mit dem Verzeichnis kommunizieren kann. Wenn Sie die Konsole verwenden, ändern oder wiederherstellen, um eine DB-Instance zu erstellen, wählen Sie im Abschnitt **Datenbankauthentifizierung** die Option **Passwort- und Kerberos-Authentifizierung** aus. Wählen Sie **Verzeichnis durchsuchen** und dann das Verzeichnis aus, oder klicken Sie auf **Neues Verzeichnis erstellen**. ![\[Der Abschnitt Datenbank-Authentifizierung mit der Passwort- und Kerberos-Authentifizierung, die in der Amazon-RDS-Konsole ausgewählt wurde.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/kerberos-authentication.png) Wenn Sie die AWS CLI oder die RDS-API verwenden, ordnen Sie eine DB-Instance einem Verzeichnis zu. Die folgenden Parameter sind erforderlich, damit die DB-Instance das von Ihnen erstellte Domain-Verzeichnis verwendet: + Für den `--domain`-Parameter verwenden Sie den Domänenbezeichner („d-\$1“-Bezeichner), der beim Erstellen des Verzeichnisses generiert wurde. + Verwenden Sie für den `--domain-iam-role-name`-Parameter die von Ihnen erstellte Rolle, die die verwaltete IAM-Richtlinie `AmazonRDSDirectoryServiceAccess` verwendet. Beispielsweise ändert der folgende CLI-Befehl eine DB-Instance zur Verwendung eines Verzeichnisses. Für Linux, macOS oder Unix: ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --domain d-ID \ --domain-iam-role-name role-name ``` Für Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --domain d-ID ^ --domain-iam-role-name role-name ``` **Wichtig** Wenn Sie eine DB-Instance zur Aktivierung der Kerberos-Authentifizierung ändern, starten Sie die DB-Instance neu, nachdem Sie die Änderung vorgenommen haben. ### Schritt 5: Erstellen von MySQL-Anmeldeinformationen für die Kerberos-Authentifizierung Verwenden Sie die Amazon-RDS-Hauptbenutzer-Anmeldeinformationen, um sich mit der MySQL-DB-Instance wie mit jeder anderen DB-Instance zu verbinden. Die DB-Instance ist mit der AWS Managed Microsoft AD Domain verbunden. Auf diese Weise können Sie MySQL-Anmeldenamen und -Benutzer aus den Active Directory-Benutzern Ihrer Domäne bereitstellen. Die Datenbankberechtigungen werden durch Standard-MySQL-Berechtigungen verwaltet, die diesen Anmeldeinformationen gewährt und entzogen werden. Sie können einem Active Directory-Benutzer erlauben, sich bei MySQL zu authentifizieren. Dazu verwenden Sie zunächst die Amazon-RDS-Hauptbenutzer-Anmeldeinformationen, um sich mit der MySQL-DB-Instance wie mit jeder anderen DB-Instance zu verbinden. Nachdem Sie sich angemeldet haben, erstellen Sie einen extern authentifizierten Benutzer mit PAM (Pluggable Authentication Modules) in MySQL durch Ausführen des folgenden Befehls. Ersetzen Sie `testuser` durch den Benutzernamen. ``` CREATE USER 'testuser'@'%' IDENTIFIED WITH 'auth_pam'; ``` Benutzer (sowohl Menschen als auch Anwendungen) aus Ihrer Domäne können sich nun von einem mit der Domäne verbundenen Client-Rechner aus mit Hilfe der Kerberos-Authentifizierung mit der DB-Instance verbinden. **Wichtig** Wir empfehlen dringend, dass Clients SSL/TLS Verbindungen verwenden, wenn sie die PAM-Authentifizierung verwenden. Wenn sie keine SSL/TLS Verbindungen verwenden, wird das Passwort in einigen Fällen möglicherweise als Klartext gesendet. Um eine SSL/TLS verschlüsselte Verbindung für Ihren AD-Benutzer zu verlangen, führen Sie den folgenden Befehl aus und `testuser` ersetzen Sie ihn durch den Benutzernamen: ``` ALTER USER 'testuser'@'%' REQUIRE SSL; ``` Weitere Informationen finden Sie unter [SSL/TLS-Unterstützung für MySQL-DB-Instances in Amazon RDS](MySQL.Concepts.SSLSupport.md). ## Verwalten einer DB-Instance in einer Domäne Sie können die CLI oder die RDS-API verwenden, um Ihre DB-Instance und ihre Beziehung zu Ihrem verwalteten Active Directory zu verwalten. Sie können z. B. ein Active Directory für die Kerberos-Authentifizierung zuordnen und ein Active Directory trennen, um die Kerberos-Authentifizierung zu deaktivieren. Sie können auch eine DB-Instance, die extern von einem Active Directory authentifiziert werden soll, in ein anderes Active Directory verschieben. Sie können z. B. mithilfe der Amazon-RDS-API Folgendes tun: + Um erneut zu versuchen, die Kerberos-Authentifizierung für eine fehlgeschlagene Mitgliedschaft zu aktivieren, verwenden Sie die `ModifyDBInstance` API-Operation und geben Sie die Verzeichnis-ID der aktuellen Mitgliedschaft an. + Um den IAM-Rollennamen für die Mitgliedschaft zu aktualisieren, verwenden Sie die `ModifyDBInstance`-API-Operation und geben Sie die Verzeichnis-ID der aktuellen Mitgliedschaft und die neue IAM-Rolle an. + Um die Kerberos-Authentifizierung in einer DB-Instance zu deaktivieren, verwenden Sie die `ModifyDBInstance` API-Operation. Geben Sie `none` als Domänenparameter an. + Um eine DB-Instance von einer Domäne in eine andere zu verschieben, verwenden Sie die `ModifyDBInstance` API-Operation. Geben Sie die Domänen-ID der neuen Domäne als Domänenparameter an. + Um die Mitgliedschaft für jede DB-Instance aufzulisten, verwenden Sie die `DescribeDBInstances` API-Operation. ### Grundlegendes zur Domänenmitgliedschaft Nachdem Sie Ihre DB-Instance erstellt oder geändert haben, wird sie Mitglied der Domäne. Sie können den Status der Domänenmitgliedschaft für die DB-Instance anzeigen, indem Sie den [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI-Befehl ausführen. Der Status der DB-Instance kann einer der folgenden sein: + `kerberos-enabled` – Für die DB-Instance ist die Kerberos-Authentifizierung aktiviert. + `enabling-kerberos`— AWS ist dabei, die Kerberos-Authentifizierung für diese DB-Instance zu aktivieren. + `pending-enable-kerberos` – Die Aktivierung der Kerberos-Authentifizierung in dieser DB-Instance steht aus. + `pending-maintenance-enable-kerberos`— AWS wird versuchen, die Kerberos-Authentifizierung auf der DB-Instance während des nächsten geplanten Wartungsfensters zu aktivieren. + `pending-disable-kerberos` – Die Deaktivierung der Kerberos-Authentifizierung in dieser DB-Instance steht aus. + `pending-maintenance-disable-kerberos`— AWS wird versuchen, die Kerberos-Authentifizierung auf der DB-Instance während des nächsten geplanten Wartungsfensters zu deaktivieren. + `enable-kerberos-failed` – Ein Konfigurationsproblem hat AWS daran gehindert, die Kerberos-Authentifizierung auf der DB-Instance zu aktivieren. Überprüfen und korrigieren Sie Ihre Konfiguration, bevor Sie den Befehl zu Änderung der DB-Instance erneut ausführen. + `disabling-kerberos`— AWS ist dabei, die Kerberos-Authentifizierung auf dieser DB-Instance zu deaktivieren. Eine Anfrage zur Aktivierung der Kerberos-Authentifizierung kann wegen eines Netzwerkverbindungsproblems oder einer falschen IAM-Rolle fehlschlagen. Angenommen, Sie erstellen eine DB-Instance oder ändern eine vorhandene DB-Instance und der Versuch, die Kerberos-Authentifizierung zu aktivieren, schlägt fehl. Wenn dies geschieht, führen Sie den Ändern-Befehl erneut aus oder ändern Sie die neu erstellte DB-Instance, um der Domäne beizutreten. ## Verbindung zu MySQL mit Kerberos-Authentifizierung Um eine Verbindung zu MySQL mit Kerberos-Authentifizierung herzustellen, müssen Sie sich mit dem Kerberos-Authentifizierungstyp anmelden. Um einen Datenbankbenutzer zu erstellen, zu dem Sie eine Verbindung mit der Kerberos-Authentifizierung herstellen können, verwenden Sie eine `IDENTIFIED WITH`-Klausel in der `CREATE USER`-Anweisung. Detaillierte Anweisungen finden Sie unter [Schritt 5: Erstellen von MySQL-Anmeldeinformationen für die Kerberos-Authentifizierung](#mysql-kerberos-setting-up.create-logins). Um Fehler zu vermeiden, sollten Sie den MariaDB-`mysql`-Client verwenden. Sie können die MariaDB-Software unter [https://downloads.mariadb.org/](https://downloads.mariadb.org/) herunterladen. Stellen Sie über die Eingabeaufforderung eine Verbindung zu einem der Endpunkte her, die mit Ihrer MySQL-DB-Instance verbunden sind. Befolgen Sie die allgemeinen Verfahren in [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). Wenn Sie zur Eingabe des Passworts aufgefordert werden, geben Sie es mit diesem Benutzernamen verknüpfte Kerberos-Passwort ein. ## Wiederherstellen einer MySQL-DB-Instance und Hinzufügen zu einer Domäne Sie können einen DB-Snapshot point-in-time wiederherstellen oder eine Wiederherstellung für eine MySQL-DB-Instance abschließen und sie dann einer Domain hinzufügen. Nachdem die DB-Instance wiederhergestellt wurde, modifizieren Sie die DB-Instance mit dem in [Schritt 4: Erstellen oder Ändern einer MySQL-DB-Instance](#mysql-kerberos-setting-up.create-modify) erklärten Prozess, um die DB-Instance zu einer Domäne hinzuzufügen. ## MySQL-Einschränkungen bei der Kerberos-Authentifizierung Die folgenden Einschränkungen gelten für die Kerberos-Authentifizierung für MySQL: + Es AWS Managed Microsoft AD wird nur eine Verbindung unterstützt. Sie können jedoch DB-Instances von RDS für MySQL zu gemeinsam genutzten verwalteten Microsoft-AD-Domänen zusammenführen, die verschiedene Konten in derselben AWS-Region gehören. + Sie müssen die DB-Instance neu starten, nachdem Sie die Funktion aktiviert haben. + Die Länge des Domänennamens darf nicht länger als 61 Zeichen sein. + Sie können nicht gleichzeitig die Kerberos-Authentifizierung und die IAM-Authentifizierung aktivieren. Wählen Sie die eine oder die andere Authentifizierungsmethode für Ihre MySQL-DB-Instance aus. + Ändern Sie den DB-Instance-Port nicht, nachdem Sie die Funktion aktiviert haben. + Verwenden Sie keine Kerberos-Authentifizierung mit Lesereplikaten. + Wenn Sie das automatische Minor-Versions-Upgrade für eine MySQL DB-Instance aktiviert haben, die die Kerberos-Authentifizierung verwendet, müssen Sie die Kerberos-Authentifizierung deaktivieren und nach einem automatischen Upgrade wieder einschalten. Weitere Informationen zu kleineren automatischen Versionsaktualisierungen finden Sie unter [Automatische Unterversion-Upgrades von RDS für MySQL](USER_UpgradeDBInstance.MySQL.Minor.md). + Um eine DB-Instance bei aktivierter Funktion zu löschen, deaktivieren Sie zuerst die Funktion. Führen Sie dazu den CLI-Befehl `modify-db-instance` für die DB-Instance aus und geben Sie `none` für den Parameter `--domain` an. Wenn Sie die CLI oder die RDS-API verwenden, um eine DB-Instance bei aktivierter Funktion zu löschen, müssen Sie mit einer Verzögerung rechnen. + RDS für MySQL unterstützt keine Kerberos-Authentifizierung in einer Gesamtstruktur zwischen dem lokalen oder selbst gehosteten AD und dem AWS Managed Microsoft AD. # Verbesserung der Abfrageleistung für RDS für MySQL mit Amazon RDS Optimized Reads Mit Amazon RDS Optimized Reads können Sie eine schnellere Abfrageverarbeitung für RDS für MySQL erreichen. Eine DB-Instance oder ein Multi-AZ-DB-Cluster von RDS für MySQL, die bzw. der RDS-optimierte Lesevorgänge verwendet, kann eine doppelt so schnelle Abfrageverarbeitung erreichen wie eine DB-Instance oder ein DB-Cluster, die bzw. der diese Funktion nicht verwendet. **Topics** + [ ## Übersicht über RDS Optimized Reads ](#rds-optimized-reads-overview) + [ ## Anwendungsfälle für RDS Optimized Reads ](#rds-optimized-reads-use-cases) + [ ## Bewährte Methoden für RDS Optimized Reads ](#rds-optimized-reads-best-practices) + [ ## Verwenden von RDS Optimized Reads ](#rds-optimized-reads-using) + [ ## Überwachen von DB-Instances, die RDS Optimized Reads verwenden ](#rds-optimized-reads-monitoring) + [ ## Einschränkungen für RDS Optimized Reads ](#rds-optimized-reads-limitations) ## Übersicht über RDS Optimized Reads Wenn Sie eine DB-Instance oder einen Multi-AZ-DB-Cluster von RDS für MySQL verwenden, für die bzw. den RDS-optimierte Lesevorgänge aktiviert sind, wird durch die Verwendung eines Instance-Speichers eine schnellere Abfrageleistung erreicht. Ein *Instance-Speicher* stellt für Ihre DB-Instance bzw. Ihren Multi-AZ-DB-Cluster temporären Speicher auf Blockebene bereit. Der Speicher befindet sich auf Non-Volatile Memory Express (NVMe)-SSDs, die physisch mit dem Hostserver verbunden sind. Dieser Speicher ist für niedrige Latenzen, eine hohe Random-I/O-Leistung und einen hohen sequentiellen Lesedurchsatz optimiert. RDS-optimierte Lesevorgänge sind standardmäßig aktiviert, wenn eine DB-Instance oder ein Multi-AZ-DB-Cluster 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-Speicher finden Sie unter [Instance-Speicher von Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) im *Benutzerhandbuch für Amazon Elastic Compute Cloud für Linux-Instances*. Die Workloads, die temporäre Objekte in MySQL 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, Joins mit hoher Auslastung, Common Table Expressions (CTEs) und Abfragen für nicht indizierte 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 mit temporären Objekten in den Instance-Speicher auslagert, können die Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) oder der Durchsatz des persistenten Speichers (Amazon EBS) jetzt für Operationen an 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 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 Common Table Expressions (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 den verfügbaren Speicherplatz im Instance-Speicher mit der CloudWatch-Metrik `FreeLocalStorage`. 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 bzw. Ihr Multi-AZ-DB-Cluster ü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 bei den MySQL 8.0-Versionen und früheren Versionen den Standardwert von `MIXED` für den Parameter `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. Verwenden Sie bei MySQL 8.4 und höheren Versionen den Standardwert von `ROW` für den Parameter `binlog_format`. + Stellen Sie den Parameter [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) auf `TempTable` ein und legen Sie den Parameter [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) so fest, dass er der Größe des verfügbaren Speichers im Instance-Speicher entspricht. + 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 Sie den Standardwert `ABORT_SERVER` für den `binlog_error_action`-Parameter. Dadurch werden Probleme mit der binären Protokollierung auf DB-Instances mit aktivierten Backups vermieden. ## Verwenden von RDS Optimized Reads Wenn Sie eine DB-Instance von RDS für MySQL mit einer der folgenden DB-Instance-Klassen in einer Single-AZ-Bereitstellung oder einer Multi-AZ-Bereitstellung der DB-Instance oder in einer Multi-AZ-DB-Cluster-Bereitstellung 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 oder einen Multi-AZ-DB-Cluster von RDS für MySQL 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 oder einen Multi-AZ-DB-Cluster von RDS für MySQL so, dass eine dieser DB-Instance-Klassen verwendet wird. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). RDS Optimized Reads ist in allen AWS-Regionen verfügbar, in denen eine oder mehrere der 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-Klasse ist für AWS-Regionen unterschiedlich. Informationen dazu, ob eine DB-Instance-Klasse in einer bestimmten AWS-Region unterstützt wird, finden Sie unter [Ermitteln der Unterstützung für DB-Instance-Klassen in AWS-Regionen](Concepts.DBInstanceClass.RegionSupport.md). Wenn Sie RDS-optimierte Lesevorgänge nicht verwenden möchten, ändern Sie Ihre DB-Instance bzw. Ihren Multi-AZ-DB-Cluster so, dass keine DB-Instance-Klasse verwendet wird, die die Funktion unterstützt. ## Überwachen von DB-Instances, die RDS Optimized Reads verwenden Sie können DB-Instances, die RDS Optimized Reads verwenden, mit den 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 unterstützt: + RDS für MySQL 8.0.28 und höhere Haupt- und Unterversionen Informationen zu den Versionen von RDS für MySQL finden Sie unter [MySQL in Amazon-RDS-Versionen](MySQL.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 MySQL 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 RDS-optimierten Schreibvorgängen für MySQL Sie können die Leistung von Schreibtransaktionen mit RDS-optimierten Schreibvorgängen für MySQL verbessern. Wenn Ihre Datenbank von RDS für MySQL RDS Optimized Writes 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) + [ ## Aktivieren von RDS-optimierten Schreibvorgängen in einer vorhandenen Datenbank ](#rds-optimized-writes-modify-enable) + [ ## Einschränkungen für RDS Optimized Writes ](#rds-optimized-writes-limitations) ## Übersicht über RDS Optimized Writes Wenn Sie RDS-optimierte Schreibvorgänge aktivieren, schreiben die Datenbanken von RDS für MySQL beim Leeren von Daten in einen dauerhaften Speicher nur einmal, 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 MySQL bieten die *ACID-Eigenschaften* Atomizität, Konsistenz, Isolation und Beständigkeit für zuverlässige Datenbanktransaktionen. Um diese Eigenschaften bereitzustellen, verwendet MySQL 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 MySQL-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 MySQL finden Sie unter [Doublewrite-Puffer](https://dev.mysql.com/doc/refman/8.0/en/innodb-doublewrite-buffer.html) in der MySQL-Dokumentation. Wenn Amazon RDS Optimized Writes aktiviert ist, schreiben Ihre Datenbanken von RDS für MySQL beim Leeren von Daten in einen dauerhaften Speicher nur einmal, ohne den Doublewrite-Puffer zu verwenden. RDS Optimized Writes ist nützlich, wenn Sie schreibintensive Workloads in Ihren Datenbanken von RDS für MySQL 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 Optimized Writes für Datenbanken von RDS für MySQL zu steuern. Greifen Sie auf diesen Parameter in der DB-Parametergruppe von RDS für MySQL 8.0 und RDS für MySQL 8.4 zu. 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 über eine bestehende Datenbank mit einer Engine-Version, DB-Instance-Klasse und and/or file system format that doesn't support RDS Optimized Writes, you can enable the feature by creating a blue/green Bereitstellung verfügen. Weitere Informationen finden Sie unter [Aktivieren von RDS-optimierten Schreibvorgängen in einer vorhandenen Datenbank](#rds-optimized-writes-modify-enable). Wenn Sie eine Datenbank von RDS für MySQL, die für die Verwendung von RDS Optimized Writes konfiguriert ist, zu einer DB-Instance-Klasse migrieren, die die Funktion nicht unterstützt, deaktiviert RDS die Funktion RDS Optimized Writes für die Datenbank automatisch. Wenn RDS Optimized Writes deaktiviert ist, verwendet die Datenbank den MySQL-Doublewrite-Puffer. Um festzustellen, ob eine Datenbank von RDS für MySQL die Funktion RDS Optimized Writes 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 MySQL-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 MySQL Version 8.0.30 und höher unterstützt. Informationen zu den Versionen von RDS für MySQL finden Sie unter [MySQL in Amazon-RDS-Versionen](MySQL.Concepts.VersionMgmt.md). + RDS Optimized Writes wird für Datenbanken von RDS für MySQL 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). Um Ihre Datenbank auf eine DB-Instance-Klasse zu aktualisieren, die RDS-optimierte Schreibvorgänge unterstützt, können Sie eine blue/green Bereitstellung erstellen. Weitere Informationen finden Sie unter [Aktivieren von RDS-optimierten Schreibvorgängen in einer vorhandenen Datenbank](#rds-optimized-writes-modify-enable). + 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 MySQL zu erstellen, können Sie nach den Versionen der DB-Engine und den DB-Instance-Klassen filtern, die RDS Optimized Writes 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 Optimized Writes unterstützt, filtern Sie in **Engine version** (Engine-Version) nach den DB-Engine-Versionen von RDS für MySQL, 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.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 MySQL mit der Konsole abschließen. ### AWS CLI Um eine DB-Instance mithilfe von 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 mysql \ 4. --engine-version 8.0.30 \ 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 mysql ^ 4. --engine-version 8.0.30 ^ 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 RDS-für-MySQL-Datenbank zu ändern, um 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 27. November 2022 erstellt worden sein, da die erforderliche zugrunde liegende Dateisystemkonfiguration nicht mit der 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 `rds.optimized_writes`-Parameter 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). + 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 die blue/green Bereitstellung umschalten, 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 MySQL 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 DB-Engine von RDS für MySQL 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 MySQL-Datenbanken: Hauptversion-Upgrades und Unterversion-Upgrades. **Hauptversions-Upgrades** *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 Hauptversion-Upgrade durchführen, wird das Befolgen der Schritte unter [Hauptversion-Upgrades von RDS für MySQL](USER_UpgradeDBInstance.MySQL.Major.md) empfohlen. Für Hauptversion-Upgrades von DB-Instance-Bereitstellungen mit Multi-AZ werden sowohl die Primär- als auch die Standby-Replikate in Amazon RDS gleichzeitig aktualisiert. Ihre DB-Instance ist möglicherweise erst verfügbar, wenn das Upgrade abgeschlossen ist. Bei Hauptversion-Upgrades von DB-Cluster-Bereitstellungen mit Multi-AZ aktualisiert Amazon RDS die Cluster-Mitglieds-Instances nacheinander. Sie können die Ausfallzeit, die für ein Upgrade einer Hauptversion erforderlich ist, 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). **Unterversion-Upgrades** *Unterversion-Upgrades* enthalten nur Änderungen, die abwärtskompatibel mit bestehenden Anwendungen 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 **Automatisches Unterversion-Upgrade** aktivieren. Hierdurch wird Ihre DB-Instance von Amazon RDS automatisch aktualisiert, nachdem die neue Version 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 Sie ein Unterversions-Upgrade eines DB-Clusters mit Multi-AZ durchführen, aktualisiert Amazon RDS zunächst die Reader-DB-Instances nacheinander. Dann wechselt eine der Reader-DB-Instances zur neuen Writer-DB-Instance. Amazon RDS aktualisiert anschließend die alte Writer-Instance (die nun eine Reader-Instance ist). Die Ausfallzeit kann bei einem Unterversion-Upgrade einer DB-*Instance*-Bereitstellung mit Multi-AZ mehrere Minuten betragen. DB-Cluster mit Multi-AZ reduzieren die Ausfallzeit bei Unterversion-Upgrades in der Regel auf etwa 35 Sekunden. Bei Verwendung mit dem RDS-Proxy können Sie die Ausfallzeit weiter auf eine Sekunde oder weniger reduzieren. Weitere Informationen finden Sie unter [Amazon RDS-Proxy ](rds-proxy.md). Alternativ können Sie einen Open-Source-Datenbank-Proxy wie [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/) oder den [AWS Advanced JDBC [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/)Wrapper Driver verwenden. 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). Wenn Ihre MySQL-DB-Instance Lesereplikate verwendet, müssen Sie alle Lesereplikate aktualisieren, bevor Sie die Quell-Instance aktualisieren. **Topics** + [ ## Überlegungen zu MySQL-Upgrades ](#USER_UpgradeDBInstance.MySQL.Considerations) + [ ## Finden gültiger Upgrade-Ziele ](#USER_UpgradeDBInstance.MySQL.FindingTargets) + [ # MySQL-Versionsnummern ](USER_UpgradeDBInstance.MySQL.VersionID.md) + [ # RDS-Versionsnummern in RDS für MySQL ](USER_UpgradeDBInstance.MySQL.rds.version.md) + [ # Hauptversion-Upgrades von RDS für MySQL ](USER_UpgradeDBInstance.MySQL.Major.md) + [ # Testen eines Upgrades von RDS für MySQL ](USER_UpgradeDBInstance.MySQL.UpgradeTesting.md) + [ ## Upgraden einer MySQL-DB-Instance ](#USER_UpgradeDBInstance.MySQL.Upgrading) + [ # Automatische Unterversion-Upgrades von RDS für MySQL ](USER_UpgradeDBInstance.MySQL.Minor.md) + [ # Verwenden eines Lesereplikats zur Reduzierung von Ausfallzeiten beim Upgrade einer Datenbank in RDS für MySQL ](USER_UpgradeDBInstance.MySQL.ReducedDowntime.md) + [ # Überwachung von RDS für MySQL-Engine-Upgrades mit Ereignissen ](USER_UpgradeDBInstance.MySQL.Monitoring.md) ## Überlegungen zu MySQL-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 Lesereplikate aktualisieren, bevor Sie die Quell-Instance aktualisieren. ## 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 mysql \ --engine-version version_number \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Für Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version version_number ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Um beispielsweise die gültigen Upgrade-Ziele für eine MySQL-DB-Instance der Version 8.0.28 zu identifizieren, führen Sie den folgenden AWS CLI Befehl aus: Für Linux, macOS oder Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version 8.0.28 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Für Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version 8.0.28 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` # MySQL-Versionsnummern Die Versionsnummerierungssequenz für die Datenbank-Engine von RDS für MySQL hat entweder die Form *Hauptversion.Unterversion.Patch.JJJJMMTT* oder *Hauptversion.Unterversion.Patch*, zum Beispiel 8.0.33.R2.20231201 oder 5.7.44. Das Format hängt von der Version der MySQL-Engine ab. Informationen zur Versionsnummerierung von RDS Extended Support finden Sie unter [Versionsnamen bei Amazon RDS Extended Support](extended-support-versions.md#extended-support-naming). **Hauptversion** Die Hauptversionsnummer ist sowohl die Ganzzahl als auch der erste Nachkommateil der Versionsnummer, z. B. 8.0. Ein Upgrade der Hauptversion erhöht den Hauptteil der Versionsnummer. Beispielsweise ist ein Upgrade von *5.7*.44 auf 8.0.33 ein Hauptversion-Upgrade, wobei *5.7* und *8.0* die Hauptversionsnummern sind. **Unterversion** Die Unterversionsnummer ist der dritte Teil der Versionsnummer, z. B. die 33 in 8.0.33. **Patch** Der Patch ist der vierte Teil der Versionsnummer, zum Beispiel R2 in 8.0.33.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 8.0.33.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 8.4 von RDS für MySQL erklärt. | Unterversion 8.4 | Benennungsschema | | --- | --- | | ≥ 3 | Neue DB-Instances verwenden das Format *Hauptversion.Unterversion.Patch.JJMMTT*, z. B. 8.4.3.R2.20241201. Bestehende DB-Instances verwenden möglicherweise *Hauptversion.Unterversion.Patch*, z. B. 8.4.3.R2, bis Sie Ihr nächstes Haupt- oder Unterversion-Upgrade durchführen. | In der folgenden Tabelle wird das Benennungsschema für Version 8.0 von RDS für MySQL erklärt. | Unterversion 8.0 | Benennungsschema | | --- | --- | | ≥ 33 | Neue DB-Instances verwenden das Format *Hauptversion.Unterversion.Patch.JJMMTT*, z. B. 8.0.33.R2.20231201. Bestehende DB-Instances verwenden möglicherweise *Hauptversion.Unterversion.Patch*, z. B. 8.0.33.R2, bis Sie Ihr nächstes Haupt- oder Unterversion-Upgrade durchführen. | | < 33 | Bestehende DB-Instances verwenden *Hauptversion.Unterversion.Patch*, z. B. 8.0.32.R2. | In der folgenden Tabelle wird das Benennungsschema für Version 5.7 von RDS für MySQL erklärt. | Unterversion 5.7 | Benennungsschema | | --- | --- | | ≥ 42 | Neue DB-Instances verwenden das Format *Hauptversion.Unterversion.Patch.JJMMTT*, z. B. 5.7.42.R2.20231201. Bestehende DB-Instances verwenden möglicherweise *Hauptversion.Unterversion.Patch*, z. B. 5.7.42.R2, bis Sie Ihr nächstes Haupt- oder Unterversion-Upgrade durchführen. | # RDS-Versionsnummern in RDS für MySQL RDS-Versionsnummern verwenden das Benennungsschema `major.minor.patch` oder `major.minor.patch.YYYYMMDD`. Die Versionen von Amazon RDS Extended Support verwenden das Benennungsschema für *minor-RDS.YYYYMMDD* Nebenversionen. Eine RDS-Patch-Version enthält wichtige Korrekturen, die einer Nebenversion nach ihrer Veröffentlichung hinzugefügt werden. Eine RDS-Datumsversion (*YYYYMMDD*) ist ein Sicherheitspatch. Ein Sicherheits-Patch enthält keine Korrekturen, die das Verhalten der Engine ändern könnten. Informationen zur Versionsnummerierung von RDS Extended Support finden Sie unter [Versionsnamen bei Amazon RDS Extended Support](extended-support-versions.md#extended-support-naming). Sie können die RDS-Versionsnummer Ihrer Datenbank von RDS für MySQL mit der folgenden SQL-Abfrage herausfinden: ``` mysql> select mysql.rds_version(); ``` Wenn Sie beispielsweise eine Datenbank von RDS für MySQL 8.0.34 abfragen, wird Folgendes zurückgegeben: ``` +---------------------+ | mysql.rds_version() | +---------------------+ | 8.0.34.R2.20231201 | +---------------------+ 1 row in set (0.01 sec) ``` # Hauptversion-Upgrades von RDS für MySQL Amazon RDS unterstützt die folgenden direkten Upgrades für Hauptversionen des MySQL-Datenbank-Engine: + MySQL 5.7 auf MySQL 8.0 + MySQL 8.0 auf MySQL 8.4 **Anmerkung** Sie können DB-Instances mit MySQL-Version 5.7, 8.0 und 8.4 nur mit DB-Instance-Klassen der neuesten und der aktuellen Generation erstellen. Es ist möglich, dass Sie eine DB-Instance, die auf einer DB-Instance-Klasse einer früheren Generation ausgeführt wird, auf eine höhere MySQL-Engine-Version upgraden möchten. In einem solchen Fall ändern Sie zunächst die DB-Instance so, dass diese eine DB-Instance-Klasse der neuesten oder aktuellen Generation verwendet. Anschließend können Sie die DB-Instance so modifizieren, dass sie die höhere Datenbank-Engine-Version von MySQL nutzt. Weiterführende Informationen zu Amazon-RDS-DB-Instance-Klassen finden Sie unter [](Concepts.DBInstanceClass.md). **Topics** + [ ## Übersicht über Upgrades von MySQL-Hauptversionen ](#USER_UpgradeDBInstance.MySQL.Major.Overview) + [ ## Vorabprüfung bei Upgrades ](#USER_UpgradeDBInstance.MySQL.Prechecks) + [ ## Rollback nach einem fehlgeschlagenen Upgrade ](#USER_UpgradeDBInstance.MySQL.Major.RollbackAfterFailure) ## Übersicht über Upgrades von MySQL-Hauptversionen Hauptversions-Upgrades können Datenbankänderungen enthalten, die nicht mit vorhandenen Anwendungen rückwärts kompatibel sind. Folglich werden Hauptversion-Upgrades in Amazon RDS nicht automatisch ausgeführt, sondern Sie müssen Ihre DB-Instance manuell ändern. Sie sollten jedes Upgrade gründlich testen, bevor Sie es auf Ihre Produktions-Instances anwenden. Um ein Hauptversion-Upgrade durchzuführen, müssen zunächst alle verfügbaren Betriebssystemupdates durchgeführt werden. Führen Sie nach Abschluss der Betriebssystemupdates das Upgrade auf die einzelnen Hauptversionen durch, z. B. von 5.7 auf 8.0 und dann von 8.0 auf 8.4. Informationen über das Upgrade eines DB-Clusters mit Multi-AZ von RDS für MySQL finden Sie unter [Aktualisieren der Engine-Version eines Multi-AZ-DB-Clusters für Amazon RDS](multi-az-db-clusters-upgrading.md). Vor dem 24. April 2014 erstellte MySQL-DB-Instances zeigen verfügbare Updates für das Betriebssystem an, bis es angewendet wurde. Weitere Informationen zu Betriebssystemupdates finden Sie unter [Updates auf einen anwenden](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades). Während des Upgrades einer Hauptversion von MySQL führt Amazon RDS die MySQL-Binärdatei `mysql_upgrade` aus, um die Tabellen zu aktualisieren, falls erforderlich. Außerdem leert Amazon RDS während des Upgrades einer Hauptversion die Tabellen `slow_log` und `general_log`. Speichern Sie die Protokollinhalte vor dem Upgrade einer Hauptversion, um die Protokollinformationen zu erhalten. MySQL-Hauptversions-Upgrades sind normalerweise in etwa 10 Minuten abgeschlossen. Einige Aktualisierungen können aufgrund der Klassengröße der DB-Instance länger dauern, oder weil die Instance bestimmten Richtlinien in nicht entsprich [Bewährte Methoden für Amazon RDS](CHAP_BestPractices.md). Wenn Sie eine DB-Instance von der Amazon-RDS-Konsole aktualisieren, zeigt der Status der DB-Instance an, wann das Upgrade abgeschlossen ist. Wenn Sie ein Upgrade mit AWS Command Line Interface (AWS CLI) durchführen, verwenden Sie den [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)Befehl und überprüfen Sie den `Status` Wert. ## Vorabprüfung bei Upgrades Amazon RDS führt vor dem Upgrade eine Vorabprüfung auf Inkompatibilität durch. Die Inkompatibilität variiert je nach MySQL-Version, auf die das Upgrade erfolgt. Die Vorabprüfungen enthalten einige Prüfungen, die in MySQL enthalten sind, und einige spezifische Prüfungen, die vom Amazon-RDS-Team erstellt wurden. Informationen zu den von MySQL bereitgestellten Vorabprüfungen finden Sie unter [Upgrade Checker-Dienstprogramm](https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-shell-utilities-upgrade.html). Die Vorabprüfungen werden ausgeführt, bevor die DB-Instance aufgrund des Upgrades angehalten wird. Sie verursachen also keine Ausfallzeiten. Wird während der Vorabprüfungen eine Inkompatibilität entdeckt, bricht Amazon RDS automatisch das Upgrade ab, ehe die DB-Instance angehalten wird. Amazon RDS generiert auch ein Ereignis für die Inkompatibilität. Weitere Informationen über Amazon-RDS-Ereignisse finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md). Amazon RDS zeichnet detaillierte Informationen zu allen Inkompatibilitäten in der Protokolldatei au `PrePatchCompatibility.log`. In den meisten Fällen enthalten die Protokolleinträge einen Link zur MySQL-Dokumentation mit Informationen zur Lösung des Inkompatibilitätsproblems. Weitere Informationen zum Anzeigen von Protokolldateien finden Sie unter [Anzeigen und Auflisten von Datenbank-Protokolldateien](USER_LogAccess.Procedural.Viewing.md). Aufgrund der Art der Vorabprüfung werden die Objekte in Ihrer Datenbank geprüft. Diese Analyse verbraucht Ressourcen und verlängert die Zeit, die für die Durchführung des Upgrades benötigt wird. **Topics** + [ ### Vorabprüfung bei Upgrades von MySQL 8.0 auf 8.4 ](#USER_UpgradeDBInstance.MySQL.80to84Prechecks) + [ ### Vorabprüfung bei Upgrades von MySQL 5.7 auf 8.0 ](#USER_UpgradeDBInstance.MySQL.57to80Prechecks) ### Vorabprüfung bei Upgrades von MySQL 8.0 auf 8.4 MySQL 8.4 ist in vielen Punkten nicht mit MySQL 8.0 kompatibel. Diese Inkompatibilitäten können bei einem Upgrade von MySQL 8.0 auf MySQL 8.4 Probleme verursachen. Damit das Upgrade erfolgreich durchgeführt werden kann, sind einige Vorbereitungsmaßnahmen auf Ihrer Datenbank durchzuführen. Im Folgenden finden Sie eine allgemeine Liste dieser Inkompatibilitäten: + Es darf keine Tabellen geben, die veraltete Datentypen oder Funktionen verwenden. + Es darf keine Auslöser mit fehlenden oder leeren Definern oder ungültigen Erstellungskontexten geben. + Es darf keine Verletzungen von Schlüsselwörtern oder reservierten Wörtern geben. Einige Schlüsselwörter sind in MySQL 8.4 möglicherweise reserviert, die zuvor nicht reserviert waren. Weitere Informationen finden Sie unter [Schlüsselwörter und reservierte Wörter](https://dev.mysql.com/doc/refman/8.4/en/keywords.html) in der MySQL-Dokumentation. + Es darf keine Tabellen in der `mysql`-Systemdatenbank von MySQL 8.0 geben, die denselben Namen wie eine Tabelle haben, die vom Daten-Dictionary von MySQL 8.4 verwendet wird. + Es dürfen keine veralteten SQL-Modi in Ihrer `sql_mode`-Systemvariableneinstellung definiert sein. + Es darf keine Tabellen oder gespeicherte Prozeduren mit einzelnen `ENUM`- oder `SET`-Spaltenelementen geben, deren Länge 255 Zeichen oder 1020 Bytes überschreitet. + Ihre MySQL-8.0-Installation darf keine Features verwenden, die in MySQL 8.4 nicht unterstützt werden. Weitere Informationen finden Sie unter [ Features removed in MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html#mysql-nutshell-removals) in der MySQL-Dokumentation. + Es darf keine Namen für Fremdschlüsseleinschränkungen mit mehr als 64 Zeichen geben. + Informationen zu verbesserter Unicode-Unterstützung finden Sie im folgenden Abschnitt: + Konvertieren Sie Objekte, die den `utf8mb3`-Zeichensatz verwenden, eventuell in Objekte, die den `utf8mb4`-Zeichensatz verwenden. Der `utf8mb3`-Zeichensatz ist veraltet. + Sie sollten anstelle von `utf8mb4` die Verwendung von `utf8` für Zeichensatzverweise in Betracht ziehen, da `utf8` zurzeit ein Alias für den `utf8mb3`-Zeichensatz ist. Wenn möglich, ändern Sie `utf8mb4` zuerst in `utf8` und führen Sie dann das Datenbank-Upgrade durch. + Da bei älteren Clients möglicherweise ein unbekannter Zeichensatzfehler für `utf8mb3` angezeigt wird, aktualisieren Sie Ihre Datenbankclients, bevor Sie das Datenbank-Upgrade durchführen. Weitere Informationen finden Sie unter [Der utf8mb3-Zeichensatz (UTF-8-Unicode-Kodierung mit 3 Bytes)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) in der MySQL-Dokumentation. Um den Zeichensatz zu ändern, können Sie manuell ein Backup, eine Wiederherstellung und eine Replikation Ihrer Datenbank durchführen. Oder Sie können Amazon RDS Blue/Green Deployments verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon RDS Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md). Wenn Sie ein Upgrade von MySQL 8.0 auf 8.4 starten, führt Amazon RDS Vorabprüfungen durch, um eventuelle Inkompatibilitäten zu entdecken. Informationen zum Ausführen von Upgrades auf MySQL 8.4 finden Sie unter [Upgrading MySQL](https://dev.mysql.com/doc/refman/8.4/en/upgrading.html) in der MySQL-Dokumentation. Diese Vorabprüfungen müssen durchgeführt werden. Sie können nicht ausgelassen werden. Die Vorabprüfungen bieten folgende Vorteile: + Sie können ungeplante Ausfallzeiten während des Upgrades vermeiden. + Wenn es Inkompatibilitäten gibt, verhindert Amazon RDS das Upgrade und stellt Ihnen ein Protokoll mit Informationen zu den Inkompatibilitäten bereit. Sie können das Protokoll für die Vorbereitung Ihrer Datenbank auf das Upgrade auf MySQL 8.4 verwenden, indem Sie die Inkompatibilitäten reduzieren. Detaillierte Informationen zum Entfernen von Inkompatibilitäten finden Sie unter [Preparing your installation for upgrade](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) in der MySQL-Dokumentation. ### Vorabprüfung bei Upgrades von MySQL 5.7 auf 8.0 MySQL 8.0 ist in vielen Punkten nicht mit MySQL 5.7 kompatibel. Diese Inkompatibilitäten können bei einem Upgrade von MySQL 5.7 auf MySQL 8.0 Probleme verursachen. Damit das Upgrade erfolgreich durchgeführt werden kann, sind einige Vorbereitungsmaßnahmen auf Ihrer Datenbank durchzuführen. Im Folgenden finden Sie eine allgemeine Liste dieser Inkompatibilitäten: + Es darf keine Tabellen geben, die veraltete Datentypen oder Funktionen verwenden. + Es darf keine verwaisten FRM-Dateien geben. + Es darf keine Auslöser mit fehlenden oder leeren Definern oder ungültigen Erstellungskontexten geben. + Es darf keine partitionierte Tabelle mit einer Speicher-Engine geben, für die es keine native Partitionierungsunterstützung gibt. + Es darf keine Verletzungen von Schlüsselwörtern oder reservierten Wörtern geben. Einige Schlüsselwörter sind in MySQL 8.0 möglicherweise reserviert, die zuvor nicht reserviert waren. Weitere Informationen finden Sie unter [Schlüsselwörter und reservierte Wörter](https://dev.mysql.com/doc/refman/8.0/en/keywords.html) in der MySQL-Dokumentation. + Es darf keine Tabellen in der MySQL 5.7 `mysql`-Systemdatenbank geben, die denselben Namen wie eine Tabelle haben, die vom MySQL 8.0-Daten-Dictionary verwendet wird. + Es dürfen keine veralteten SQL-Modi in Ihrer `sql_mode`-Systemvariableneinstellung definiert sein. + Es darf keine Tabellen oder gespeicherte Prozeduren mit einzelnen `ENUM`- oder `SET`-Spaltenelementen geben, deren Länge 255 Zeichen oder 1020 Bytes überschreitet. + Vor dem Upgrade auf MySQL 8.0.13 oder höher darf es keine Tabellenpartitionen innerhalb von freigegebenen InnoDB-Tabellenräumen geben. + Es darf keine Abfragen oder gespeicherten Programmdefinitionen aus MySQL 8.0.12 oder früher geben, die `ASC` oder `DESC`-Qualifizierer für `GROUP BY`-Klauseln verwenden. + Ihre MySQL 5.7-Installation darf keine Funktionen verwenden, die in MySQL 8.0 nicht unterstützt werden. Weitere Informationen finden Sie unter [In MySQL 8.0 entfernte Funktionen](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals) in der MySQL-Dokumentation. + Es darf keine Namen für Fremdschlüsseleinschränkungen mit mehr als 64 Zeichen geben. + Informationen zu verbesserter Unicode-Unterstützung finden Sie im folgenden Abschnitt: + Konvertieren Sie Objekte, die den `utf8mb3`-Zeichensatz verwenden, eventuell in Objekte, die den `utf8mb4`-Zeichensatz verwenden. Der `utf8mb3`-Zeichensatz ist veraltet. + Sie sollten anstelle von `utf8mb4` die Verwendung von `utf8` für Zeichensatzverweise in Betracht ziehen, da `utf8` zurzeit ein Alias für den `utf8mb3`-Zeichensatz ist. Wenn möglich, ändern Sie `utf8mb4` zuerst in `utf8` und führen Sie dann das Datenbank-Upgrade durch. + Da bei älteren Clients möglicherweise ein unbekannter Zeichensatzfehler für `utf8mb3` angezeigt wird, aktualisieren Sie Ihre Datenbankclients, bevor Sie das Datenbank-Upgrade durchführen. Weitere Informationen finden Sie unter [Der utf8mb3-Zeichensatz (UTF-8-Unicode-Kodierung mit 3 Bytes)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) in der MySQL-Dokumentation. Um den Zeichensatz zu ändern, können Sie manuell ein Backup, eine Wiederherstellung und eine Replikation Ihrer Datenbank durchführen. Oder Sie können Amazon RDS Blue/Green Deployments verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon RDS Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md). Wenn Sie ein Upgrade von MySQL 5.7 auf 8.0 starten, führt Amazon RDS Vorabprüfungen durch, um eventuelle Inkompatibilitäten zu entdecken. Informationen zum Ausführen von Upgrades auf MySQL 8.0 finden Sie unter [Ausführen von MySQL Upgrades](https://dev.mysql.com/doc/refman/8.0/en/upgrading.html) in der MySQL-Dokumentation. Diese Vorabprüfungen müssen durchgeführt werden. Sie können nicht ausgelassen werden. Die Vorabprüfungen bieten folgende Vorteile: + Sie können ungeplante Ausfallzeiten während des Upgrades vermeiden. + Wenn es Inkompatibilitäten gibt, verhindert Amazon RDS das Upgrade und stellt Ihnen ein Protokoll mit Informationen zu den Inkompatibilitäten bereit. Sie können das Protokoll für die Vorbereitung Ihrer Datenbank auf das Upgrade auf MySQL 8.0 verwenden, indem Sie die Inkompatibilitäten reduzieren. Detaillierte Informationen zum Entfernen von Inkompatibilitäten finden Sie unter [Vorbereiten Ihrer Installation auf ein Upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) in der MySQL-Dokumentation und unter [Upgrade auf MySQL 8.0? Dies müssen Sie wissen ...](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/) im MySQL Server Blog. ## Rollback nach einem fehlgeschlagenen Upgrade Wenn Sie eine DB-Instance von MySQL Version 5.7 auf MySQL-Version 8.0 oder von MySQL-Version 8.0 auf 8.4 aktualisieren, kann das Upgrade fehlschlagen. Insbesondere kann es scheitern, wenn das Datenwörterbuch Inkompatibilitäten enthält, die von den Vorprüfungen nicht erfasst wurden. In diesem Fall kann die Datenbank in der neuen MySQL-Version (8.0 bzw. 8.4) nicht erfolgreich gestartet werden. Zu diesem Zeitpunkt macht Amazon RDS die für das Upgrade durchgeführten Änderungen rückgängig. Nach dem Rollback führt die MySQL-DB-Instance die ursprüngliche Version aus. + MySQL-Version 8.0 (bei einem Rollback von MySQL 8.4) + MySQL-Version 5.7 (bei einem Rollback von MySQL 8.0) Wenn ein Upgrade fehlschlägt und rückgängig gemacht wird, generiert Amazon RDS ein Ereignis mit der Ereignis-ID RDS-EVENT-0188. In der Regel schlägt ein Upgrade fehl, da es Inkompatibilitäten in den Metadaten zwischen den Datenbanken in Ihrer DB-Instance und der Ziel-MySQL-Version gibt. Wenn ein Upgrade fehlschlägt, können Sie die Details zu diesen Inkompatibilitäten in der `upgradeFailure.log`-Datei einsehen. Beheben Sie die Inkompatibilitäten, bevor Sie erneut versuchen, ein Upgrade durchzuführen. Während eines erfolglosen Upgrade-Versuchs und Rollbacks wird Ihre DB-Instance neu gestartet. Alle ausstehenden Parameteränderungen werden während des Neustarts angewendet und bleiben nach dem Rollback bestehen. Weitere Informationen zum Upgrade auf MySQL 8.0 finden Sie in den folgenden Themen der MySQL-Dokumentation: + [Vorbereiten Ihrer Installation für das Upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) + [Upgrade auf MySQL 8.0? Hier ist was Sie wissen müssen…](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/) Detaillierte Informationen zum Upgrade auf MySQL 8.4 finden Sie unter [Preparing Your Installation for Upgrade](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) in der MySQL-Dokumentation. # Testen eines Upgrades von RDS für MySQL Ehe Sie ein Upgrade einer Hauptversion auf Ihrer DB-Instance durchführen, sollten Sie sorgfältig prüfen, ob Ihre Datenbank mit der neuen Version kompatibel ist. Darüber hinaus sollten Sie die Kompatibilität aller Anwendungen mit der neuen Version testen, die auf die Datenbank zugreifen. Wir empfehlen Ihnen folgendes Vorgehen. **Um ein Hauptversions-Upgrade zu testen** 1. Informieren Sie sich in der Upgrade-Dokumentation von Oracle über die neue Version der Datenbank-Engine, um zu prüfen, ob es Kompatibilitätsprobleme geben könnte, die sich auf Ihre Datenbank oder Anwendungen auswirken könnten: + [Änderungen in MySQL 5.7](http://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html) + [Änderungen in MySQL 8.0](http://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) + [Änderungen in MySQL 8.4](http://dev.mysql.com/doc/refman/8.4/en/upgrading-from-previous-series.html) 1. Wenn Ihre DB-Instance Mitglied einer benutzerdefinierten DB-Parametergruppe ist, müssen Sie eine neue DB-Parametergruppe mit Ihren vorhandenen Einstellungen erstellen, die mit der neuen Hauptversion kompatibel ist. Geben Sie die neue DB-Parametergruppe an, wenn Sie Ihre Test-Instance aktualisieren, damit Ihr Upgrade-Test sicherstellt, dass sie ordnungsgemäß funktioniert. Weitere Informationen über das Erstellen einer Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). 1. Erstellen Sie einen DB-Snapshot der zu aktualisierenden DB-Instance. Weitere Informationen finden Sie unter [Erstellen eines DB-Snapshots für eine DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md). 1. Stellen Sie den DB-Snapshot wieder her, um eine neue Test-DB-Instance zu erstellen. Weitere Informationen finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md). 1. Ändern Sie diese neue Test-DB-Instance, um sie auf die neue Version upzugraden. Verwenden Sie dazu eine der folgenden Methoden. Wenn Sie in Schritt 2 eine neue Parametergruppe erstellt haben, geben Sie diese Parametergruppe an. 1. Beurteilen Sie den Speicherplatz, den die upgegradete Instance verwendet, um zu bestimmen, ob das Upgrade zusätzlichen Speicherplatz benötigt. 1. Führen Sie so viele Qualitätssicherungstests mit der upgegradeten DB-Instance durch, wie nötig, um sicherzustellen, dass Ihre Datenbank und Anwendung mit der neuen Version korrekt ausgeführt werden. Führen Sie alle nötigen neuen Tests aus, um die Auswirkungen von Kompatibilitätsproblemen zu bewerten, die Sie in Schritt 1 bestimmt haben. Testen Sie alle gespeicherten Prozeduren und Funktionen. Leiten Sie Testversionen Ihrer Anwendungen an die aktualisierte DB-Instance weiter. 1. Wenn alle Tests erfolgreich sind, führen Sie das Upgrade für Ihre Produktions-DB-Instance durch. Wir empfehlen, dass Sie keine Schreiboperationen auf der DB-Instance zulassen, bis Sie bestätigen können, dass alles richtig ausgeführt wird. ## Upgraden einer MySQL-DB-Instance Informationen über das manuelle oder automatische Upgraden einer MySQL-DB-Instance finden Sie unter [Upgrade der Engine-Version für eine DB-Instance ](USER_UpgradeDBInstance.Upgrading.md). # Automatische Unterversion-Upgrades von RDS für MySQL 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. ![\[Bereich Wartung in der Amazon-RDS-Konsole, die Option Automatische Aktualisierung von Unterversionen aktivieren ist ausgewählt.\]](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 MySQL 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 MySQL-Community-Version + Gesamtflottenstabilität seit Erscheinen der Minor-Version Sie können den folgenden AWS CLI-Befehl verwenden, um die aktuelle Ziel-Unterversion des automatischen Upgrades für eine bestimmte MySQL-Unterversion in einer bestimmten AWS-Region festzulegen. Für Linux, macOS oder Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --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 mysql ^ --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 MySQL-Nebenversion 8.0.11 in der AWS-Region USA Ost (Ohio) (us-east-2) fest. Für Linux, macOS oder Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version 8.0.11 \ --region us-east-2 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output table ``` Für Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version 8.0.11 ^ --region us-east-2 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output table ``` Ihre Ausgabe sieht Folgendem ähnlich. ``` ---------------------------------- | DescribeDBEngineVersions | +--------------+-----------------+ | AutoUpgrade | EngineVersion | +--------------+-----------------+ | False | 8.0.15 | | False | 8.0.16 | | False | 8.0.17 | | False | 8.0.19 | | False | 8.0.20 | | False | 8.0.21 | | True | 8.0.23 | | False | 8.0.25 | +--------------+-----------------+ ``` In diesem Beispiel ist der `AutoUpgrade`-Wert `True` für MySQL-Version 8.0.23. Das automatische Nebenversions-Upgrade-Ziel ist daher die MySQL-Version 8.0.23, die in der Ausgabe hervorgehoben wird. Eine MySQL 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 zur Reduzierung von Ausfallzeiten beim Upgrade einer Datenbank in RDS für MySQL In den meisten Fällen ist eine Blau/Grün-Bereitstellung die beste Option, um Ausfallzeiten beim Upgrade einer MySQL-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 MySQL-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 der MySQL Version 5.7 auf MySQL Version 8.0 gezeigt. Sie können die gleichen allgemeinen Schritte für Upgrades auf andere Hauptversionen durchführen. Sie können die gleichen allgemeinen Schritte für Upgrades auf andere Hauptversionen durchführen. **Anmerkung** Wenn Sie von MySQL-Version 5.7 auf MySQL-Version 8.0 oder von MySQL-Version 8.0 auf MySQL-Version 8.4 aktualisieren, führen Sie die Vorprüfungen durch, bevor Sie das Upgrade durchführen. Weitere Informationen erhalten Sie unter [Vorabprüfung bei Upgrades von MySQL 5.7 auf 8.0](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.57to80Prechecks) und [Vorabprüfung bei Upgrades von MySQL 8.0 auf 8.4](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.80to84Prechecks). **So führen Sie ein Upgrade einer MySQL-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 eine Read Replica Ihrer MySQL 5.7-DB-Instance. 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 die Read Replica einen Wert im Feld **DB-Instance-Kennung** ein und stellen Sie sicher, dass der Eintrag unter **DB-Instance-Klasse)** und die anderen Einstellungen mit Ihrer MySQL 5.7-DB-Instance ü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 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 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 Read Replica-**Status** **Verfügbar** anzeigt, aktualisieren Sie die Read Replica auf MySQL 8.0: 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** die gewünschte Version von MySQL 8.0 für das Upgrade aus und klicken Sie auf **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 **Status** **Verfügbar** anzeigt, überprüfen Sie, ob die aktualisierte Read Replica mit der MySQL-5.7-DB-Quellinstance 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 MySQL verwenden `SHOW SLAVE STATUS` anstelle von `SHOW REPLICA STATUS`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `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 die Read Replica einen Wert im Feld **DB-Instance-Kennung** ein und stellen Sie sicher, dass der Eintrag unter **DB-Instance-Klasse)** und die anderen Einstellungen mit Ihrer MySQL 5.7-DB-Instance ü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 MySQL 8.0. 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 die **DB-Parametergruppe** die soeben erstellte MySQL 8.0 DB-Parametergruppe aus, und klicken Sie dann auf **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 Ihre MySQL 8.0 Read Replica zu einer eigenständigen DB-Instance. **Wichtig** Wenn Sie Ihr Lesereplikat von MySQL 8.0 auf eine eigenständige DB-Instance hochstufen, handelt es sich nicht mehr um ein Replikat der DB-Instance von MySQL 5.7. Wir empfehlen, dass Sie Ihre MySQL 8.0 Read Replica während eines Wartungsfensters hochstufen, wenn sich Ihre MySQL-5.7 Quell-DB-Instance im schreibgeschützten Modus befindet und alle Schreiboperationen ausgesetzt sind. Wenn die Aktion abgeschlossen ist, können Sie Ihre Schreiboperationen an die aktualisierte MySQL 8.0 DB-Instance weiterleiten, um sicherzustellen, dass keine Schreiboperationen verloren gehen. Zusätzlich empfehlen wir, dass Sie, bevor Sie die MySQL 8.0 Read Replica hochstufen, alle erforderlichen Data Definition Language (DDL)-Operationen auf der MySQL 8.0 Read Replica ausführen. Ein Beispiel hierfür ist das Erstellen von Indizes. Dieser Ansatz vermeidet negative Auswirkungen auf die Leistung der MySQL 8.0 Read Replica, nachdem sie 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 upgegradete Version Ihrer MySQL-Datenbank. An dieser Stelle können Sie Ihre Anwendungen auf die neue MySQL 8.0 DB-Instance verweisen. # Überwachung von RDS für MySQL-Engine-Upgrades mit Ereignissen Wenn Sie die Engine-Version einer RDS for MySQL-Datenbank aktualisieren, gibt Amazon RDS in jeder Phase des Prozesses ein bestimmtes Ereignis aus. Um den Fortschritt eines Upgrades zu verfolgen, können Sie diese Ereignisse anzeigen 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 MySQL-DB-Snapshots Mit Amazon RDS können Sie einen DB-Snapshot für das Speicher-Volume Ihrer MySQL-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. Bei RDS für MySQL können Sie einen Snapshot der Version 5.7 auf Version 8.0 oder einen Snapshot der Version 8.0 auf Version 8.4 aktualisieren. 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 MySQL anzuzeigen. ``` aws rds describe-db-engine-versions --engine mysql --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 MySQL](mysql-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 DB-Engine von RDS für MySQL](USER_UpgradeDBInstance.MySQL.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 MySQL 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 MySQL 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 | | --- | --- | | 5.5.8 | 5.5.62, 5.6.51 | | 5.5.12 | 5.5.62, 5.6.51 | | 5.5.20 | 5.5.62, 5.6.51 | | 5.5.23 | 5.5.62, 5.6.51 | | 5.5.25a | 5.5.62, 5.6.51 | | 5.5,27 | 5.5.62, 5.6.51 | | 5.5,31 | 5.5.62, 5.6.51 | | 5.5.33 | 5.5.62, 5.6.51 | | 5.5,37 | 5.5.62, 5.6.51 | | 5,5,38 | 5.5.62, 5.6.51 | | 5,5,40 | 5.5.62, 5.6.51 | | 5.5.40a | 5.5.62, 5.6.51 | | 5.5.40b | 5.5.62, 5.6.51 | | 5,5,41 | 5.5.62, 5.6.51 | | 5,5,42 | 5.5.62, 5.6.51 | | 5.5.59 | 5.5.62, 5.6.51 | | 5.6.12 | 5.6.51, 5.7.44 | | 5.6.13 | 5.6.51, 5.7.44 | | 5.6.17 | 5.6.51, 5.7.44 | | 5.6,19 | 5.6.51, 5.7.44 | | 5.6.19a | 5.6.51, 5.7.44 | | 5.6.19b | 5.6.51, 5.7.44 | | 5.6.21 | 5.6.51, 5.7.44 | | 5.6.21b | 5.6.51, 5.7.44 | | 5.6.22 | 5.6.51, 5.7.44 | | 5.6.23 | 5.6.51, 5.7.44 | | 5.6.27 | 5.6.51, 5.7.44 | | 5.6.27a | 5.6.51, 5.7.44 | | 5.7.10 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | | 5.7.11 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | | 5.7.12 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | # Importieren von Daten in eine DB-Instance von Amazon RDS für MySQL Für den Import von Daten in eine DB-Instance von RDS für MySQL 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 MySQL angegeben: | Quelle | Datenmenge | Einmalig oder kontinuierlich | Ausfallzeit der Anwendung | Technik | Weitere Informationen | | --- | --- | --- | --- | --- | --- | | Lokal oder auf Amazon EC2 vorhandene MySQL-Datenbank | Alle | Einmalig | Etwas | Erstellen Sie ein Backup der Datenbank vor Ort, speichern Sie es auf Amazon S3 und stellen Sie die Sicherungsdatei anschließend auf einer neuen Amazon-RDS-DB-Instance wieder her, auf der MySQL ausgeführt wird. | [Wiederherstellen eines Backups in eine DB-Instance von Amazon RDS für MySQL](MySQL.Procedural.Importing.md) | | Lokal oder auf Amazon EC2 vorhandene MySQL-Datenbank | Beliebig | Kontinuierlich | Minimal | Konfigurieren Sie die Replikation mit einer vorhandenen MySQL-Datenbank als Replikationsquelle. | [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md) [Importieren von Daten in eine Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-importing-data-reduced-downtime.md) | | Alle vorhandenen Datenbanken | Alle | Einmalig oder kontinuierlich | Minimal | Wird verwendet AWS Database Migration Service , um die Datenbank mit minimaler Ausfallzeit 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* | | Bestehende MySQL-DB-Instance | Alle | 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 MySQL-Datenbank | Small | Einmalig | Etwas | Kopieren Sie die Daten mit einem Befehlszeilen-Dienstprogramm direkt in die MySQL-DB-Instance. | [Importieren von Daten aus einer externen MySQL-Datenbank in eine DB-Instance von Amazon RDS für MySQL](mysql-importing-data-external-database.md) | | Nicht in einer vorhandenen Datenbank gespeicherte Daten | Medium | Einmalig | Etwas | Erstellen Sie Flatfiles und importieren Sie diese mithilfe von MySQL-LOAD DATA LOCAL INFILE-Anweisungen. | [Importieren von Daten aus einer beliebigen Quelle in eine DB-Instance von Amazon RDS für MySQL](mysql-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 AWS CLI [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)Befehl wiederherstellen. # Überlegungen zum Importieren von Daten für MySQL Der folgende Inhalt enthält technische Informationen zum Laden von Daten in MySQL. Dieser Inhalt richtet sich an Benutzer, die mit der MySQL-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 MySQL-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 MySQL die Daten aus dem Binärprotokoll in eine Flat-File. MySQL 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 MySQL 5.7 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 MySQL-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 MySQL 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 mysqldump-Dateien nicht neu gestartet werden können. Wenn während des Ladens einer mysqldump-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 MySQL-Datenbanken laden. Im Gegensatz zu anderen Datenbanksystemen erstellt MySQL 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. `mysqldump`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. # Wiederherstellen eines Backups in eine DB-Instance von Amazon RDS für MySQL Amazon RDS unterstützt den Import von MySQL-Datenbanken mithilfe von Backup-Dateien. Sie können ein Backup der Datenbank erstellen, die Backup-Datei in Amazon S3 speichern und anschließend auf einer neuen Amazon-RDS-DB-Instance wiederherstellen, auf der MySQL ausgeführt wird. Amazon RDS unterstützt den Import von Backup-Dateien aus Amazon S3 in allen AWS-Regionen. Im in diesem Abschnitt beschriebenen Szenario wird ein Backup einer On-Premise-Datenbank wiederhergestellt. Sie können diese Technik für Datenbanken an anderen Speicherorten verwenden, z. B. in Amazon EC2 oder anderen Cloud-Services, solange der Zugriff auf die Datenbank unterstützt wird. Das folgende Diagramm veranschaulicht das unterstützte Szenario. ![\[MySQL importiert Backup-Dateien von S3.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MySQL-bak-file.png) Wenn die On-Premise-Datenbank beim Erstellen, Kopieren und Wiederherstellen der Backup-Dateien offline sein kann, wird empfohlen, dass Sie die Datenbank mithilfe von Backup-Dateien in Amazon RDS importieren. Wenn die Datenbank nicht offline sein darf, können Sie eine der folgenden Methoden verwenden: + **Binärprotokolle**: Importieren Sie zunächst Backup-Dateien von Amazon S3 in Amazon RDS, wie in diesem Thema erläutert. Verwenden Sie dann die Binärprotokollreplikation (binlog), um die Datenbank zu aktualisieren. Weitere Informationen finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md). + **AWS Database Migration Service**— Wird verwendet AWS Database Migration Service , um Ihre Datenbank zu Amazon RDS zu migrieren. Weitere Informationen finden Sie unter [Was ist AWS Database Migration Service?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) ## Übersicht über die Einrichtung zum Importieren von Backup-Dateien von Amazon S3 in Amazon RDS Sie benötigen die folgenden Komponenten, um Backup-Dateien von Amazon S3 in Amazon RDS zu importieren: + Einen Amazon S3-Bucket zum Speichern Ihrer Sicherungsdateien Wenn Sie bereits über einen Amazon-S3-Bucket verfügen, können Sie diesen verwenden. Wenn noch kein Amazon-S3-Bucket vorliegt, können Sie einen neuen erstellen. Weitere Informationen finden Sie unter [Bucket erstellen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html). + Ein von XtraBackup Percona erstelltes Backup Ihrer lokalen Datenbank. Weitere Informationen finden Sie unter [Erstellen Ihrer Datenbanksicherung](#MySQL.Procedural.Importing.Backup). + Eine AWS Identity and Access Management (IAM-) Rolle, die Amazon RDS den Zugriff auf den S3-Bucket ermöglicht. Wenn Sie bereits über eine IAM-Rolle verfügen, können Sie diese verwenden und ihr Vertrauens- und Berechtigungsrichtlinien hinzufügen. Weitere Informationen finden Sie unter [Manuelles Erstellen einer IAM-Rolle](#MySQL.Procedural.Importing.Enabling.IAM). Wenn Sie noch keine IAM-Rolle besitzen, haben Sie zwei Möglichkeiten: + Sie können eine neue IAM-Rolle manuell erstellen. Weitere Informationen finden Sie unter [Manuelles Erstellen einer IAM-Rolle](#MySQL.Procedural.Importing.Enabling.IAM). + Sie können auswählen, ob Amazon RDS eine neue IAM-Rolle für Sie erstellen soll. Wenn Sie möchten, dass Amazon RDS eine neue IAM-Rolle für Sie erstellt, folgen Sie dem Verfahren, das den [Importieren von Daten aus Amazon S3 in eine neue MySQL-DB-Instance](#MySQL.Procedural.Importing.PerformingImport) Abschnitt AWS-Managementkonsole in verwendet. ## Erstellen Ihrer Datenbanksicherung Verwenden Sie die XtraBackup Percona-Software, um Ihr Backup zu erstellen. Wir empfehlen Ihnen, die neueste Version von XtraBackup Percona zu verwenden. Sie können Percona XtraBackup über [Software-Downloads](https://www.percona.com/downloads/) auf der Percona-Website installieren. **Warnung** Beim Erstellen einer Datenbanksicherung werden XtraBackup möglicherweise Anmeldeinformationen in der Datei xtrabackup\$1info gespeichert. Vergewissern Sie sich, dass die Einstellung `tool_command` in der xtrabackup\$1info-Datei keine vertraulichen Informationen enthält. Welche XtraBackup Percona-Version Sie verwenden, hängt von der MySQL-Version ab, die Sie sichern. + **MySQL 8.4** — Verwenden Sie Percona XtraBackup Version 8.4. + **MySQL 8.0** — Verwenden Sie Percona XtraBackup Version 8.0. **Anmerkung** Percona XtraBackup 8.0.12 und höhere Versionen unterstützen die Migration aller Versionen von MySQL 8.0. Wenn Sie zu RDS für MySQL 8.0.32 oder höher migrieren, müssen Sie Percona XtraBackup 8.0.12 oder höher verwenden. + **MySQL 5.7** — Verwenden Sie Percona XtraBackup Version 2.4. Sie können Percona verwenden XtraBackup , um eine vollständige Sicherung Ihrer MySQL-Datenbankdateien zu erstellen. Wenn Sie Percona bereits XtraBackup zum Sichern Ihrer MySQL-Datenbankdateien verwenden, können Sie alternativ Ihre vorhandenen vollständigen und inkrementellen Backup-Verzeichnisse und -Dateien hochladen. Weitere Informationen zur Sicherung Ihrer Datenbank mit Percona finden Sie unter [Percona XtraBackup XtraBackup — Dokumentation auf der Percona-Website](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html). ### Erstellen Sie ein vollständiges Backup mit Percona XtraBackup Verwenden Sie das XtraBackup Percona-Hilfsprogramm (`xtrabackup`), um eine vollständige Sicherung Ihrer MySQL-Datenbankdateien zu erstellen, die Amazon RDS aus Amazon S3 wiederherstellen kann. Mit dem folgenden Befehl können Sie beispielsweise ein Backup einer MySQL-Datenbank erstellen und die Dateien im Ordner `/on-premises/s3-restore/backup` speichern. ``` xtrabackup --backup --user=myuser --password=password --target-dir=/on-premises/s3-restore/backup ``` Wenn Sie das Backup in einer einzelnen Datei komprimieren möchten (die gegebenenfalls später in mehrere Dateien aufgeteilt werden kann), können Sie das Backup je nach Ihrer MySQL-Version in einem der folgenden Formate speichern: + **Gzip (.gz)**: Für MySQL 5.7 und frühere Versionen + **tar (.tar)**: Für MySQL 5.7 und frühere Versionen + **Percona xbstream (.xbstream)**: Für alle MySQL-Versionen **Anmerkung** Percona XtraBackup 8.0 und höher unterstützt nur Percona xbstream für die Komprimierung. **MySQL 5.7 und frühere Versionen** Mit dem folgenden Befehl wird ein Backup einer MySQL-Datenbank erstellt und in mehreren Gzip-Dateien gespeichert. Ersetzen Sie die Werte durch Ihre Angaben. ``` xtrabackup --backup --user=my_user --password=password --stream=tar \ --target-dir=/on-premises/s3-restore/backup | gzip - | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.tar.gz ``` **MySQL 5.7 und frühere Versionen** Mit dem folgenden Befehl wird ein Backup einer MySQL-Datenbank erstellt und in mehreren tar-Dateien gespeichert. Ersetzen Sie die Werte durch Ihre Angaben. ``` xtrabackup --backup --user=my_user --password=password --stream=tar \ --target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.tar ``` **Alle MySQL-Versionen** Mit dem folgenden Befehl wird ein Backup einer MySQL-Datenbank erstellt und in mehreren xbstream-Dateien gespeichert. Ersetzen Sie die Werte durch Ihre Angaben. ``` xtrabackup --backup --user=myuser --password=password --stream=xbstream \ --target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.xbstream ``` **Anmerkung** Wenn der folgende Fehler angezeigt wird, haben Sie möglicherweise unterschiedliche Dateiformate in Ihrem Befehl verwendet: ``` ERROR:/bin/tar: This does not look like a tar archive ``` ### Verwendung inkrementeller Backups mit Percona XtraBackup Wenn Sie Percona bereits verwenden XtraBackup , um vollständige und inkrementelle Backups Ihrer MySQL-Datenbankdateien durchzuführen, müssen Sie kein vollständiges Backup erstellen und die Sicherungsdateien auf Amazon S3 hochladen. Um Zeit zu sparen, können Sie stattdessen die vorhandenen Backup-Verzeichnisse und -Dateien in den Amazon-S3-Bucket kopieren. Weitere Informationen zum Erstellen inkrementeller Backups mit Percona XtraBackup finden Sie unter [Erstellen eines inkrementellen Backups](https://docs.percona.com/percona-xtrabackup/LATEST/create-incremental-backup.html) auf der Percona-Website. Wenn Sie die Dateien der vollständigen und inkrementellen Backups in einen Amazon S3-Bucket hochladen, müssen Sie den Inhalt des Basisverzeichnisses rekursiv kopieren. Es müssen sämtliche Verzeichnisse und Dateien der vollständigen und inkrementellen Backups enthalten sein. Diese Kopie muss die Verzeichnisstruktur im Amazon-S3-Bucket beibehalten. Amazon RDS durchläuft alle Dateien und Verzeichnisse. Amazon RDS verwendet die in jedem inkrementellen Backup enthaltene Datei `xtrabackup-checkpoints`, um das Basisverzeichnis zu identifizieren und inkrementelle Backups nach dem Bereich der Protokollsequenznummer (Log Sequence Number, LSN) zu ordnen. ### Überlegungen zum Backup für Percona XtraBackup Amazon RDS verarbeitet Sicherungsdateien auf Basis des Dateinamens. Benennen Sie die Backup-Dateien mit der entsprechenden Dateierweiterung basierend auf dem Dateiformat. Verwenden Sie beispielsweise `.xbstream` für Dateien, die im xbstream-Format von Percona gespeichert werden. Amazon RDS verarbeitet Sicherungsdateien in alphanumerischer Reihenfolge. Verwenden Sie die Option `split` für den Befehl `xtrabackup`, um sicherzustellen, dass die Backup-Dateien in der richtigen Reihenfolge geschrieben und benannt werden. Amazon RDS unterstützt keine Teilsicherungen, die mit Percona XtraBackup erstellt wurden. Sie können beim Backup der Quelldateien Ihrer Datenbank nicht die folgenden Optionen zum Erstellen eines partiellen Backups verwenden: + `--tables` + `--tables-exclude` + `--tables-file` + `--databases` + `--databases-exclude` + `--databases-file` ## Manuelles Erstellen einer IAM-Rolle Wenn Sie noch keine IAM-Rolle besitzen, können Sie manuell eine neue erstellen. Wenn Sie die Datenbank jedoch mithilfe von wiederherstellen AWS-Managementkonsole, empfehlen wir Ihnen, Amazon RDS diese neue IAM-Rolle für Sie erstellen zu lassen. Damit Amazon RDS diese Rolle für Sie erstellen kann, führen Sie die im Abschnitt [Importieren von Daten aus Amazon S3 in eine neue MySQL-DB-Instance](#MySQL.Procedural.Importing.PerformingImport) beschriebenen Schritte aus. Wenn Sie eine neue IAM-Rolle zum Importieren der Datenbank aus Amazon S3 manuell erstellen, erstellen Sie eine Rolle, um Berechtigungen von Amazon RDS an den Amazon-S3-Bucket weiterzugeben. Beim Anlegen einer IAM-Rolle geben Sie Vertrauens- und Berechtigungsrichtlinien an. Um Ihre Backup-Dateien aus Amazon S3 zu importieren, verwenden Sie Vertrauens- und Berechtigungsrichtlinien, ähnlich den folgenden Beispielen. Weitere Informationen zum Erstellen der Rolle finden Sie unter Eine Rolle [erstellen, um Berechtigungen an einen Service zu delegieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html). AWS Für die Vertrauens- und Berechtigungsrichtlinien müssen Sie einen Amazon-Ressourcennamen (ARN) angeben. Weitere Informationen zur ARN-Formatierung finden Sie unter [Amazon Resource Names (ARNs) und AWS Service-Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). **Example Vertrauensrichtlinie für den Import aus Amazon S3** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleForBackup", "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` **Example Berechtigungsrichtlinie für den Import aus Amazon S3 – IAM-Benutzerberechtigungen** Ersetzen Sie im folgenden Beispiel durch Ihren *iam\$1user\$1id* eigenen Wert. **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3AccessRole", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/S3Access" } ] } ``` **Example Berechtigungsrichtlinie für den Import aus Amazon S3 – Rollenberechtigungen** Ersetzen Sie im folgenden Beispiel *amzn-s3-demo-bucket* und *prefix* durch Ihre eigenen Werte. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket" }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:111122223333:key/key_id*" ] } ] } ``` Wenn Sie ein Dateinamen-Präfix einfügen, fügen Sie das Sternchen (\$1) nach dem Präfix ein. Wenn Sie kein Präfix verwenden möchten, geben Sie nur ein Sternchen ein. ## Importieren von Daten aus Amazon S3 in eine neue MySQL-DB-Instance Mit der, oder RDS-API können Sie Daten aus Amazon S3 in eine neue MySQL-DB-Instance importieren. AWS-Managementkonsole AWS CLI ### Konsole **Um Daten aus Amazon S3 in eine neue MySQL DB-Instance zu importieren** 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 in der oberen rechten Ecke der Amazon RDS-Konsole den Ort aus, AWS-Region an dem Sie Ihre DB-Instance erstellen möchten. Wählen Sie dasselbe AWS-Region wie für den Amazon S3 S3-Bucket, der Ihr Datenbank-Backup enthält. 1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus. 1. Wählen Sie **Von S3 wiederherstellen**. Die Seite **Datenbank durch Wiederherstellen von S3 erstellen** wird angezeigt. ![\[Die Seite Datenbank durch Wiederherstellen von S3 erstellen, in der Sie die Details zum Wiederherstellen einer DB-Instance aus S3 angeben.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/mys-s3-ingestion.png) 1. Unter **S3-Quelle**: 1. Wählen Sie den **S3 bucket** (S3-Bucket) aus, in dem sich das Backup befindet. 1. (Optional) Geben Sie für das **S3-Präfix** ein Dateipfadpräfix für die Dateien ein, die im Amazon-S3-Bucket gespeichert sind. Wenn Sie kein Präfix angeben, dann erstellt Amazon RDS Ihre DB-Instance unter Verwendung aller Dateien und Ordner im Stammordner des S3-Bucket. Wenn Sie ein Präfix angeben, erstellt Amazon RDS Ihre DB-Instance mit den Ordnern und Dateien im S3-Bucket, deren vollständiger Pfadname mit dem angegebenen Präfix beginnt. Beispiel: Sie speichern Backup-Dateien auf S3 im Unterordner „backups“ und haben mehrere Sätze von Backup-Dateien, die sich jeweils in einem eigenen Verzeichnis befinden (gzip\$1backup1, gzip\$1backup2 usw.). In diesem Fall geben Sie das Präfix „backups/gzip\$1backup1“ an, um die Wiederherstellung mit den Dateien im Ordner „gzip\$1backup1“ durchzuführen. 1. Unter **Engine-Optionen**: 1. Wählen Sie in **Engine-Typ** die Option **MySQL** aus. 1. Wählen Sie für **Quellen-Engine-Version** die MySQL-Hauptversion Ihrer Quelldatenbank. 1. Wählen Sie unter **Engine-Version** die Standard-Nebenversion der MySQL-Hauptversion in der AWS-Region aus. In der AWS-Managementkonsole ist nur die Standard-Nebenversion verfügbar. Nachdem Sie den Import abgeschlossen haben, können Sie die DB-Instance aktualisieren. 1. Erstellen Sie unter **IAM-Rolle** eine IAM-Rolle mit den erforderlichen Vertrauens- und Berechtigungsrichtlinien bzw. wählen Sie sie aus, die Amazon RDS den Zugriff auf den Amazon-S3-Bucket ermöglicht. Führen Sie eine der folgenden Aktionen aus: + (Empfohlen) Wählen Sie **Neue Rolle erstellen** aus und geben Sie den **IAM-Rollennamen** ein. Mit dieser Option erstellt Amazon RDS die Rolle mit der Vertrauens- und Berechtigungsrichtlinie automatisch für Sie. + Wählen Sie eine vorhandene IAM-Rolle aus. Vergewissern Sie sich, dass diese Rolle alle Kriterien unter [Manuelles Erstellen einer IAM-Rolle](#MySQL.Procedural.Importing.Enabling.IAM) erfüllt. 1. Geben Sie Ihre DB-Instance-Informationen an. Weitere Informationen zu den einzelnen Einstellungen finden Sie unter [Einstellungen für DB-Instances](USER_CreateDBInstance.Settings.md). **Anmerkung** Vergewissern Sie sich, dass Sie genügend Speicherplatz für Ihre neue DB-Instance zuweisen, damit die Wiederherstellung erfolgreich verlaufen kann. Um eine zukünftige Speichererweiterung automatisch zu ermöglichen, wählen Sie unter **Zusätzliche Speicherkonfiguration** die Option **Automatische Speicherskalierung aktivieren** aus. 1. Wählen Sie zusätzliche Einstellungen wie erforderlich aus. 1. Wählen Sie **Create database (Datenbank erstellen)** aus. ### AWS CLI Um Daten mit dem aus Amazon S3 in eine neue MySQL-DB-Instance zu importieren AWS CLI, führen Sie den Befehl [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html) mit den folgenden Optionen aus. Weitere Informationen zu den einzelnen Einstellungen finden Sie unter [Einstellungen für DB-Instances](USER_CreateDBInstance.Settings.md). **Anmerkung** Vergewissern Sie sich, dass Sie genügend Speicherplatz für Ihre neue DB-Instance zuweisen, damit die Wiederherstellung erfolgreich verlaufen kann. Verwenden Sie die Option `--max-allocated-storage`, um die automatische Speicherskalierung zu aktivieren und eine zukünftige Speichererweiterung automatisch zu ermöglichen. + `--allocated-storage` + `--db-instance-identifier` + `--db-instance-class` + `--engine` + `--master-username` + `--manage-master-user-password` + `--s3-bucket-name` + `--s3-ingestion-role-arn` + `--s3-prefix` + `--source-engine` + `--source-engine-version` **Example** Für Linux, macOS oder Unix: ``` 1. aws rds restore-db-instance-from-s3 \ 2. --allocated-storage 250 \ 3. --db-instance-identifier my_identifier \ 4. --db-instance-class db.m5.large \ 5. --engine mysql \ 6. --master-username admin \ 7. --manage-master-user-password \ 8. --s3-bucket-name amzn-s3-demo-bucket \ 9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename \ 10. --s3-prefix bucket_prefix \ 11. --source-engine my_sql \ 12. --source-engine-version 8.0.32 \ 13. --max-allocated-storage 1000 ``` Für Windows: ``` 1. aws rds restore-db-instance-from-s3 ^ 2. --allocated-storage 250 ^ 3. --db-instance-identifier my_identifier ^ 4. --db-instance-class db.m5.large ^ 5. --engine mysql ^ 6. --master-username admin ^ 7. --manage-master-user-password ^ 8. --s3-bucket-name amzn-s3-demo-bucket ^ 9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename ^ 10. --s3-prefix bucket_prefix ^ 11. --source-engine mysql ^ 12. --source-engine-version 8.0.32 ^ 13. --max-allocated-storage 1000 ``` ### RDS-API Um Daten mithilfe der Amazon RDS-API aus Amazon S3 in eine neue MySQL-DB-Instance zu importieren, rufen Sie den Vorgang [Restore DBInstance FromS3 auf](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html). ## Einschränkungen und Überlegungen für das Importieren von Backup-Dateien von Amazon S3 in Amazon RDS Die folgenden Einschränkungen und Überlegungen gelten für das Importieren von Backup-Dateien von Amazon S3 in eine DB-Instance von RDS für MySQL: + Sie können die Daten nur zu einer neuen DB-Instance migrieren, nicht zu einer bestehenden DB-Instance. + Sie müssen Percona verwenden XtraBackup , um Ihre Daten auf Amazon S3 zu sichern. Weitere Informationen finden Sie unter [Erstellen Ihrer Datenbanksicherung](#MySQL.Procedural.Importing.Backup). + Das Amazon-S3-Bucket und die DB-Instance von RDS für MySQL müssen sich in der gleichen AWS-Region befinden. + Sie können keine Wiederherstellung aus den folgenden Quellen durchführen: + Export eines DB-Instance-Snapshots nach Amazon S3. Sie können auch keine Daten von einem DB-Instance-Snapshot-Export zum Amazon-S3-Bucket migrieren. + Verschlüsselte Quelldatenbank. Sie können jedoch die zu migrierenden Daten verschlüsseln. Sie können die Daten während des Migrationsprozesses auch unverschlüsselt lassen. + MySQL 5.5- oder 5.6-Datenbank. + RDS für MySQL unterstützt Percona Server für MySQL nicht als Quelldatenbank, da sie `compression_dictionary*`-Tabellen im `mysql schema` enthalten kann. + RDS für MySQL unterstützt keine abwärtskompatible Migration für Haupt- und Nebenversionen. Sie können zum Beispiel keine Migration von MySQL 8.0 zu RDS für MySQL 5.7 und auch nicht von MySQL 8.0.32 zu RDS für MySQL 8.0.26 durchführen. + Amazon RDS unterstützt nicht den Import von Amazon S3 in die DB-Instance-Klasse „db.t2.micro“. Sie können jedoch eine Wiederherstellung in eine andere DB-Instance-Klasse durchführen und die DB-Instance-Klasse dann später ändern. Weitere Informationen zu Instance-Klassen finden Sie unter [Hardwarespezifikationen für DB-Instance-Klassen ](Concepts.DBInstanceClass.Summary.md). + Amazon S3 begrenzt die Größe einer Datei, die in einen Amazon S3-Bucket hochgeladen werden kann, auf 5 TB. Wenn eine Sicherungsdatei größer als 5 TB ist, müssen Sie die Sicherungsdatei in kleinere Dateien aufteilen. + Amazon RDS begrenzt die Anzahl der Dateien, die in ein Amazon S3-Bucket hochgeladen werden können, auf 1 Million. Wenn es mehr als mehr als 1 Million Sicherungsdateien für Ihre Datenbank gibt (einschließlich aller vollständigen und inkrementellen Backups), speichern Sie diese mittels Gzip (.gz), tar (.tar.gz) oder Percona xbstream (.xbstream) im Amazon S3-Bucket. Percona XtraBackup 8.0 unterstützt nur Percona xbstream für die Komprimierung. + Um Verwaltungsservices für die jeweilige DB-Instance bereitzustellen, legt Amazon RDS den Benutzer `rdsadmin` an, wenn die DB-Instance erstellt wird. Da `rdsamin` ein reservierter Benutzer in Amazon RDS ist, gelten die folgenden Einschränkungen: + Funktionen, Prozeduren, Ansichten, Ereignisse und Auslöser mit dem Definierer `'rdsadmin'@'localhost'` werden in Amazon RDS nicht importiert. Weitere Informationen erhalten Sie unter [Gespeicherte Objekte mit 'rdsadmin'@'localhost' als Definierer](#MySQL.Procedural.Importing.StoredObjects) und [Berechtigungen von Hauptbenutzerkonten](UsingWithRDS.MasterAccounts.md). + Beim Erstellen der DB-Instance legt Amazon RDS einen Masterbenutzer mit den maximal unterstützten Berechtigungen an. Bei der Wiederherstellung anhand des Backups werden in Amazon RDS alle nicht unterstützten Berechtigungen, die den importierten Benutzern zugewiesen sind, automatisch entfernt. Informationen zu Benutzern, die davon betroffen sein könnten, finden Sie unter [Benutzerkonten mit nicht unterstützten Rechten](#MySQL.Migrating.ExtMySQL.Prechecks.Users). Weitere Informationen zu den in RDS für MySQL unterstützten Berechtigungen finden Sie unter [Rollenbasiertes Berechtigungsmodell für RDS für MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). + In Amazon RDS werden keine vom Benutzer erstellten Tabellen im Schema `mysql` migriert. + Sie dürfen den Parameter `innodb_data_file_path` nur mit einer Datendatei konfigurieren, die den Standarddateinamen `ibdata1:12M:autoextend` verwendet. Mit dieser Methode können Sie Datenbanken mit zwei Datendateien oder mit nur einer Datendatei eines anderen Namens migrieren. Die folgenden Beispiele sind Dateinamen, die Amazon RDS nicht zulässt: + `innodb_data_file_path=ibdata1:50M` + `ibdata2:50M:autoextend` + `innodb_data_file_path=ibdata01:50M:autoextend` + Sie können nicht von einer Quelldatenbank migrieren, deren Tabellen außerhalb des standardmäßigen MySQL-Datenverzeichnisses definiert sind. + Die maximal unterstützte Größe für unkomprimierte Backups mit dieser Methode ist derzeit auf 64 TiB begrenzt. Bei komprimierten Backups ist dieser Grenzwert niedriger, um den Speicherplatzanforderungen bei der Dekomprimierung Rechnung zu tragen. In solchen Fällen ist die maximal unterstützte Backup-Größe `64 TiB - compressed backup size`. Informationen zur maximal unterstützten Datenbankgröße, die von RDS für MySQL unterstützt wird, finden Sie unter [Allzweck-SSD-Speicher](CHAP_Storage.md#Concepts.Storage.GeneralSSD) und [Bereitgestellter IOPS SSD-Speicher](CHAP_Storage.md#USER_PIOPS). + Amazon RDS unterstützt den Import von MySQL und anderen externen Komponenten und Plugins nicht. + Amazon RDS stellt nicht alles anhand der Datenbank wieder her. Es wird empfohlen, das Datenbankschema und die Werte der folgenden Elemente der Quell-MySQL-Systemdatenbank zu speichern und diese zur wiederhergestellten DB-Instance von RDS für MySQL nach der Erstellung hinzufügen: + Benutzerkonten + Funktionen + Gespeicherte Prozeduren + Zeitzoneninformation. Die Zeitzoneninformationen werden vom lokalen Betriebssystem der DB-Instance von RDS für MySQL übernommen. Weitere Informationen finden Sie unter [Lokale Zeitzone für MySQL-DB-Instances](MySQL.Concepts.LocalTimeZone.md). ### Gespeicherte Objekte mit 'rdsadmin'@'localhost' als Definierer Funktionen, Prozeduren, Ansichten, Ereignisse und Auslöser mit `'rdsadmin'@'localhost'` als Definierer werden in Amazon RDS nicht importiert. Mit dem folgenden SQL-Skript können die in Ihrer MySQL-Datenbank gespeicherten Objekte mit nicht unterstützten Definierern auflisten. ``` -- This SQL query lists routines with `rdsadmin`@`localhost` as the definer. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE definer = 'rdsadmin@localhost'; -- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer. SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.triggers WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists events with `rdsadmin`@`localhost` as the definer. SELECT EVENT_SCHEMA, EVENT_NAME FROM information_schema.events WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists views with `rdsadmin`@`localhost` as the definer. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE DEFINER = 'rdsadmin@localhost'; ``` ### Benutzerkonten mit nicht unterstützten Rechten Benutzerkonten mit Berechtigungen, die von RDS für MySQL nicht unterstützt werden, werden ohne die nicht unterstützten Berechtigungen importiert. Die Liste der unterstützten Rechte finden Sie unter [Rollenbasiertes Berechtigungsmodell für RDS für MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). Sie können die folgende SQL-Abfrage in Ihrer Quelldatenbank ausführen, um die Benutzerkonten aufzulisten, die nicht unterstützte Rechte haben. ``` SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'y' OR File_priv = 'y' OR Super_priv = 'y' OR Create_tablespace_priv = 'y'; ``` # Importieren von Daten aus einer externen MySQL-Datenbank in eine DB-Instance von Amazon RDS für MySQL Sie können Daten aus einer vorhandenen MySQL-Datenbank in eine DB-Instance von RDS für MySQL importieren. Zu diesem Zweck kopieren Sie die Datenbank mit [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) und importieren sie direkt in die DB-Instance von RDS für MySQL. Das Befehlszeilen-Dienstprogramm `mysqldump` wird üblicherweise verwendet, um Backups zu erstellen und Daten von einem MySQL-Server zu einem anderen zu übertragen. Es ist in der MySQL-Clientsoftware enthalten. **Anmerkung** Wenn Sie große Datenmengen mit einer MySQL-DB-Instance importieren oder exportieren, ist es zuverlässiger und schneller, Daten mithilfe von `xtrabackup`-Backup-Dateien und Amazon S3 in und aus Amazon RDS zu verschieben. Weitere Informationen finden Sie unter [Wiederherstellen eines Backups in eine DB-Instance von Amazon RDS für MySQL](MySQL.Procedural.Importing.md). 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. ``` mysqldump -u local_user \ --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ --routines=0 \ --triggers=0 \ --events=0 \ -plocal_password | mysql -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` Das Dienstprogramm `mysqldump` schließt 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 MySQL-Datenbank an, die durch den Parameter `--databases` identifiziert wird. + `--databases database_name`: für die Angabe des Datenbanknamens in der lokalen MySQL-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` 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 MySQL-DB-Instance an, die durch den Parameter `--host` gekennzeichnet ist. + `--port port_number` – für die Angabe des Ports für die MySQL-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. Falls Sie eines dieser Objekte in der Datenbank haben, die Sie kopieren, schließen Sie sie aus, wenn Sie `mysqldump` ausführen. Fügen Sie dazu die folgenden Parameter in den Befehl `mysqldump` ein: + `--routines=0` + `--triggers=0` + `--events=0` **Beispiel** Im folgenden Beispiel wird die Beispieldatenbank `world` des lokalen Hosts in eine DB-Instance von RDS für MySQL kopiert. Ersetzen Sie die Werte durch Ihre Angaben. Für Linux, macOS oder Unix: ``` sudo mysqldump -u local_user \ --databases world \ --single-transaction \ --compress \ --order-by-primary \ --routines=0 \ --triggers=0 \ --events=0 \ -plocal_password | mysql -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. ``` mysqldump -u local_user ^ --databases world ^ --single-transaction ^ --compress ^ --order-by-primary ^ --routines=0 ^ --triggers=0 ^ --events=0 ^ -plocal_password | mysql -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 Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit In einigen Situationen müssen Sie Daten aus einer externen MySQL-Datenbank importieren, die eine Live-Anwendung für eine DB-Instance von RDS für MySQL oder einen Multi-AZ-DB-Cluster von RDS für MySQL 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 Kosten des Imports durch Reduzierung der Menge an Daten senken, die über das Netzwerk an AWS weitergeleitet werden. 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. Konfigurieren Sie die Replikation basierend auf den Binärprotokollkoordinaten. **Anmerkung** Wenn Sie Daten in eine DB-Instance von RDS für MySQL importieren möchten und Ihr Szenario dies unterstützt, empfehlen wir, Daten mithilfe von Backup-Dateien und Amazon S3 in und aus Amazon RDS zu verschieben. Weitere Informationen finden Sie unter [Wiederherstellen eines Backups in eine DB-Instance von Amazon RDS für MySQL](MySQL.Procedural.Importing.md). Im folgenden Diagramm ist der Import einer externen MySQL-Datenbank in eine MySQL-Datenbank auf Amazon RDS veranschaulicht. ![\[Workflow, der den Import einer externen MySQL-Datenbank in eine MySQL-Datenbank auf Amazon RDS darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_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 MySQL mit minimaler Ausfallzeit besteht darin, eine Kopie der Quelldaten zu erstellen. Das folgende Diagramm veranschaulicht die Erstellung eines Backups der MySQL-Datenbank. ![\[Workflow, der das Erstellen eines Backups der MySQL-Datenbank darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_2.png) Sie können das Hilfsprogramm `mysqldump` verwenden, um ein Datenbank-Backup im SQL-Format oder im separierten Textformat zu erstellen. Es wird empfohlen, mit jedem Format in einer Nichtproduktionsumgebung einen Testlauf durchzuführen, um festzustellen, welche Methode die Ausführungsdauer von `mysqldump` minimiert. Wir empfehlen auch, dass Sie die Leistung von `mysqldump` 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](mysql-importing-data-any-source.md#mysql-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 MySQL-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`, da sie einen einheitlichen Zustand der Datenbank speichert. Um eine gültige Dump-Datei sicherzustellen, führen Sie beim Ausführen von `mysqldump` 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` Das Dienstprogramm `mysqldump` schließt 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) für deren Neuerstellung generiert, z. B. das Hilfsprogramm. [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 `[mysqld]`-Abschnitt einer `my.cnf`-Datei angegeben: ``` [mysqld] log-bin=mysql-bin server-id=1 ``` Weitere Informationen finden Sie unter [Setting the Replication Master Configuration](https://dev.mysql.com/doc/refman/8.4/en/replication-howto-masterbaseconfig.html) in der MySQL-Dokumentation. 1. Legen Sie für die Replikation mit einem Multi-AZ-DB-Cluster die Parameter `ENFORCE_GTID_CONSISTENCY` und `GTID_MODE` auf `ON` fest. ``` mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON; ``` ``` mysql> SET @@GLOBAL.GTID_MODE = ON; ``` Diese Einstellungen sind für die Replikation mit einer DB-Instance nicht erforderlich. 1. Den Service `mysql` neu starten. ``` sudo service mysqld restart ``` ### So erstellen Sie eine Sicherungskopie für Ihre bestehende Datenbank: 1. Erstellen Sie ein Backup für Ihre Daten mithilfe des Hilfsprogramms `mysqldump`, indem Sie entweder das SQL- oder separierte Textformat festlegen. Geben Sie bei MySQL 8.0.25 und älteren Versionen `--master-data=2` an, um eine Backup-Datei zu erstellen, die für das Starten einer Replikation zwischen Servern verwendet werden kann. Geben Sie bei MySQL 8.0.26 und neueren Versionen `--source-data=2` an, um eine Backup-Datei zu erstellen, die für das Starten einer Replikation zwischen Servern verwendet werden kann. Weitere Informationen finden Sie unter [mysqldump – A Database Backup Program](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html) in der MySQL-Dokumentation. Verwenden Sie die Optionen `--order-by-primary` und `--single-transaction` für `mysqldump`., um die Leistung zu verbessern und die Datenintegrität sicherzustellen. Verwenden Sie die Option `--all-databases` nicht mit `mysqldump`, 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: Für Linux, macOS oder Unix: ``` sudo mysqldump \ --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: ``` mysqldump ^ --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: 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. Falls Sie eines dieser Objekte in der Datenbank haben, die Sie kopieren, schließen Sie sie aus, wenn Sie `mysqldump` ausführen. Fügen Sie dazu die folgenden Argumente in den Befehl `mysqldump` ein: `--routines=0` `--triggers=0` `--events=0` Bei MySQL 8.0.22 und früheren Versionen wird der Kommentar `CHANGE MASTER TO` zurückgegeben, wenn Sie `mysqldump` ausführen und das separierte Textformat festlegen. Dieser Kommentar beinhaltet den Namen und die Position der Hauptprotokolldatei. Bei MySQL 8.0.23 und neueren Versionen wird der Kommentar `CHANGE REPLICATION SOURCE TO` zurückgegeben, wenn Sie `mysqldump` mithilfe des separierten Textformats ausführen. Dieser Kommentar beinhaltet den Namen und die Position der Quellprotokolldatei. Wenn es sich bei der externen Instance um MySQL 8.0.23 oder eine neuere 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 MySQL 8.0.22 und frühere 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; ``` Die folgende Ausgabe wird für MySQL 8.0.23 und neuere Versionen zurückgegeben: ``` -- Position to start replication or point-in-time recovery from -- -- CHANGE SOURCE TO SOURCE_LOG_FILE='mysql-bin-changelog.000031', SOURCE_LOG_POS=107; ``` Wenn Sie bei MySQL 8.0.22 und früheren Versionen das SQL-Format verwenden, können Sie den Namen und die Position der Hauptprotokolldatei im Kommentar `CHANGE MASTER TO` in der Backup-Datei abrufen. Wenn Sie bei MySQL 8.0.23 und neueren Versionen das SQL-Format verwenden, können Sie den Namen und die Position der Quellprotokolldatei im Kommentar `CHANGE REPLICATION SOURCE TO` in der Backup-Datei abrufen. 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. Wenn sich die Daten in Amazon EC2 befinden, können Sie diese von dort direkt in die MySQL-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-Instance in derselben AWS-Region wie die Amazon-RDS-Datenbank befindet, wird auch die Netzwerklatenz während des Importvorgangs 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/MigrateMySQLToRDS_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. Verbinden Sie sich mit Ihrer Amazon EC2-Instance und installieren Sie die neusten Updates und MySQL-Client-Tools mithilfe der folgenden Befehle: ``` sudo yum update -y sudo yum install mysql -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*. **Wichtig** In diesem Beispiel wird der MySQL-Client auf einem Amazon Machine Image (AMI) für eine Amazon-Linux-Verteilung installiert. Mit diesem Beispiel kann der MySQL-Client nicht auf einer anderen Verteilung wie Ubuntu oder Red Hat Enterprise Linux installiert werden. Informationen zum Installieren von MySQL finden Sie unter [Installation von MySQL](https://dev.mysql.com/doc/refman/8.4/en/installing.html) in der MySQL-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 MySQL-Datenbank und Importieren von Daten aus der Amazon EC2-Instance Wenn Sie eine DB-Instance von RDS für MySQL oder einen Multi-AZ-DB-Cluster von RDS für MySQL in derselben AWS-Region wie die Amazon EC2-Instance erstellen, können Sie die Backup-Datei der Datenbank schneller aus EC2 importieren als über das Internet. Das folgende Diagramm veranschaulicht den Importvorgang der Backup-Datei von einer Amazon EC2-Instance in eine MySQL-Datenbank. ![\[Workflow, der den Importvorgang der Backup-Datei von der EC2-Instance in die MySQL-Datenbank darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_4.png) ### So erstellen Sie eine MySQL-Datenbank und importieren Ihre 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 MySQL-Quelldatenbank einschätzen. Weitere Informationen finden Sie unter [](Concepts.DBInstanceClass.md). 1. Erstellen Sie eine DB-Instance oder einen Multi-AZ-DB-Cluster in dem AWS-Region , der Ihre Amazon EC2 EC2-Instance enthält. Befolgen Sie die Anweisungen unter [Erstellen eines Multi-AZ-DB-Clusters für Amazon RDS](create-multi-az-db-cluster.md), um einen Multi-AZ-DB-Cluster von RDS für MySQL zu erstellen. Wenn Sie eine DB-Instance von RDS für MySQL erstellen möchten, befolgen Sie die 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: ``` mysql> 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. ``` mysql> create database database_name; mysql> use database_name; ``` Erstellen Sie anschließend die Tabellen. ``` mysql> source table1.sql mysql> source table2.sql etc... ``` Importieren Sie dann die Daten. ``` mysql> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a'; mysql> 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` 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 MySQL-Datenbank kopiert und übertragen wurden, wahrscheinlich aktualisiert. Sie können also die Replikation verwenden, um die kopierte Datenbank up-to-date mit der Quelldatenbank zu verknüpfen. ![\[Workflow, der die Replikation von Daten aus der externen MySQL-Datenbank in die Datenbank in Amazon RDS darstellt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_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 für die Engine-Hauptversion: + [mysql\$1rds\$1set\$1external\$1master (Hauptversionen von RDS für MySQL 8.0 und frühere Versionen)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) + [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) + [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](#mysql-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. Konfigurieren Sie die Amazon-RDS-Datenbank als Replikat. Stellen Sie eine Verbindung mit der Amazon-RDS-Datenbank als Masterbenutzer her und identifizieren Sie die Quelldatenbank mithilfe der entsprechenden gespeicherten Amazon-RDS-Prozedur als Quellreplikations-Instance. + [mysql\$1rds\$1set\$1external\$1master (Hauptversionen von RDS für MySQL 8.0 und frühere Versionen)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) + [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) 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. Die folgenden Befehle sind Beispiele. **MySQL 8.4 und neuere Versionen** ``` CALL mysql.rds_set_external_source ('myserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **MySQL 8.0 und frühere Versionen** ``` 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. 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. Führen Sie in der Amazon-RDS-Datenbank den Befehl [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) aus, um festzustellen, wann das Replikat auf dem aktuellen Stand der Quellreplikations-Instance ist. Zu den Ergebnissen des `SHOW REPLICA STATUS`-Befehls gehört das Feld `Seconds_Behind_Master`. Wenn das Feld `Seconds_Behind_Master` 0 zurückgibt, ist das Replikat auf dem aktuellen Stand der Quellreplikations-Instance. **Anmerkung** Frühere Versionen von MySQL verwenden `SHOW SLAVE STATUS` anstelle von `SHOW REPLICA STATUS`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `SHOW SLAVE STATUS`. 1. Nachdem die Amazon-RDS-Datenbank auf den aktuellen Stand gebracht wurde, aktivieren Sie die automatischen 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 Wenn die MySQL-Datenbank auf den aktuellen Stand der Quellreplikations-Instance gebracht wurde, können Sie nun die Live-Anwendung aktualisieren, damit sie die Amazon-RDS-Instance nutzt. ![\[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/MigrateMySQLToRDS_6.png) ### So leiten Sie die Live-Anwendung an die MySQL-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. Vergewissern Sie sich, dass das Feld `Seconds_Behind_Master` im Ergebnis des Befehls [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) 0 ist, was darauf hinweist, dass das Replikat auf dem neuesten Stand mit der Quellreplikations-Instance ist. ``` SHOW REPLICA STATUS; ``` **Anmerkung** Frühere Versionen von MySQL verwenden `SHOW SLAVE STATUS` anstelle von `SHOW REPLICA STATUS`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `SHOW SLAVE STATUS`. 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. Stellen Sie für einen Multi-AZ-DB-Cluster eine Verbindung mit der Writer-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 die entsprechende gespeicherte Amazon-RDS-Prozedur in der Amazon-RDS-Datenbank verwenden: + [mysql\$1rds\$1reset\$1external\$1master (Hauptversionen von RDS für MySQL 8.0 und frühere Versionen)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) + [mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) **MySQL 8.4 und neuere Versionen** ``` CALL mysql.rds_reset_external_source; ``` **MySQL 8.0 und frühere Versionen** ``` 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 in eine DB-Instance von Amazon RDS für MySQL Mit Amazon RDS können Sie vorhandene MySQL-Daten von einer beliebigen Quelle zu einer DB-Instance von RDS für MySQL migrieren. Sie können Daten von lokalen Datenbanken, anderen Cloud-Anbietern oder vorhandenen DB-Instances von RDS für MySQL auf Ihre Ziel-DB-Instance von RDS für MySQL ü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 MySQL-Servern zu vollständig verwalteten Amazon-RDS-DB-Instances, die Konsolidierung mehrerer MySQL-Datenbanken in eine einzige DB-Instance oder die Erstellung von Testumgebungen mit Produktionsdaten. Die folgenden Abschnitte enthalten step-by-step Anweisungen zum Importieren Ihrer MySQL-Daten mithilfe von Methoden wie `mysqldump` 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](#mysql-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** Deaktivieren Sie automatische Backups nicht, 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 MySQL 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 MySQL-Anweisung `LOAD DATA LOCAL INFILE`, um Zeilen aus den Flatfiles in die Datenbanktabellen einzulesen. **Anmerkung** Sie müssen die `mysql`-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: ``` mysql> 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-Anweisung](https://dev.mysql.com/doc/refman/8.4/en/load-data.html) in der MySQL-Dokumentation. ## Schritt 6: Reaktivieren von automatischen Backups für Amazon RDS Wenn Sie die automatischen Backups für Amazon RDS in [Schritt 4](#mysql-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 MySQL-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 MySQL finden Sie unter [Arbeiten mit MySQL-Lesereplikaten](USER_MySQL.Replication.ReadReplicas.md). Sie können globale Transaktions-Identifikatoren (GTIDs) für die Replikation mit RDS for MySQL verwenden. Weitere Informationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). Sie können auch eine Replikation zwischen einer RDS für MySQL-DB-Instance und einer MariaDB- oder MySQL-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.Repl.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 [Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken](USER_LogAccess.MySQL.BinaryFormat.md). **Anmerkung** Sie können die Replikation zum Importieren von Datenbanken aus einer MariaDB- oder MySQL-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 Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-importing-data-reduced-downtime.md) und [Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation](MySQL.Procedural.Exporting.NonRDSRepl.md). Nachdem Sie Ihre DB-Instance aus einem Snapshot wiederhergestellt oder eine point-in-time Wiederherstellung durchgeführt haben, können Sie die zuletzt wiederhergestellte Binlog-Position aus der Quelldatenbank in der RDS-Konsole anzeigen. Geben Sie unter **Protokolle und Ereignisse** **binlog** ein. Die Binlog-Position wird unter **Systemhinweise** angezeigt. **Topics** + [ # Arbeiten mit MySQL-Lesereplikaten ](USER_MySQL.Replication.ReadReplicas.md) + [ # Verwenden der GTID-basierten Replikation ](mysql-replication-gtid.md) + [ # Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance ](MySQL.Procedural.Importing.External.Repl.md) + [ # Konfiguration multi-source-replication für Amazon RDS for MySQL ](mysql-multi-source-replication.md) # Arbeiten mit MySQL-Lesereplikaten Im Folgenden finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten unter RDS für MySQL. Allgemeine Informationen zu Lesereplikaten und Anleitungen zu ihrer Verwendung finden Sie in [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Weitere Informationen zu MySQL-Lesereplikaten finden Sie in den folgenden Themen. + [Konfigurieren von Replikationsfiltern mit MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md) + [Konfigurieren der verzögerten Replikation mit MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md) + [Aktualisieren von Lesereplikaten mit MySQL](USER_MySQL.Replication.ReadReplicas.Updates.md) + [Arbeiten mit Bereitstellungen von Multi-AZ-Lesereplikaten mit MySQL](USER_MySQL.Replication.ReadReplicas.MultiAZ.md) + [Verwendung von kaskadierenden Lesereplikaten mit RDS für MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md) + [Überwachen der Replikationsverzögerung für MySQL-Lesereplikate](USER_MySQL.Replication.ReadReplicas.Monitor.md) + [Starten und Stoppen der Replikation mit MySQL Read Replicas](USER_MySQL.Replication.ReadReplicas.StartStop.md) + [Fehlerbehebung für ein Problem mit einer MySQL Read Replica](USER_ReadRepl.Troubleshooting.md) ## Konfigurieren von Lesereplikaten mit MySQL Bevor eine MySQL-DB-Instance als Replikationsquelle dienen kann, stellen Sie sicher, dass automatische Sicherungen für die Quell-DB-Instance aktiviert werden. Hierzu legen Sie für den Aufbewahrungszeitraum für Sicherungen einen anderen Wert als 0 fest. Diese Erfordernis gilt auch für ein Lesereplikat, das die Quell-DB-Instance für ein anderes Lesereplikat ist. Automatische Sicherungen werden nur für Lesereplikate unterstützt, die mit einer beliebigen MySQL-Version ausgeführt werden. Sie können die Replikation basierend auf den Binärprotokollkoordinaten für eine MySQL-DB-Instance konfigurieren. Sie können die Replikation mithilfe von globalen Transaktionskennungen (GTIDs) in den folgenden Versionen konfigurieren: + RDS für MySQL Version 5.7.44 und höhere 5.7-Versionen + RDS für MySQL Version 8.0.28 und höhere 8.0-Versionen + RDS für MySQL Version 8.4.3 und höhere 8.4-Versionen Weitere Informationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). 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 die selbe 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 MySQL unterstützt kaskadierende Lesereplikate. Informationen zum Konfigurieren von kaskadierenden Lesereplikaten finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für MySQL](USER_MySQL.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. Eine Lesereplikat einer MySQL-DB-Instance kann keine niedrigere DB-Engine-Version als die Quell-DB-Instance verwenden. ### Vorbereiten von MySQL-DB-Instances, die MyISAM verwenden Wenn Ihre MySQL-DB-Instance eine nicht-transaktionale Engine, wie MyISAM, verwendet, müssen Sie die folgenden Schritte erfolgreich ausführen, um Ihr Lesereplikat einzurichten. Diese Schritte sind unbedingt notwendig, damit das Lesereplikat eine konsistente Kopie Ihrer Daten enthält. Diese Schritte sind nicht erforderlich, wenn alle Ihre Tabellen eine transaktionale Engine wie InnoDB nutzen. 1. Halten Sie alle Data Manipulation Language (DML)- und Data Definition Language (DDL)-Operationen in nicht-transaktionalen Tabellen in der Quell-DB-Instance an und warten Sie bis diese abgeschlossen sind. SELECT-Anweisungen können weiter ausgeführt werden. 1. Bereinigen und sperren Sie die Tabellen in der Quell-DB-Instance. 1. Erstellen Sie das Lesereplikat mithilfe der Methoden in den folgenden Abschnitten. 1. Überprüfen Sie den Vorgang der Lesereplikat-Erstellung mithilfe von beispielsweise der API-Operation `DescribeDBInstances`. Sobald das Lesereplikat verfügbar ist, entsperren Sie die Tabellen in der Quell-DB-Instance und fahren Sie mit den normalen Datenbank-Operationen fort. # Konfigurieren von Replikationsfiltern mit MySQL 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, die Read Replicas in verschiedenen hat AWS-Regionen, um verschiedene Datenbanken oder Tabellen in verschiedenen zu replizieren. AWS-Regionen **Anmerkung** Sie können Replikationsfilter auch verwenden, um anzugeben, welche Datenbanken und Tabellen mit einer primären MySQL -DB-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** + [ ## Einrichten der Parameter der Replikationsfilter bei RDS für MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Configuring) + [ ## Einschränkungen der Replikationsfilter bei RDS für MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Limitations) + [ ## Beispiele für Replikationsfilter bei RDS für MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Examples) + [ ## Anzeigen der Replikationsfilter für ein Lesereplikat ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Viewing) ## Einrichten der Parameter der Replikationsfilter bei RDS für MySQL 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, müssen Sie die Datenbank, welche die angegebenen Tabellen enthält, in die Replikation mit dem Lesereplikat einbeziehen. + `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 zur Funktionsweise dieser Parameter finden Sie in der MySQL-Dokumentation: + Allgemeine Informationen finden Sie unter [Optionen und Variablen für Replikatserver](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html). + Informationen darüber, wie Filterparameter für die Datenbankreplikation ausgewertet werden, finden Sie unter [Optionen zur Auswertung der Replikation auf Datenbankebene und für die binäre Protokollierung](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html). + Informationen darüber, wie Filterparameter für die Tabellenreplikation ausgewertet werden, finden Sie unter [Optionen zur Auswertung der Replikation auf Tabellenebene](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html). 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 [Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken](USER_LogAccess.MySQL.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 MySQL Folgende Einschränkungen gelten für Replikationsfilter bei RDS für MySQL: + Jeder Filterparameter für die Replikation hat ein Limit von 2 000 Zeichen. + Kommas werden in Replikationsfiltern für Parameterwerte nicht unterstützt. In einer Liste mit Parametern können Kommas nur als Werttrennzeichen verwendet werden. Beispiel: `ParameterValue='`a,b`'` wird unterstützt, `ParameterValue='a,b'` jedoch nicht. + Die Optionen `--binlog-do-db` und `--binlog-ignore-db` von MySQL 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. ## Beispiele für Replikationsfilter bei RDS für MySQL 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 der AWS-Managementkonsole AWS CLI, oder 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-mysql) + [Including tables in replication](#rep-filter-in-tables-mysql) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mysql) + [Excluding databases from replication](#rep-filter-ex-dbs-mysql) + [Excluding tables from replication](#rep-filter-ex-tables-mysql) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mysql) **Example Einschließen von Datenbanken in die Replikation** Das folgende Beispiel schließt die Datenbanken `mydb1` und `mydb2` 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-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 `order` und `return` 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.order%,mydb.return%',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` **Example Ausschließen von Datenbanken von der Replikation** Das folgende Beispiel schließt die Datenbanken `mydb5` und `mydb6` 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='mydb5,mydb6',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` **Example Ausschließen von Tabellen von der Replikation** Das folgende Beispiel schließt die Tabellen `table1` in Datenbank `mydb5` und `table2` in Datenbank `mydb6` 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='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` **Example Ausschließen von Tabellen von der Replikation mit Platzhalterzeichen** Das folgende Beispiel schließt Tabellen mit Namen, die mit `order` und `return` beginnen, in Datenbank `mydb7` 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='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',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 MySQL-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. # Konfigurieren der verzögerten Replikation mit MySQL 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. + Starten Sie die Replikation und geben Sie an, dass die Replikation automatisch an einer bestimmten Position in der Protokolldatei stoppen soll. Mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) geben Sie eine Position unmittelbar vor Eintreten des Notfalls an. + 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** Unter RDS für MySQL 8.4 wird die verzögerte Replikation für MySQL ab 8.4.3 unterstützt. In RDS für MySQL 8.0 wird die verzögerte Replikation für MySQL ab 8.0.28 unterstützt. Unter RDS für MySQL 5.7 wird die verzögerte Replikation für MySQL ab 5.7.44 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 AWS CLI, der oder der Amazon RDS-API konfigurieren. Sie können die Replikation auf der Grundlage globaler Transaktions-Identifikatoren (GTIDs) in einer Konfiguration mit verzögerter Replikation für die folgenden Versionen verwenden: RDS für MySQL Version 5.7.44 und höhere 5.7-Versionen RDS für MySQL Version 8.0.28 und höhere 8.0-Versionen RDS für MySQL Version 8.4.3 und höhere 8.4-Versionen Wenn Sie die GTID-basierte Replikation verwenden, nutzen Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) anstelle der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Weitere Informationen zu GTID-basierten Replikationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). **Topics** + [ ## Konfigurieren der verzögerten Replikation während der Erstellung von Read Replicas ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ReplicaCreation) + [ ## Ändern der verzögerten Replikation einer vorhandenen Read Replica ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ExistingReplica) + [ ## Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.StartUntil) + [ ## Hochstufen eines Lesereplikats ](#USER_MySQL.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 MySQL-Client eine Verbindung zu der MySQL-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** Nachdem Sie diese gespeicherte Prozedur ausgeführt haben, wird jedes Lesereplikat, das Sie mit der AWS CLI oder der Amazon RDS-API erstellen, so konfiguriert, dass die Replikation um die angegebene Anzahl von Sekunden verzögert wird. ## Ä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 MySQL-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. ## Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica Nachdem Sie die Replikation für ein Lesereplikat gestoppt haben, können Sie die Replikation mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) starten und dann an einer angegebenen Position in der Binärprotokolldatei stoppen lassen. **Starten Sie die Replikation für ein Lesereplikat und stoppen Sie die Replikation an einer bestimmten Position wie folgt:** 1. Verwenden Sie einen MySQL-Client, um als Masterbenutzer eine Verbindung zur MySQL-DB-Instance herzustellen. 1. Führen Sie die gespeicherte Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) aus. Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die Position `120` in der Binärprotokolldatei `mysql-bin-changelog.000777` erreicht wird. Beispiel: In einem Szenario der Notfallwiederherstellung liegt die Position `120` unmittelbar vor der Katastrophe. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` Die Replikation stoppt automatisch, sobald der Stopppunkt erreicht ist. Das folgende RDS-Ereignis wird generiert: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`. ## 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). # Aktualisieren von Lesereplikaten mit MySQL 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 zu optimieren, die auf das Replica zugreifen. Zwar können Sie Updates aktivieren, indem Sie den Parameter `read_only` in der DB-Parametergruppe für das Lesereplikat auf `0` setzen. Wir raten jedoch davon ab, da Probleme auftreten können, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Für Wartungsarbeiten empfehlen wir, blue/green Bereitstellungen zu verwenden. Weitere Informationen finden Sie unter [Verwendung von Blue/Green Bereitstellungen für Datenbankaktualisierungen](blue-green-deployments.md). Wenn Sie den Schreibschutz für ein Lesereplikat deaktivieren, ändern Sie den Wert des Parameters `read_only` sobald wie möglich wieder in `1`. # Arbeiten mit Bereitstellungen von Multi-AZ-Lesereplikaten mit MySQL 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 MySQL RDS für MySQL unterstützt kaskadierende Lesereplikate. Mit *kaskadierenden Lesereplikaten* können Sie Lesereplikate skalieren, ohne dass Sie zusätzlichen Overhead für Ihre Quell-DB-Instance von RDS für MySQL verursachen. Bei kaskadierenden Lesereplikaten sendet Ihre DB-Instance von RDS für MySQL 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 MySQL 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 MySQL erstellen. Angenommen, Sie haben eine DB-Instance von RDS für MySQL, `mysql-main`. Sie haben die folgenden Möglichkeiten: + Beginnend mit `mysql-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 `mysql-main` erstellen. Eine vollständige Reihe von Instances aus einer Quell-DB-Instance von RDS für MySQL 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 MySQL 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 `mysql-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 `mysql-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). # Überwachen der Replikationsverzögerung für MySQL-Lesereplikate Für MySQL-Lesereplikat können Sie die Replikationsverzögerung in Amazon CloudWatch überwachen, indem Sie sich die Amazon-RDS-Metrik `ReplicaLag` ansehen. Die Kennzahl `ReplicaLag` meldet den Wert des Feldes `Seconds_Behind_Master` des Befehls `SHOW REPLICA STATUS`. Häufige Ursachen für Replikationsverzögerungen in MySQL: + Ein Netzwerkausfall. + Schreiben in Tabellen, die verschiedene Indizes in einem Lesereplikat haben. Wenn der Parameter `read_only` in einem Lesereplikat auf `0` gesetzt ist, kann die Replikation fehlschlagen, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Nachdem Sie Wartungsarbeiten für ein Lesereplikat durchgeführt haben, sollten Sie den Parameter `read_only` wieder zurück auf `1` setzen. + Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Die Replikation wird nur für die InnoDB-Speicher-Engine für MySQL 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 MySQL 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 Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-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 für ein Problem mit einer MySQL Read Replica Im Fall von MySQL-DB-Instances zeigen Lesereplikate manchmal Replikationsfehler oder Dateninkonsistenzen (oder beides) zwischen dem Lesereplikat und seiner DB-Quell-Instance an. Dieses Problem tritt auf, wenn einige Binärprotokoll (Binlog)-Ereignisse oder InnoDB-Wiederholungsprotokolle während eines Fehlers des Lesereplikats oder der Quell-DB-Instance nicht bereinigt werden. 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. **Warnung** In der Parametergruppe, die mit der Quell-DB-Instance verknüpft ist, sollten diese Parameterwerte beibehalten werden: `sync_binlog=1` und `innodb_flush_log_at_trx_commit=1`. Diese Parameter sind dynamisch. Wenn Sie diese Einstellungen nicht verwenden möchten, empfehlen wir Ihnen, diese Werte vorübergehend festzulegen, bevor Sie einen Vorgang für die Quell-DB-Instance ausführen, der einen Neustart verursachen könnte. Zu diesen Vorgängen gehören unter anderem Neustart, Neustart mit Failover, das Aktualisieren der Datenbankversion und das Ändern der DB-Instance-Klasse oder ihres Speichers. Die gleiche Empfehlung gilt für das Erstellen neuer Lesereplikate für die Quell-DB-Instance. Die Nichteinhaltung dieser Anleitung erhöht das Risiko, dass Lesereplikate Replikationsfehler oder Dateninkonsistenzen (oder beides) zwischen dem Lesereplikat und seiner DB-Quell-Instance aufweisen. Die Replikationstechnologien in MySQL funktionieren nach einem asynchronen Prinzip. 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 MySQL-Dokumentation finden Sie unter [Details zur Implementierung der Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html). 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 MySQL-Engine zurückgegebenen Fehlers dem Feld `Replication Error` entnehmen. 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 MySQL-Fehlermeldung zurückgegeben wird, überprüfen Sie die Fehlernummer in der [MySQL-Fehlermeldungsdokumentation](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html). 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. Sie verwenden `max_allowed_packet`, um die maximale Größe von DML-Code anzugeben, der in der Datenbank ausgeführt werden kann. In einigen Fällen ist der `max_allowed_packet`-Wert in der mit einer Quell-DB-Instance verknüpften DB-Parametergruppe kleiner als der `max_allowed_packet`-Wert in der mit dem Lesereplikat der Quelle verknüpften DB-Parametergruppe. In diesen Fällen kann der Replikationsprozess den Fehler `Packet bigger than 'max_allowed_packet' bytes` auslösen und die Replikation beenden. Um den Fehler zu beheben, lassen Sie die DB-Quell-Instance und das Lesereplikat DB-Parametergruppen mit denselben `max_allowed_packet`-Parameterwerten verwenden. Weitere Situationen, bei denen Replikationsfehler auftreten können, sind die Folgenden: + Schreibvorgänge auf Tabellen in einem Lesereplikat. In einigen Fällen können Sie Indizes für ein Lesereplikat erstellen, die sich von den Indizes in der Quell-DB-Instance unterscheiden. Wenn Sie dies tun, setzen Sie den Parameter `read_only` auf `0`, um die Indizes zu erstellen. Wenn Sie in einem Lesereplikat in Tabellen schreiben, kann die Replikation unterbrochen werden, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Nachdem Sie Wartungsarbeiten für ein Lesereplikat durchgeführt haben, sollten Sie den Parameter `read_only` wieder zurück auf `1` setzen. + Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Read Replicas erfordern eine transaktionale Speicher-Engine. Die Replikation wird nur für die InnoDB-Speicher-Engine für MySQL 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 im Abschnitt [Überspringen des aktuellen Replikationsfehlers für RDS für MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Andernfalls können Sie zuerst das Lesereplikat löschen. Anschließend erstellen Sie eine Instance mit derselben DB-Instance-Kennung, sodass der Endpunkt mit dem des alten Lesereplikats übereinstimmt. Wird ein Replikationsfehler behoben, ändert sich das Feld `Replication State` zu *Replicating*. # Verwenden der GTID-basierten Replikation Der folgende Inhalt beschreibt, wie Sie globale Transaktionskennungen (Global Transaction Identifiers, GTIDs) mit Binärprotokoll (binlog)-Replikation unter DB-Instances von Amazon RDS für MySQL verwenden. Wenn Sie die binlog-Replikation verwenden und nicht mit der GTID-basierten Replikation mit MySQL vertraut sind, finden Sie unter [Replikation mit globalen Transaktionskennungen](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) in der MySQL-Dokumentation weitere Informationen. Die GTID-basierte Replikation wird für die folgenden Versionen unterstützt: + RDS für MySQL 8.4 (alle Versionen) + RDS für MySQL 8.0 (alle Versionen) + RDS für MySQL 5.7 (alle Versionen) Alle MySQL-DB-Instances in einer Replikationskonfiguration müssen diese Versionsanforderung erfüllen. **Topics** + [ ## Übersicht über globale Transaktionskennungen (GTIDs) ](#mysql-replication-gtid.overview) + [ ## Parameter für die GTID-basierte Replikation ](#mysql-replication-gtid.parameters) + [ # Aktivieren der GTID-basierten Replikation für neue Lesereplikate für RDS für MySQL ](mysql-replication-gtid.configuring-new-read-replicas.md) + [ # Aktivieren der GTID-basierten Replikation für vorhandene Lesereplikate für RDS für MySQL ](mysql-replication-gtid.configuring-existing-read-replicas.md) + [ # Deaktivieren einer GTID-basierten Replikation für eine MySQL-DB-Instance mit Read Replicas ](mysql-replication-gtid.disabling.md) ## Übersicht über globale Transaktionskennungen (GTIDs) *Globale Transaktionskennungen (GTIDs)* sind eindeutige IDs, die für festgeschriebene MySQL-Transaktionen generiert werden. Sie können GTIDs verwenden, um die Fehlerbehebung für die binlog-Replikation zu erleichtern. MySQL verwendet für die binlog-Replikation zwei verschiedene Arten von Transaktionen: + *GTID-Transaktionen* – Transaktionen, die durch eine GTID gekennzeichnet sind. + *Anonyme Transaktionen* – Transaktionen, denen keine GTID zugeordnet ist. In einer Replikationskonfiguration sind GTIDs bei allen DB-Instances eindeutig. GTIDs vereinfachen die Replikationskonfiguration, weil Sie nicht auf die Protokolldateipositionen verweisen müssen, wenn Sie diese verwenden. GTIDs erleichtern das Verfolgen von replizierten Transaktionen und legen fest, ob die Quellinstance und Replikate konsistent sind. Zur Replikation von Daten mit RDS-MySQL-Lesereplikaten können Sie die GTID-basierte Replikation verwenden. Sie können beim Erstellen neuer Lesereplikate die GTID-basierte Replikation konfigurieren oder bestehende Lesereplikate zum Verwenden der GTID-basierten Replikation konvertieren. Sie können die GTID-basierte Replikation in einer zeitlich verzögerten Replikationskonfiguration mit RDS für MySQL verwenden. Weitere Informationen finden Sie unter [Konfigurieren der verzögerten Replikation mit MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md). ## Parameter für die GTID-basierte Replikation Mit den folgenden Parametern konfigurieren Sie die GTID-basierte Replikation. | Parameter | Zulässige Werte | Beschreibung | | --- | --- | --- | | `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` gibt an, dass neue Transaktionen anonyme Transaktionen sind (d. h. keine GTIDs haben). Eine Transaktion muss anonym sein, um repliziert werden zu können. `OFF_PERMISSIVE` gibt an, dass neue Transaktionen anonyme Transaktionen sind und alle Transaktionen repliziert werden können. `ON_PERMISSIVE` gibt an, dass neue Transaktionen GTID-Transaktionen sind und alle Transaktionen repliziert werden können. `ON` gibt an, dass neue Transaktionen GTID-Transaktionen sind. Eine Transaktion muss eine GTID-Transaktion sein, um repliziert zu werden. | | `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` erlaubt es Transaktionen, gegen die GTID-Konsistenz zu verstoßen. `ON` verhindert das Verstoßen von Transaktionen gegen die GTID-Konsistenz. `WARN` erlaubt es Transaktionen, gegen die GTID-Konsistenz zu verstoßen, generiert aber eine Warnung, wenn ein Verstoß auftritt. | **Anmerkung** In der AWS-Managementkonsole erscheint der Parameter `gtid_mode` als `gtid-mode`. Bei einer GTID-basierten Replikation verwenden Sie diese Einstellungen für die Parametergruppe für Ihre DB-Instance oder Lesereplikate: + `ON` und `ON_PERMISSIVE` gelten nur für die ausgehende Replikation von einer RDS-DB-Instance. Beide Werte bewirken, dass Ihre RDS-DB-Instance GTIDs für Transaktionen verwenden, die repliziert werden. `ON` erfordert, dass die Zieldatenbank ebenfalls die GTID-basierte Replikation verwendet. Mit `ON_PERMISSIVE` ist die GTID-basierte Replikation auf der Zieldatenbank optional. + Wenn `OFF_PERMISSIVE` eingestellt ist, bedeutet dies, dass Ihre RDS-DB-Instances die eingehende Replikation von einer Quelldatenbank akzeptieren können. Dabei ist unerheblich, ob die Quelldatenbank eine GTID-basierte Replikation verwendet. + Wenn `OFF` eingestellt ist, bedeutet dies, dass Ihre RDS-DB-Instance nur eingehende Replikation von Quelldatenbanken akzeptieren, die keine GTID-basierte Replikation verwenden. Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). # Aktivieren der GTID-basierten Replikation für neue Lesereplikate für RDS für MySQL Wenn die GTID-basierte Replikation für eine RDS für MySQL-DB-Instance aktiviert ist, wird die GTID-basierte Replikation automatisch für Lesereplikate der DB-Instance konfiguriert. **So aktivieren Sie die GTID-basierte Replikation für neue Lesereplikate** 1. Die Parametergruppe, die der DB-Instance zugeordnet ist, muss über die folgenden Parametereinstellungen verfügen: + `gtid_mode` – `ON` oder `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). 1. Wenn Sie die Parametergruppe der DB-Instance geändert haben, müssen Sie die DB-Instance neu starten. Weitere Information dazu finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). 1. Erstellen Sie mindestens ein Lesereplikat der DB-Instance. Weitere Information dazu finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md). Amazon RDS versucht, mithilfe von eine GTID-basierte Replikation zwischen der MySQL-DB-Instance und den Lesereplikaten herzustelle `MASTER_AUTO_POSITION`. Wenn der Versuch fehlschlägt, verwendet Amazon RDS Protokolldateipositionen für die Replikation mit den Lesereplikaten. Weitere Informationen zu `MASTER_AUTO_POSITION` finden Sie unter [ Automatische GTID-Positionierung](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-auto-positioning.html) in der MySQL-Dokumentation. # Aktivieren der GTID-basierten Replikation für vorhandene Lesereplikate für RDS für MySQL Für eine vorhandene MySQL-DB-Instance mit Lesereplikaten, die keine GTID-basierte Replikation verwendet, können Sie eine GTID-basierte Replikation zwischen der DB-Instance und den Lesereplikaten konfigurieren. **So aktivieren Sie die GTID-basierte Replikation für bestehende Lesereplikate** 1. Wenn die DB-Instance oder eine Read Replica eine 8.0-Version von RDS für MySQL unter 8.0.26 verwendet, aktualisieren Sie die DB-Instance oder Read Replica auf 8.0.26 oder eine höhere MySQL 8.0-Version. Alle Versionen von RDS für MySQL 8.4 und 5.7 unterstützen die GTID-basierte Replikation. Weitere Informationen finden Sie unter [Upgrades der DB-Engine von RDS für MySQL](USER_UpgradeDBInstance.MySQL.md). 1. (Optional) Setzen Sie die GTID-Parameter zurück und testen Sie das Verhalten der DB-Instance und der Lesereplikate: 1. Die Parametergruppe, die der DB-Instance zugeordnet ist, und jedes Lesereplikat muss den Wert für den Parameter `enforce_gtid_consistency` auf `WARN` gesetzt haben. Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). 1. Wenn Sie die Parametergruppe der DB-Instance geändert haben, müssen Sie die DB-Instance neu starten. Wenn Sie die Parametergruppe des Lesereplikats geändert haben, müssen Sie das Lesereplikat neu starten. Weitere Informationen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). 1. Führen Sie Ihre DB-Instance und Lesereplikate mit Ihrem normalen Workload aus und überwachen Sie die Protokolldateien. Wenn Ihnen Warnungen über GTID-inkompatible Transaktionen angezeigt werden, passen Sie Ihre Anwendung so an, dass sie nur GTID-kompatible Funktionen verwendet. Die DB-Instance darf keine Warnungen über GTID-inkompatible Transaktionen erzeugen, bevor Sie mit dem nächsten Schritt fortfahren. 1. Setzen Sie die GTID-Parameter für die GTID-basierte Replikation zurück, die anonyme Transaktionen erlaubt, bis die Lesereplikate alle verarbeitet haben. 1. Die Parametergruppe, die der DB-Instance zugeordnet ist, und jedes Lesereplikat muss die folgenden Parametereinstellungen haben: + `gtid_mode` – `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Wenn Sie die Parametergruppe der DB-Instance geändert haben, müssen Sie die DB-Instance neu starten. Wenn Sie die Parametergruppe des Lesereplikats geändert haben, müssen Sie das Lesereplikat neu starten. 1. Warten Sie, bis alle anonymen Transaktionen abgeschlossen sind. Um zu überprüfen, ob diese repliziert sind, gehen Sie wie folgt vor: 1. Führen Sie die folgende Anweisung auf Ihrer Quell-DB-Instance aus. **MySQL 8.4** ``` SHOW BINARY LOG STATUS; ``` **MySQL 5.7 und 8.0** ``` SHOW MASTER STATUS; ``` Notieren Sie die Werte in den Spalten `File` und `Position`. 1. Verwenden Sie bei jedem Lesereplikat die Datei- und Positionsinformationen der Quell-Instance im vorherigen Schritt, um die folgende Abfrage auszuführen. ``` SELECT MASTER_POS_WAIT('file', position); ``` Führen Sie die folgende Anweisung aus, wenn der Dateiname `mysql-bin-changelog.000031` lautet und die Position `107` ist. ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Wenn das Lesereplikat über die angegebene Position hinausgeht, wird die Abfrage sofort zurückgegeben. Andernfalls wartet die Funktion. Gehen Sie zum nächsten Schritt über, wenn die Abfrage für alle Lesereplikate zurückgegeben wird. 1. Setzen Sie die GTID-Parameter ausschließlich für die GTID-basierte Replikation zurück. 1. Die Parametergruppe, die der DB-Instance zugeordnet ist, und jedes Lesereplikat muss die folgenden Parametereinstellungen haben: + `gtid_mode` – `ON` + `enforce_gtid_consistency` – `ON` 1. Starten Sie die DB-Instance und jedes Lesereplikat neu. 1. Führen Sie auf jedem Lesereplikat die folgende Prozedur aus. **MySQL 8.4 und höhere Hauptversionen** ``` CALL mysql.rds_set_source_auto_position(1); ``` **MySQL 8.0 und niedrigere Hauptversionen** ``` CALL mysql.rds_set_master_auto_position(1); ``` # Deaktivieren einer GTID-basierten Replikation für eine MySQL-DB-Instance mit Read Replicas Sie können eine GTID-basierte Replikation für die eine GTID-basierte Replikation für eine MySQL-DB-Instance mit Lesereplikaten verwenden. **So deaktivieren Sie die GTID-basierte Replikation für eine MySQL-DB-Instance mit Lesereplikaten** 1. Führen Sie auf jedem Lesereplikat die folgende Prozedur aus: **MySQL 8.4 und höhere Hauptversionen** ``` CALL mysql.rds_set_source_auto_position(0); ``` **MySQL 8.0 und niedrigere Hauptversionen** ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Setzen Sie den Wert für `gtid_mode` auf `ON_PERMISSIVE` zurück. 1. Die Parametergruppe, die der MySQL-DB-Instance zugeordnet ist, und jedes Read Replica muss den Wert für den Parameter `gtid_mode` auf `ON_PERMISSIVE` gesetzt haben. Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). 1. Starten Sie die MySQL-DB-Instance und jedes Read Replica neu. Weitere Informationen zum Neustarten finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). 1. Setzen Sie den Wert für `gtid_mode` auf `OFF_PERMISSIVE` zurück. 1. Die Parametergruppe, die der MySQL-DB-Instance zugeordnet ist, und jedes Read Replica muss den Wert für den Parameter `gtid_mode` auf `OFF_PERMISSIVE` gesetzt haben. 1. Starten Sie die MySQL-DB-Instance und jedes Read Replica neu. 1. Warten Sie, bis alle GTID-Transaktionen auf alle Lesereplikate angewendet wurden. Um zu überprüfen, ob diese angewendet werden, führen Sie die folgenden Schritte aus: 1. Führen Sie für die MySQL-DB-Instance den folgenden Befehl aus: **MySQL 8.4** ``` SHOW BINARY LOG STATUS ``` **MySQL 5.7 und 8.0** ``` SHOW MASTER STATUS ``` Die Ausgabe sollte in etwa wie folgt aussehen. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` Notieren Sie die Datei und Position in Ihrer Ausgabe. 1. Verwenden Sie bei jedem Lesereplikat die Datei- und Positionsinformationen der Quell-Instance im vorherigen Schritt, um die folgende Abfrage auszuführen. **MySQL 8.4 und MySQL 8.0.26 und höhere MySQL-8.0-Versionen** ``` SELECT SOURCE_POS_WAIT('file', position); ``` **MySQL 5.7** ``` SELECT MASTER_POS_WAIT('file', position); ``` Führen Sie die folgende Anweisung aus, wenn der Dateiname `mysql-bin-changelog.000031` lautet und die Position `107` ist: **MySQL 8.4 und MySQL 8.0.26 und höhere MySQL-8.0-Versionen** ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` **MySQL 5.7** ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` 1. Setzen Sie die GTID-Parameter zurück, um die GTID-basierte Replikation zu deaktivieren: 1. Die Parametergruppe, die der MySQL-DB-Instance zugeordnet ist, und jedes Read Replica muss die folgenden Parametereinstellungen haben: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Starten Sie die MySQL-DB-Instance und jedes Read Replica neu. # 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; ``` # Konfiguration multi-source-replication für Amazon RDS for MySQL Bei der Multi-Source-Replikation können Sie eine DB-Instance von Amazon RDS für MySQL als Replikat einrichten, das binäre Protokollereignisse aus mehreren Quell-DB-Instances von RDS für MySQL empfängt. Die Multi-Source-Replikation wird für DB-Instances von RDS für MySQL unterstützt, auf denen die folgenden Engine-Versionen ausgeführt werden: + Alle MySQL 8.4-Versionen + 8.0.35 und höhere Nebenversionen + 5.7.44 und höhere Nebenversionen Informationen zur MySQL-Multi-Source-Replikation finden Sie unter [MySQL-Multi-Source-Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html) in der MySQL-Dokumentation. Die MySQL-Dokumentation enthält detaillierte Informationen zu dieser Funktion. In diesem Thema wird beschrieben, wie Sie die Multi-Source-Replikationskanäle auf den DB-Instances von RDS für MySQL konfigurieren und verwalten. ## Anwendungsfälle für die Multi-Source-Replikation Die folgenden Fälle eignen sich gut für die Verwendung der Multi-Source-Replikation in RDS für MySQL: + Anwendungen, die mehrere Shards auf separaten DB-Instances mit einem einzigen Shard zusammenführen oder kombinieren müssen. + Anwendungen, die Berichte anhand von Daten generieren müssen, die aus mehreren Quellen zusammengefasst wurden. + Anforderungen zum Erstellen zusammengefasster langfristiger Backups von Daten, die auf mehreren DB-Instances von RDS für MySQL verteilt sind. ## Voraussetzungen für eine Multi-Source-Replikation Damit Sie die Multi-Source-Replikation konfigurieren können, müssen die folgenden Voraussetzungen erfüllt sein. + Vergewissern Sie sich, dass für jede Quell-DB-Instance von RDS für MySQL automatische Backups aktiviert sind. Durch die Aktivierung automatischer Backups wird die binäre Protokollierung ermöglicht. Informationen zum Aktivieren von automatischen Backups finden Sie unter [Aktivieren von automatisierten Backups](USER_WorkingWithAutomatedBackups.Enabling.md). + Um Replikationsfehler zu vermeiden, wird empfohlen, Schreibvorgänge in die Quell-DB-Instances zu blockieren. Legen Sie hierzu den Parameter `read-only` in einer benutzerdefinierten Parametergruppe, die mit der Quell-DB-Instance von RDS für MySQL verbunden ist, auf `ON` fest. Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um eine neue benutzerdefinierte Parametergruppe zu erstellen oder eine bestehende zu ändern. Weitere Informationen erhalten Sie unter [Erstellen einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Creating.md) und [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). + Fügen Sie für die jeweilige Quell-DB-Instance die IP-Adresse der Instance zur Sicherheitsgruppe von Amazon Virtual Private Cloud (VPC) für die Multi-Source-DB-Instance hinzu. Um die IP-Adresse einer Quell-DB-Instance zu identifizieren, können Sie den Befehl `dig RDS Endpoint` ausführen. Führen Sie den Befehl von einer Amazon-EC2-Instance aus, die sich in derselben VPC wie die Ziel-Multi-Source-DB-Instance befindet. + Verwenden Sie für die jeweilige Quell-DB-Instance einen Client, um eine Verbindung mit der DB-Instance herzustellen und einen Datenbankbenutzer mit den erforderlichen Berechtigungen für die Replikation zu erstellen, wie im folgenden Beispiel gezeigt. ``` CREATE USER 'repl_user' IDENTIFIED BY 'password'; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'; ``` **Anmerkung** Ab MySQL 8.4 wurde die Berechtigung `REPLICATION SLAVE` eingestellt und durch `REPLICATION REPLICA` ersetzt. Verwenden Sie für MySQL 8.4 und höhere Versionen stattdessen die folgende Syntax: ``` CREATE USER 'repl_user' IDENTIFIED BY 'password'; GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'repl_user'; ``` ## Konfigurieren von Multi-Source-Replikationskanälen auf DB-Instances von RDS für MySQL Die Konfiguration von Multi-Source-Replikationskanälen ähnelt der Konfiguration einer Single-Source-Replikation. Bei der Multi-Source-Replikation aktivieren Sie zunächst die Binärprotokollierung für die Quell-Instance. Importieren Sie anschließend die Daten aus den Quellen in das Multi-Source-Replikat. Starten Sie danach die Replikation von jeder Quelle aus, indem Sie die Binärprotokollkoordinaten oder die automatische GTID-Positionierung verwenden. Führen Sie die folgenden Schritte aus, um eine DB-Instance von RDS für MySQL als Multi-Source-Replikat von zwei oder mehr DB-Instances von RDS für MySQL zu konfigurieren. **Topics** + [ ### Schritt 1: Importieren von Daten aus den Quell-DB-Instances in das Multi-Source-Replikat ](#mysql-multi-source-replication-import) + [ ### Schritt 2: Starten der Replikation von den Quell-DB-Instances in das Multi-Source-Replikat ](#mysql-multi-source-replication-setting-up-start-replication-other) ### Schritt 1: Importieren von Daten aus den Quell-DB-Instances in das Multi-Source-Replikat Führen Sie die folgenden Schritte für jede Quell-DB-Instance aus. Bevor Sie die Daten einer Quelle in das Multi-Source-Replikat importieren, ermitteln Sie die aktuelle Binärprotokolldatei und Position, indem Sie den Befehl `SHOW MASTER STATUS` ausführen. Notieren Sie sich diese Details zwecks Verwendung im nächsten Schritt. In dieser Beispielausgabe ist die Datei `mysql-bin-changelog.000031` und die Position `107`. **Anmerkung** Ab MySQL 8.4 wurde der Befehl `SHOW MASTER STATUS` nicht mehr verwendet und durch `SHOW BINARY LOG STATUS` ersetzt. Verwenden Sie für MySQL 8.4 und höhere Versionen stattdessen `SHOW BINARY LOG STATUS`. ``` File Position ----------------------------------- mysql-bin-changelog.000031 107 ----------------------------------- ``` Kopieren Sie nun die Datenbank von der Quell-DB-Instance mithilfe von `mysqldump` in das Multi-Source-Replikat, wie im folgenden Beispiel aufgeführt. ``` mysqldump --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ -u RDS_user_name \ -p RDS_password \ --host=RDS Endpoint | mysql \ --host=RDS Endpoint \ --port=3306 \ -u RDS_user_name \ -p RDS_password ``` Nach dem Kopieren der Datenbank können Sie den schreibgeschützten Parameter in der Quell-DB-Instance auf `OFF` festlegen. ### Schritt 2: Starten der Replikation von den Quell-DB-Instances in das Multi-Source-Replikat Verwenden Sie für die jeweilige Quell-DB-Instance die Anmeldeinformationen des Administratorbenutzers, um eine Verbindung mit der Instance herzustellen, und führen Sie die folgenden zwei gespeicherten Prozeduren aus. Mit diesen gespeicherten Prozeduren wird die Replikation auf einem Kanal konfiguriert und dann gestartet. In diesem Beispiel wird der Name und die Position der Binärprotokolldatei aus der Beispielausgabe im vorherigen Schritt verwendet. ``` CALL mysql.rds_set_external_source_for_channel('mysourcehost.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1, 'channel_1'); CALL mysql.rds_start_replication_for_channel('channel_1'); ``` Weitere Informationen zur Verwendung dieser und anderer gespeicherten Prozeduren zum Einrichten und Verwalten der Replikationskanäle finden Sie unter [Verwalten der Multi-Source-Replikation](mysql-stored-proc-multi-source-replication.md). ## Verwenden von Filtern bei der Multi-Source-Replikation Sie können Replikationsfilter verwenden, um festzulegen, 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. Weitere Informationen zu Replikationsfiltern finden Sie unter [Konfigurieren von Replikationsfiltern mit MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md). Bei der Multi-Source-Replikation können Sie Replikationsfilter global oder auf Kanalebene konfigurieren. Die Filterung auf Kanalebene ist nur für unterstützte DB-Instances verfügbar, auf denen Version 8.0 oder Version 8.4 ausgeführt wird. In den folgenden Beispielen ist die Konfiguration von Filtern global oder auf Kanalebene angegeben. Beachten Sie die folgenden Anforderungen und das folgende Verhalten bei der Filterung von Multi-Source-Replikationen: + Die Kanalnamen müssen in invertierte Anführungszeichen (``) gesetzt werden. + Wenn Sie die Replikationsfilter in der Parametergruppe ändern, werden die Multi-Source-Replikate von `sql_thread` für alle Kanäle mit den Aktualisierungen neu gestartet, um die Änderungen dynamisch zu übernehmen. Wenn eine Aktualisierung einen globalen Filter einbezieht, werden alle Replikationskanäle im Ausführungszustand neu gestartet. + Alle globalen Filter werden vor jeglichen kanalspezifischen Filtern angewendet. + Wenn ein Filter global und auf Kanalebene angewendet wird, wird nur der Filter auf Kanalebene übernommen. Wenn die Filter beispielsweise `replicate_ignore_db="db1,`channel_22`:db2"` lauten, wird der auf `db1` festgelegte Parameter `replicate_ignore_db` auf alle Kanäle angewendet, mit Ausnahme von `channel_22`, und nur `channel_22` ignoriert Änderungen von `db2`. Beispiel 1: Festlegen eines globalen Filters Im folgenden Beispiel wird die Datenbank `temp_data` in jedem Kanal von der Replikation ausgeschlossen. Für Linux, macOS oder Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='temp_data',ApplyMethod=immediate" ``` Beispiel 2: Festlegen eines Filters auf Kanalebene Im folgenden Beispiel sind Änderungen der Datenbank `sample22` nur im Kanal `channel_22` enthalten. Ebenso sind Änderungen der Datenbank `sample99` nur im Kanal `channel_99` enthalten. Für Linux, macOS oder Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='\`channel_22\`:sample22,\`channel_99\`:sample99',ApplyMethod=immediate" ``` ## Überwachen von Multi-Source-Replikationskanälen Sie können einzelne Kanäle in einem Multi-Source-Replikat mithilfe der folgenden Methoden überwachen: + Um den Status aller Kanäle oder eines bestimmten Kanals zu überwachen, stellen Sie eine Verbindung mit dem Multi-Source-Replikat her und führen Sie den Befehl `SHOW REPLICA STATUS` oder `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'` aus. Weitere Informationen finden Sie unter [Überprüfen des Replikationsstatus](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) in der MySQL-Dokumentation. + Verwenden Sie die RDS-Ereignisbenachrichtigung, um eine Benachrichtigung zu erhalten, wenn ein Replikationskanal gestartet, gestoppt oder entfernt wird. Weitere Informationen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md). + Um die Verzögerung für einen bestimmten Kanal zu überwachen, überprüfen Sie dessen Metrik `ReplicationChannelLag`. Datenpunkte für diese Metrik mit einem Zeitraum von 60 Sekunden (1 Minute) stehen 15 Tage lang zur Verfügung. Zum Ermitteln der Replikationskanalverzögerung für einen Kanal verwenden Sie die Instance-ID und den Namen des Replikationskanals. Um eine Benachrichtigung zu erhalten, wenn diese Verzögerung einen bestimmten Schwellenwert überschreitet, können Sie einen CloudWatch Alarm einrichten. Weitere Informationen finden Sie unter [Überwachung von Amazon RDS mit Amazon CloudWatch](monitoring-cloudwatch.md). ## Überlegungen und bewährte Methoden bei der Multi-Source-Replikation Bevor Sie die Multi-Source-Replikation von RDS für MySQL verwenden, machen Sie sich mit den folgenden Faktoren und bewährten Methoden vertraut: + Vergewissern Sie sich, dass eine als Multi-Source-Replikat konfigurierte DB-Instance über ausreichende Ressourcen wie Durchsatz, Arbeitsspeicher, CPU und IOPS verfügt, um den Workload mehrerer Quell-Instances zu verarbeiten. + Überwachen Sie die Ressourcennutzung für das Multi-Source-Replikat regelmäßig und passen Sie die Speicher- oder Instance-Konfiguration an, um den Workload zu verarbeiten, ohne die Ressourcen zu belasten. + Sie können die Multi-Thread-Replikation für ein Multi-Source-Replikat konfigurieren, indem Sie die Systemvariable `replica_parallel_workers` auf einen Wert größer als `0` festlegen. In diesem Fall entspricht die Anzahl der Threads, die jedem Kanal zugewiesen sind, dem Wert dieser Variablen zuzüglich eines Koordinator-Threads zur Verwaltung der Anwender-Threads. + Konfigurieren Sie die Replikationsfilter entsprechend, um Konflikte zu vermeiden. Um eine gesamte Datenbank in eine andere Datenbank eines Replikats zu replizieren, können Sie die Option `--replicate-rewrite-db` verwenden. Sie können beispielsweise alle Tabellen von Datenbank A in Datenbank B einer Replikat-Instance replizieren. Diese Vorgehensweise kann hilfreich sein, wenn alle Quell-Instances dieselbe Schema-Benennungskonvention verwenden. Informationen zur Option `--replicate-rewrite-db` finden Sie unter [Optionen und Variablen für Replikatserver](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html) in der MySQL-Dokumentation. + Um Replikationsfehler zu vermeiden, sollten Sie nicht in das Replikat schreiben. Es wird empfohlen, den Parameter `read_only` in Multi-Source-Replikaten zu aktivieren, um Schreibvorgänge zu blockieren. Auf diese Weise können Replikationsprobleme vermieden werden, die durch widersprüchliche Schreibvorgänge verursacht werden. + Um die Leistung von Lesevorgängen wie Sortierungen und Verknüpfungen mit hoher Auslastung zu verbessern, die auf dem Multi-Source-Replikat ausgeführt werden, erwägen Sie die Verwendung von RDS-optimierten Lesevorgängen. Diese Funktion kann bei Abfragen hilfreich sein, die von großen temporären Tabellen oder Sortierdateien abhängen. Weitere Informationen finden Sie unter [Verbesserung der Abfrageleistung für RDS für MySQL mit Amazon RDS Optimized Reads](rds-optimized-reads.md). + Um die Replikationsverzögerung zu minimieren und die Leistung eines Multi-Source-Replikats zu verbessern, erwägen Sie die Aktivierung optimierter Schreibvorgänge. Weitere Informationen finden Sie unter [Verbesserung der Schreibleistung mit RDS-optimierten Schreibvorgängen für MySQL](rds-optimized-writes.md). + Führen Sie Verwaltungsvorgänge (z. B. Konfigurationsänderungen) jeweils auf einem Kanal durch und vermeiden Sie es, an mehreren Kanälen von mehreren Verbindungen aus Änderungen vorzunehmen. Diese Vorgehensweisen können zu Konflikten bei Replikationsvorgängen führen. Beispielsweise kann die gleichzeitige Ausführung der Prozeduren `rds_skip_repl_error_for_channel` und `rds_start_replication_for_channel` von mehreren Verbindungen aus dazu führen, dass Ereignisse auf einem anderen Kanal als vorgesehen übersprungen werden. + Sie können Backups auf einer Multi-Source-Replikations-Instance aktivieren und Daten dieser Instance in einen Amazon-S3-Bucket exportieren, um sie für langfristige Zwecke zu speichern. Es ist jedoch wichtig, auch Backups mit entsprechender Aufbewahrungsdauer für die einzelnen Quell-Instances zu konfigurieren. Informationen zum Exportieren von Snapshot-Daten nach Amazon S3 finden Sie unter [Exportieren von DB-Snapshot-Daten nach Amazon S3 für Amazon RDS](USER_ExportSnapshot.md). + Um den Workload des Lesevorgangs auf ein Multi-Source-Replikat zu verteilen, können Sie Lesereplikate eines Multi-Source-Replikats erstellen. Sie können diese Read Replicas AWS-Regionen je nach den Anforderungen Ihrer Anwendung an unterschiedlichen Orten lokalisieren. Weitere Informationen über Lesereplikate finden Sie unter [Arbeiten mit MySQL-Lesereplikaten](USER_MySQL.Replication.ReadReplicas.md). ## Einschränkungen für die Multi-Source-Replikation bei RDS für MySQL Folgende Einschränkungen gelten für die Multi-Source-Replikation bei RDS für MySQL: + Derzeit unterstützt RDS für MySQL die Konfiguration von maximal 15 Kanälen für ein Multi-Source-Replikat. + Eine Lesereplikat-Instance kann nicht als Multi-Source-Replikat konfiguriert werden. + Um die Multi-Source-Replikation bei RDS für MySQL zu konfigurieren, auf dem Engine-Version 5.7 ausgeführt wird, muss das Leistungsschema auf der Replikat-Instance aktiviert sein. Die Aktivierung des Leistungsschemas ist bei RDS für MySQL mit Engine-Version 8.0 oder 8.4 optional. + Bei RDS für MySQL mit Engine-Version 5.7 gelten Replikationsfilter für alle Replikationskanäle. Bei RDS für MySQL mit Engine-Version 8.0 oder 8.4 können Sie Filter konfigurieren, die für alle Replikationskanäle oder für einzelne Kanäle gelten. + Durch das Wiederherstellen eines RDS-Snapshots oder das Durchführen eines Point-in-time-Restore (PITR) werden keine Replikatkanalkonfigurationen mit mehreren Quellen wiederhergestellt. + Wenn Sie ein Lesereplikat eines Multi-Source-Replikats erstellen, werden nur Daten der Multi-Source-Instance repliziert. Kanalkonfigurationen werden nicht wiederhergestellt. + MySQL unterstützt nicht die Einrichtung einer unterschiedlichen Anzahl paralleler Worker des jeweiligen Kanals. Basierend auf dem Wert `replica_parallel_workers` erhält der Kanal die gleiche Anzahl paralleler Worker. Die folgenden zusätzlichen Einschränkungen gelten, wenn das Multi-Source-Replikationsziel ein Multi-AZ-DB-Cluster ist: + Ein Kanal muss für eine Quell-Instance von RDS für MySQL konfiguriert werden, bevor Schreibvorgänge auf diese Instance ausgeführt werden. + Für die jeweilige Quell-Instance von RDS für MySQL muss die GTID-basierte Replikation aktiviert sein. + Durch ein Failover-Ereignis auf dem DB-Cluster wird die Konfiguration der Multi-Source-Replikation entfernt. Um diese Konfiguration wiederherzustellen, müssen die Konfigurationsschritte wiederholt werden. # Konfigurieren von Aktiv/Aktiv-Clustern von RDS für MySQL Ein Aktiv/Aktiv-Cluster in Amazon RDS ist eine Datenbankkonfiguration, bei der mehrere Knoten aktiv Lese- und Schreibvorgänge verarbeiten und die Workload auf die Instances verteilen, um die Verfügbarkeit und Skalierbarkeit zu verbessern. Jeder Knoten im Cluster wird synchronisiert, um die Datenkonsistenz zu bewahren, was eine hohe Verfügbarkeit und ein schnelleres Failover bei einem Ausfall des Knotens ermöglicht. Sie können einen Aktiv/Aktiv-Cluster von RDS für MySQL einrichten, indem Sie das MySQL-Gruppenreplikations-Plugin verwenden. Das Gruppenreplikations-Plugin wird für DB-Instances von RDS für MySQL unterstützt, auf denen die folgenden Versionen ausgeführt werden: + Alle MySQL 8.4-Versionen + MySQL 8.0.35 und höhere Unterversionen Informationen zur MySQL-Gruppenreplikation finden Sie unter [Gruppenreplikation](https://dev.mysql.com/doc/refman/8.0/en/group-replication.html) in der MySQL-Dokumentation. Die MySQL-Dokumentation enthält detaillierte Informationen zu dieser Funktion. In diesem Thema wird beschrieben, wie Sie das Plugin für die DB-Instances von RDS für MySQL konfigurieren und verwalten. **Anmerkung** Der Kürze halber beziehen sich alle Erwähnungen von „Aktiv/Aktiv“-Cluster in diesem Thema auf Aktiv/Aktiv-Cluster, die das MySQL-Gruppenreplikations-Plugin verwenden. ## Anwendungsfälle für Aktiv/Aktiv-Cluster Die folgenden Fälle eignen sich gut für die Verwendung von Aktiv/Aktiv-Clustern: + Anwendungen, die alle DB-Instances im Cluster benötigen, um Schreibvorgänge zu unterstützen. Das Gruppenreplikations-Plugin sorgt für Datenkonsistenz für jede DB-Instance im Aktiv/Aktiv-Cluster. Weitere Informationen zu dieser Funktionsweise finden Sie unter [Gruppenreplikation](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) in der MySQL-Dokumentation. + Anwendungen, die eine kontinuierliche Verfügbarkeit der Datenbank benötigen. Bei einem Aktiv/Aktiv-Cluster werden die Daten für alle DB-Instances im Cluster beibehalten. Wenn eine DB-Instance ausfällt, kann die Anwendung den Datenverkehr zu einer anderen DB-Instance im Cluster umleiten. + Anwendungen, die zwecks Lastenverteilung möglicherweise Lese- und Schreibvorgänge auf verschiedene DB-Instances im Cluster aufteilen müssen. Mit einem Aktiv/Aktiv-Cluster können die Anwendungen den Lesedatenverkehr an bestimmte DB-Instances und den Schreibdatenverkehr an andere senden. Sie können auch jederzeit ändern, an welche DB-Instances Lese- oder Schreibvorgänge gesendet werden sollen. **Topics** + [ ## Anwendungsfälle für Aktiv/Aktiv-Cluster ](#mysql-active-active-clusters-benefits) + [ # Einschränkungen und Überlegungen zu Aktiv/Aktiv-Clustern ](mysql-active-active-clusters-considerations-limitations.md) + [ # Vorbereitungen für einen VPC-übergreifenden Aktiv/Aktiv-Cluster ](mysql-active-active-clusters-cross-vpc-prerequisites.md) + [ # Erforderliche Parametereinstellungen für Aktiv/Aktiv-Cluster ](mysql-active-active-clusters-parameters.md) + [ # Konvertieren einer vorhandenen DB-Instance in einen Aktiv/Aktiv-Cluster ](mysql-active-active-clusters-converting.md) + [ # Einrichten eines Aktiv/Aktiv-Clusters mit neuen DB-Instances ](mysql-active-active-clusters-setting-up.md) + [ # Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster ](mysql-active-active-clusters-adding.md) + [ # Überwachen von Aktiv/Aktiv-Clustern ](mysql-active-active-clusters-monitoring.md) + [ # Beenden der Gruppenreplikation für eine DB-Instance in einem Aktiv/Aktiv-Cluster ](mysql-active-active-clusters-stopping.md) + [ # Umbenennen einer DB-Instance in einem Aktiv/Aktiv-Cluster ](mysql-active-active-clusters-renaming.md) + [ # Entfernen einer DB-Instance aus einem Aktiv/Aktiv-Cluster ](mysql-active-active-clusters-remove.md) # Einschränkungen und Überlegungen zu Aktiv/Aktiv-Clustern Aktiv/Aktiv-Cluster in Amazon RDS bieten verbesserte Verfügbarkeit und Skalierbarkeit, indem sie Workloads auf mehrere Instances verteilen. Bei der Verwendung dieser Architektur sind jedoch wichtige Einschränkungen und Faktoren zu beachten. In den folgenden Abschnitten werden wichtige Faktoren wie Replikationsverzögerungen, Konfliktlösung, Ressourcenzuweisung und Failover-Verhalten erläutert. Das Verständnis dieser Faktoren kann dazu beitragen, für eine optimale Leistung und Zuverlässigkeit bei der Bereitstellung von Aktiv/Aktiv-Clustern zu sorgen. **Topics** + [ ## Einschränkungen für Aktiv/Aktiv-Cluster von RDS für MySQL ](#mysql-active-active-clusters-limitations) + [ ## Überlegungen und bewährte Methoden für Aktiv/Aktiv-Cluster von RDS für MySQL ](#mysql-active-active-clusters-considerations) ## Einschränkungen für Aktiv/Aktiv-Cluster von RDS für MySQL Folgende Einschränkungen gelten für Aktiv/Aktiv-Cluster von RDS für MySQL: + Der Name des Masterbenutzers darf für DB-Instances in einem Aktiv/Aktiv-Cluster nicht `rdsgrprepladmin` sein. Dieser Benutzername ist für Gruppenreplikationsverbindungen reserviert. + Bei DB-Instances mit Lesereplikaten in Aktiv/Aktiv-Clustern kann ein anderer länger andauernder Replikationsstatus als `Replicating` dazu führen, dass Protokolldateien die Speicherlimits überschreiten. Weitere Informationen zum Status der Lesereplikate finden Sie unter [Überwachen der Lesereplikation](USER_ReadRepl.Monitoring.md). + Blau/Grün-Bereitstellungen werden für DB-Instances in einem Aktiv/Aktiv-Cluster nicht unterstützt. Weitere Informationen finden Sie unter [Verwenden von Amazon RDS Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md). + Die Kerberos-Authentifizierung wird für DB-Instances in einem Aktiv/Aktiv-Cluster nicht unterstützt. Weitere Informationen finden Sie unter [Verwenden der Kerberos-Authentifizierung von Amazon RDS für MySQL](mysql-kerberos.md). + Die DB-Instances in einem Multi-AZ-DB-Cluster können einem Aktiv/Aktiv-Cluster nicht hinzugefügt werden. Die DB-Instances in einer Bereitstellung von Multi-AZ-DB-Instances können jedoch einem Aktiv/Aktiv-Cluster hinzugefügt werden. Weitere Informationen finden Sie unter [Konfigurieren und Verwalten einer Multi-AZ-Bereitstellung für Amazon RDS](Concepts.MultiAZ.md). + Tabellen, die keinen Primärschlüssel haben, werden in einem Aktiv/Aktiv-Cluster nicht repliziert, da Schreibvorgänge vom Gruppenreplikations-Plugin abgelehnt werden. + Nicht-InnoDB-Tabellen werden in einem Aktiv/Aktiv-Cluster nicht repliziert. + Aktiv/Aktiv-Cluster unterstützen keine gleichzeitig stattfindenden DML- und DDL-Anweisungen auf verschiedenen DB-Instances im Cluster. + Sie können einen Aktiv/Aktiv-Cluster nicht so konfigurieren, dass er den Single-Primary-Modus für den Gruppenreplikationsmodus verwendet. Für diese Konfiguration empfehlen wir, stattdessen einen Multi-AZ-DB-Cluster zu verwenden. Weitere Informationen finden Sie unter [Bereitstellungen von Multi-AZ-DB-Clustern für Amazon RDS](multi-az-db-clusters-concepts.md). + Die Replikation mehrerer Quellen wird für DB-Instances in einem Aktiv/Aktiv-Cluster nicht unterstützt. + Ein regionsübergreifender Aktiv/Aktiv-Cluster kann die Überprüfung durch eine Zertifizierungsstelle (CA) für Gruppenreplikationsverbindungen nicht erzwingen. ## Überlegungen und bewährte Methoden für Aktiv/Aktiv-Cluster von RDS für MySQL Bevor Sie Aktiv/Aktiv-Cluster von RDS für MySQL verwenden, sollten Sie die folgenden Hinweise und bewährten Methoden lesen: + Aktiv/Aktiv-Cluster dürfen nicht mehr als neun DB-Instances enthalten. + Mit dem Gruppenreplikations-Plugin können Sie die Garantien für Transaktionskonsistenzen des Aktiv/Aktiv-Clusters steuern. Weitere Informationen finden Sie unter [Garantien für Transaktionskonsistenzen](https://dev.mysql.com/doc/refman/8.0/en/group-replication-consistency-guarantees.html) in der MySQL-Dokumentation. + Konflikte sind möglich, wenn verschiedene DB-Instances dieselbe Zeile in einem Aktiv/Aktiv-Cluster aktualisieren. Informationen zu Konflikten und zur Konfliktlösung finden Sie unter [Gruppenreplikation](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) in der MySQL-Dokumentation. + Zwecks Fehlertoleranz sollten die Aktiv/Aktiv-Cluster mindestens drei DB-Instances enthalten. Es ist möglich, einen Aktiv/Aktiv-Cluster mit nur einer oder zwei DB-Instances zu konfigurieren, der Cluster ist jedoch nicht fehlertolerant. Informationen zur Fehlertoleranz finden Sie unter [Fehlertoleranz](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html) in der MySQL-Dokumentation. + Wenn eine DB-Instance mit einem vorhandenen Aktiv/Aktiv-Cluster kombiniert wird und dieselbe Engine-Version wie die niedrigste Engine-Version im Cluster ausführt, wechselt die DB-Instance in den Lese-Schreibmodus. + Wenn eine DB-Instance mit einem vorhandenen Aktiv/Aktiv-Cluster kombiniert wird und eine höhere Engine-Version als die niedrigste Engine-Version im Cluster ausführt, muss die DB-Instance im schreibgeschützten Modus verbleiben. + Wenn Sie die Gruppenreplikation für eine DB-Instance aktivieren, indem Sie ihren `rds.group_replication_enabled` Parameter `1` in der DB-Parametergruppe auf setzen, die Replikation aber nicht gestartet wurde oder nicht gestartet werden konnte, wird die DB-Instance in den super-read-only Modus versetzt, um Dateninkonsistenzen zu vermeiden. Informationen zum super-read-only Modus finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). + Sie können eine DB-Instance in einem Aktiv/Aktiv-Cluster aktualisieren, die DB-Instance bleibt jedoch so lange schreibgeschützt, bis alle anderen DB-Instances im Aktiv/Aktiv-Cluster auf dieselbe Engine-Version oder eine höhere Engine-Version aktualisiert wurden. Wenn Sie eine DB-Instance aktualisieren, wird diese nach Abschluss des Upgrades automatisch mit demselben Aktiv/Aktiv-Cluster kombiniert. Um zu verhindern, dass eine DB-Instance unbeabsichtigt in den schreibgeschützten Modus wechselt, deaktivieren Sie für sie automatische Unterversions-Upgrades. Weitere Informationen über das Upgraden einer MySQL-DB-Instance finden Sie unter [Upgrades der DB-Engine von RDS für MySQL](USER_UpgradeDBInstance.MySQL.md). + Sie können eine DB-Instance in einer Multi-AZ-DB-Instance-Bereitstellung zu einem vorhandenen Aktiv/Aktiv-Cluster hinzufügen. Sie können auch eine Single-AZ-DB-Instance in einem Aktiv/Aktiv-Cluster in eine Multi-AZ-DB-Instance-Bereitstellung konvertieren. Wenn eine primäre DB-Instance in einer Multi-AZ-Bereitstellung ausfällt, wird für diese primäre Instance ein Failover auf die Standby-Instance ausgeführt. Die neue primäre DB-Instance wird nach Abschluss des Failovers automatisch mit demselben Cluster kombiniert. Weitere Informationen zu Multi-AZ-DB-Instance-Bereitstellungen finden Sie unter [Bereitstellungen von Multi-AZ-DB-Instances für Amazon RDS](Concepts.MultiAZSingleStandby.md). + Wir empfehlen, dass Sie für die DB-Instances in einem Aktiv/Aktiv-Cluster unterschiedliche Wartungsintervalle festlegen. So wird vermieden, dass mehrere DB-Instances im Cluster zwecks Wartung gleichzeitig offline geschaltet werden. Weitere Informationen finden Sie unter [Amazon-RDS-Wartungsfenster](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance). + Aktiv/Aktiv-Cluster können SSL für Verbindungen zwischen DB-Instances verwenden. Um SSL-Verbindungen zu konfigurieren, legen Sie die Parameter [group\$1replication\$1recovery\$1use\$1ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) und [group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) fest. Die Werte für diese Parameter müssen mit allen DB-Instances im Aktiv/Aktiv-Cluster übereinstimmen. Derzeit unterstützen Aktiv/Aktiv-Cluster für Verbindungen zwischen AWS-Regionen keine Überprüfung durch eine Zertifizierungsstelle (CA). Daher muss der Parameter [group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) auf `DISABLED` (Standardwert) oder für regionsübergreifende Cluster auf `REQUIRED` festgelegt werden. + Ein Aktiv/Aktiv-Cluster von RDS für MySQL wird im Multi-Primärmodus ausgeführt. Der Standardwert von [group\$1replication\$1enforce\$1update\$1everywhere\$1checks](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks) ist `ON` und der Parameter ist statisch. Wenn dieser Parameter auf `ON` festgelegt ist, können Anwendungen keine Daten in eine Tabelle einfügen, für die kaskadierende Fremdschlüsselbeschränkungen gelten. + Ein Aktiv/Aktiv-Cluster von RDS für MySQL verwendet für die Verbindungssicherheit anstatt von XCOM den MySQL-Kommunikationsstack. Weitere Informationen finden Sie unter [Kommunikationsstack zur Verwaltung der Verbindungssicherheit](https://dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html) in der MySQL-Dokumentation. + Wenn eine DB-Parametergruppe mit einer DB-Instance in einem Aktiv/Aktiv-Cluster verknüpft ist, empfehlen wir, diese DB-Parametergruppe nur anderen DB-Instances zuzuordnen, die sich im Cluster befinden. + Aktiv/Aktiv-Cluster unterstützen nur DB-Instances von RDS für MySQL. Auf diesen DB-Instances müssen unterstützte DB-Engine-Versionen ausgeführt werden. + Wenn bei einer DB-Instance in einem Aktiv/Aktiv-Cluster unerwartet ein Fehler auftritt, führt RDS automatisch eine Wiederherstellung der DB-Instance durch. Wenn die DB-Instance nicht wiederhergestellt werden kann, empfehlen wir, sie durch eine neue DB-Instance zu ersetzen, indem Sie eine point-in-time Wiederherstellung mit einer fehlerfreien DB-Instance im Cluster durchführen. Detaillierte Anweisungen finden Sie unter [Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster mithilfe von zeitpunktbezogener Wiederherstellung](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). + Sie können eine DB-Instance in einem Aktiv/Aktiv-Cluster löschen, ohne dass dies Auswirkungen auf die anderen DB-Instances im Cluster hat. Weitere Informationen zum Löschen einer DB-Instance finden Sie unter [Löschen einer DB-Instance](USER_DeleteInstance.md). + Wenn eine DB-Instance unbeabsichtigt aus einem Aktiv/Aktiv-Cluster ausgeschlossen wird, ändert sich der Parameter `group_replication_exit_state_action` standardmäßig in `OFFLINE_MODE`. In diesem Status ist der Zugriff auf die DB-Instance nicht möglich und Sie müssen die DB-Instance neu starten, um sie wieder online zu schalten und dem Cluster wieder hinzuzufügen. Sie können dieses Verhalten ändern, indem Sie den Parameter `group_replication_exit_state_action` in einer benutzerdefinierten Parametergruppe modifizieren. Durch Festlegen des Parameters auf `READ_ONLY` wechselt die DB-Instance, wenn sie versehentlich aus einem Cluster ausgeschlossen wird, in einen Super-Read-Only-Status, anstatt offline zu schalten. # Vorbereitungen für einen VPC-übergreifenden Aktiv/Aktiv-Cluster Sie können einen Aktiv/Aktiv-Cluster mit DB-Instances von Amazon RDS für MySQL in mehr als einer VPC konfigurieren. Sie VPCs können gleich AWS-Region oder unterschiedlich sein AWS-Regionen. **Anmerkung** Das Senden von Datenverkehr zwischen mehreren AWS-Regionen kann zusätzliche Kosten verursachen. Weitere Informationen finden Sie unter [Überblick über die Datenübertragungskosten für gängige Architekturen](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/). Wenn Sie einen Aktiv/Aktiv-Cluster in einer einzelnen VPC konfigurieren, können Sie diese Schritte überspringen und mit [Einrichten eines Aktiv/Aktiv-Clusters mit neuen DB-Instances](mysql-active-active-clusters-setting-up.md) fortfahren. **So treffen Sie Vorbereitungen für einen Aktiv/Aktiv-Cluster mit DB-Instances in mehr als einer VPC** 1. Stellen Sie sicher, dass die IPv4 Adressbereiche in den CIDR-Blöcken die folgenden Anforderungen erfüllen: + Die IPv4 Adressbereiche in den CIDR-Blöcken von VPCs dürfen sich nicht überschneiden. + Alle IPv4 Adressbereiche in den CIDR-Blöcken müssen entweder niedriger `128.0.0.0/subnet_mask` oder höher als 128.0.0.0/ sein. *subnet\$1mask* Die folgenden Bereiche veranschaulichen diese Anforderungen: + Unterstützt werden `10.1.0.0/16` in einer VPC und `10.2.0.0/16` in der anderen VPC. + Unterstützt werden `172.1.0.0/16` in einer VPC und `172.2.0.0/16` in der anderen VPC. + `10.1.0.0/16` in einer VPC und `10.1.0.0/16` in der anderen VPC wird *nicht* unterstützt, da sich die Bereiche überschneiden. + `10.1.0.0/16` in einer VPC und `172.1.0.0/16` in der anderen VPC wird *nicht* unterstützt, da ein Bereich niedriger als `128.0.0.0/subnet_mask` und der andere Bereich höher als `128.0.0.0/subnet_mask` ist. Informationen zu CIDR-Blöcken finden Sie unter [VPC-CIDR-Blöcke](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) im *Amazon-VPC-Benutzerhandbuch*. 1. Vergewissern Sie sich, dass sowohl die DNS-Auflösung als auch DNS-Hostnamen für die jeweilige VPC aktiviert sind. Anweisungen dazu finden Sie unter [Anzeigen und Aktualisieren von DNS-Attributen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) im *Amazon-VPC-Benutzerhandbuch*. 1. Konfigurieren Sie die VPCs so, dass Sie den Verkehr zwischen ihnen auf eine der folgenden Arten weiterleiten können: + Erstellen Sie eine VPC-Peering-Verbindung zwischen den. VPCs Anweisungen dazu finden Sie unter [Erstellen einer VPC-Peering-Verbindung](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) im *Handbuch zu Amazon VPC Peering*. Vergewissern Sie sich bei der jeweiligen VPC, dass es eingehende Regeln für die Sicherheitsgruppen gibt, die auf Sicherheitsgruppen in der per Peering verbundenen VPC verweisen. Danach kann der Datenverkehr von und zu den Instances fließen, die der referenzierten Sicherheitsgruppe in der über Peering verbundenen VPC zugewiesen sind. Anweisungen dazu finden Sie unter [Aktualisieren Ihrer Sicherheitsgruppen, um auf Peer-Sicherheitsgruppen zu verweisen](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html) im *Handbuch zu Amazon VPC Peering*. + Erstellen Sie ein Transit-Gateway zwischen den. VPCs Anweisungen dazu finden Sie unter [Erste Schritte mit Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) im *Handbuch zu Amazon VPC Transit Gateways*. Vergewissern Sie sich bei der jeweiligen VPC, dass es eingehende Regeln für die Sicherheitsgruppen gibt, die Datenverkehr von der anderen VPC zulassen, z. B. eingehende Regeln, die den CIDR-Block der anderen VPC festlegen. Dadurch kann der Datenverkehr von und zu den Instances fließen, die mit der referenzierten Sicherheitsgruppe im Aktiv/Aktiv-Cluster verknüpft sind. Weitere Informationen finden Sie unter [Steuern des Datenverkehrs zu Ihren AWS Ressourcen mithilfe von Sicherheitsgruppen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#working-with-security-groups) im *Amazon VPC-Benutzerhandbuch*. # Erforderliche Parametereinstellungen für Aktiv/Aktiv-Cluster Die Konfiguration von Parametern für Aktiv/Aktiv-Cluster in Amazon RDS für MySQL ist für die Aufrechterhaltung einer konsistenten Leistung und der Betriebsstabilität unerlässlich. In dieser Tabelle sind die wichtigsten Parameter aufgeführt, mit denen die Replikation, Konfliktlösung und Verteilung von Workloads gesteuert werden. Eine ordnungsgemäße Konfiguration sorgt für eine effiziente Synchronisation zwischen den Knoten, minimiert die Replikationsverzögerung und optimiert die Ressourcennutzung in dezentralisierten Umgebungen oder Umgebungen mit hohem Datenverkehrsaufkommen. | Parameter | Beschreibung | Erforderliche Einstellung | | --- | --- | --- | | `binlog_format` | Legt das binäre Protokollformat fest. Der Standardwert für Versionen von RDS für MySQL 8.0 und niedriger ist `MIXED`. Der Standardwert für Versionen von RDS für MySQL 8.4 ist `ROW`. Weitere Informationen finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format). | `ROW` | | `enforce_gtid_consistency` | Erzwingt die GTID-Konsistenz für die Ausführung von Anweisungen. Der Standardwert für RDS für MySQL lautet `OFF`. Weitere Informationen finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_enforce_gtid_consistency). | `ON` | | `group_replication_group_name` | Legt den Namen der Gruppenreplikation auf eine UUID fest. Das UUID-Format ist `11111111-2222-3333-4444-555555555555`. Sie können eine MySQL-UUID generieren, indem Sie eine Verbindung mit einer MySQL-DB-Instance herstellen und `SELECT UUID()` ausführen. Der Wert muss für alle DB-Instances im Aktiv/Aktiv-Cluster identisch sein. Weitere Informationen finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid). | A MySQL UUID | | `gtid-mode` | Steuert die GTID-basierte Protokollierung. Der Standardwert für RDS für MySQL lautet `OFF_PERMISSIVE`. Weitere Informationen finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_mode). | `ON` | | `rds.custom_dns_resolution` | Legt fest, ob die DNS-Auflösung vom Amazon-DNS-Server in der VPC zulässig sein soll. Die DNS-Auflösung muss aktiviert sein, wenn die Gruppenreplikation mit dem Parameter `rds.group_replication_enabled` aktiviert wurde. Die DNS-Auflösung kann nicht aktiviert werden, wenn die Gruppenreplikation mit dem Parameter `rds.group_replication_enabled` deaktiviert wurde. Weitere Informationen finden Sie unter [Amazon-DNS-Server](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#AmazonDNS) im *Amazon-VPC-Benutzerhandbuch*. | `1` | | `rds.group_replication_enabled` | Legt fest, ob die Gruppenreplikation für eine DB-Instance aktiviert werden soll. Die Gruppenreplikation muss für eine DB-Instance in einem Aktiv/Aktiv-Cluster aktiviert sein. | `1` | | `replica_preserve_commit_order` (RDS für MySQL 8.4 und höhere Versionen) oder `slave_preserve_commit_order` (Versionen von RDS für MySQL 8.0) | Steuert die Reihenfolge, in der Transaktionen auf einem Replikat festgeschrieben werden. Der Standardwert für RDS für MySQL lautet `ON`. Weitere Informationen finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvar_slave_preserve_commit_order). | `ON` | # Konvertieren einer vorhandenen DB-Instance in einen Aktiv/Aktiv-Cluster Die DB-Engine-Version der DB-Instance, die Sie zu einem Aktiv/Aktiv-Cluster migrieren möchten, muss eine der folgenden Versionen sein: + Alle MySQL 8.4-Versionen + MySQL 8.0.35 und höhere Unterversionen Informationen zum Upgrade der Engine-Version finden Sie unter [Upgrades der DB-Engine von RDS für MySQL](USER_UpgradeDBInstance.MySQL.md). Wenn Sie einen Aktiv/Aktiv-Cluster mit DB-Instances in mehr als einer VPC einrichten, vergewissern Sie sich, dass die unter [Vorbereitungen für einen VPC-übergreifenden Aktiv/Aktiv-Cluster](mysql-active-active-clusters-cross-vpc-prerequisites.md) angegebenen Voraussetzungen erfüllt sind. Führen Sie die folgenden Schritte aus, um eine vorhandene DB-Instance zu einem Aktiv/Aktiv-Cluster von RDS für MySQL zu migrieren. **Topics** + [ ## Schritt 1: Festlegen des Parameters für den Aktiv/Aktiv-Cluster in einer oder mehreren benutzerdefinierten Parametergruppen ](#mysql-active-active-clusters-converting-parameter-group) + [ ## Schritt 2: Zuordnen der DB-Instance zu einer DB-Parametergruppe, für die die erforderlichen Gruppenreplikationsparameter festgelegt wurden ](#mysql-active-active-clusters-converting-associate-parameter-group) + [ ## Schritt 3: Erstellen des Aktiv/Aktiv-Clusters ](#mysql-active-active-clusters-converting-associate-parameter-groups) + [ ## Schritt 4: Erstellen von zusätzlichen DB-Instances von RDS für MySQL für den Aktiv/Aktiv-Cluster ](#mysql-active-active-clusters-converting-add-db-instances) + [ ## Schritt 5: Initialisieren der Gruppe auf der konvertierten DB-Instance ](#mysql-active-active-clusters-converting-start-replication-first) + [ ## Schritt 6: Starten der Replikation auf den anderen DB-Instances im Aktiv/Aktiv-Cluster ](#mysql-active-active-clusters-converting-start-replication-other) + [ ## Schritt 7: Überprüfen des Status des Aktiv/Aktiv-Clusters (empfohlen) ](#mysql-active-active-clusters-converting-view) ## Schritt 1: Festlegen des Parameters für den Aktiv/Aktiv-Cluster in einer oder mehreren benutzerdefinierten Parametergruppen Die DB-Instances von RDS für MySQL in einem Aktiv/Aktiv-Cluster müssen einer benutzerdefinierten Parametergruppe zugeordnet werden, die über die entsprechende Einstellung für die erforderlichen Parameter verfügt. Informationen zu den Parametern und ihren jeweiligen erforderlichen Einstellungen finden Sie unter [Erforderliche Parametereinstellungen für Aktiv/Aktiv-Cluster](mysql-active-active-clusters-parameters.md). Sie können diese Parameter in neuen oder vorhandenen Parametergruppen festlegen. Um jedoch zu verhindern, dass hierdurch versehentlich DB-Instances beeinträchtigt werden, die nicht zum Aktiv/Aktiv-Cluster gehören, empfehlen wir dringend, eine neue benutzerdefinierte Parametergruppe zu erstellen. Die DB-Instances in einem Aktiv/Aktiv-Cluster können derselben DB-Parametergruppe oder unterschiedlichen DB-Parametergruppen zugeordnet werden. Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um eine neue benutzerdefinierte Parametergruppe zu erstellen. Weitere Informationen finden Sie unter [Erstellen einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). Im folgenden Beispiel wird der [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI Befehl ausgeführt, um eine benutzerdefinierte DB-Parametergruppe mit dem Namen RDS `myactivepg` for MySQL 8.0 zu erstellen: Für Linux, macOS oder Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Für Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` Sie können auch das AWS-Managementkonsole oder das verwenden AWS CLI , um die Parameter in der benutzerdefinierten Parametergruppe festzulegen. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Im folgenden Beispiel wird der [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI Befehl ausgeführt, um die Parameter für RDS for MySQL 8.0 festzulegen. Um dieses Beispiel mit RDS für MySQL 8.4 zu verwenden, ändern Sie `slave_preserve_commit_order` in `replica_preserve_commit_order`. Für Linux, macOS oder Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Schritt 2: Zuordnen der DB-Instance zu einer DB-Parametergruppe, für die die erforderlichen Gruppenreplikationsparameter festgelegt wurden Ordnen Sie die DB-Instance einer Parametergruppe zu, die Sie im vorherigen Schritt erstellt oder geändert haben. Detaillierte Anweisungen finden Sie unter [Verknüpfen einer DB-Parametergruppe mit einer DB-Instance in Amazon RDS](USER_WorkingWithParamGroups.Associating.md). Starten Sie die DB-Instance neu, damit die neuen Parametereinstellungen wirksam werden. Detaillierte Anweisungen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). ## Schritt 3: Erstellen des Aktiv/Aktiv-Clusters Legen Sie den Parameter `group_replication_group_seeds` in der DB-Parametergruppe, die mit der DB-Instance verknüpft ist, auf den Endpunkt der konvertierten DB-Instance fest. Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um den Parameter festzulegen. Sie müssen die DB-Instance nicht neu starten, nachdem Sie diesen Parameter festgelegt haben. Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Im folgenden Beispiel wird der [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI Befehl ausgeführt, um die Parameter festzulegen: Für Linux, macOS oder Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` ## Schritt 4: Erstellen von zusätzlichen DB-Instances von RDS für MySQL für den Aktiv/Aktiv-Cluster Um zusätzliche DB-Instances für den Active-Active-Cluster zu erstellen, führen Sie eine point-in-time Wiederherstellung auf der DB-Instance durch, die Sie konvertieren. Detaillierte Anweisungen finden Sie unter [Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster mithilfe von zeitpunktbezogener Wiederherstellung](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). Ein Aktiv/Aktiv-Cluster kann bis zu neun DB-Instances enthalten. Führen Sie die point-in-time Wiederherstellung auf der DB-Instance durch, bis Sie die Anzahl der DB-Instances haben, die Sie für den Cluster benötigen. Stellen Sie bei der Ausführung sicher point-in-recovery, dass Sie die DB-Instance, die Sie hinzufügen, einer DB-Parametergruppe zuordnen, für die der Wert auf `rds.group_replication_enabled` festgelegt ist`1`. Andernfalls wird die Gruppenreplikation auf der neu hinzugefügten DB-Instance nicht gestartet. ## Schritt 5: Initialisieren der Gruppe auf der konvertierten DB-Instance Initialisieren Sie die Gruppe und starten Sie die Replikation: 1. Stellen Sie für einen SQL-Client eine Verbindung mit der konvertierten DB-Instance her. Weitere Informationen zum Herstellen einer Verbindung mit einer DB-Instance von RDS für MySQL finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). 1. Führen Sie im SQL-Client die folgenden gespeicherten Prozeduren aus und *group\$1replication\$1user\$1password* ersetzen Sie sie durch das Kennwort für den `rdsgrprepladmin` Benutzer. Der Benutzer `rdsgrprepladmin` ist für Gruppenreplikationsverbindungen in einem Aktiv/Aktiv-Cluster reserviert. Das Passwort für diesen Benutzer muss auf allen DB-Instances in einem Aktiv/Aktiv-Cluster identisch sein. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` In diesem Beispiel wird der Wert `binlog retention hours` auf `168` festgelegt, was bedeutet, dass Binärprotokolldateien sieben Tage lang auf der DB-Instance beibehalten werden. Sie können diesen Wert an Ihre Anforderungen anpassen. In diesem Beispiel wird `1` in der gespeicherten Prozedur `mysql.rds_group_replication_start` festgelegt, um eine neue Gruppe mit der aktuellen DB-Instance zu initialisieren. Weitere Informationen zu den im Beispiel aufgerufenen gespeicherten Prozeduren finden Sie unter [Verwalten von Aktiv/Aktiv-Clustern](mysql-stored-proc-active-active-clusters.md). ## Schritt 6: Starten der Replikation auf den anderen DB-Instances im Aktiv/Aktiv-Cluster Verwenden Sie für alle DB-Instances im Aktiv/Aktiv-Cluster einen SQL-Client, um eine Verbindung mit der Instance herzustellen, und führen Sie die folgenden gespeicherten Prozeduren aus. *group\$1replication\$1user\$1password*Ersetzen Sie es durch das Passwort für den `rdsgrprepladmin` Benutzer. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` In diesem Beispiel wird der Wert `binlog retention hours` auf `168` festgelegt, was bedeutet, dass Binärprotokolldateien sieben Tage lang auf der jeweiligen DB-Instance beibehalten werden. Sie können diesen Wert an Ihre Anforderungen anpassen. In diesem Beispiel wird `0` in der gespeicherten Prozedur `mysql.rds_group_replication_start` festgelegt, um die aktuelle DB-Instance einer vorhandenen Gruppe hinzuzufügen. **Tipp** Achten Sie darauf, dass Sie diese gespeicherten Prozeduren auf allen anderen DB-Instances im Aktiv/Aktiv-Cluster ausführen. ## Schritt 7: Überprüfen des Status des Aktiv/Aktiv-Clusters (empfohlen) Um sich zu vergewissern, dass jedes Mitglied des Clusters korrekt konfiguriert ist, überprüfen Sie den Status des Clusters, indem Sie eine Verbindung mit einer DB-Instance im Aktiv/Aktiv-Cluster herstellen und den folgenden SQL-Befehl ausführen: ``` SELECT * FROM performance_schema.replication_group_members; ``` Für die Ausgabe sollte `ONLINE` für `MEMBER_STATE` der jeweiligen DB-Instance wie in der folgenden Beispielausgabe angezeigt werden: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Informationen zu den möglichen `MEMBER_STATE`-Werten finden Sie unter [Gruppenreplikations-Serverstatus](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) in der MySQL-Dokumentation. # Einrichten eines Aktiv/Aktiv-Clusters mit neuen DB-Instances Führen Sie die folgenden Schritte aus, um einen Aktiv/Aktiv-Cluster einzurichten, der die neuen DB-Instances von Amazon RDS für MySQL verwendet. Wenn Sie einen Aktiv/Aktiv-Cluster mit DB-Instances in mehr als einer VPC einrichten, vergewissern Sie sich, dass die unter [Vorbereitungen für einen VPC-übergreifenden Aktiv/Aktiv-Cluster](mysql-active-active-clusters-cross-vpc-prerequisites.md) angegebenen Voraussetzungen erfüllt sind. **Topics** + [ ## Schritt 1: Festlegen des Parameters für den Aktiv/Aktiv-Cluster in einer oder mehreren benutzerdefinierten Parametergruppen ](#mysql-active-active-clusters-setting-up-parameter-group) + [ ## Schritt 2: Erstellen der neuen DB-Instances von RDS für MySQL für den Aktiv/Aktiv-Cluster ](#mysql-active-active-clusters-setting-up-db-instances) + [ ## Schritt 3: Festlegen der DB-Instances im Aktiv/Aktiv-Cluster ](#mysql-active-active-clusters-setting-up-associate-parameter-groups) + [ ## Schritt 4: Initialisieren der Gruppe für eine DB-Instance und Starten der Replikation ](#mysql-active-active-clusters-setting-up-start-replication-first) + [ ## Schritt 5: Starten der Replikation auf den anderen DB-Instances im Aktiv/Aktiv-Cluster ](#mysql-active-active-clusters-setting-up-start-replication-other) + [ ## Schritt 6: Überprüfen des Status des Aktiv/Aktiv-Clusters (empfohlen) ](#mysql-active-active-clusters-setting-up-view) + [ ## Schritt 7: Importieren von Daten in eine DB-Instance im Aktiv/Aktiv-Cluster (optional) ](#mysql-active-active-clusters-import) ## Schritt 1: Festlegen des Parameters für den Aktiv/Aktiv-Cluster in einer oder mehreren benutzerdefinierten Parametergruppen Die DB-Instances von RDS für MySQL in einem Aktiv/Aktiv-Cluster müssen einer benutzerdefinierten Parametergruppe zugeordnet werden, die über die entsprechende Einstellung für die erforderlichen Parameter verfügt. Informationen zu den Parametern und ihren jeweiligen erforderlichen Einstellungen finden Sie unter [Erforderliche Parametereinstellungen für Aktiv/Aktiv-Cluster](mysql-active-active-clusters-parameters.md). Sie können diese Parameter in neuen oder vorhandenen Parametergruppen festlegen. Um jedoch zu verhindern, dass hierdurch versehentlich DB-Instances beeinträchtigt werden, die nicht zum Aktiv/Aktiv-Cluster gehören, empfehlen wir dringend, eine neue benutzerdefinierte Parametergruppe zu erstellen. Die DB-Instances in einem Aktiv/Aktiv-Cluster können derselben DB-Parametergruppe oder unterschiedlichen DB-Parametergruppen zugeordnet werden. Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um eine neue benutzerdefinierte Parametergruppe zu erstellen. Weitere Informationen finden Sie unter [Erstellen einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). Im folgenden Beispiel wird der [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI Befehl ausgeführt, um eine benutzerdefinierte DB-Parametergruppe mit dem Namen RDS `myactivepg` for MySQL 8.0 zu erstellen: Für Linux, macOS oder Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Für Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` Sie können auch das AWS-Managementkonsole oder das verwenden AWS CLI , um die Parameter in der benutzerdefinierten Parametergruppe festzulegen. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Im folgenden Beispiel wird der [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI Befehl ausgeführt, um die Parameter für RDS for MySQL 8.0 festzulegen. Um dieses Beispiel mit RDS für MySQL 8.4 zu verwenden, ändern Sie `slave_preserve_commit_order` in `replica_preserve_commit_order`. Für Linux, macOS oder Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Schritt 2: Erstellen der neuen DB-Instances von RDS für MySQL für den Aktiv/Aktiv-Cluster Aktiv/Aktiv-Cluster werden für die DB-Instances mit den folgenden Versionen von RDS für MySQL unterstützt: + Alle MySQL 8.4-Versionen + MySQL Version 8.0.35 und höhere Unterversionen Sie können bis zu neun neue DB-Instances für den Cluster erstellen. Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um neue DB-Instances zu erstellen. Weitere Informationen zum Erstellen einer DB-Instance finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md). Wenn Sie die DB-Instance erstellen, ordnen Sie sie einer DB-Parametergruppe zu, die Sie im vorherigen Schritt erstellt oder geändert haben. ## Schritt 3: Festlegen der DB-Instances im Aktiv/Aktiv-Cluster Legen Sie den Parameter `group_replication_group_seeds` in der DB-Parametergruppe, die mit der jeweiligen DB-Instance verknüpft ist, auf die Endpunkte der DB-Instances fest, die Sie in den Cluster aufnehmen möchten. Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um den Parameter festzulegen. Sie müssen die DB-Instance nicht neu starten, nachdem Sie diesen Parameter festgelegt haben. Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Im folgenden Beispiel wird der [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI Befehl ausgeführt, um die Parameter festzulegen: Für Linux, macOS oder Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` **Tipp** Achten Sie darauf, den Parameter `group_replication_group_seeds` in der jeweiligen DB-Parametergruppe zu ändern, die einer DB-Instance im Aktiv/Aktiv-Cluster zugeordnet ist. ## Schritt 4: Initialisieren der Gruppe für eine DB-Instance und Starten der Replikation Sie können eine beliebige neue DB-Instance auswählen, um die Gruppe zu initialisieren und die Replikation zu starten. Führen Sie dazu die folgenden Schritte aus: 1. Wählen Sie eine DB-Instance im Aktiv/Aktiv-Cluster aus und stellen Sie eine Verbindung mit dieser DB-Instance in einem SQL-Client her. Weitere Informationen zum Herstellen einer Verbindung mit einer DB-Instance von RDS für MySQL finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). 1. Führen Sie im SQL-Client die folgenden gespeicherten Prozeduren aus und *group\$1replication\$1user\$1password* ersetzen Sie sie durch das Kennwort für den `rdsgrprepladmin` Benutzer. Der Benutzer `rdsgrprepladmin` ist für Gruppenreplikationsverbindungen in einem Aktiv/Aktiv-Cluster reserviert. Das Passwort für diesen Benutzer muss auf allen DB-Instances in einem Aktiv/Aktiv-Cluster identisch sein. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` In diesem Beispiel wird der Wert `binlog retention hours` auf `168` festgelegt, was bedeutet, dass Binärprotokolldateien sieben Tage lang auf der DB-Instance beibehalten werden. Sie können diesen Wert an Ihre Anforderungen anpassen. In diesem Beispiel wird `1` in der gespeicherten Prozedur `mysql.rds_group_replication_start` festgelegt, um eine neue Gruppe mit der aktuellen DB-Instance zu initialisieren. Weitere Informationen zu den im Beispiel aufgerufenen gespeicherten Prozeduren finden Sie unter [Verwalten von Aktiv/Aktiv-Clustern](mysql-stored-proc-active-active-clusters.md). ## Schritt 5: Starten der Replikation auf den anderen DB-Instances im Aktiv/Aktiv-Cluster Verwenden Sie für alle DB-Instances im Aktiv/Aktiv-Cluster einen SQL-Client, um eine Verbindung mit der Instance herzustellen, und führen Sie die folgenden gespeicherten Prozeduren aus. *group\$1replication\$1user\$1password*Ersetzen Sie es durch das Passwort für den `rdsgrprepladmin` Benutzer. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` In diesem Beispiel wird der Wert `binlog retention hours` auf `168` festgelegt, was bedeutet, dass Binärprotokolldateien sieben Tage lang auf der jeweiligen DB-Instance beibehalten werden. Sie können diesen Wert an Ihre Anforderungen anpassen. In diesem Beispiel wird `0` in der gespeicherten Prozedur `mysql.rds_group_replication_start` festgelegt, um die aktuelle DB-Instance einer vorhandenen Gruppe hinzuzufügen. **Tipp** Achten Sie darauf, dass Sie diese gespeicherten Prozeduren auf allen anderen DB-Instances im Aktiv/Aktiv-Cluster ausführen. ## Schritt 6: Überprüfen des Status des Aktiv/Aktiv-Clusters (empfohlen) Um sich zu vergewissern, dass jedes Mitglied des Clusters korrekt konfiguriert ist, überprüfen Sie den Status des Clusters, indem Sie eine Verbindung mit einer DB-Instance im Aktiv/Aktiv-Cluster herstellen und den folgenden SQL-Befehl ausführen: ``` SELECT * FROM performance_schema.replication_group_members; ``` Für die Ausgabe sollte `ONLINE` für `MEMBER_STATE` der jeweiligen DB-Instance wie in der folgenden Beispielausgabe angezeigt werden: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Informationen zu den möglichen `MEMBER_STATE`-Werten finden Sie unter [Gruppenreplikations-Serverstatus](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) in der MySQL-Dokumentation. ## Schritt 7: Importieren von Daten in eine DB-Instance im Aktiv/Aktiv-Cluster (optional) Sie können Daten von einer MySQL-Datenbank in eine DB-Instance im Aktiv/Aktiv-Cluster importieren. Nach dem Import der Daten werden sie von der Gruppenreplikation auf die anderen DB-Instances im Cluster repliziert. Weitere Informationen zum Importieren von Daten finden Sie unter [Importieren von Daten in eine Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-importing-data-reduced-downtime.md). # Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster Sie können eine DB-Instance zu einem Aktiv/Aktiv-Cluster von Amazon RDS für MySQL hinzufügen, indem Sie einen DB-Snapshot oder eine DB-Instance auf einen bestimmten Zeitpunkt wiederherstellen. Ein Aktiv/Aktiv-Cluster kann bis zu neun DB-Instances enthalten. Wenn Sie eine DB-Instance auf einen bestimmten Zeitpunkt wiederherstellen, umfasst sie in der Regel neuere Transaktionen als eine DB-Instance, die anhand eines DB-Snapshots wiederhergestellt wurde. Wenn die DB-Instance über neuere Transaktionen verfügt, müssen zu Beginn der Replikation weniger Transaktionen angewendet werden. Daher ist eine zeitpunktbezogene Wiederherstellung zum Hinzufügen einer DB-Instance zu einem Cluster in der Regel schneller als die Wiederherstellung anhand eines DB-Snapshots. **Topics** + [ ## Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster mithilfe von zeitpunktbezogener Wiederherstellung ](#mysql-active-active-clusters-adding-pitr) + [ ## Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster mithilfe eines DB-Snapshots ](#mysql-active-active-clusters-adding-snapshot) ## Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster mithilfe von zeitpunktbezogener Wiederherstellung Sie können einem Aktiv/Aktiv-Cluster eine DB-Instance hinzufügen, indem Sie eine zeitpunktbezogene Wiederherstellung für eine DB-Instance im Cluster durchführen. Informationen zum Wiederherstellen einer DB-Instance auf einen Zeitpunkt in einer anderen AWS-Region finden Sie unter [Automatisierte Backups auf ein anderes replizieren AWS-Region](USER_ReplicateBackups.md). **So fügen Sie eine DB-Instance mithilfe von zeitpunktbezogener Wiederherstellung einem Aktiv/Aktiv-Cluster hinzu** 1. Erstellen Sie eine neue DB-Instance, indem Sie eine zeitpunktbezogene Wiederherstellung für eine DB-Instance im Aktiv/Aktiv-Cluster durchführen. Sie können eine zeitpunktbezogene Wiederherstellung für beliebige DB-Instances im Cluster durchführen, um die neue DB-Instance zu erstellen. Detaillierte Anweisungen finden Sie unter [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md). **Wichtig** Ordnen Sie während der zeitpunktbezogenen Wiederherstellung die neue DB-Instance einer DB-Parametergruppe zu, für die die Parameter der Aktiv/Aktiv-Cluster festgelegt wurden. Andernfalls wird die Gruppenreplikation für die neue DB-Instance nicht gestartet. Informationen zu den Parametern und ihren jeweiligen erforderlichen Einstellungen finden Sie unter [Erforderliche Parametereinstellungen für Aktiv/Aktiv-Cluster](mysql-active-active-clusters-parameters.md). **Tipp** Wenn Sie vor dem Starten der zeitpunktbezogenen Wiederherstellung einen Snapshot der DB-Instance erstellen, können Sie möglicherweise die Zeitdauer reduzieren, die für die Anwendung von Transaktionen auf die neue DB-Instance erforderlich ist. 1. Fügen Sie die DB-Instance dem `group_replication_group_seeds` Parameter in der jeweiligen DB-Parametergruppe hinzu, die mit einer DB-Instance im Aktiv/Aktiv-Cluster verknüpft ist, darunter auch die DB-Parametergruppe, die Sie der neuen DB-Instance zugeordnet haben. Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Stellen Sie in einem SQL-Client eine Verbindung mit der neuen DB-Instance her und rufen Sie die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel) auf. Ersetzen Sie *group\$1replication\$1user\$1password* durch das Passwort für den Benutzer `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Rufen Sie mithilfe des SQL-Clients die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) auf, um die Replikation zu starten: ``` call mysql.rds_group_replication_start(0); ``` ## Hinzufügen einer DB-Instance zu einem Aktiv/Aktiv-Cluster mithilfe eines DB-Snapshots Sie können einem Aktiv/Aktiv-Cluster eine DB-Instance hinzufügen, indem Sie einen DB-Snapshot einer DB-Instance im Cluster erstellen und dann den DB-Snapshot wiederherstellen. Informationen zum Kopieren eines Snapshots in eine andere AWS-Region finden Sie unter [Überlegungen zum regionsübergreifenden Kopieren von Snapshots](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions). **So fügen Sie eine DB-Instance mithilfe eines DB-Snapshots einem Aktiv/Aktiv-Cluster hinzu** 1. Erstellen Sie einen DB-Snapshot einer DB-Instance im Aktiv/Aktiv-Cluster. Sie können einen DB-Snapshot einer beliebigen DB-Instance im Cluster erstellen. Detaillierte Anweisungen finden Sie unter [Erstellen eines DB-Snapshots für eine DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md). 1. Stellen Sie eine DB-Instance anhand eines DB-Snapshots wieder her. Ordnen Sie während der Snapshot-Wiederherstellung die neue DB-Instance einer DB-Parametergruppe zu, für die die Parameter der Aktiv/Aktiv-Cluster festgelegt wurden. Informationen zu den Parametern und ihren jeweiligen erforderlichen Einstellungen finden Sie unter [Erforderliche Parametereinstellungen für Aktiv/Aktiv-Cluster](mysql-active-active-clusters-parameters.md). Informationen zum Wiederherstellen einer DB-Instance anhand eines DB-Snapshots finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md). 1. Fügen Sie die DB-Instance dem `group_replication_group_seeds` Parameter in der jeweiligen DB-Parametergruppe hinzu, die mit einer DB-Instance im Aktiv/Aktiv-Cluster verknüpft ist, darunter auch die DB-Parametergruppe, die Sie der neuen DB-Instance zugeordnet haben. Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Stellen Sie in einem SQL-Client eine Verbindung mit der neuen DB-Instance her und rufen Sie die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel) auf. Ersetzen Sie *group\$1replication\$1user\$1password* durch das Passwort für den Benutzer `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Rufen Sie mithilfe des SQL-Clients die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) auf, um die Replikation zu starten: ``` call mysql.rds_group_replication_start(0); ``` # Überwachen von Aktiv/Aktiv-Clustern Die Überwachung von Aktiv/Aktiv-Clustern in Amazon RDS für MySQL ist entscheidend für die Verfolgung der Leistung, Replikationsintegrität und Knotensynchronisierung. Sie können den Aktiv/Aktiv-Cluster überwachen, indem Sie eine Verbindung mit einer DB-Instance im Cluster herstellen und den folgenden SQL-Befehl ausführen: ``` SELECT * FROM performance_schema.replication_group_members; ``` Für die Ausgabe sollte `ONLINE` für `MEMBER_STATE` der jeweiligen DB-Instance wie in der folgenden Beispielausgabe angezeigt werden: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Informationen zu den möglichen `MEMBER_STATE`-Werten finden Sie unter [Gruppenreplikations-Serverstatus](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) in der MySQL-Dokumentation. # Beenden der Gruppenreplikation für eine DB-Instance in einem Aktiv/Aktiv-Cluster Sie können die Gruppenreplikation für eine DB-Instance in einem Aktiv/Aktiv-Cluster beenden. Wenn Sie die Gruppenreplikation beenden, wird die DB-Instance in den super-read-only Modus versetzt, bis die Replikation neu gestartet oder diese DB-Instance aus dem Active-Active-Cluster entfernt wird. Informationen zum super-read-only Modus finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). **So beenden Sie die Gruppenreplikation für einen Aktiv/Aktiv-Cluster vorübergehend** 1. Stellen Sie mithilfe eines SQL-Clients eine Verbindung mit einer DB-Instance im Aktiv/Aktiv-Cluster her. Weitere Informationen zum Herstellen einer Verbindung mit einer DB-Instance von RDS für MySQL finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). 1. Rufen Sie im SQL-Client die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) auf: ``` call mysql.rds_group_replication_stop(); ``` # Umbenennen einer DB-Instance in einem Aktiv/Aktiv-Cluster Sie können den Namen einer DB-Instance in einem Aktiv/Aktiv-Cluster ändern. Um mehr als eine DB-Instance in einem Aktiv/Aktiv-Cluster umzubenennen, benennen Sie die DB-Instances jeweils nacheinander um. Benennen Sie also eine DB-Instance um und fügen Sie sie erneut dem Cluster hinzu, bevor Sie die nächste DB-Instance umbenennen. **So benennen Sie eine DB-Instance in einem Aktiv/Aktiv-Cluster um** 1. Stellen Sie eine Verbindung mit der DB-Instance in einem SQL-Client her und rufen Sie die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) auf: ``` call mysql.rds_group_replication_stop(); ``` 1. Benennen Sie die DB-Instance um, indem Sie die Anweisungen unter [Umbenennen einer DB-Instance](USER_RenameInstance.md) ausführen. 1. Ändern Sie den Parameter `group_replication_group_seeds` in der jeweiligen DB-Parametergruppe, die einer DB-Instance im Aktiv/Aktiv-Cluster zugeordnet ist. Ersetzen Sie in der Parametereinstellung den alten DB-Instance-Endpunkt durch den neuen. Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Stellen Sie eine Verbindung mit der DB-Instance in einem SQL-Client her und rufen Sie die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) auf: ``` call mysql.rds_group_replication_start(0); ``` # Entfernen einer DB-Instance aus einem Aktiv/Aktiv-Cluster Wenn Sie eine DB-Instance aus einem Aktiv/Aktiv-Cluster entfernen, wird sie wieder zu einer eigenständigen DB-Instance. **So entfernen Sie eine DB-Instance aus einem Aktiv/Aktiv-Cluster** 1. Stellen Sie eine Verbindung mit der DB-Instance in einem SQL-Client her und rufen Sie die gespeicherte Prozedur [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) auf: ``` call mysql.rds_group_replication_stop(); ``` 1. Ändern Sie den Parameter `group_replication_group_seeds` für die DB-Instances, die im Aktiv/Aktiv-Cluster verbleiben. Löschen Sie im Parameter `group_replication_group_seeds` die DB-Instance, die Sie aus dem Aktiv/Aktiv-Cluster entfernen möchten. Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Ändern Sie die Parameter der DB-Instance, die Sie aus dem Aktiv/Aktiv-Cluster entfernen möchten, sodass sie nicht mehr Teil des Clusters ist. Sie können die DB-Instance entweder einer anderen Parametergruppe zuordnen oder die Parameter in der DB-Parametergruppe ändern, die mit der DB-Instance verknüpft ist. Zu den zu ändernden Parametern gehören `group_replication_group_name`, `rds.group_replication_enabled` und `group_replication_group_seeds`. Weitere Informationen zu den Parametern von Aktiv/Aktiv-Clustern finden Sie unter [Erforderliche Parametereinstellungen für Aktiv/Aktiv-Cluster](mysql-active-active-clusters-parameters.md). Wenn Sie die Parameter in einer DB-Parametergruppe ändern, vergewissern Sie sich, dass die DB-Parametergruppe nicht mit anderen DB-Instances im Aktiv/Aktiv-Cluster verknüpft ist. 1. Starten Sie die DB-Instance neu, die Sie aus dem Aktiv/Aktiv-Cluster entfernt haben, damit die neuen Parametereinstellungen wirksam werden. Detaillierte Anweisungen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). # Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation Sie können eine Replikation verwenden, um Daten aus einer DB-Instance von RDS für MySQL in eine MySQL-Instance zu exportieren, die außerhalb von Amazon RDS ausgeführt wird. In diesem Szenario ist die MySQL-DB-Instance die *MySQL-Quell-DB-Instance* und die MySQL-Instance, die außerhalb von Amazon RDS ausgeführt wird, ist die *externe MySQL-Datenbank*. Die externe MySQL-Datenbank kann entweder lokal in Ihrem Rechenzentrum oder auf einer Amazon EC2-Instance ausgeführt werden. Die externe MySQL-Datenbank muss dieselbe Version wie die MySQL-Quell-DB-Instance oder eine höhere Version ausführen. Die Replikation auf eine externe MySQL-Datenbank wird nur während des Exports einer Datenbank aus der MySQL-Quell-DB-Instance unterstützt. Die Replikation sollte nach Abschluss des Exportvorgangs beendet werden und die Anwendungen können dann wieder auf die externe MySQL-Instance zugreifen. Im Folgenden sind die durchzuführenden Schritte aufgeführt. In den folgenden Abschnitten wird jeder Schritt im Detail erklärt. 1. Bereiten Sie eine externe MySQL DB-Instance vor. 1. Bereiten Sie die MySQL-DB-Quell-Instance für die Replikation vor. 1. Verwenden Sie das Dienstprogramm mysqldump, um die Datenbank von der MySQL-DB-Quell-Instance in die externe MySQL-Datenbank zu übertragen. 1. Starten Sie die Replikation zu der externen MySQL-Datenbank. 1. Nachdem der Exportvorgang abgeschlossen ist, stoppt die Replikation. ## Vorbereiten einer externen MySQL-Datenbank Führen Sie die folgenden Schritte aus, um die externe MySQL-Datenbank vorzubereiten. **So bereiten Sie die externe MySQL-Datenbank vor:** 1. Installieren Sie die externe MySQL-Datenbank. 1. Stellen Sie als Masterbenutzer eine Verbindung zur externen MySQL-Datenbank her. Erstellen Sie dann die Benutzer, die erforderlich sind, um die Administratoren, Anwendungen und Services zu unterstützen, die auf die Datenbank zugreifen. 1. Folgen Sie den Anweisungen in der MySQL-Dokumentation, um die externe MySQL-Datenbank als Replikat vorzubereiten. Weitere Informationen finden Sie unter [Festlegen der Replikatkonfiguration](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-slavebaseconfig.html) in der MySQL-Dokumentation. 1. Konfigurieren Sie eine Ausgangsregel für die externe MySQL-Datenbank, damit diese während des Exportvorgangs als Read Replica funktioniert. Die Ausgangsregel ermöglicht es der externen MySQL-Datenbank, während der Replikation eine Verbindung mit der MySQL-DB-Quell-Instance herzustellen. Legen Sie eine Ausgangsregel fest, die TCP-Verbindungen zum Port und zur IP-Adresse der MySQL-DB-Quell-Instance zulässt. Geben Sie die entsprechenden Ausgangsregeln für Ihre Umgebung an: + Wenn die externe MySQL-Datenbank in einer Amazon EC2-Instance in einer Virtual Private Cloud (VPC) ausgeführt wird, die auf dem Amazon VPC-Service basiert, geben Sie die Ausgangregeln in einer VPC-Sicherheitsgruppe an. Weitere Informationen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md). + Wenn die externe MySQL-Datenbank lokal installiert ist, geben Sie die Ausgangregeln in einer Firewall an. 1. Wenn die externe MySQL-Datenbank in einer VPC ausgeführt wird, konfigurieren Sie zusätzlich zur Sicherheitsgruppenausgangsregel Regeln für die VPC-Zugriffskontrollliste (ACL): + Konfigurieren Sie eine ACL-Eingangsregel, die TCP-Datenverkehr zu den Ports 1024–65535 von der IP-Adresse der MySQL-DB-Quell-Instance erlaubt. + Konfigurieren Sie eine ACL-Ausgangsregel, die ausgehenden TCP-Datenverkehr zum Port und zur IP-Adresse der MySQL-DB-Quell-Instance erlaubt. Weitere Informationen zum Amazon VPC-Netzwerk ACLs finden Sie unter [Netzwerk ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) im *Amazon VPC-Benutzerhandbuch*. 1. (Optional) Legen Sie den Parameter `max_allowed_packet` auf die maximale Größe fest, um Replikationsfehler zu vermeiden. Wir empfehlen diese Einstellung. ## Vorbereiten der MySQL-DB-Quell-Instance Führen Sie die folgenden Schritte aus, um die MySQL-DB-Quell-Instance als Replikationsquelle vorzubereiten. **So bereiten Sie die MySQL DB-Quell-Instance vor:** 1. Stellen Sie sicher, dass Ihr Client-Computer über genügend freien Speicherplatz verfügt, um die Binärprotokolle während des Einrichtens der Replikation zu speichern. 1. Stellen Sie eine Verbindung mit der MySQL-DB-Quell-Instance her und erstellen Sie ein Replikationskonto, indem Sie die Anweisungen unter [Erstellen eines Benutzers für die Replikation](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-repuser.html) in der MySQL-Dokumentation befolgen. 1. Konfigurieren Sie die Eingangsregeln auf dem System, auf dem die MySQL DB-Quell-Instance ausgeführt wird, damit die externe MySQL-Datenbank während der Replikation eine Verbindung herstellen kann. Legen Sie eine Eingangsregel fest, die TCP-Verbindungen zum Port, der von der MySQL-DB-Quell-Instance verwendet wird, von der IP-Adresse der externen MySQL-Datenbank erlaubt. 1. Geben Sie die Ausgangregeln an: + Wenn die MySQL-DB\$1Quell-Instance in einer VPC ausgeführt wird, legen Sie die Eingangsregeln in einer VPC-Sicherheitsgruppe fest. Weitere Informationen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md). 1. Wenn die MySQL\$1DB\$1Quell-Instance in einer VPC ausgeführt wird, konfigurieren Sie VPC-ACL-Regeln, zusätzlich zur Eingangsregel der Sicherheitsgruppe. + Konfigurieren Sie eine Regel für eingehenden ACL-Datenverkehr, die TCP-Verbindungen zum Port, der von der Amazon-RDS-Instance verwendet wird, von der IP-Adresse der externen MySQL-Datenbank erlaubt. + Konfigurieren Sie eine ACL\$1Ausgangsregel, die TCP-Verbindungen von den Ports 1024–65535 zur IP-Adresse der externen MySQL-Datenbank erlaubt. Weitere Informationen zum Amazon VPC-Netzwerk ACLs finden Sie unter [Netzwerk ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) im *Amazon VPC-Benutzerhandbuch*. 1. Stellen Sie sicher, dass der Aufbewahrungszeitraum für Backup auf eine ausreichend lange Dauer eingestellt ist, damit keine Binärprotokolle während des Exportvorgangs bereinigt werden. Wenn Protokolle bereinigt werden, bevor der Exportvorgang abgeschlossen ist, müssen Sie die Replikation von Anfang an neu starten. Weitere Informationen zum Einstellen des Aufbewahrungszeitraums für Backups finden Sie unter [Einführung in Backups](USER_WorkingWithAutomatedBackups.md). 1. Verwenden Sie die gespeicherte Prozedur `mysql.rds_set_configuration`, um das Binärprotokoll für den Aufbewahrungszeitraum auf eine ausreichend lange Dauer einzustellen, damit die Binärprotokolle während des Exportvorgangs nicht bereinigt werden. Weitere Informationen finden Sie unter [Zugriff auf MySQL-Binärprotokolle](USER_LogAccess.MySQL.Binarylog.md). 1. Erstellen Sie ein Amazon-RDS-Read Replica aus der MySQL-DB-Quell-Instance, um nochmals sicherzustellen, dass die Binärprotokolle der MySQL-DB-Quell-Instance nicht bereinigt werden. Weitere Informationen finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md). 1. Nachdem das Amazon-RDS-Lesereplikat erstellt wurde, rufen Sie die gespeicherte Prozedur `mysql.rds_stop_replication` auf, um den Replikationsvorgang zu stoppen. Die MySQL-DB-Quell-Instance löscht ihre binären Protokolldateien nicht mehr, so dass sie für den Replikationsprozess verfügbar sind. 1. (Optional) Legen Sie sowohl den Parameter `max_allowed_packet` als auch den Parameter `slave_max_allowed_packet` auf die maximale Größe fest, um Replikationsfehler zu vermeiden. Die maximale Größe für beide Parameter beträgt 1 GB. Wir empfehlen diese Einstellung für beide Parameter. Weitere Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ## Kopieren der Datenbank Führen Sie die folgenden Schritte aus, um die Datenbank zu kopieren. **So kopieren Sie die Datenbank:** 1. Stellen Sie eine Verbindung mit dem RDS-Read Replica der MySQL-DB-Instance her und führen Sie die MySQL-Anweisung `SHOW REPLICA STATUS\G` aus. Beachten Sie die Werte für Folgendes: + `Master_Host` + `Master_Port` + `Master_Log_File` + `Exec_Master_Log_Pos` **Anmerkung** Frühere Versionen von MySQL verwenden `SHOW SLAVE STATUS` anstelle von `SHOW REPLICA STATUS`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `SHOW SLAVE STATUS`. 1. Verwenden Sie das Dienstprogramm mysqldump, um einen Snapshot zu erstellen, der die Daten von Amazon RDS auf Ihren lokalen Client-Computer kopiert. Stellen Sie sicher, dass Ihr Client-Computer ausreichend Speicherplatz zur Verfügung hat, um die zu replizierenden `mysqldump`-Dateien aus den Datenbanken zu speichern. Dieser Vorgang kann für große Datenbanken einige Stunden in Anspruch nehmen. Folgen Sie den Anweisungen unter [Erstellen eines Daten-Snapshots mit mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) in der MySQL-Dokumentation. Im folgenden Beispiel wird `mysqldump` auf einem Client ausgeführt und schreibt das Dump in eine Datei. Für Linux, macOS oder Unix: ``` mysqldump -h source_MySQL_DB_instance_endpoint \ -u user \ -ppassword \ --port=3306 \ --single-transaction \ --routines \ --triggers \ --databases database database2 > path/rds-dump.sql ``` Für Windows: ``` mysqldump -h source_MySQL_DB_instance_endpoint ^ -u user ^ -ppassword ^ --port=3306 ^ --single-transaction ^ --routines ^ --triggers ^ --databases database database2 > path\rds-dump.sql ``` Sie können die Backup-Datei in die externe MySQL-Datenbank laden. Weitere Informationen finden Sie unter [Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) in der MySQL-Dokumentation. Sie können ein anderes Dienstprogramm ausführen, um die Daten in die externe MySQL-Datenbank zu laden. ## Abschließen des Exportvorgangs Führen Sie die folgenden Schritte aus, um den Export abzuschließen. **So schließen Sie den Export ab:** 1. Verwenden Sie das MySQL-Statement `CHANGE MASTER`, um die externe MySQL-Datenbank zu konfigurieren. Geben Sie die ID und das Passwort des Benutzers an, dem `REPLICATION SLAVE`-Berechtigungen erteilt wurden. Geben Sie die Werte `Master_Host`, `Master_Port`, `Relay_Master_Log_File` und `Exec_Master_Log_Pos` aus der MySQL-`SHOW REPLICA STATUS\G`-Anweisung an, die Sie auf dem RDS-Read Replica ausgeführt haben. Weitere Informationen finden Sie unter [CHANGE MASTER TO-Anweisung](https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html) in der MySQL-Dokumentation. **Anmerkung** Frühere Versionen von MySQL verwenden `SHOW SLAVE STATUS` anstelle von `SHOW REPLICA STATUS`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `SHOW SLAVE STATUS`. 1. Verwenden Sie den MySQL-Befehl `START REPLICA`, um die Replikation von der MySQL-DB-Quell-Instance in die externe MySQL-Datenbank zu initiieren. Dadurch wird die Replikation von der MySQL-DB-Quell-Instance gestartet und alle Quelländerungen werden exportiert, die nach Beendigung der Replikation aus dem Amazon-RDS-Read Replica aufgetreten sind. **Anmerkung** Frühere Versionen von MySQL verwenden `START SLAVE` anstelle von `START REPLICA`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `START SLAVE`. 1. Führen Sie den MySQL-Befehl `SHOW REPLICA STATUS\G` in der externen MySQL-Datenbank aus, um zu überprüfen, ob diese als Read Replica ausgeführt wird. Weitere Informationen zum Interpretieren der Ergebnisse finden Sie unter [SHOW SLAVE \$1 REPLICA STATUS-Anweisung](https://dev.mysql.com/doc/refman/8.0/en/show-slave-status.html) in der MySQL-Dokumentation. 1. Nachdem die Replikation auf der externen MySQL-Datenbank die MySQL-DB-Quell-Instance eingeholt hat, verwenden Sie den MySQL-Befehl `STOP REPLICA`, um die Replikation von der MySQL-DB-Quell-Instance anzuhalten. **Anmerkung** Frühere Versionen von MySQL verwenden `STOP SLAVE` anstelle von `STOP REPLICA`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `STOP SLAVE`. 1. Rufen Sie im Amazon-RDS-Lesereplikat die gespeicherte Prozedur `mysql.rds_start_replication` auf. Dies ermöglicht Amazon RDS, die Binärprotokolldateien aus der MySQL-DB-Quell-Instance zu bereinigen. # Optionen für MySQL-DB-Instances Im Folgenden finden Sie eine Beschreibung der Optionen oder zusätzlichen Funktionen, die für Amazon-RDS-Instances verfügbar sind, auf denen die MySQL-DB-Engine ausgeführt wird. Damit diese Optionen aktiviert werden, 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 MySQL: **** | Option | Options-ID | Engine-Versionen | | --- | --- | --- | | [MariaDB-Audit-Plugin-Support für MySQL](Appendix.MySQL.Options.AuditPlugin.md) | `MARIADB_AUDIT_PLUGIN` | Alle MySQL 8.4-VersionenMySQL 8.0.28 und höhere 8.0-VersionenAlle MySQL 5.7-Versionen | | [Unterstützung für MySQL-memcached](Appendix.MySQL.Options.memcached.md) | `MEMCACHED` | Alle MySQL 5.7- und 8.0-Versionen | # MariaDB-Audit-Plugin-Support für MySQL Amazon RDS bietet ein Audit-Plugin für MySQL-Datenbank-Instances, das auf dem Open-Source-MariaDB-Audit-Plugin basiert. Weitere Informationen finden Sie im [ GitHubRepository Audit Plugin for MySQL Server](https://github.com/aws/audit-plugin-for-mysql). **Anmerkung** Das Audit-Plugin für MySQL basiert auf dem MariaDB-Audit-Plugin. In diesem Artikel bezeichnen wir es als MariaDB-Audit-Plugin. Das MariaDB-Audit-Plugin zeichnet Datenbankaktivitäten auf, z. B. Benutzer, die sich bei der Datenbank anmelden, in der Datenbank ausgeführte Abfragen 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. | 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 [ MySQL-Datenbank-Logdateien](USER_LogAccess.Concepts.MySQL.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 [Überblick über RDS-for-MySQL-Datenbankprotokolle](USER_LogAccess.MySQL.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 [Überblick über RDS-for-MySQL-Datenbankprotokolle](USER_LogAccess.MySQL.LogFileSize.md) und [Herunterladen einer Datenbank-Protokolldatei](USER_LogAccess.Procedural.Downloading.md). | | `SERVER_AUDIT_EVENTS` | `CONNECT`, `QUERY`, `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.MySQL.Options.AuditPlugin.html) Bei MySQL wird `TABLE` nicht unterstützt. | | `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.MySQL.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: + Erstellen einer neuen Optionsgruppe oder Kopieren oder Ändern einer bestehenden Optionsgruppe + Hinzufügen der Option zur Optionsgruppe + Zuordnen der Optionsgruppe zu einer DB-Instance 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. **Wichtig** Das Hinzufügen des MariaDB-Audit-Plugin zu einer DB-Instance kann einen Ausfall verursachen. Sie sollten das MariaDB-Audit-Plugin während eines Wartungsfensters hinzufügen oder wenn die Arbeitslast der Datenbank gering ist. **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 **mysql** für **Engine** und **5.7**, **8.0** oder **8.4** für **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.MySQL.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 Instance ändern und die neue Optionsgruppe anhängen. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). ## Format des Prüfprotokolls Protokolldateien werden als CSV-Dateien (durch Kommas getrennte Werte) im UTF-8-Format dargestellt. **Tipp** Protokolldateieinträge folgen keiner sequenziellen Reihenfolge. Um die Einträge zu sortieren, verwenden Sie den Wert des Zeitstempels. Sie müssen eventuell alle Protokolldateien überprüfen, um die aktuellen Ereignisse zu sehen. Wenn Sie mehr Flexibilität beim Sortieren und Durchsuchen der Protokolldaten wünschen, aktivieren Sie die Einstellung, in die Auditprotokolle hochzuladen CloudWatch und sie über die CloudWatch Benutzeroberfläche anzuzeigen. Um Prüfdaten mit mehreren Feldtypen und mit Ausgabe im JSON-Format anzuzeigen, können Sie auch die Funktion Datenbankaktivitäts-Streams verwenden. Weitere Informationen finden Sie unter [Überwachung von Amazon RDS mithilfe von Datenbankaktivitätsstreams](DBActivityStreams.md). Die Prüfprotokolldateien beinhalten die folgenden durch Kommata getrennten Informationen in Zeilen in der festgelegten Reihenfolge: | Feld | Beschreibung | | --- | --- | | Zeitstempel | `YYYYMMDD`, gefolgt von `HH:MI:SS` (24-Stunden-Uhr) für das protokollierte Ereignis. | | serverhost | Der Name der Instance, für die das Ereignis protokolliert wird. | | username | Der verbundene Benutzername des Benutzers. | | host | Der Host, von dem sich der Benutzer verbunden hat. | | connectionid | Die Nummer der Verbindungs-ID für den protokollierte Vorgang. | | queryid | Die Nummer der Abfragen-ID, die verwendet werden kann, um Ereignisse für relationale Tabellenereignisse und zugehörige Abfragen zu finden. Für `TABLE`-Ereignisse werden mehrere Zeilen hinzugefügt. | | operation | Der dokumentierte Aktionstyp. Mögliche Werte sind: `CONNECT`, `QUERY`, `READ`, `WRITE`, `CREATE`, `ALTER`, `RENAME` und `DROP`. | | Datenbank | Die aktive Datenbank, wie vom `USE`-Befehl eingestellt. | | Objekt | Bei `QUERY`-Ereignissen gibt dieser Wert die Abfrage an, die die Datenbank ausgeführt hat. Bei `TABLE`-Ereignissen gibt er den Tabellennamen an. | | retcode | Der zurückgegebene Code des protokollierten Vorgangs. | | connection\$1type | Der Sicherheitsstatus der Verbindung zum Server. Die möglichen Werte sind: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) | ## 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 ä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.MySQL.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). # Unterstützung für MySQL-memcached Amazon RDS unterstützt die Verwendung der Schnittstelle `memcached` für InnoDB-Tabellen, die in MySQL 5.6 eingeführt wurde. Die API `memcached` erlaubt Anwendungen, InnoDB-Tabellen zu verwenden, ähnlich wie es in NoSQL-Schlüsselwert-Datenspeichern möglich ist. **Anmerkung** Die Memcached-Benutzeroberfläche ist in MySQL 8.4 nicht mehr verfügbar. Wenn Sie Ihre DB-Instances auf MySQL 8.4 aktualisieren, müssen Sie `memcached` in vorhandenen Optionsgruppen deaktivieren. Die `memcached`-Benutzeroberfläche ist ein einfacher, schlüsselbasierter Cache. Anwendungen verwenden `memcached`, um im Cache Schlüsselwert-Datenpaare einzufügen, zu manipulieren oder abzurufen. Mit MySQL 5.6 wurde ein Plugin eingeführt, das einen Daemon-Service implementiert, der Daten von InnoDB-Tabellen über das `memcached`-Protokoll freigibt. Weitere Informationen zum MySQL-`memcached`-Plug-in finden Sie unter [InnoDB-Integration mit memcached](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached.html). **So aktivieren Sie Memcached-Unterstützung für eine DB-Instance von RDS für MySQL** 1. Bestimmen der Sicherheitsgruppe, die für den kontrollierten Zugriff auf die `memcached`-Schnittstelle verwendet werden soll. Wenn die vom Anwendungs-Set bereits verwendete SQL-Schnittstelle dieselbe ist, die auf die `memcached`-Schnittstelle zugreifen wird, können Sie die bestehende VPC-Sicherheitsgruppe verwenden, die von der SQL-Schnittstelle verwendet wird. Wenn ein anderes Anwendungs-Set auf die `memcached`-Schnittstelle zugreifen wird, definieren Sie eine neue VPC- oder DB-Sicherheitsgruppe. Weitere Informationen über das Verwalten von Sicherheitsgruppen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md) 1. Erstellen einer benutzerdefinierten DB-Optionsgruppe, Auswählen von MySQL als Engine-Typ und Version. Weitere Informationen zum Erstellen einer Optionsgruppe finden Sie unter [Erstellen einer Optionsgruppe](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create). 1. Fügen Sie die Option `MEMCACHED` zur Optionsgruppe hinzu. Angeben des Ports, den die `memcached`-Schnittstelle verwenden soll, und der Sicherheitsgruppe, die für die Kontrolle des Zugriffs auf die Schnittstelle verwendet werden soll. Weitere Informationen über das Hinzufügen von Optionen finden Sie unter [Hinzufügen einer Option zu einer Optionsgruppe](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). 1. Ändern der Optionseinstellungen, um die `memcached`-Parameter zu konfigurieren, falls notwendig. Weitere Informationen über das Ändern von Optionseinstellungen finden Sie unter [Ändern einer Optionseinstellung](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). 1. Wenden Sie die Optionsgruppe auf eine Instance an. Amazon RDS aktiviert die `memcached`-Unterstützung für diese Instance, wenn die Optionsgruppe angewendet wurde: + Sie können die `memcached`-Unterstützung für eine neue Instance aktivieren, indem Sie beim Starten der Instance die benutzerdefinierte Optionsgruppe angeben. Weitere Informationen über das Starten einer MySQL-Instance finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md). + Sie können die `memcached`-Unterstützung für eine bestehende Instance aktivieren, indem Sie beim Ändern der Instance eine benutzerdefinierte Optionsgruppe angeben. Weitere Informationen über das Ändern einer DB-Instance finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). 1. Angeben, auf welche Spalten in Ihren MySQL-Tabellen über die `memcached`-Schnittstelle zugegriffen werden darf. Das Plugin `memcached` erstellt eine Katalog-Tabelle mit dem Namen `containers` in einer dedizierten Datenbank mit dem Namen `innodb_memcache`. Sie können eine Zeile in der `containers`-Tabelle einfügen, um eine InnoDB-Tabelle für den Zugriff durch `memcached` zu berechtigen. Sie können eine Spalte in der InnoDB-Tabelle festlegen, die verwendet werden soll, um `memcached`-Schlüsselwerte zu speichern, und eine oder mehrere Spalten, die dazu verwendet werden sollen, um die Datenwerte zu speichern, die mit dem Schlüssel zusammenhängen. Sie können einen Namen angeben, den eine `memcached`-Anwendung verwenden soll, um sich auf diese Spalten zu beziehen. Weitere Details zum Einfügen von Zeilen in der `containers`-Tabelle finden Sie unter [InnoDB memcached Plugin Internals](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-internals.html). Ein Beispiel für die Zuordnung einer InnoDB-Tabelle und den Zugriff über `memcached` finden Sie unter [Schreiben von Anwendungen für das InnoDB-memcached Plugin](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-developing.html). 1. Wenn sich die Anwendungen, die auf die `memcached` Schnittstelle zugreifen, auf anderen Computern oder EC2 Instanzen befinden als die Anwendungen, die die SQL-Schnittstelle verwenden, fügen Sie die Verbindungsinformationen für diese Computer der VPC-Sicherheitsgruppe hinzu, die der MySQL-Instance zugeordnet ist. Weitere Informationen über das Verwalten von Sicherheitsgruppen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md). Sie können die `memcached`-Unterstützung für eine Instance deaktivieren, indem Sie die Instance ändern und die Standard-Sicherheitsgruppe für Ihre MySQL-Version angeben. Weitere Informationen über das Ändern einer DB-Instance finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). ## Sicherheitsüberlegungen zu MySQL memcached Das `memcached`-Protokoll unterstützt keine Benutzer-Authentifizierung. Weitere Informationen zu `memcached`-Sicherheitsüberlegungen von MySQL finden Sie unter [Sicherheitsüberlegungen für das InnoDB Memcached Plugin](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-security.html) in der MySQL-Dokumentation. Sie können folgende Aktionen durchführen, um die Sicherheit der `memcached`-Schnittstelle zu erhöhen: + Geben Sie einen anderen Port als den Standard-Port 11211 an, wenn Sie die Option `MEMCACHED` Ihrer Sicherheitsgruppe hinzufügen. + Stellen Sie sicher, dass Sie die `memcached` Schnittstelle einer VPC-Sicherheitsgruppe zuordnen, die den Zugriff auf bekannte, vertrauenswürdige Clientadressen und EC2 Instances beschränkt. Weitere Informationen über das Verwalten von Sicherheitsgruppen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md). ## Verbindungsinformationen zu MySQL memcached Um auf eine `memcached`-Schnittstelle zuzugreifen, müssen in einer Anwendung der DNS-Name der Amazon-RDS-Instance und die `memcached`-Portnummer angegeben sein. Wenn eine Instance beispielsweise den DNS-Namen `my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com` trägt und die Memcached-Schnittstelle den Port 11212 verwendet, würde die Verbindungsinformation in PHP wie folgt aussehen: ``` 1. connect('my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com',11212); 5. ?> ``` **So finden Sie den DNS-Namen und den Memcached-Port einer MySQL-DB-Instance** 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 in der oberen rechten Ecke von die Region aus AWS-Managementkonsole, die die DB-Instance enthält. 1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus. 1. Wählen Sie den Namen der MySQL DB-Instance, um deren Details anzuzeigen. 1. Beachten Sie im Bereich **Verbinden** den Wert im Feld **Endpunkt**. Der DNS-Name stimmt mit dem Endpunkt überein. Beachten Sie ebenfalls, dass der Port im Bereich **Verbinden** nicht für den Zugriff auf die `memcached`-Schnittstelle verwendet wird. 1. Achten Sie im Bereich **Details** auf den aufgeführten Namen im Feld **Optionsgruppe**. 1. Wählen Sie im Navigationsbereich **Option groups (Optionsgruppen)** aus. 1. Wählen Sie den Namen der Optionsgruppe aus, die von der MySQL-DB-Instance verwendet wird, um die Details für die Optionsgruppe anzuzeigen. Achten Sie im Bereich **Optionen** auf den Wert der Einstellung **Port** für die Option **MEMCACHED**. ## Optionseinstellungen in MySQL memcached Amazon RDS gibt die MySQL-`memcached`-Parameter als Optionseinstellungen in der Amazon-RDS-`MEMCACHED`-Option frei. ### MySQL memcached-Parameter + `DAEMON_MEMCACHED_R_BATCH_SIZE` – Eine Zahl, die angibt, wie viele `memcached`-Leseoperationen durchgeführt (erhalten) werden müssen, bevor ein COMMIT ausgeführt wird, um eine neue Transaktion zu starten. Der erlaubte Wertebereich liegt zwischen 1 und 4294967295; der Standardwert ist 1. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `DAEMON_MEMCACHED_W_BATCH_SIZE` – Eine Zahl, die angibt, wie viele `memcached`-Schreiboperationen, wie Addition, Set oder Erhöhung, durchgeführt werden müssen, bevor ein COMMIT ausgeführt wird, um eine neue Transaktion zu starten. Der erlaubte Wertebereich liegt zwischen 1 und 4294967295; der Standardwert ist 1. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `INNODB_API_BK_COMMIT_INTERVAL` – Eine Zahl, die angibt, wie oft für Verbindungen im Leerlauf, die die InnoDB-`memcached`-Schnittstelle verwenden, ein Auto-Commit durchgeführt werden muss. Der erlaubte Wertebereich liegt zwischen 1 und 1073741824; der Standardwert ist 5. Die Option wird angewendet, ohne dass ein Neustart der Instance notwendig ist. + `INNODB_API_DISABLE_ROWLOCK` – Ein boolescher Wert, der die Verwendung von Zeilensperren aktiviert (1 (wahr)) oder deaktiviert (0 (falsch)), wenn die InnoDB-`memcached`-Schnittstelle verwendet wird. Der Standardwert lautet 0 (falsch). Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `INNODB_API_ENABLE_MDL` – Ein boolescher Wert, der, wenn auf 0 (falsch) festgelegt, die vom InnoDB-`memcached`-Plug-in verwendete Tabelle sperrt, damit diese durch DDL über die SQL-Schnittstelle nicht verworfen oder geändert werden kann. Der Standardwert lautet 0 (falsch). Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `INNODB_API_TRX_LEVEL` – Eine Zahl, die das Level der Transaktionsisolation für Abfragen festlegt, die von der `memcached`-Schnittstelle verarbeitet werden. Zulässige Werte liegen zwischen 0 und 3. Der Standardwert ist 0. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. Amazon RDS konfiguriert diese MySQL-`memcached`-Parameter und sie können nicht geändert werden: `DAEMON_MEMCACHED_LIB_NAME`, `DAEMON_MEMCACHED_LIB_PATH` und `INNODB_API_ENABLE_BINLOG`. Die Parameter, die MySQL-Administratoren mithilfe von `daemon_memcached_options` festlegen, sind als einzelne `MEMCACHED`-Optionseinstellung in Amazon RDS verfügbar. ### MySQL-daemon\$1memcached\$1options-Parameter + `BINDING_PROTOCOL` – Ein String, der das zu verwendende verbindliche Protokoll angibt. Die zulässigen Werte sind `auto`, `ascii` oder `binary`. Der Standardwert lautet `auto`. Das bedeutet, dass der Server mit dem Client das Protokoll automatisch vereinbart. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `BACKLOG_QUEUE_LIMIT` – Eine Zahl, die festlegt, wie viele Netzwerkverbindungen in der Warteschlange stehen dürfen, um von verarbeitet zu werden `memcached`. Das Erhöhen dieser Beschränkung könnte Fehler reduzieren, die ein Client erhält, wenn er nicht mit der `memcached`-Instance verbunden ist, aber es verbessert nicht die Leistung des Servers. Der erlaubte Wertebereich liegt zwischen 1 und 2048; der Standardwert ist 1024. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `CAS_DISABLED` – Ein boolescher Wert, der die Verwendung von compare und swap (CAS) aktiviert (1 (wahr)) oder deaktiviert (0 (falsch)), welche die Pro-Element-Größe um 8 Bytes reduzieren. Der Standardwert lautet 0 (falsch). Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `CHUNK_SIZE` – Eine Zahl, die das Minimum der Chunk-Größe festlegt, um die kleinsten Schlüssel, Werte und Kennzeichnungen für ein Element bereitzustellen. Die zulässigen Werte liegen zwischen 1 und 48. Der Standardwert lautet 48. Mit einem niedrigeren Wert können Sie die Effizienz des Arbeitsspeichers signifikant verbessern. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `CHUNK_SIZE_GROWTH_FACTOR` – Eine Float-Zahl, die die Größe neuer Chunks steuert. Die Größe eines neuen Chunks ist die Größe des Vielfachen des vorherigen Chunks `CHUNK_SIZE_GROWTH_FACTOR`. Der erlaubte Wertebereich liegt zwischen 1 und 2; der Standardwert ist 1,25. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `ERROR_ON_MEMORY_EXHAUSTED` – Ein boolescher Wert, der, wenn auf 1 (wahr) festgelegt, angibt, dass `memcached` eine Fehlermeldung zurückgibt, anstatt Elemente zu entfernen, wenn kein freier Arbeitsspeicher mehr für die Elemente verfügbar ist. Wenn auf 0 (falsch) festgelegt, wird `memcached` Elemente exmittieren, falls kein freier Arbeitsspeicher mehr verfügbar ist. Der Standardwert lautet 0 (falsch). Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `MAX_SIMULTANEOUS_CONNECTIONS` – Eine Zahl, die die maximale Anzahl an gleichzeitigen Verbindungen angibt. Wenn dieser Wert unter dem von 10 festgelegt wird, kann MySQL nicht gestartet werden. Der erlaubte Wertebereich liegt zwischen 10 und 1024; der Standardwert ist 1024. Die Option wird nicht angewendet, bis die Instance neu gestartet wird. + `VERBOSITY` – Eine Zeichenfolge, die das Informationslevel des vom `memcached`-Service erstellten MySQL-Fehlerprotokolls angibt. Der Standardwert ist v. Die Option wird erst wirksam, wenn die Instance neu gestartet wird. Die zulässigen Werte lauten: + `v` – Protokolliert Fehler und Warnungen während der Ausführung der Hauptereignisschleife. + `vv` – Protokolliert zusätzlich zu den von v protokollierten Informationen auch jeden Client-Befehl und die Antwort. + `vvv` – Protokolliert zusätzlich zu den von vv protokollierten Informationen auch interne Zustandsübergänge. Amazon RDS konfiguriert diese MySQL-`DAEMON_MEMCACHED_OPTIONS`-Parameter und sie können nicht geändert werden: `DAEMON_PROCESS`, `LARGE_MEMORY_PAGES`, `MAXIMUM_CORE_FILE_LIMIT`, `MAX_ITEM_SIZE`, `LOCK_DOWN_PAGE_MEMORY`, `MASK`, `IDFILE`, `REQUESTS_PER_EVENT`, `SOCKET` und `USER`. # Parameter für MySQL Standardmäßig verwendet eine MySQL-DB-Instance eine für eine MySQL-Datenbank spezifische DB-Parametergruppe. Diese Parametergruppe enthält Parameter für die MySQL-Datenbank-Engine. Weitere Informationen zum Arbeiten mit Parametergruppen und zum Festlegen von Parametern finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Parameter von RDS für MySQL werden auf die Standardwerte der von Ihnen ausgewählten Speicher-Engine gesetzt. Weitere Informationen zu MySQL-Parametern finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html). Weitere Informationen über MySQL-Speicher-Engines finden Sie unter [Unterstützte Speicher-Engines für RDS für MySQL](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.Storage). Sie können die für eine bestimmte Version von RDS für MySQL verfügbaren Parameter mithilfe der RDS-Konsole oder des AWS CLI anzeigen. Weitere Informationen zum Anzeigen von Parametern in einer MySQL-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 Version von RDS für MySQL anzeigen, indem Sie den Befehl [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) ausführen. Geben Sie einen der folgenden Werte für die Option `--db-parameter-group-family` an: + `mysql8.4` + `mysql8.0` + `mysql5.7` Um beispielsweise die Parameter für RDS für MySQL Version 8.0 anzuzeigen, führen Sie den folgenden Befehl aus. ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 ``` Die Ausgabe sieht folgendermaßen oder ähnlich aus. ``` { "EngineDefaults": { "Parameters": [ { "ParameterName": "activate_all_roles_on_login", "ParameterValue": "0", "Description": "Automatically set all granted roles as active after the user has authenticated successfully.", "Source": "engine-default", "ApplyType": "dynamic", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": true }, { "ParameterName": "allow-suspicious-udfs", "Description": "Controls whether user-defined functions that have only an xxx symbol for the main function can be loaded", "Source": "engine-default", "ApplyType": "static", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": false }, { "ParameterName": "auto_generate_certs", "Description": "Controls whether the server autogenerates SSL key and certificate files in the data directory, if they do not already exist.", "Source": "engine-default", "ApplyType": "static", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": false }, ... ``` Führen Sie den folgenden Befehl aus, um nur die änderbaren Parameter für RDS für MySQL Version 8.0 aufzulisten. Für Linux, macOS oder Unix: ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 \ --query 'EngineDefaults.Parameters[?IsModifiable==`true`]' ``` Für Windows: ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 ^ --query "EngineDefaults.Parameters[?IsModifiable==`true`]" ``` # Geläufige DBA-Aufgaben für MySQL-DB-Instances Im folgenden Inhalt finden Sie Beschreibungen der Amazon-RDS-spezifische Implementierungen häufiger DBA-Aufgaben für DB-Instances, auf denen die MySQL-Datenbank-Engine ausgeführt wird. 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. Informationen zum Arbeiten mit MySQL-Protokolldateien in Amazon RDS finden Sie unter [ MySQL-Datenbank-Logdateien](USER_LogAccess.Concepts.MySQL.md). ## Grundlegendes zu vordefinierten Benutzern Amazon RDS erstellt automatisch mehrere im vordefinierte Benutzer mit neuen DB-Instances von RDS für MySQL. Vordefinierte Benutzer und ihre Berechtigungen können nicht geändert werden. Sie können Berechtigungen für diese vordefinierten Benutzer nicht löschen, umbenennen oder ändern. Jeder entsprechende Versuch führt zu einem Fehler. + **rdsadmin** – Ein Benutzer, der erstellt wurde, um viele der Verwaltungsaufgaben zu erledigen, die der Administrator mit `superuser`-Berechtigungen für eine eigenständige MySQL-Datenbank ausführt. Dieser Benutzer wird intern von RDS für MySQL für viele Verwaltungsaufgaben verwendet. + **rdsrepladmin** – Ein Benutzer, der intern von Amazon RDS verwendet wird, um Replikationsaktivitäten auf DB-Instances und Clustern von RDS für MySQL zu unterstützen. Weitere Informationen zu anderen häufigen DBA-Aufgaben finden Sie unter den folgenden Themen. **Topics** + [ ## Grundlegendes zu vordefinierten Benutzern ](#Appendix.MySQL.CommonDBATasks.users) + [ # Rollenbasiertes Berechtigungsmodell für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.privilege-model.md) + [ # Dynamische Berechtigungen für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.dynamic-privileges.md) + [ # Beenden einer Sitzung oder Abfrage für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.End.md) + [ # Überspringen des aktuellen Replikationsfehlers für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.SkipError.md) + [ # Arbeiten mit InnoDB-Tabellenräumen zur Verbesserung der Wiederherstellungszeiten nach Abstürzen für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.Tables.md) + [ # Verwalten des globalen Statusverlaufs für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.GoSH.md) + [ # Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4 ](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md) # Rollenbasiertes Berechtigungsmodell für RDS für MySQL Ab RDS für MySQL Version 8.0.36 können Sie die Tabellen in der `mysql`-Datenbank nicht direkt ändern. Insbesondere können Sie keine Datenbankbenutzer erstellen, indem Sie DML-Vorgänge (Data Manipulation Language) in den `grant`-Tabellen durchführen. Stattdessen verwenden Sie MySQL-Kontoverwaltungsanweisungen wie `CREATE USER`, `GRANT` und `REVOKE`, um Benutzern rollenbasierte Berechtigungen zu gewähren. Sie können auch keine anderen Objekte wie gespeicherte Prozeduren in der `mysql`-Datenbank erstellen. Sie können immer noch die `mysql`-Tabellen abfragen. Wenn Sie die Binärprotokollreplikation verwenden, werden Änderungen direkt an `mysql`-Tabellen im Quell-DB-Cluster nicht auf den Zielcluster repliziert. In einigen Fällen verwendet Ihre Anwendung möglicherweise Verknüpfungen, um Benutzer oder andere Objekte zu erstellen, indem Sie sie in die`mysql`-Tabellen Wenn ja, ändern Sie Ihren Anwendungscode, um die entsprechenden Anweisungen wie `CREATE USER` zu verwenden. Um Metadaten für Datenbankbenutzer während der Migration aus einer externen MySQL-Datenbank zu exportieren, können Sie eine der folgenden Methoden verwenden. + Verwenden Sie das Instance-Dump-Dienstprogramm von MySQL Shell mit einem Filter, um Benutzer, Rollen und Erteilungen auszuschließen. Das folgende Beispiel zeigt die zu verwendenden Befehle. Stellen Sie sicher, dass `outputUrl` leer ist. ``` mysqlsh user@host -- util.dumpInstance(outputUrl,{excludeSchemas:['mysql'],users: true}) ``` Weitere Informationen finden Sie unter [Instance-Dump-Dienstprogramm, Schema-Dump-Dienstprogramm und Tabellen-Dump-Dienstprogramm](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html) im MySQL-Referenzhandbuch. + Verwenden Sie das Client-Dienstprogramm `mysqlpump`. Dieses Beispiel umfasst alle Tabellen mit Ausnahme der Tabellen in der `mysql`-Systemdatenbank. Sie enthalten auch `CREATE USER` und `GRANT`-Anweisungen zur Reproduktion aller MySQL-Benutzer in der migrierten Datenbank. ``` mysqlpump --exclude-databases=mysql --users ``` Das Client-Dienstprogramm `mysqlpump` ist in MySQL 8.4 nicht mehr verfügbar. Nutzen Sie stattdessen `mysqldump`. Um die Verwaltung von Berechtigungen für viele Benutzer oder Anwendungen zu vereinfachen, können Sie`CREATE ROLE`-Anweisung zum Erstellen einer Rolle mit einer Reihe von Berechtigungen. Dann können Sie die`GRANT`und`SET ROLE`-Anweisungen und die`current_role`Funktion, um Benutzern oder Anwendungen Rollen zuzuweisen, die aktuelle Rolle zu wechseln und zu überprüfen, welche Rollen in Kraft sind. Weitere Informationen zum rollenbasierten Berechtigungssystem in MySQL 8.0 finden Sie unter [Verwenden von Rollen](https://dev.mysql.com/doc/refman/8.0/en/roles.html) im MySQL-Referenzhandbuch. **Wichtig** Wir empfehlen Ihnen, den Hauptbenutzer nicht direkt in Ihren Anwendungen zu verwenden. Bleiben Sie stattdessen bei der bewährten Methode, einen Datenbankbenutzer zu verwenden, der mit den Mindestberechtigungen erstellt wurde, die für Ihre Anwendung erforderlich sind. Ab Version 8.0.36 enthält RDS für MySQL eine spezielle Rolle, die alle folgenden Berechtigungen besitzt. Der Name der Rolle lautet `rds_superuser_role`. Dem primären Administratorbenutzer für jede DB-Instance wurde diese Rolle bereits gewährt. Die`rds_superuser_role`enthält die folgenden Berechtigungen für alle Datenbankobjekte: + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` Die Rollendefinition umfasst auch`WITH GRANT OPTION`damit ein Administratorbenutzer diese Rolle anderen Benutzern gewähren kann. Insbesondere muss der Administrator alle Berechtigungen erteilen, die zur Durchführung der Binärprotokollreplikation mit dem MySQL-Cluster als Ziel erforderlich sind. **Tipp** Um die vollständigen Details der Berechtigungen anzuzeigen, verwenden Sie die folgenden Anweisungen. ``` SHOW GRANTS FOR rds_superuser_role@'%'; ``` Wenn Sie Zugriff mithilfe von Rollen in RDS für MySQL Version 8.0.36 und höher gewähren, aktivieren Sie die Rolle auch mithilfe der `SET ROLE role_name`- oder`SET ROLE ALL`-Anweisung. Im folgenden Beispiel wird gezeigt, wie dies geschieht. Ersetzen Sie den entsprechenden Rollennamen für `CUSTOM_ROLE`. ``` # Grant role to user mysql> GRANT CUSTOM_ROLE TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the CUSTOM_ROLE role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +--------------------------------------------------+ | CURRENT_ROLE() | +--------------------------------------------------+ | `CUSTOM_ROLE`@`%`,`rds_superuser_role`@`%` | +--------------------------------------------------+ ``` # Dynamische Berechtigungen für RDS für MySQL Dynamische Berechtigungen sind MySQL-Berechtigungen, die Sie mithilfe der `GRANT`-Anweisung explizit gewähren können. Abhängig von Ihrer Version von RDS für MySQL können Sie mit RDS nur bestimmte dynamische Berechtigungen gewähren. RDS verbietet einige dieser Berechtigungen, da sie die spezifischen Datenbankvorgänge wie Replikation und Sicherung beeinträchtigen können. Die folgende Tabelle zeigt, welche dieser Berechtigungen Sie für verschiedene MySQL-Versionen gewähren können. Wenn Sie von einer MySQL-Version unter 8.0.36 auf Version 8.0.36 oder höher aktualisieren, müssen Sie möglicherweise Ihren Anwendungscode aktualisieren, wenn die Gewährung einer bestimmten Berechtigung nicht mehr zulässig ist. | Recht | MySQL 8.0.35 und niedriger | MySQL 8.0.36 und höhere Unterversionen | MySQL 8.4.3 und höher | | --- | --- | --- | --- | | [ALLOW\$1NONEXISTENT\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_allow-nonexistent-definer) | Nicht verfügbar | Nicht verfügbar | Unzulässige | | [APPLICATION\$1PASSWORD\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_application-password-admin) | Zulässig | Zulässig | Zulässig | | [AUDIT\$1ABORT\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-abort-exempt) | Zulässig | Unzulässige | Unzulässige | | [AUDIT\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-admin) | Unzulässige | Unzulässige | Unzulässige | | [AUTHENTICATION\$1POLICY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_authentication-policy-admin) | Zulässig | Unzulässige | Unzulässige | | [BACKUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin) | Zulässig | Unzulässige | Unzulässige | | [BINLOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-admin) | Zulässig | Unzulässige | Unzulässige | | [BINLOG\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-encryption-admin) | Unzulässige | Unzulässige | Unzulässige | | [CLONE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_clone-admin) | Unzulässige | Unzulässige | Unzulässige | | [CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_connection-admin) | Zulässig | Unzulässige | Unzulässige | | [ENCRYPTION\$1KEY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_encryption-key-admin) | Unzulässige | Unzulässige | Unzulässige | | [FIREWALL\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-admin) | Unzulässige | Unzulässige | Unzulässige | | [FIREWALL\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-exempt) | Zulässig | Unzulässige | Unzulässige | | [FIREWALL\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-user) | Unzulässige | Unzulässige | Unzulässige | | [FLUSH\$1OPTIMIZER\$1COSTS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-optimizer-costs) | Zulässig | Zulässig | Zulässig | | [FLUSH\$1PRIVILEGES](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_flush-privileges) | Nicht verfügbar | Nicht verfügbar | Zulässig | | [FLUSH\$1STATUS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-status) | Zulässig | Zulässig | Zulässig | | [FLUSH\$1TABLES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-tables) | Zulässig | Zulässig | Zulässig | | [FLUSH\$1USER\$1RESOURCES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-user-resources) | Zulässig | Zulässig | Zulässig | | [GROUP\$1REPLICATION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-admin) | Unzulässige | Unzulässige | Unzulässige | | [GROUP\$1REPLICATION\$1STREAM](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-stream) | Unzulässige | Unzulässige | Unzulässige | | [INNODB\$1REDO\$1LOG\$1ARCHIVE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-archive) | Unzulässige | Unzulässige | Unzulässige | | [INNODB\$1REDO\$1LOG\$1ENABLE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-enable) | Unzulässige | Unzulässige | Unzulässige | | [MASKING\$1DICTIONARIES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_masking-dictionaries-admin) | Unzulässige | Unzulässige | Unzulässige | | [NDB\$1STORED\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_ndb-stored-user) | Unzulässige | Unzulässige | Unzulässige | | [OPTIMIZE\$1LOCAL\$1TABLE](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_optimize-local-table) | Nicht verfügbar | Nicht verfügbar | Unzulässige | | [PASSWORDLESS\$1USER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_passwordless-user-admin) | Unzulässige | Unzulässige | Unzulässige | | [PERSIST\$1RO\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_persist-ro-variables-admin) | Unzulässige | Unzulässige | Unzulässige | | [REPLICATION\$1APPLIER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-applier) | Zulässig | Unzulässige | Unzulässige | | [REPLICATION\$1SLAVE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave-admin) | Unzulässige | Unzulässige | Unzulässige | | [RESOURCE\$1GROUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-admin) | Zulässig | Unzulässige | Unzulässige | | [RESOURCE\$1GROUP\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-user) | Zulässig | Unzulässige | Unzulässige | | [ROLE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_role-admin) | Zulässig | Zulässig | Zulässig | | [SENSITIVE\$1VARIABLES\$1OBSERVER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_sensitive-variables-observer) | Zulässig | Zulässig | Zulässig | | [SERVICE\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_service-connection-admin) | Zulässig | Unzulässige | Unzulässige | | [SESSION\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_session-variables-admin) | Zulässig | Zulässig | Zulässig | | [SET\$1ANY\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_set-any-definer) | Nicht verfügbar | Nicht verfügbar | Zulässig | | [SET\$1USER\$1ID](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_set-user-id) | Zulässig | Zulässig | Nicht verfügbar | | [SHOW\$1ROUTINE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_show-routine) | Zulässig | Zulässig | Zulässig | | [SKIP\$1QUERY\$1REWRITE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_skip-query-rewrite) | Unzulässige | Unzulässige | Unzulässige | | [SYSTEM\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-user) | Unzulässige | Unzulässige | Unzulässige | | [SYSTEM\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-variables-admin) | Unzulässige | Unzulässige | Unzulässige | | [TABLE\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_table-encryption-admin) | Unzulässige | Unzulässige | Unzulässige | | [TELEMETRY\$1LOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_telemetry-log-admin) | Zulässig | Unzulässige | Unzulässige | | [TP\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_tp-connection-admin) | Unzulässige | Unzulässige | Unzulässige | | [TRANSACTION\$1GTID\$1TAG](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_transaction-gtid-tag) | Nicht verfügbar | Nicht verfügbar | Unzulässige | | [VERSION\$1TOKEN\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_version-token-admin) | Unzulässige | Unzulässige | Unzulässige | | [XA\$1RECOVER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_xa-recover-admin) | Zulässig | Zulässig | Zulässig | # Beenden einer Sitzung oder Abfrage für RDS für MySQL Sie können Benutzersitzungen oder Abfragen in DB-Instances mit den Befehlen `rds_kill` und `rds_kill_query` beenden. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). ``` CALL mysql.rds_kill(thread-ID) CALL mysql.rds_kill_query(thread-ID) ``` Um beispielsweise die Sitzung zu beenden, die auf Thread 99 ausgeführt wird, würden Sie Folgendes eingeben: ``` CALL mysql.rds_kill(99); ``` Um die Abfrage zu beenden, die auf Thread 99 ausgeführt wird, würden Sie Folgendes eingeben: ``` CALL mysql.rds_kill_query(99); ``` # Überspringen des aktuellen Replikationsfehlers für RDS für MySQL Amazon RDS stellt einen Mechanismus bereit, mit dem Sie einen Fehler für Ihre Lesereplikate überspringen können, wenn der Fehler dazu führt, dass Ihr Lesereplikat aufhört zu reagieren und der Fehler keine Auswirkungen auf die Integrität Ihrer Daten hat. **Anmerkung** Sie sollten zunächst überprüfen, ob der Fehler sicher übersprungen werden kann. Stellen Sie in einem MySQL-Hilfsprogramm eine Verbindung mit dem Lesereplikat her und führen Sie den folgenden MySQL-Befehl aus: ``` SHOW REPLICA STATUS\G ``` Informationen zu den zurückgegebenen Werten finden Sie in [der MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Frühere Versionen von MySQL verwenden `SHOW SLAVE STATUS` anstelle von `SHOW REPLICA STATUS`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `SHOW SLAVE STATUS`. Sie können einen Fehler in Ihrem Lesereplikat wie folgt überspringen. **Topics** + [ ## Aufrufen der Prozedur mysql.rds\$1skip\$1repl\$1error ](#Appendix.MySQL.CommonDBATasks.SkipError.procedure) + [ ## Festlegen des Parameters slave\$1skip\$1error ](#Appendix.MySQL.CommonDBATasks.SkipError.parameter) ## Aufrufen der Prozedur mysql.rds\$1skip\$1repl\$1error Amazon RDS bietet eine gespeicherte Prozedur, die Sie aufrufen können, um einen Fehler bei Ihren Read-Replikaten zu überspringen. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). Um den Fehler zu überspringen, können Sie den folgenden Befehl ausgeben: ``` CALL mysql.rds_skip_repl_error; ``` Dieser Befehl hat keine Auswirkungen, wenn Sie ihn auf der Quell-DB-Instance oder einem Lesereplikat ausführen, für den kein Replikationsfehler aufgetreten ist. Weitere Informationen wie beispielsweise zu den Versionen von MySQL, die `mysql.rds_skip_repl_error` unterstützen, finden Sie unter [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). **Wichtig** Wenn Sie versuchen, `mysql.rds_skip_repl_error` aufzurufen und der Fehler `ERROR 1305 (42000): PROCEDURE mysql.rds_skip_repl_error does not exist` angezeigt wird, müssen Sie Ihre MySQL-DB-Instance auf die neueste kleinere Version oder eine der kleineren mindestens erforderlichen Versionen aktualisieren, die in [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error) aufgelistet werden. ## Festlegen des Parameters slave\$1skip\$1error Um einen oder mehrere Fehler zu überspringen, können Sie die `slave_skip_errors` statischer Parameter für das Lesereplikat setzen. Sie können diesen Parameter so einstellen, dass ein oder mehrere spezifische Replikationsfehlercodes übersprungen werden. Derzeit können Sie diesen Parameter nur für RDS für MySQL 5.7 DB-Instances festlegen. Nachdem Sie die Einstellung für diesen Parameter geändert haben, starten Sie Ihre DB-Instance neu, damit die neue Einstellung wirksam wird. Weitere Informationen zur Funktionsweise dieser Parameter finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_skip_errors). Wir empfehlen, diesen Parameter in einer separaten DB-Parametergruppe einzustellen. Sie können diese DB-Parametergruppe nur den Lese-Replikaten zuordnen, die Fehler überspringen müssen. Nach dieser Best Practice werden die potenziellen Auswirkungen auf andere DB-Instances und Lese-Replikate reduziert. **Wichtig** Das Festlegen eines nicht standardmäßigen Werts für diesen Parameter kann zu Inkonsistenz der Replikation führen. Stellen Sie diesen Parameter nur auf einen nicht standardmäßigen Wert ein, wenn Sie andere Optionen zur Behebung des Problems ausgeschöpft haben und Sie sich der möglichen Auswirkungen auf die Daten Ihres Read Replica sicher sind. # Arbeiten mit InnoDB-Tabellenräumen zur Verbesserung der Wiederherstellungszeiten nach Abstürzen für RDS für MySQL Jede Tabelle in MySQL besteht aus einer Tabellendefinition, Daten und Indizes. Die MySQL-Speicher-Engine InnoDB speichert Tabellendaten und Indizes in einem *Tabellenraum*. InnoDB erstellt einen globalen, freigegebenen Tabellenraum, der ein Datenverzeichnis und andere relevante Metadaten enthält, und kann Tabellendaten und Indizes enthalten. InnoDB kann darüber hinaus für jede Tabelle und Partition eigene Tabellenräume erstellen. Diese getrennten Tabellenräume werden in Dateien mit der Erweiterung .ibd gespeichert. Die Kopfzeile der einzelnen Tabellenräume enthalten eine Zahl, welche diese eindeutig identifiziert. Amazon RDS stellt in einer MySQL-Parametergruppe einen Parameter namens berei `innodb_file_per_table`. Dieser Parameter steuert, ob InnoDB neue Tabellendaten und Indizes in den gemeinsamen Tabellenraum (durch Setzen des Parameterwertes auf 0) oder in einzelne Tabellenräume (durch Setzen des Parameterwertes auf 1) einfügt. Amazon RDS legt den Standardwert für `innodb_file_per_table` auf 1, mit dem Sie einzelne InnoDB-Tabellen löschen und Speicher zurückgewinnen können, der von diesen Tabellen für die DB-Instance verwendet wird. In der Mehrzahl der Anwendungsfälle stellt die Festlegung des Parameters `innodb_file_per_table` auf 1 die empfohlene Einstellung dar. Sie sollten den Parameter `innodb_file_per_table` auf 0 festlegen, wenn es eine große Zahl von Tabellen gibt, beispielsweise mehr als 1 000 Tabellen, wenn Sie einen Standard-SSD-Speicher (magnetisch) oder einen SSD-Speicher für allgemeine Zwecke verwenden, oder mehr als 10 000 Tabellen, wenn Sie Speicher mit bereitgestellten IOPS verwenden. Wenn Sie diesen Parameter auf 0 festlegen, werden keine einzelnen Tabellenräume erstellt. Dies kann die Zeit für die Datenbankwiederherstellung nach einem Absturz verkürzen. MySQL verarbeitet während des Wiederherstellungszyklus nach Abstürzen jede Metadatendatei, die Tabellenräume enthält. Die Zeit, die MySQL für die Verarbeitung der Metadateninformationen im freigegebenen Tabellenraum benötigt, ist im Vergleich zu der Zeit, die für die Verarbeitung von Tausenden von Tabellenraumdateien benötigt wird, vernachlässigbar, wenn es mehrere Tabellenräume gibt. Da die Tabellenraumnummer in den Kopfzeilen der einzelnen Dateien gespeichert wird, kann die Gesamtzeit für das Lesen aller Tabellenraumdateien mehrere Stunden betragen. Beispielsweise kann die Verarbeitung von einer Million InnoDB-Tabellenräumen in einem Standardspeicher während eines Wiederherstellungszyklus nach einem Absturz zwischen fünf und acht Stunden betragen. In einigen Fällen kann InnoDB feststellen, dass im Anschluss an einen Wiederherstellungszyklus nach einem Absturz eine zusätzliche Bereinigung erforderlich ist. Dann wird ein weiterer Absturzwiederherstellungszyklus gestartet, was die Wiederherstellungszeit verlängert. Denken Sie daran, dass ein Absturzwiederherstellungszyklus zusätzlich zur Verarbeitung von Tabellenrauminformationen auch Rollbacks von Transaktionen, die Reparatur beschädigter Seiten und andere Operationen umfasst. Da sich der Parameter `innodb_file_per_table` in einer Parametergruppe befindet, können Sie den Parameterwert ändern, indem Sie die von Ihrer DB-Instance verwendete Parametergruppe bearbeiten, anstatt die DB-Instance neu starten zu müssen. Nach dem Ändern der Einstellung, beispielsweise von 1 (Erstellen einzelner Tabellen) in 0 (Verwenden freigegebener Tabellenräume) werden dem freigegebenen Tabellenraum neue InnoDB-Tabellen hinzugefügt, während die vorhandenen Tabellen weiterhin über einzelne Tabellenräume verfügen. Um eine InnoDB-Tabelle zum freigegebenen Tabellenraum zu verschieben, müssen Sie den Befehl `ALTER TABLE` verwenden. ## Migrieren mehrerer Tabellenräume zum freigegebenen Tabellenraum Sie können die Metadaten einer InnoDB-Tabelle vom eigenen Tabellenraum zum freigegebenen Tabellenraum verschieben. Hierdurch werden die Tabellenmetadaten entsprechend der Parametereinstellung `innodb_file_per_table` neu erstellt. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). ``` ALTER TABLE table_name ENGINE = InnoDB, ALGORITHM=COPY; ``` Zum Beispiel gibt die folgende Abfrage für jede nicht im freigegebenen Tabellenraum enthaltene InnoDB-Tabelle eine `ALTER TABLE`-Anweisung zurück. **Für MySQL 5.7 DB-Instances:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` **Für MySQL 8.4- und 8.0-DB-Instances:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` Die Neuerstellung einer MySQL-Tabelle, um die Metadaten der Tabelle zum freigegebenen Tabellenraum zu verschieben, erfordert vorübergehend zusätzlichen Speicherplatz, um die Tabelle neu zu erstellen. Daher muss die DB-Instance über freien Speicherplatz verfügen. Während der Neuerstellung ist die Tabelle gesperrt und für Abfragen nicht verfügbar. Im Fall kleiner Tabellen oder von Tabellen, auf die nicht häufig zugegriffen wird, stellt dies möglicherweise kein Problem dar. Im Fall großer Tabellen oder von Tabellen, auf die in einer stark gleichzeitigen Umgebung häufig zugegriffen wird, können Sie Tabellen in einem Lesereplikat neu erstellen. Sie können ein Lesereplikat erstellen und Tabellenmetadaten zum freigegebenen Tabellenraum in dem Lesereplikat verschieben. Die Anweisung ALTER TABLE sperrt zwar den Zugriff auf das Lesereplikat, die Quell-DB-Instance ist hiervon jedoch nicht betroffen. Die Quell-DB-Instance generiert weiterhin Binärprotokolle, während das Lesereplikat während der Neuerstellung der Tabelle folgt. Da für die Neuerstellung zusätzlicher Speicherplatz benötigt wird und die Wiedergabeprotokolldatei sehr groß werden kann, sollten Sie ein Lesereplikat erstellen, dessen Speicher größer als der der Quell-DB-Instance ist. Führen Sie die folgenden Schritte aus, um ein Lesereplikat zu erstellen und InnoDB-Tabellen, die den freigegebenen Tabellenraum verwenden sollen, neu zu erstellen: 1. Stellen Sie sicher, dass die Sicherungsbeibehaltung in der Quell-DB-Instance aktiviert ist, damit die Binärprotokollierung aktiviert ist. 1. Verwenden Sie das AWS-Managementkonsole oder AWS CLI , um eine Read Replica für die Quell-DB-Instance zu erstellen. Da die Erstellung eines Lesereplikats viele derselben Verfahren umfasst wie eine Wiederherstellung nach einem Absturz, kann der Erstellungsvorgang eine Weile dauern, wenn es eine große Zahl von InnoDB-Tabellenräumen gibt. Teilen Sie dem Lesereplikat mehr Speicherplatz zu, als zurzeit in der Quell-DB-Instance verwendet wird. 1. Wenn das Lesereplikat erstellt wurde, erstellen Sie eine Parametergruppe mit den Parametereinstellungen `read_only = 0` und `innodb_file_per_table = 0`. Ordnen Sie dann die Parametergruppe dem Lesereplikat zu. 1. Führen Sie die folgende SQL-Anweisung für alle Tabellen aus, die auf dem Replikat migriert werden sollen: ``` ALTER TABLE name ENGINE = InnoDB ``` 1. Wenn alle `ALTER TABLE`-Anweisungen für das Lesereplikat ausgeführt wurden, überprüfen Sie, ob das Lesereplikat mit der Quell-DB-Instance verknüpft ist und die beiden Instances synchronisiert sind. 1. Verwenden Sie die Konsole oder CLI, um das Lesereplikat als Instance hochzustufen. Achten Sie darauf, dass für die Parametergruppe, die für die neue eigenständige DB-Instance verwendet wird, der Parameter `innodb_file_per_table` auf 0 festgelegt ist. Ändern Sie den Namen der neuen eigenständigen DB-Instance, und verweisen Sie alle Anwendungen auf die neue eigenständige DB-Instance. # Verwalten des globalen Statusverlaufs für RDS für MySQL **Tipp** Zum Analysieren der Datenbankleistung können Sie auch Performance Insights in Amazon RDS verwenden. Weitere Informationen finden Sie unter [Überwachung mit Performance Insights auf Amazon RDS](USER_PerfInsights.md). MySQL besitzt zahlreiche Statusvariablen, die Informationen zur Ausführung bereitstellen. Ihre Werte können Ihnen helfen, Probleme mit Sperren oder Arbeitsspeichern in einer DB-Instance zu entdecken. Die Werte dieser Statusvariablen sind seit dem letzten Zeitpunkt, an dem die DB-Instance gestartet wurde, kumulativ. Sie können die meisten Statusvariablen auf 0 zurücksetzen, indem Sie den Befehl `FLUSH STATUS` verwenden. Um die Überwachung dieser Werte über die Zeit zu ermöglichen, stellt Amazon RDS einen Satz von Verfahren bereit, die Snapshots der Werte dieser Statusvariablen über die Zeit erstellen und diese zusammen mit allen Änderungen seit dem letzten Snapshot in eine Tabelle schreiben. Diese Infrastruktur wird als globaler Statusverlauf (Global Status History, GoSH) bezeichnet und ist auf allen MySQL-DB-Instances ab Version 5.5.23 installiert. GoSH ist standardmäßig deaktiviert. Um GoSH zu aktivieren, müssen Sie zunächst den Ereignis-Scheduler aus einer DB-Parametergruppe aktivieren, indem Sie den Parameter `event_scheduler` auf `ON` festlegen. Setzen Sie darüber hinaus für MySQL-DB-Instances unter MySQL 5.7 den Parameter `show_compatibility_56` auf `1`. Weitere Informationen zum Erstellen und Ändern einer DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Informationen zu den Nebeneffekten bei Aktivierung dieses Parameters finden Sie unter.[show\$1compatibility\$156](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_show_compatibility_56) im *Referenzhandbuch zu MySQL 5.7*. Sie können anschließend die Verfahren in der folgenden Tabelle verwenden, um GoSH zu aktivieren und zu konfigurieren. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). Führen Sie für jede Prozedur den folgenden Befehl aus und ersetzen Sie ihn **procedure-name**: ``` CALL procedure-name; ``` In der folgenden Tabelle sind alle Verfahren aufgeführt, die Sie **procedure-name**im vorherigen Befehl verwenden können. | Verfahren | Beschreibung | | --- | --- | | `mysql.rds_enable_gsh_collector` | Aktiviert GoSH, um Standard-Snapshots in zeitlichen Abständen zu erstellen, die durch angegeben werde `rds_set_gsh_collector`. | | `mysql.rds_set_gsh_collector` | Gibt den zeitlichen Abstand in Minuten für die periodische Generierung von Snapshots an. Der Standardwert ist 5. | | `mysql.rds_disable_gsh_collector` | Deaktiviert Snapshots. | | `mysql.rds_collect_global_status_history` | Generiert einen Snapshot auf Anforderung. | | `mysql.rds_enable_gsh_rotation` | Aktiviert die Rotation der Inhalte der Tabelle `mysql.rds_global_status_history` zu `mysql.rds_global_status_history_old` in zeitlichen Abständen, die durch `rds_set_gsh_rotation` angegeben werden. | | `mysql.rds_set_gsh_rotation` | Gibt den zeitlichen Abstand in Tagen für die periodische Tabellenrotation an. Der Standardwert ist 7. | | `mysql.rds_disable_gsh_rotation` | Deaktiviert die Tabellenrotation. | | `mysql.rds_rotate_global_status_history` | Rotiert die Inhalte der Tabelle `mysql.rds_global_status_history` bei Anforderung zu `mysql.rds_global_status_history_old`. | Wenn GoSH ausgeführt wird, können Sie Abfragen für die Tabellen ausführen, in die GoSH schreibt. Um beispielsweise eine Abfrage für das Trefferverhältnis des InnoDB-Pufferpools auszuführen, würden Sie die folgende Abfrage ausgeben: ``` select a.collection_end, a.collection_start, (( a.variable_Delta-b.variable_delta)/a.variable_delta)*100 as "HitRatio" from mysql.rds_global_status_history as a join mysql.rds_global_status_history as b on a.collection_end = b.collection_end where a. variable_name = 'Innodb_buffer_pool_read_requests' and b.variable_name = 'Innodb_buffer_pool_reads' ``` # Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4 In MySQL 8.4 aktiviert Amazon RDS den Parameter `innodb_dedicated_server` standardmäßig. Mit dem Parameter `innodb_dedicated_server` berechnet die Datenbank-Engine die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity`. Informationen zur Berechnung dieser Parameter finden Sie unter [Konfigurieren der Größe des InnoDB-Buffer-Pools](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-resize.html) und [Redo-Protokoll](https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html) in der MySQL-Dokumentation. Wenn `innodb_dedicated_server` aktiviert ist, wird der Parameter `innodb_buffer_pool_size` basierend auf dem DB-Instance-Klassenspeicher berechnet. Die folgende Tabelle zeigt den erkannten Serverspeicher und die entsprechende Puffergröße. | Serverspeicher wurde erkannt | Pufferpoolgröße | | --- | --- | | 1 GB | Der Standardwert ist 128 MB | | 1 GB bis 4 GB | *Detected server memory*\$1 0,5 | | 4 GB | *Detected server memory*\$1 0,75 | Der `innodb_redo_log_capacity` Parameter skaliert automatisch mit der Instanzklasse auf (Anzahl v CPUs /2) GB bis zu einem Maximum von 16 GB. Größere Instance-Klassen verfügen über eine größere Redo-Protokollkapazität, wodurch die Leistung und Stabilität bei schreibintensiven Workloads verbessert werden kann. Stellen Sie vor dem Upgrade von MySQL 8.0 auf MySQL 8.4 sicher, dass Sie Ihren Speicherplatz vergrößern, um eine mögliche Vergrößerung der Redo-Protokolle zu bewältigen, die nach Abschluss des Upgrades auftreten kann. Weitere Informationen finden Sie unter [Steigern der DB-Instance-Speicherkapazität](USER_PIOPS.ModifyingExisting.md). Wenn Sie nicht möchten, dass der Parameter `innodb_dedicated_server` die Werte für die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity` berechnet, können Sie diese Werte überschreiben, indem Sie spezifische Werte für sie in einer benutzerdefinierten Parametergruppe festlegen. Alternativ können Sie den Parameter `innodb_dedicated_server` deaktivieren und Werte für die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity` in einer benutzerdefinierten Parametergruppe festlegen. Weitere Informationen finden Sie unter [Standard- und benutzerdefinierte Parametergruppen](parameter-groups-overview.md#parameter-groups-overview.custom). Wenn Sie den Parameter `innodb_dedicated_server` deaktivieren, indem Sie ihn auf `0` festlegen und keine Werte für die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity` festlegen, setzt Amazon RDS die beiden letztgenannten Parameter auf 128 MB bzw. 100 MB. Diese Standardwerte führen zu einer schlechteren Leistung bei größeren Instance-Klassen. # Lokale Zeitzone für MySQL-DB-Instances Standardmäßig ist die Zeitzone für eine MySQL-DB-Instance auf die koordinierte Weltzeit (UTC) eingestellt. 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 MySQL veröffentlicht, wird diese mit den neuesten Zeitzonendaten zum Zeitpunkt der Veröffentlichung ausgeliefert. Wenn Sie die neuesten Versionen von RDS für MySQL 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://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html) 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 Amazon RDS für MySQL Bekannte Probleme und Einschränkungen bei der Arbeit Amazon RDS für MySQL sind wie folgt. **Topics** + [ ## Reserviertes Wort InnoDB ](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbDatabaseName) + [ ## Vollständiges Storage-Verhalten für Amazon RDS für MySQL ](#MySQL.Concepts.StorageFullBehavior) + [ ## Inkonsistente Größe des InnoDB-Buffer-Pools ](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbBufferPoolSize) + [ ## Index-Merge-Optimierung zeigt falsche Ergebnisse an ](#MySQL.Concepts.KnownIssuesAndLimitations.IndexMergeOptimization) + [ ## MySQL-Parameterausnahmen für Amazon-RDS-DB-Instances ](#MySQL.Concepts.ParameterNotes) + [ ## MySQL-Dateigrößenlimits in Amazon RDS ](#MySQL.Concepts.Limits.FileSize) + [ ## MySQL Keyring-Plugin wird nicht unterstützt ](#MySQL.Concepts.Limits.KeyRing) + [ ## Benutzerdefinierte Ports ](#MySQL.Concepts.KnownIssuesAndLimitations.CustomPorts) + [ ## Einschränkungen bei gespeicherten MySQL-Prozeduren ](#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures) + [ ## GTID-basierte Replikation mit einer externen Quell-Instance ](#MySQL.Concepts.KnownIssuesAndLimitations.GTID) + [ ## Standardauthentifizierungs-Plugin für MySQL ](#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin) + [ ## Überschreiben von innodb\$1buffer\$1pool\$1size ](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-size) + [ ## Upgrade von MySQL 5.7 auf MySQL 8.4 ](#MySQL.Concepts.KnownIssuesAndLimitations.upgrade-8-4) + [ ## InnoDB-Seitenkomprimierung ](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-page-compression) ## Reserviertes Wort InnoDB `InnoDB` ist ein reserviertes Wort für RDS für MySQL. Sie können diesen Namen für eine MySQL-Datenbank nicht verwenden. ## Vollständiges Storage-Verhalten für Amazon RDS für MySQL Wenn der Speicher für eine MySQL-DB-Instance voll ist, kann es zu Inkonsistenzen bei Metadaten, Diskatorkonsistenzen und verwaisten Tabellen kommen. Um diese Probleme zu vermeiden, stoppt Amazon RDS automatisch eine DB-Instance, die den `storage-full` Status erreicht. Eine MySQL-DB-Instance erreicht den `storage-full` Status in den folgenden Fällen: + Die DB-Instance verfügt über weniger als 20 000 MiB Speicher, und der verfügbare Speicher erreicht 200 MiB oder weniger. + Die DB-Instance verfügt über mehr als 102.400 MiB Speicher, und der verfügbare Speicher erreicht 1024 MiB oder weniger. + Die DB-Instance verfügt über zwischen 20 000 MiB und 102.400 MiB Speicher und verfügt über weniger als 1% des verfügbaren Speichers. Nachdem eine DB-Instance automatisch Amazon RDS gestoppt wurde, weil sie den `storage-full` Status erreicht hat, können Sie sie immer noch ändern. Um die DB-Instance neu zu starten, führen Sie mindestens einen der folgenden Schritte aus: + Ändern Sie die DB-Instance, um die automatische Speicherung zu aktivieren. Weitere Informationen zum Autoscaling von Storage finden Sie unter [Automatische Kapazitätsverwaltung mit automatischer Amazon-RDS-Speicherskalierung](USER_PIOPS.Autoscaling.md). + Ändern Sie die DB-Instance, um ihre Speicherkapazität zu erhöhen. Weitere Informationen zur Erhöhung der Speicherkapazität finden Sie unter [Steigern der DB-Instance-Speicherkapazität](USER_PIOPS.ModifyingExisting.md). Nachdem Sie eine dieser Änderungen vorgenommen haben, wird die DB-Instance automatisch neu gestartet. Informationen zum Ändern einer DB-Instance finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). ## Inkonsistente Größe des InnoDB-Buffer-Pools Für MySQL 5.7 gibt es aktuell einen Bug beim Verwalten der Größe des InnoDB-Buffer-Pools. MySQL 5.7 könnte den Wert des Parameters `innodb_buffer_pool_size` an einen großen Wert anpassen, was dazu führen kann, dass der InnoDB-Buffer-Pool zu groß wird und dadurch zu viel Arbeitsspeicher verbraucht. Dieser Effekt kann dazu führen, dass die Ausführung der MySQL-Datenbank-Engine beendet wird oder die Engine nicht gestartet werden kann. Dieses Problem ist häufiger bei DB-Instance-Klassen vorhanden, die weniger Arbeitsspeicher zur Verfügung haben. Setzen Sie den Wert des Parameters `innodb_buffer_pool_size` auf ein Vielfaches des Produkts der Parameterwerte `innodb_buffer_pool_instances` und `innodb_buffer_pool_chunk_size`, um das Problem zu beheben. Sie könnten beispielsweise den Parameterwert `innodb_buffer_pool_size` auf das achtfache des Produkts der Parameterwerte `innodb_buffer_pool_instances` und `innodb_buffer_pool_chunk_size` setzen, wie im folgenden Beispiel gezeigt. ``` innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184 ``` Einzelheiten zu diesem MySQL 5.7-Bug finden Sie unter [https://bugs.mysql.com/bug.php? id=79379](https://bugs.mysql.com/bug.php?id=79379) in der MySQL-Dokumentation. ## Index-Merge-Optimierung zeigt falsche Ergebnisse an Abfragen über die Index-Merge-Optimierung geben aufgrund eines Fehlers im MySQL-Abfrageoptimierer, der in MySQL 5.5.37 eingeführt wurde, möglicherweise falsche Ergebnisse zurück. Wenn Sie eine Abfrage für eine Tabelle mit mehreren Indizes ausführen, scannt der Optimierer die Zeilenbereiche anhand der Indizes, führt die Ergebnisse jedoch nicht korrekt zusammen. Weitere Informationen zum Bug im Abfragenoptimierer finden Sie unter [http://bugs.mysql.com/bug.php?id=72745](https://bugs.mysql.com/bug.php?id=72745) und [http://bugs.mysql.com/bug.php?id=68194](https://bugs.mysql.com/bug.php?id=68194) in der MySQL-Bug-Datenbank. Denken Sie beispielsweise an eine Abfrage für eine Tabelle mit zwei Indizes, wobei die Suchmuster auf die indizierten Spalten verweisen. ``` 1. SELECT * FROM table1 2. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2'; ``` In diesem Fall durchsucht die Suchmaschine beide Indizes. Jedoch sind die zusammengeführten Ergebnisse aufgrund des Programmfehlers falsch. Um dieses Problem zu beheben, können Sie eine der folgenden Aktionen ausführen: + Stellen Sie den Parameter `optimizer_switch` in Ihrer DB-Parametergruppe für Ihre MySQL-DB-Instance auf `index_merge=off` ein. Weitere Informationen über das Einstellen von Parametern in DB-Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). + Führen Sie für Ihre MySQL-DB-Instance ein Upgrade auf MySQL Version 5.7 oder 8.0 durch. Weitere Informationen finden Sie unter [Upgrades der DB-Engine von RDS für MySQL](USER_UpgradeDBInstance.MySQL.md). + Wenn Sie Ihre Instance nicht upgraden oder den Parameter `optimizer_switch` nicht ändern können, können Sie alternativ einen Index für die Abfrage explizit bestimmen, beispielsweise so: ``` 1. SELECT * FROM table1 2. USE INDEX covering_index 3. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2'; ``` Weitere Informationen finden Sie unter [Index-Merge-Optimierung](https://dev.mysql.com/doc/refman/8.0/en/index-merge-optimization.html) in der MySQL-Dokumentation. ## MySQL-Parameterausnahmen für Amazon-RDS-DB-Instances Einige MySQL-Parameter erfordern besondere Beachtung bei der Verwendung in einer Amazon-RDS-DB-Instance. ### lower\$1case\$1table\$1names Da Amazon RDS ein Dateisystem mit Berücksichtigung von Groß- und Kleinschreibung verwendet, wird die Festlegung des Werts 2 für den Serverparameter `lower_case_table_names` (Namen werden wie angegeben gespeichert, aber in Kleinbuchstaben verglichen) nicht unterstützt. Nachfolgend sind die unterstützten Werte für Amazon RDS für MySQL DB-Instances aufgeführt: + 0 (Namen werden wie angegeben gespeichert und bei Vergleichen wird die Groß-/Kleinschreibung berücksichtigt) wird für alle RDS-für-MySQL-Versionen unterstützt. + 1 (Namen werden in Kleinbuchstaben gespeichert und bei Vergleichen wird die Groß- und Kleinschreibung nicht beachtet) wird für RDS für MySQL Version 5.7, Version 8.0.28 und höhere 8.0-Versionen sowie Version 8.4 unterstützt. Legen Sie den Parameter `lower_case_table_names` in einer benutzerdefinierten DB-Parametergruppe fest, bevor Sie eine DB-Instance erstellen. Stellen Sie dann die benutzerdefinierte DB-Parametergruppe ein, wenn Sie die DB-Instance erstellen. Wenn eine Parametergruppe mit einer MySQL-DB-Instance mit einer niedrigeren Version als 8.0 verknüpft ist, empfehlen wir, die Parameter `lower_case_table_names` in der Parametergruppe nicht zu ändern. Eine Änderung könnte zu Inkonsistenzen bei point-in-time Wiederherstellungs-Backups und Read Replica-DB-Instances führen. Wenn eine Parametergruppe mit einer DB-Instance von MySQL 8.0 oder 8.4 verknüpft ist, können Sie den Parameter `lower_case_table_names` in der Parametergruppe nicht ändern. Lesereplikate sollten immer den selben `lower_case_table_names`-Parameterwert wie die Quell-DB-Instance verwenden. ### long\$1query\$1time Sie können den Parameter `long_query_time` auf einen Fließkommawert einstellen, damit Sie langsame Abfragen im MySQL-Slow-Query-Protokoll in Mikrosekunden-Auflösung protokollieren können. Sie können einen Wert von z. B. 0,1 Sekunden einstellen (100 Millisekunden), um das Debuggen bei langsamen Transaktionen, die weniger als eine Sekunde dauern, zu erleichtern. ## MySQL-Dateigrößenlimits in Amazon RDS Für DB-Instances der MySQL-Versionen 8.0 und höher beträgt die maximale Dateigröße 16 TiB. Bei der Verwendung von file-per-table Tablespaces begrenzt die maximale Dateigröße die Größe einer InnoDB-Tabelle auf 16 TiB. file-per-tableInnoDB-Tablespaces (mit Tabellen in jeweils einem eigenen Tablespace) sind standardmäßig für MySQL-DB-Instances festgelegt. Weitere Informationen finden Sie unter [Limits für InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) in der MySQL-Dokumentation. **Anmerkung** Einige existierende DB-Instances haben eine Untergrenze. Beispielsweise haben MySQL-DB-Instances, die vor April 2014 erstellt wurden, ein Datei- und Tabellenlimit von 2 TB. Dieses Dateilimit von 2 TB gilt auch für DB-Instances oder Lesereplikate, die aus DB-Snapshots erstellt wurden, die vor April 2014 gemacht wurden, unabhängig davon wann die DB-Instance erstellt wurde. Die Verwendung von file-per-table InnoDB-Tablespaces hat je nach Ihrer Anwendung Vor- und Nachteile. Informationen zum besten Ansatz für Ihre Anwendung finden Sie unter [File-per-table Tablespaces](https://dev.mysql.com/doc/refman/8.0/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/8.0/en/partitioning.html) in der MySQL-Dokumentation. Da es keine einzelne Systemtabelle oder Ansicht gibt, in der die Größe aller Tabellen und des Tabellenraums des InnoDB-Systems angegeben ist, müssen Sie mehrere Tabellen abfragen, um die Größe der Tabellenräume zu ermitteln. **So ermitteln Sie die Größe des Tabellenraums des InnoDB-Systems und des Tabellenraums des Datenwörterbuchs** + Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob einer Ihrer Tabellenräume zu groß ist und eventuell partitioniert werden sollte. **Anmerkung** Der Tabellenraum des Datenwörterbuchs ist für MySQL 8.0 und höheren Versionen spezifisch. ``` 1. select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE) 2. /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES 3. where tablespace_name in ('mysql','innodb_system'); ``` **So ermitteln Sie die Größe von InnoDB-Benutzertabellen außerhalb des Tabellenraums des InnoDB-Systems (für MySQL 5.7-Versionen)** + Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Tabellen zu groß ist und evtl. partitioniert werden sollte. ``` 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 InnoDB-Benutzertabellen außerhalb des Tabellenraums des InnoDB-Systems (für MySQL 8.0 und höhere Versionen)** + Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Tabellen zu groß ist und evtl. partitioniert werden sollte. ``` 1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) 2. as "Tablespace Size (GB)" 3. FROM information_schema.INNODB_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'; ``` **Um file-per-table InnoDB-Tablespaces zu aktivieren** + Setzen Sie den Parameter *innodb\$1file\$1per\$1table* in der Parametergruppe für die DB-Instance auf `1`. **Um file-per-table InnoDB-Tablespaces zu deaktivieren** + Setzen Sie den Parameter *innodb\$1file\$1per\$1table* 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 file-per-table InnoDB-Tablespaces aktiviert oder deaktiviert haben, können Sie einen `ALTER TABLE` Befehl ausführen, um eine Tabelle vom globalen Tablespace in ihren eigenen Tablespace oder von ihrem eigenen Tablespace in den globalen Tablespace zu verschieben, wie im folgenden Beispiel gezeigt: ``` ALTER TABLE table_name TABLESPACE=innodb_file_per_table; ``` ## MySQL Keyring-Plugin wird nicht unterstützt Derzeit unterstützt Amazon RDS für MySQL das MySQL-Amazon-Web-Services-Keyring-Plugin `keyring_aws` nicht. ## Benutzerdefinierte Ports Amazon RDS blockiert Verbindungen zum benutzerdefinierten Port 33060 für die MySQL-Engine. Wählen Sie einen anderen Port für Ihre MySQL-Engine. ## Einschränkungen bei gespeicherten MySQL-Prozeduren Die gespeicherten Prozeduren [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) und [mysql.rds\$1kill\$1query](mysql-stored-proc-ending.md#mysql_rds_kill_query) können Sitzungen oder Abfragen von MySQL-Benutzern mit Benutzernamen, die länger als 16 Zeichen sind, in den folgenden Versionen von RDS für MySQL nicht beenden: + 8.0.32 und niedrigere 8-Versionen + 5.7.41 und niedrigere 5.7-Versionen ## GTID-basierte Replikation mit einer externen Quell-Instance Amazon RDS unterstützt die auf globalen Transaktions-Identifikatoren (GTIDs) basierende Replikation von einer externen MySQL-Instance in eine Amazon RDS for MySQL MySQL-DB-Instance, für die während der Konfiguration GTID\$1PURGED gesetzt werden muss. Diese Funktion wird jedoch nur in RDS für MySQL ab Version 8.0.37 unterstützt. ## Standardauthentifizierungs-Plugin für MySQL RDS für MySQL 8.0.34 und höhere 8.0-Versionen verwenden das Plugin `mysql_native_password`. Sie können die `default_authentication_plugin`-Einstellung nicht ändern. RDS für MySQL 8.4 und höhere Versionen verwenden das Plugin `caching_sha2_password` als Standard-Authentifizierungs-Plugin. Sie können das Standard-Authentifizierungs-Plugin für MySQL 8.4 ändern. Das Plugin `mysql_native_password` funktioniert weiterhin mit MySQL 8.4, aber die Unterstützung dieses Plugins endet mit MySQL 8.4. Um das Standard-Authentifizierungs-Plugin zu ändern, erstellen Sie eine benutzerdefinierte Parametergruppe und ändern den Wert des Parameters `authentication_policy`. Weitere Informationen finden Sie unter [Standard- und benutzerdefinierte Parametergruppen](parameter-groups-overview.md#parameter-groups-overview.custom). ## Überschreiben von innodb\$1buffer\$1pool\$1size Bei kleinen oder Mikro-DB-Instance-Klassen kann der Standardwert für den Parameter `innodb_buffer_pool_size` von dem Wert abweichen, der durch Ausführen des folgenden Befehls zurückgegeben wird: ``` mysql> SELECT @@innodb_buffer_pool_size; ``` Dieser Unterschied kann auftreten, wenn Amazon RDS im Rahmen der Verwaltung der DB-Instance-Klassen den Standardwert überschreiben muss. Bei Bedarf können Sie den Standardwert überschreiben und ihn auf einen Wert festlegen, den die DB-Instance-Klasse unterstützt. Um einen gültigen Wert zu ermitteln, addieren Sie die Speicherbelegung und den gesamten auf der DB-Instance verfügbaren Speicher. Weitere Informationen finden Sie unter [Amazon-RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/). Wenn die DB-Instance nur über 4 GB Arbeitsspeicher verfügt, können Sie den Parameter `innodb_buffer_pool_size` nicht auf 8 GB festlegen. Sie können ihn jedoch möglicherweise auf 3 GB festlegen, je nachdem, wie viel Speicherplatz Sie für andere Parameter zugewiesen haben. Wenn der von Ihnen eingegebene Wert zu groß ist, senkt Amazon RDS den Wert auf die folgenden Grenzwerte: + Micro-DB-Instance-Klassen: 256 MB + db.t4g.micro-DB-Instance-Klassen: 128 MB ## Upgrade von MySQL 5.7 auf MySQL 8.4 Sie können nicht direkt ein Upgrade von MySQL 5.7 auf MySQL 8.4 durchführen. Sie müssen zuerst ein Upgrade von MySQL 5.7 auf MySQL 8.0 und dann ein Upgrade von MySQL 8.0 auf MySQL 8.4 durchführen. Weitere Informationen finden Sie unter [Hauptversion-Upgrades von RDS für MySQL](USER_UpgradeDBInstance.MySQL.Major.md). ## InnoDB-Seitenkomprimierung Die InnoDB-Seitenkomprimierung funktioniert nicht mit Amazon-RDS-DB-Instances, die eine Dateisystem-Blockgröße von 16 KB haben, da diese Blockgröße kleiner als die InnoDB-Seitengröße sein muss. Ab Februar 2024 haben alle neu erstellten DB-Instances eine Dateisystem-Blockgröße von 16 KB, was den Durchsatz erhöht und den IOPS-Bedarf bei Seitenlöschungen senkt. # Referenz für gespeicherte RDS-für-MySQL-Verfahren Diese Themen beschreiben gespeicherte Prozeduren, die für Amazon RDS-Instances verfügbar sind, die die MySQL-DB-Engine ausführen. Diese Prozeduren müssen vom Hauptbenutzer ausgeführt werden. **Topics** + [ # Erfassen und Verwalten des globalen Statusverlaufs ](mysql-stored-proc-gsh.md) + [ # Konfigurieren, Starten und Beenden der Binärprotokollreplikation (binlog) ](mysql-stored-proc-replicating.md) + [ # Beenden einer Sitzung oder Abfrage ](mysql-stored-proc-ending.md) + [ # Verwalten von Aktiv/Aktiv-Clustern ](mysql-stored-proc-active-active-clusters.md) + [ # Verwalten der Multi-Source-Replikation ](mysql-stored-proc-multi-source-replication.md) + [ # Transaktionen replizieren mit GTIDs ](mysql-stored-proc-gtid.md) + [ # Rotieren der Abfrageprotokolle ](mysql-stored-proc-logging.md) + [ # Festlegen und Anzeigen der Konfiguration des Binärprotokolls ](mysql-stored-proc-configuring.md) + [ # Wärmen des InnoDB-Caches ](mysql-stored-proc-warming.md) # Erfassen und Verwalten des globalen Statusverlaufs Amazon RDS stellt einen Satz von Verfahren bereit, die Snapshots der Werte dieser Statusvariablen im Zeitverlauf erstellen und diese zusammen mit allen Änderungen seit dem letzten Snapshot in eine Tabelle schreiben. Diese Infrastruktur wird als Global Status History bezeichnet. Weitere Informationen finden Sie unter [Verwalten des globalen Statusverlaufs für RDS für MySQL](Appendix.MySQL.CommonDBATasks.GoSH.md). Die folgenden gespeicherten Verfahren verwalten, wie die Global Status History erfasst und verwaltet wird. **Topics** + [ ## mysql.rds\$1collect\$1global\$1status\$1history ](#mysql_rds_collect_global_status_history) + [ ## mysql.rds\$1disable\$1gsh\$1collector ](#mysql_rds_disable_gsh_collector) + [ ## mysql.rds\$1disable\$1gsh\$1rotation ](#mysql_rds_disable_gsh_rotation) + [ ## mysql.rds\$1enable\$1gsh\$1collector ](#mysql_rds_enable_gsh_collector) + [ ## mysql.rds\$1enable\$1gsh\$1rotation ](#mysql_rds_enable_gsh_rotation) + [ ## mysql.rds\$1rotate\$1global\$1status\$1history ](#mysql_rds_rotate_global_status_history) + [ ## mysql.rds\$1set\$1gsh\$1collector ](#mysql_rds_set_gsh_collector) + [ ## mysql.rds\$1set\$1gsh\$1rotation ](#mysql_rds_set_gsh_rotation) ## mysql.rds\$1collect\$1global\$1status\$1history Generiert einen Snapshot auf Anforderung für den globalen Statusverlauf (Global Status History, GoSH). ### Syntax ``` CALL mysql.rds_collect_global_status_history; ``` ## mysql.rds\$1disable\$1gsh\$1collector Deaktiviert die periodische Generierung von Snapshots des globalen Statusverlaufs (Global Status History, GoSH). ### Syntax ``` CALL mysql.rds_disable_gsh_collector; ``` ## mysql.rds\$1disable\$1gsh\$1rotation Schaltet die Rotation der `mysql.global_status_history`-Tabelle aus. ### Syntax ``` CALL mysql.rds_disable_gsh_rotation; ``` ## mysql.rds\$1enable\$1gsh\$1collector Aktiviert den globalen Statusverlauf (Global Status History, GoSH), um Standard-Snapshots in zeitlichen Abständen, die mithilfe von `rds_set_gsh_collector` festgelegt wurden, zu generieren. ### Syntax ``` CALL mysql.rds_enable_gsh_collector; ``` ## mysql.rds\$1enable\$1gsh\$1rotation Aktiviert die Rotation der Inhalte der Tabelle `mysql.global_status_history` zu `mysql.global_status_history_old` in zeitlichen Abständen, die durch `rds_set_gsh_rotation` angegeben werden. ### Syntax ``` CALL mysql.rds_enable_gsh_rotation; ``` ## mysql.rds\$1rotate\$1global\$1status\$1history Rotiert die Inhalte der Tabelle `mysql.global_status_history` bei Anforderung zu `mysql.global_status_history_old`. ### Syntax ``` CALL mysql.rds_rotate_global_status_history; ``` ## mysql.rds\$1set\$1gsh\$1collector Gibt den zeitlichen Abstand für die Generierung von aufeinander folgenden Snapshots durch den globalen Statusverlauf (Global Status History, GoSH) an. ### Syntax ``` CALL mysql.rds_set_gsh_collector(intervalPeriod); ``` ### Parameter *intervalPeriod* Der zeitliche Abstand in Minuten für die periodische Generierung von Snapshots. Der Standardwert ist `5`. ## mysql.rds\$1set\$1gsh\$1rotation Gibt den zeitlichen Abstand in Tagen für die periodische Rotation der Tabelle `mysql.global_status_history` an. ### Syntax ``` CALL mysql.rds_set_gsh_rotation(intervalPeriod); ``` ### Parameter *intervalPeriod* Der zeitliche Abstand in Tagen für die periodische Tabellenrotation. Der Standardwert ist `7`. # Konfigurieren, Starten und Beenden der Binärprotokollreplikation (binlog) Die folgenden gespeicherten Prozeduren steuern, wie Transaktionen aus einer externen Datenbank in RDS für MySQL oder aus Aurora für MySQL in eine externen Datenbank repliziert werden. Wenn Sie gespeicherte Prozeduren verwenden, um die Replikation mit einem mit `caching_sha2_password` konfigurierten Replikationsbenutzer zu verwalten, müssen Sie TLS konfigurieren, indem Sie `SOURCE_SSL=1` festlegen. `caching_sha2_password` ist das Standard-Authentifizierungs-Plugin für RDS für MySQL 8.4. Weitere Informationen finden Sie unter [Verschlüsseln mit SSL/TLS](mysql-ssl-connections.md). Informationen zum Konfigurieren, Verwenden und Verwalten von Lesereplikaten finden Sie unter [Arbeiten mit MySQL-Lesereplikaten](USER_MySQL.Replication.ReadReplicas.md). **Topics** + [ ## ](#mysql_rds_next_master_log) + [ ## mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher) ](#mysql_rds_next_source_log) + [ ## mysql.rds\$1next\$1master\$1log (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger) ](#mysql_rds_reset_external_master) + [ ## mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher) ](#mysql_rds_reset_external_source) + [ ## mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger) ](#mysql_rds_set_external_master) + [ ## mysql.rds\$1set\$1external\$1source (RDS-für-MySQL-Hauptversionen 8.4 und höher) ](#mysql_rds_set_external_source) + [ ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.0 und niedriger) ](#mysql_rds_set_external_master_with_auto_position) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.4 und höher) ](#mysql_rds_set_external_source_with_auto_position) + [ ## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger) ](#mysql_rds_set_external_master_with_delay) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS-für-MySQL-Hauptversionen 8.4 und höher) ](#mysql_rds_set_external_source_with_delay) + [ ## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged ](#mysql_rds_set_external_source_gtid_purged) + [ ## ](#mysql_rds_set_master_auto_position) + [ ## mysql.rds\$1set\$1source\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.4 und höher) ](#mysql_rds_set_source_auto_position) + [ ## mysql.rds\$1set\$1source\$1delay ](#mysql_rds_set_source_delay) + [ ## mysql.rds\$1skip\$1repl\$1error ](#mysql_rds_skip_repl_error) + [ ## mysql.rds\$1start\$1replication ](#mysql_rds_start_replication) + [ ## ](#mysql_rds_start_replication_until) + [ ## mysql.rds\$1stop\$1replication ](#mysql_rds_stop_replication) ## Ändert die Protokollposition der Quelldatenbankinstance in den Anfang des nächsten Binärprotokolls auf der Quelldatenbankinstance. Verwenden Sie dieses Verfahren nur, wenn Sie bei einer Read Replica den Replikationsfehler 1236 erhalten. I/O ### Syntax ``` CALL mysql.rds_next_master_log( curr_master_log ); ``` ### Parameters *curr\$1master\$1log* Der Index der aktuellen Master-Protokolldatei. Der Index ist im Dateinamen codiert. Eine aktuelle Datei mit dem Namen `mysql-bin-changelog.012345` hat beispielsweise den Index 12345. Um den Namen der aktuellen Master-Protokolldatei zu ermitteln, führen Sie den Befehl `SHOW REPLICA STATUS` aus. Sie finden den Namen anschließend im Feld `Master_Log_File`. ### Nutzungshinweise Die Prozedur `mysql.rds_next_master_log` muss vom Hauptbenutzer ausgeführt werden. **Warnung** Rufen Sie `mysql.rds_next_master_log` nur auf, wenn die Replikation nach einem Failover einer Multi-AZ-DB-Instance, die die Replikationsquelle ist, fehlschlägt und das `Last_IO_Errno` Feld den Fehler 1236 meldet. `SHOW REPLICA STATUS` I/O Ein Aufruf von `mysql.rds_next_master_log` kann zu Datenverlust im Lesereplikat führen, falls Transaktionen in der Quell-Instance nicht in das binäre Protokoll auf der Festplatte geschrieben wurden, bevor das Failover-Ereignis auftrat. Sie können durch Festlegung der Quell-Instance-Parameter `sync_binlog` und `innodb_support_xa` auf `1` das Risiko dafür verringern, obwohl dies zu einer Reduzierung der Leistung führen kann. Weitere Informationen finden Sie unter [Fehlerbehebung für ein Problem mit einer MySQL Read Replica](USER_ReadRepl.Troubleshooting.md). ### Beispiele Angenommen, die Replikation schlägt auf einer RDS-für-MySQL- -Read Replica fehl. Die Ausführung von `SHOW REPLICA STATUS\G` für das Lesereplikat gibt das folgende Ergebnis zurück: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 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: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Den Angeben im Feld `Last_IO_Errno` ist zu entnehmen, dass die Instance eine I/O-Fehlermeldung mit der Nummer 1236 erhalten hat. Dem Feld `Master_Log_File` ist zudem zu entnehmen, dass die betroffene Protokolldatei den Namen `mysql-bin-changelog.012345` aufweist und ihr Index folglich `12345` lautet. Zur Behebung des Fehlers können Sie dann `mysql.rds_next_master_log` mit dem folgenden Parameter aufrufen: ``` CALL mysql.rds_next_master_log(12345); ``` ## mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher) Ändert die Protokollposition der Quelldatenbankinstance in den Anfang des nächsten Binärprotokolls auf der Quelldatenbankinstance. Verwenden Sie dieses Verfahren nur, wenn Sie bei einer Read Replica den I/O Replikationsfehler 1236 erhalten. ### Syntax ``` CALL mysql.rds_next_source_log( curr_source_log ); ``` ### Parameters *curr\$1source\$1log* Der Index der aktuellen Quell-Protokolldatei. Der Index ist im Dateinamen codiert. Eine aktuelle Datei mit dem Namen `mysql-bin-changelog.012345` hat beispielsweise den Index 12345. Um den Namen der aktuellen Quell-Protokolldatei zu ermitteln, führen Sie den Befehl `SHOW REPLICA STATUS` aus. Sie finden den Namen anschließend im Feld `Source_Log_File`. ### Nutzungshinweise Der Administrator muss das `mysql.rds_next_source_log`-Verfahren ausführen. **Warnung** Rufen Sie `mysql.rds_next_source_log` nur auf, wenn die Replikation nach einem Failover einer Multi-AZ-DB-Instance, die die Replikationsquelle ist, fehlschlägt und das `Last_IO_Errno` Feld den Fehler 1236 meldet. `SHOW REPLICA STATUS` I/O Ein Aufruf von `mysql.rds_next_source_log` kann zu Datenverlust im Lesereplikat führen, falls Transaktionen in der Quell-Instance nicht in das binäre Protokoll auf der Festplatte geschrieben wurden, bevor das Failover-Ereignis auftrat. Sie können durch Festlegung der Quell-Instance-Parameter `sync_binlog` und `innodb_support_xa` auf `1` das Risiko dafür verringern, obwohl dies zu einer Reduzierung der Leistung führen kann. Weitere Informationen finden Sie unter [Fehlerbehebung für ein Problem mit einer MySQL Read Replica](USER_ReadRepl.Troubleshooting.md). ### Beispiele Angenommen, die Replikation schlägt auf einer RDS-für-MySQL- -Read Replica fehl. Die Ausführung von `SHOW REPLICA STATUS\G` für das Lesereplikat gibt das folgende Ergebnis zurück: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 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_Source: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Den Angeben im Feld `Last_IO_Errno` ist zu entnehmen, dass die Instance eine I/O-Fehlermeldung mit der Nummer 1236 erhalten hat. Dem Feld `Source_Log_File` ist zudem zu entnehmen, dass die betroffene Protokolldatei den Namen `mysql-bin-changelog.012345` aufweist und ihr Index folglich `12345` lautet. Zur Behebung des Fehlers können Sie dann `mysql.rds_next_source_log` mit dem folgenden Parameter aufrufen: ``` CALL mysql.rds_next_source_log(12345); ``` ## mysql.rds\$1next\$1master\$1log (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger) Rekonfiguriert eine RDS-für-MySQL-DB-Instance, sodass sie keine Read Replica einer Instance von MySQL außerhalb von Amazon RDS ist. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_reset_external_master; ``` ### Nutzungshinweise Die Prozedur `mysql.rds_reset_external_master` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die nicht mehr Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance sein soll. **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Informationen zur Verwaltung der Replikation zwischen Amazon-RDS-DB-Instances finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Weitere Informationen zur Verwendung von Replikation für den Import von Daten aus einer außerhalb von Amazon RDS ausgeführten MySQL-Instance finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md). ## mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher) Rekonfiguriert eine RDS-für-MySQL-DB-Instance, sodass sie keine Read Replica einer Instance von MySQL außerhalb von Amazon RDS ist. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_reset_external_source; ``` ### Nutzungshinweise Der Administrator muss das `mysql.rds_reset_external_source`-Verfahren ausführen. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die nicht mehr Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance sein soll. **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Informationen zur Verwaltung der Replikation zwischen Amazon-RDS-DB-Instances finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Weitere Informationen zur Verwendung von Replikation für den Import von Daten aus einer außerhalb von Amazon RDS ausgeführten MySQL-Instance finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md). ## mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger) Konfiguriert eine RDS-für-MySQL-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). **Anmerkung** Sie können die gespeicherte Prozedur [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](#mysql_rds_set_external_master_with_delay) zum Konfigurieren einer externer Quelldatenbank-Instance und einer verzögerten Replikation verwenden. ### Syntax ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Quelldatenbank-Instance festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-Instance konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position in der binären Protokolldatei `mysql_binary_log_file_name`, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binlog-Datei ermitteln, indem Sie `SHOW MASTER STATUS`auf der Quelldatenbank-Instance starten. *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` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Vor der Ausführung von `mysql.rds_set_external_master` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` bereitstellen, die auf einen Replikationsbenutzer verweisen, der über die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance verfügt. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein -Beispiel gezeigt. **MySQL 5.7** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password'; ``` **Anmerkung** Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an. 1. Erteilen Sie innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer 'repl\$1user' für Ihre Domäne die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für alle Datenbanken erteilt. **MySQL 5.7** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Um die verschlüsselte Replikation zu verwenden, konfigurieren Sie die Quelldatenbank-Instance für die Verwendung von SSL-Verbindungen. **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. 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` aufgerufen haben, um eine Amazon-RDS-DB-Instance als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten 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_rds_reset_external_master) die Lesereplikat-Konfiguration zu entfernen. Beim Aufrufen von `mysql.rds_set_external_master` werden von Amazon RDS Uhrzeit, Benutzer und eine Aktion von `set master` in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` protokolliert. ### Beispiele Bei Ausführung innerhalb einer MySQL-DB-Instance konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. ``` call mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1source (RDS-für-MySQL-Hauptversionen 8.4 und höher) Konfiguriert eine RDS-für-MySQL-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Quelldatenbank-Instance festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-Instance konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position in der binären Protokolldatei `mysql_binary_log_file_name`, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binlog-Datei ermitteln, indem Sie `SHOW MASTER STATUS`auf der Quelldatenbank-Instance starten. *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 `SOURCE_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 Der Administrator muss das `mysql.rds_set_external_source`-Verfahren ausführen. Dieses Verfahren muss auf der DB-Instance von RDS für MySQL ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Vor der Ausführung von `mysql.rds_set_external_source` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` bereitstellen, die auf einen Replikationsbenutzer verweisen, der über die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance verfügt. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. 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 innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer 'repl\$1user' für Ihre Domäne die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Um die verschlüsselte Replikation zu verwenden, konfigurieren Sie die Quelldatenbank-Instance für die Verwendung von SSL-Verbindungen. Importieren Sie außerdem mit der Prozedur [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html) das Zertifizierungsstellenzertifikat, das Clientzertifikat und den Clientschlüssel in die DB-Instance bzw. den DB-Cluster. **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. 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_source` aufgerufen haben, um eine DB-Instance von RDS für MySQL als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten Zudem haben Sie die Möglichkeit, mit einem Aufruf von [mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher)](#mysql_rds_reset_external_source) die Lesereplikat-Konfiguration zu entfernen. Beim Aufrufen von `mysql.rds_set_external_source` werden von Amazon RDS Uhrzeit, Benutzer und eine Aktion von `set master` in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` protokolliert. ### Beispiele Bei Ausführung auf einer DB-Instance von RDS für MySQL konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. ``` call mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.0 und niedriger) Konfiguriert eine RDS für MySQL-DB-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. Bei diesem Verfahren werden auch verzögerte Replikation und Replikation auf der Grundlage globaler Transaktions-Identifikatoren () konfiguriert. GTIDs **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Quelldatenbank-Instance festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-Instance konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *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. *delay* Die Mindestanzahl von Sekunden, um die Replikation von der Quelldatenbank-Instance zu verzögern. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). ### Nutzungshinweise Die Prozedur `mysql.rds_set_external_master_with_auto_position` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Diese Prozedur wird für alle RDS für MySQL 5.7 und RDS für MySQL 8.0.26 und höhere 8.0-Versionen unterstützt. Vor der Ausführung von `mysql.rds_set_external_master_with_auto_position` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` angeben. Diese Werte müssen einen Replikationsbenutzer mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance angeben. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Erteilen Sie innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer `REPLICATION CLIENT` für Ihre Domäne die Berechtigungen `REPLICATION SLAVE` und `'repl_user'` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Weitere Informationen finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md). **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Informationen zur Verwaltung der Replikation zwischen Amazon-RDS-DB-Instances finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Stellen Sie vor dem Aufrufen von `mysql.rds_set_external_master_with_auto_position` sicher, dass Sie [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) aufrufen, um die Systemvariable `gtid_purged` mit einem bestimmten GTID-Bereich aus einer externen Quelle aufrufen. Nachdem Sie `mysql.rds_set_external_master_with_auto_position` aufgerufen haben, um eine Amazon-RDS-DB-Instance als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten 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_rds_reset_external_master) die Lesereplikat-Konfiguration zu entfernen. Beim Aufruf von `mysql.rds_set_external_master_with_auto_position` zeichnet Amazon RDS die Uhrzeit, den Benutzer und eine `set master`-Aktion in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` auf. Für die Notfallwiederherstellung können Sie diese Prozedur mit der gespeicherten Prozedur [](#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden. Um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen, können Sie die Prozedur `mysql.rds_set_external_master_with_auto_position` ausführen. Nachdem die Prozedur `mysql.rds_start_replication_until_gtid` die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md)). Um die Prozedur `mysql.rds_rds_start_replication_until_gtid` verwenden zu können, muss die GTID-basierte Replikation aktiviert sein. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie einen Notfall verursacht, können Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). ### Beispiele Bei Ausführung innerhalb einer MySQL-DB-Instance konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. Die minimale Replikationsverzögerung wird für die MySQL-DB-Instance auf eine Stunde (3600 Sekunden) gesetzt. Eine Änderung an der MySQL-Quelldatenbankinstance, die außerhalb von Amazon RDS ausgeführt wird, wird frühestens nach einer Stunde in das Lesereplikat der MySQL-DB-Instance übernommen. ``` call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.4 und höher) Konfiguriert eine RDS für MySQL-DB-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. Bei diesem Verfahren werden auch verzögerte Replikation und Replikation auf der Grundlage globaler Transaktions-Identifikatoren () konfiguriert. GTIDs **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Quelldatenbank-Instance festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-Instance konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *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 `SOURCE_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. *delay* Die Mindestanzahl von Sekunden, um die Replikation von der Quelldatenbank-Instance zu verzögern. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). ### Nutzungshinweise Der Administrator muss das `mysql.rds_set_external_source_with_auto_position`-Verfahren ausführen. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Vor der Ausführung von `mysql.rds_set_external_source_with_auto_position` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` angeben. Diese Werte müssen einen Replikationsbenutzer mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance angeben. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Erteilen Sie innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer `REPLICATION CLIENT` für Ihre Domäne die Berechtigungen `REPLICATION SLAVE` und `'repl_user'` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Weitere Informationen finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md). **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Informationen zur Verwaltung der Replikation zwischen Amazon-RDS-DB-Instances finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Stellen Sie vor dem Aufrufen von `mysql.rds_set_external_source_with_auto_position` sicher, dass Sie [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) aufrufen, um die Systemvariable `gtid_purged` mit einem bestimmten GTID-Bereich aus einer externen Quelle aufrufen. Nachdem Sie `mysql.rds_set_external_source_with_auto_position` aufgerufen haben, um eine Amazon-RDS-DB-Instance als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten Zudem haben Sie die Möglichkeit, mit einem Aufruf von [mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher)](#mysql_rds_reset_external_source) die Lesereplikat-Konfiguration zu entfernen. Beim Aufruf von `mysql.rds_set_external_source_with_auto_position` zeichnet Amazon RDS die Uhrzeit, den Benutzer und eine `set master`-Aktion in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` auf. Für die Notfallwiederherstellung können Sie diese Prozedur mit der gespeicherten Prozedur [](#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden. Um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen, können Sie die Prozedur `mysql.rds_set_external_source_with_auto_position` ausführen. Nachdem die Prozedur `mysql.rds_start_replication_until_gtid` die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md)). Um die Prozedur `mysql.rds_rds_start_replication_until_gtid` verwenden zu können, muss die GTID-basierte Replikation aktiviert sein. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie einen Notfall verursacht, können Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). ### Beispiele Bei Ausführung innerhalb einer MySQL-DB-Instance konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. Die minimale Replikationsverzögerung wird für die MySQL-DB-Instance auf eine Stunde (3600 Sekunden) gesetzt. Eine Änderung an der MySQL-Quelldatenbankinstance, die außerhalb von Amazon RDS ausgeführt wird, wird frühestens nach einer Stunde in das Lesereplikat der MySQL-DB-Instance übernommen. ``` call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 1, 3600); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger) Konfiguriert eine RDS für MySQL-DB-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance und konfiguriert die verzögerte Replikation. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_master_with_delay( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Replikations-Master festgelegt werden soll *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-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* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position innerhalb der für `mysql_binary_log_file_name` angegebenen binären Protokolldatei, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binlog-Datei ermitteln, indem Sie `SHOW MASTER STATUS` auf der Quelldatenbank-Instance starten. *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. *delay* Die Mindestanzahl von Sekunden, um die Replikation von der Quelldatenbank-Instance zu verzögern. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). ### Nutzungshinweise Die Prozedur `mysql.rds_set_external_master_with_delay` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Vor der Ausführung von `mysql.rds_set_external_master_with_delay` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` angeben. Diese Werte müssen einen Replikationsbenutzer mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance angeben. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Erteilen Sie innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer `REPLICATION CLIENT` für Ihre Domäne die Berechtigungen `REPLICATION SLAVE` und `'repl_user'` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Weitere Informationen finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md). **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. 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_with_delay` aufgerufen haben, um eine Amazon-RDS-DB-Instance als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten 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_rds_reset_external_master) die Lesereplikat-Konfiguration zu entfernen. Beim Aufruf von `mysql.rds_set_external_master_with_delay` zeichnet Amazon RDS die Uhrzeit, den Benutzer und eine `set master`-Aktion in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` auf. Für die Notfallwiederherstellung können Sie diese Prozedur mit der gespeicherten Prozedur [](#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden. Um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen, können Sie die Prozedur `mysql.rds_set_external_master_with_delay` ausführen. Nachdem die Prozedur `mysql.rds_start_replication_until` die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md)). Um die Prozedur `mysql.rds_rds_start_replication_until_gtid` verwenden zu können, muss die GTID-basierte Replikation aktiviert sein. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie einen Notfall verursacht, können Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). Die gespeicherte Prozedur `mysql.rds_set_external_master_with_delay` ist für die folgenden Versionen von RDS für MySQL verfügbar: + MySQL 8.0.26 und höhere 8.0-Versionen + Alle 5.7-Versionen ### Beispiele Bei Ausführung innerhalb einer MySQL-DB-Instance konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. Die minimale Replikationsverzögerung wird für die MySQL-DB-Instance auf eine Stunde (3600 Sekunden) gesetzt. Eine Änderung an der MySQL-Quelldatenbankinstance, die außerhalb von Amazon RDS ausgeführt wird, wird frühestens nach einer Stunde in das Lesereplikat der MySQL-DB-Instance übernommen. ``` call mysql.rds_set_external_master_with_delay( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 'mysql-bin-changelog.000777', 120, 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS-für-MySQL-Hauptversionen 8.4 und höher) Konfiguriert eine RDS für MySQL-DB-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance und konfiguriert die verzögerte Replikation. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_source_with_delay ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Replikations-Master festgelegt werden soll *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-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* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position innerhalb der für `mysql_binary_log_file_name` angegebenen binären Protokolldatei, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binlog-Datei ermitteln, indem Sie `SHOW MASTER STATUS` auf der Quelldatenbank-Instance starten. *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 `SOURCE_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. *delay* Die Mindestanzahl von Sekunden, um die Replikation von der Quelldatenbank-Instance zu verzögern. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). ### Nutzungshinweise Der Administrator muss das `mysql.rds_set_external_source_with_delay`-Verfahren ausführen. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Vor der Ausführung von `mysql.rds_set_external_source_with_delay` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` angeben. Diese Werte müssen einen Replikationsbenutzer mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance angeben. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Erteilen Sie innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer `REPLICATION CLIENT` für Ihre Domäne die Berechtigungen `REPLICATION SLAVE` und `'repl_user'` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Weitere Informationen finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md). **Anmerkung** Wir empfehlen, Lesereplikate zur Verwaltung der Replikation zwischen zwei Amazon-RDS-DB-Instances zu verwenden, sofern dies möglich ist. In diesem Fall sollten Sie nur diese und andere replikationsbezogene gespeicherte Prozeduren verwenden. Bei dieser Vorgehensweise sind komplexere Replikationstopologien zwischen Amazon-RDS-DB-Instances möglich. Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. 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_source_with_delay` aufgerufen haben, um eine Amazon-RDS-DB-Instance als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten Zudem haben Sie die Möglichkeit, mit einem Aufruf von [mysql.rds\$1next\$1source\$1log (RDS-für-MySQL-Hauptversionen 8.4 und höher)](#mysql_rds_reset_external_source) die Lesereplikat-Konfiguration zu entfernen. Beim Aufruf von `mysql.rds_set_external_source_with_delay` zeichnet Amazon RDS die Uhrzeit, den Benutzer und eine `set master`-Aktion in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` auf. Für die Notfallwiederherstellung können Sie diese Prozedur mit der gespeicherten Prozedur [](#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden. Um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen, können Sie die Prozedur `mysql.rds_set_external_source_with_delay` ausführen. Nachdem die Prozedur `mysql.rds_start_replication_until` die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md)). Um die Prozedur `mysql.rds_rds_start_replication_until_gtid` verwenden zu können, muss die GTID-basierte Replikation aktiviert sein. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie einen Notfall verursacht, können Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). ### Beispiele Bei Ausführung innerhalb einer MySQL-DB-Instance konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. Die minimale Replikationsverzögerung wird für die MySQL-DB-Instance auf eine Stunde (3600 Sekunden) gesetzt. Eine Änderung an der MySQL-Quelldatenbankinstance, die außerhalb von Amazon RDS ausgeführt wird, wird frühestens nach einer Stunde in das Lesereplikat der MySQL-DB-Instance übernommen. ``` call mysql.rds_set_external_source_with_delay( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 'mysql-bin-changelog.000777', 120, 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged Legt die Systemvariable [gtid\$1purged](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_purged) auf einen angegebenen GTID-Bereich aus einer externen Quelle fest. Der Wert `gtid_purged` ist für die Konfiguration der GTID-basierten Replikation erforderlich, um die Replikation mithilfe der automatischen Positionierung fortzusetzen. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_source_gtid_purged( server_uuid , start_pos , end_pos ); ``` ### Parameters *server\$1uuid* Der Universally Unique Identifier (UUID) des externen Servers, von dem der GTID-Bereich importiert wird. *start\$1pos* Die Startposition des festzulegenden GTID-Bereichs. *end\$1pos* Die Startposition des festzulegenden GTID-Bereichs. ### Nutzungshinweise Das Verfahren `mysql.rds_set_external_source_gtid_purged` ist nur mit MySQL 8.0.37 und höheren 8.0-Versionen verfügbar. Rufen Sie `mysql.rds_set_external_source_gtid_purged` vor [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](#mysql_rds_set_external_master_with_auto_position), [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.4 und höher)](#mysql_rds_set_external_source_with_auto_position) oder [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_set_external_source_with_auto_position_for_channel) auf. Stellen Sie vor dem Anruf von `mysql.rds_set_external_source_gtid_purged` sicher, dass alle aktiven Replikationskanäle für die Datenbank beendet wurden. Verwenden Sie die MySQL-Anweisung `SHOW REPLICA STATUS`, um den Status eines Kanals zu überprüfen. Um die Replikation auf einem Kanal zu beenden, rufen Sie [mysql.rds\$1stop\$1replication\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_stop_replication_for_channel) auf. Der von Ihnen angegebene GTID-Bereich muss eine übergeordnete Menge des vorhandenen `GTID_PURGED`-Werts sein. Dieses gespeicherte Verfahren überprüft die folgenden Werte, bevor der Wert `GTID_PURGED` festlegt wird: + Die `server_uuid` ist gültig. + Der Wert von `start_pos` ist größer als `0` und kleiner als der Wert von `end_pos`. + Der Wert von `end_pos` ist größer oder gleich dem Wert von `start_pos`. Wenn die auf Ihrem externen Server festgelegte GTID mehrere Wertebereiche enthält, sollten Sie erwägen, das Verfahren mehrmals mit unterschiedlichen GTID-Satzwerten aufzurufen. Beim Aufruf von `mysql.rds_set_external_source_gtid_purged` zeichnet Amazon RDS die Uhrzeit, den Benutzer und eine `set gtid_purged`-Aktion in der Tabelle `mysql.rds_history` auf. Wenn Sie den Wert `gtid_purged` für die Sicherung, die Sie für die Replikation verwenden, nicht angemessen festlegen, kann dies dazu führen, dass während des Replikationsvorgangs Transaktionen fehlen oder doppelt vorhanden sind. Führen Sie die folgenden Schritte aus, um den richtigen `gtid_purged`-Wert festzulegen. **So legen Sie den Wert „gtid\$1purged“ für das Replikat fest** 1. Ermitteln Sie den Zeitpunkt oder die spezifische Sicherungsdatei, die als Ausgangspunkt für die Replikation verwendet werden soll. Dies kann eine logische Sicherung (eine mysqldump-Datei) oder eine physische Sicherung (ein Amazon-RDS-Snapshot) sein. 1. Ermitteln Sie den Wert `gtid_executed`. Dieser Wert stellt die Menge aller Daten dar GTIDs , die auf dem Server festgeschrieben wurden. Führen Sie auf der Quell-Instance einen der folgenden Schritte aus, um diesen Wert abzurufen: + Führen Sie die SQL-Anweisung `SELECT @@GLOBAL.GTID_EXECUTED;` zum Zeitpunkt der Sicherung aus. + Wenn das jeweilige Sicherungsdienstprogramm zugehörige Optionen enthält, extrahieren Sie den Wert aus der Sicherungsdatei. Weitere Informationen finden Sie in der MySQL-Dokumentation zu der [set-gtid-purged](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html#option_mysqldump_set-gtid-purged)Option. 1. Ermitteln Sie den Wert `gtid_purged`, der für den Aufruf von `mysql.rds_set_external_source_gtid_purged` verwendet werden soll. Der `gtid_purged` Wert sollte alle enthalten GTIDs , die auf der Quellinstanz ausgeführt wurden und nicht mehr für die Replikation benötigt werden. Daher sollte der Wert `gtid_purged` eine Teilmenge des im vorherigen Schritt abgerufenen `gtid_executed`-Werts sein. Um den `gtid_purged` Wert zu ermitteln, identifizieren Sie GTIDs diejenigen, die nicht im Backup enthalten sind und nicht mehr für die Replikation benötigt werden. Sie können dies tun, indem Sie die Binärprotokolle analysieren oder ein Tool wie mysqlbinlog verwenden, um diejenigen zu finden GTIDs , die aus den Binärprotokollen gelöscht wurden. Wenn Sie über eine konsistente Sicherung verfügen, die alle Binärprotokolle bis zum Sicherungspunkt umfasst, können Sie den Wert alternativ so festlegen, dass er dem `gtid_purged`-Wert am Sicherungspunkt entspricht. `gtid_executed` 1. Nachdem Sie den entsprechenden `gtid_purged`-Wert ermittelt haben, der mit Ihrer Sicherung konsistent ist, rufen Sie das gespeicherte `mysql.rds_set_external_source_gtid_purged`-Verfahren auf Ihrer DB-Instance von RDS für MySQL auf, um den Wert festzulegen. ### Beispiele Bei der Ausführung auf einer MySQL-DB-Instance legt das folgende Beispiel den GTID-Bereich von einem externen MySQL-Server mit der UUID `12345678-abcd-1234-efgh-123456789abc`, einer Startposition von `1` und einer Endposition von `100` fest. Der resultierende GTID-Wert ist auf `+12345678-abcd-1234-efgh-123456789abc:1-100` festgelegt. ``` CALL mysql.rds_set_external_source_gtid_purged('12345678-abcd-1234-efgh-123456789abc', 1, 100); ``` ## Legt fest, dass der Replikationsmodus entweder auf binären Protokolldateipositionen oder auf globalen Transaktions-Identifikatoren (GTIDs) basiert. ### Syntax ``` CALL mysql.rds_set_master_auto_position ( auto_position_mode ); ``` ### Parameters *auto\$1position\$1mode* Ein Wert, der angibt, ob die Replikation auf Basis der Protokolldateiposition oder der GTID verwendet werden soll: + `0` – Verwendung der auf der Binärprotokolldateiposition basierenden Replikationsmethode. Der Standardwert ist `0`. + `1` – Verwendung der auf GTID basierenden Replikationsmethode. ### Nutzungshinweise Die Prozedur `mysql.rds_set_master_auto_position` muss vom Hauptbenutzer ausgeführt werden. Dieses Verfahren wird für RDS-für-MySQL-5.7-Versionen und RDS-für-MySQL 8.0.26 und höhere 8.0-Versionen unterstützt. ## mysql.rds\$1set\$1source\$1auto\$1position (RDS-für-MySQL-Hauptversionen 8.4 und höher) Legt fest, dass der Replikationsmodus entweder auf binären Protokolldateipositionen oder auf globalen Transaktions-Identifikatoren () GTIDs basiert. ### Syntax ``` CALL mysql.rds_set_source_auto_position (auto_position_mode); ``` ### Parameters *auto\$1position\$1mode* Ein Wert, der angibt, ob die Replikation auf Basis der Protokolldateiposition oder der GTID verwendet werden soll: + `0` – Verwendung der auf der Binärprotokolldateiposition basierenden Replikationsmethode. Der Standardwert ist `0`. + `1` – Verwendung der auf GTID basierenden Replikationsmethode. ### Nutzungshinweise Der Administrator muss das `mysql.rds_set_source_auto_position`-Verfahren ausführen. ## mysql.rds\$1set\$1source\$1delay Legt die Mindestanzahl von Sekunden fest, in der die Replikation von der Quelldatenbankinstance auf das aktuelle Lesereplikat verzögert werden soll. Verwenden Sie diese Prozedur, wenn Sie mit einem Lesereplikat verbunden sind, um die Replikation von der zugehörigen Quelldatenbankinstance zu verzögern. ### Syntax ``` CALL mysql.rds_set_source_delay( delay ); ``` ### Parameters *delay* Die Mindestanzahl von Sekunden, um die Replikation von der Quelldatenbank-Instance zu verzögern. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). ### Nutzungshinweise Die Prozedur `mysql.rds_set_source_delay` muss vom Hauptbenutzer ausgeführt werden. Für die Notfallwiederherstellung können Sie diese Prozedur mit der gespeicherten Prozedur [](#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden. Um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen, können Sie die Prozedur `mysql.rds_set_source_delay` ausführen. Nachdem die Prozedur `mysql.rds_start_replication_until` oder `mysql.rds_start_replication_until_gtid` die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md)). Um die Prozedur `mysql.rds_rds_start_replication_until_gtid` verwenden zu können, muss die GTID-basierte Replikation aktiviert sein. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie einen Notfall verursacht, können Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen zur GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). Die gespeicherte Prozedur `mysql.rds_set_source_delay` ist für die folgenden Versionen von RDS für MySQL verfügbar: + RDS für MySQL 8.4 (alle Versionen) + MySQL 8.0.26 und höhere 8.0-Versionen + Alle 5.7-Versionen ### Beispiele Um die Replikation von der Quelldatenbankinstance zum aktuellen Lesereplikat um mindestens eine Stunde (3.600 Sekunden) zu verzögern, können Sie `mysql.rds_set_source_delay` mit dem folgenden Parameter aufrufen: ``` CALL mysql.rds_set_source_delay(3600); ``` ## mysql.rds\$1skip\$1repl\$1error Ignoriert und löscht einen Replikationsfehler in einem MySQL-DB-Lesereplikat. ### Syntax ``` CALL mysql.rds_skip_repl_error; ``` ### Nutzungshinweise Der Hauptbenutzer muss die Prozedur `mysql.rds_skip_repl_error` auf einem Lesereplikat ausführen. Weitere Informationen zu dieser Prozedur finden Sie unter [Aufrufen der Prozedur mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure). Führen Sie den MySQL-Befehl `SHOW REPLICA STATUS\G` aus, um festzustellen, ob Fehler aufgetreten sind. Wenn ein Replikationsfehler nicht als kritisch eingestuft, ist, können Sie `mysql.rds_skip_repl_error` ausführen, um den Fehler zu überspringen. Wenn mehrere Fehler aufgetreten sind, löscht `mysql.rds_skip_repl_error` den ersten Fehler und weist darauf hin, dass weitere Fehlermeldungen anhängig sind. In diesem Fall können Sie mithilfe von `SHOW REPLICA STATUS\G` die angemessene Vorgehensweise bei der Handhabung des nächsten Fehlers ermitteln. Informationen zu den zurückgegebenen Werten finden Sie unter [SHOW REPLICA STATUS-Anweisung](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) in der MySQL-Dokumentation. Weitere Informationen zur Handhabung von Replikationsfehlern mit Amazon RDS finden Sie unter [Fehlerbehebung für ein Problem mit einer MySQL Read Replica](USER_ReadRepl.Troubleshooting.md). #### Fehler „Replication stopped (Replikation gestoppt)“ Wenn Sie die Prozedur `mysql.rds_skip_repl_error` aufrufen, wird möglicherweise eine Fehlermeldung angezeigt, die besagt, dass das Replikat ausgefallen oder deaktiviert ist. Diese Fehlermeldung wird angezeigt, wenn Sie die Prozedur auf der primären Instance statt auf dem Lesereplikat ausführen. Sie müssen diese Prozedur auf dem Lesereplikat ausführen, damit sie funktioniert. Diese Fehlermeldung wird möglicherweise auch angezeigt, wenn Sie die Prozedur zwar auf dem Lesereplikat ausführen, die Replikation jedoch nicht neu gestartet werden kann. Wenn Sie eine größere Anzahl von Fehlern überspringen müssen, kann die Dauer der Replikationsverzögerung den standardmäßigen Aufbewahrungszeitraum für binäre Protokolldateien (binlog) überschreiten. In diesem Fall kann es zu einem schwerwiegenden Fehler kommen, weil Binärprotokolldateien bereinigt werden, bevor ihr Inhalt in das Lesereplikat repliziert wurde. Diese Bereinigung führt zur Beendigung der Replikation, und Sie können den Befehl `mysql.rds_skip_repl_error` nicht mehr aufrufen, um Replikationsfehler zu überspringen und zu ignorieren. Sie können dieses Problem verringern, indem Sie die Anzahl der Stunden erhöhen, die die Binärprotokolldateien auf Ihrer Quelldatenbankinstance aufbewahrt werden. Nachdem Sie die Aufbewahrungsdauer für binäre Protokolldateien verlängert haben, können Sie die Replikation neu starten und nach Bedarf den Befehl `mysql.rds_skip_repl_error` aufrufen. Verwenden Sie zur Festlegung der Aufbewahrungszeit für Binärprotokolldateien die Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) und legen Sie einen Konfigurationsparameter für `'binlog retention hours'` zusammen mit der Stundenanzahl für die Aufbewahrung der Binärprotokolldateien im DB-Cluster fest. Beim folgenden Beispiel wird die Aufbewahrungszeit für binäre Protokolle auf 48 Stunden festgelegt. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ## mysql.rds\$1start\$1replication Startet die Replikation von einer/einem RDS-für-MySQL-DB-Instance. **Anmerkung** Sie können die gespeicherte Prozedur [](#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden, um die Replikation von einer RDS-für-MySQL--DB-Instance zu initiieren und die Replikation an der angegebenen Position der Binärprotokolldatei zu stoppen. ### Syntax ``` CALL mysql.rds_start_replication; ``` ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication` muss vom Hauptbenutzer ausgeführt werden. Um Daten aus einer außerhalb von Amazon RDS ausgeführten MySQL-Instance zu importieren, rufen Sie `mysql.rds_start_replication` für das Lesereplikat auf, um den Replikationsvorgang zu starten, nachdem Sie [mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](#mysql_rds_set_external_master) oder [mysql.rds\$1set\$1external\$1source (RDS-für-MySQL-Hauptversionen 8.4 und höher)](#mysql_rds_set_external_source) aufgerufen haben, um die Replikation zu konfigurieren. Weitere Informationen finden Sie unter [Wiederherstellen eines Backups in eine DB-Instance von Amazon RDS für MySQL](MySQL.Procedural.Importing.md). Zum Export von Daten in eine außerhalb von Amazon RDS ausgeführte MySQL-Instance rufen Sie `mysql.rds_start_replication` und `mysql.rds_stop_replication` für das Lesereplikat auf, um Replikationsaktionen wie das Bereinigen von Binärprotokollen zu steuern. Weitere Informationen finden Sie unter [Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation](MySQL.Procedural.Exporting.NonRDSRepl.md). Darüber hinaus können Sie `mysql.rds_start_replication` für das Lesereplikat aufrufen, um einen zuvor durch einen Aufruf von `mysql.rds_stop_replication` gestoppten Replikationsprozess wieder zu starten. Weitere Informationen finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). ## Initiiert die Replikation von einer RDS-für-MySQL-DB-Instance und stoppt die Replikation an der angegebenen Position in der Binärprotokolldatei. ### Syntax ``` CALL mysql.rds_start_replication_until ( replication_log_file , replication_stop_point ); ``` ### Parameters *replication\$1log\$1file* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *replication\$1stop\$1point * Die Position im `replication_log_file`-Binärprotokoll, an der die Replikation stoppt. ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication_until` muss vom Hauptbenutzer ausgeführt werden. Die gespeicherte Prozedur `mysql.rds_start_replication_until` ist für die folgenden Versionen von RDS für MySQL verfügbar: + RDS für MySQL 8.4 (alle Versionen) + MySQL 8.0.26 und höhere 8.0-Versionen + Alle 5.7-Versionen Sie können diese Prozedur mit verzögerter Replikation für die Notfallwiederherstellung verwenden. Wenn Sie die verzögerte Replikation konfiguriert haben, können Sie diese Prozedur verwenden, um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen. Nachdem diese Prozedur die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md). Sie können die verzögerte Replikation mit den folgenden gespeicherten Prozeduren konfigurieren: + [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) + [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](#mysql_rds_set_external_master_with_delay) + [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS-für-MySQL-Hauptversionen 8.4 und höher)](#mysql_rds_set_external_source_with_delay) + [mysql.rds\$1set\$1source\$1delay](#mysql_rds_set_source_delay) Der für den Parameter `replication_log_file` angegebene Dateiname muss mit dem Binlogdateinamen der Quelldatenbankinstance übereinstimmen. Wenn der Parameter `replication_stop_point`eine Stoppposition angibt, die in der Vergangenheit liegt, wird die Replikation sofort gestoppt. ### Beispiele Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die Position `120` in der Binärprotokolldatei `mysql-bin-changelog.000777` erreicht wird. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` ## mysql.rds\$1stop\$1replication Stoppt die Replikation von einer MySQL-DB-Instance. ### Syntax ``` CALL mysql.rds_stop_replication; ``` ### Nutzungshinweise Die Prozedur `mysql.rds_stop_replication` muss vom Hauptbenutzer ausgeführt werden. Wenn Sie die Replikation für den Import von Daten aus einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfigurieren, stoppen Sie mit einem Aufruf von `mysql.rds_stop_replication` für das Lesereplikat den Replikationsvorgang nach Abschluss des Imports. Weitere Informationen finden Sie unter [Wiederherstellen eines Backups in eine DB-Instance von Amazon RDS für MySQL](MySQL.Procedural.Importing.md). Wenn Sie die Replikation für den Export von Daten in eine außerhalb von Amazon RDS ausgeführte MySQL-Instance konfigurieren, rufen Sie `mysql.rds_start_replication` und `mysql.rds_stop_replication` für das Lesereplikat auf, um Replikationsaktionen wie das Bereinigen von Binärprotokollen zu steuern. Weitere Informationen finden Sie unter [Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation](MySQL.Procedural.Exporting.NonRDSRepl.md). Zudem können Sie `mysql.rds_stop_replication` auch dazu verwenden, die Replikation zwischen zwei Amazon-RDS-DB-Instances zu stoppen. In der Regel wird eine Replikation gestoppt, um eine länger dauernde Operation im Lesereplikat – zum Beispiel das Erstellen eines umfangreichen Indexes – durchzuführen. Ein gestoppter Replikationsvorgang kann durch Aufruf von [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat wieder gestartet werden. Weitere Informationen finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). # Beenden einer Sitzung oder Abfrage Die folgenden gespeicherten Prozeduren beenden eine Sitzung oder Abfrage. **Topics** + [ ## mysql.rds\$1kill ](#mysql_rds_kill) + [ ## mysql.rds\$1kill\$1query ](#mysql_rds_kill_query) ## mysql.rds\$1kill Beendet eine Verbindung zum MySQL-Server. ### Syntax ``` CALL mysql.rds_kill(processID); ``` ### Parameter *processID* Die ID des Verbindungs-Threads, der beendet werden soll. ### Nutzungshinweise Jede Verbindung zum MySQL-Server wird in einem eigenen Thread ausgeführt. Um eine Verbindung zu beenden, verwenden Sie die Prozedur `mysql.rds_kill` und übergeben ihr als Parameter die Thread-ID der Verbindung. Die Thread-ID erhalten Sie mithilfe des MySQL-Befehls [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). Weitere Informationen zu Einschränkungen finden Sie unter [Einschränkungen bei gespeicherten MySQL-Prozeduren](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures). ### Beispiele Im folgenden Beispiel wird eine Verbindung mit der Thread-ID 4243 beendet: ``` CALL mysql.rds_kill(4243); ``` ## mysql.rds\$1kill\$1query Beendet eine an den MySQL-Server übermittelte Abfrage. ### Syntax ``` CALL mysql.rds_kill_query(processID); ``` ### Parameter *processID* Die Identität des Prozesses oder Threads, der die zu beendende Abfrage ausführt. ### Nutzungshinweise Um eine an den MySQL-Server übermittelte Abfrage zu beenden, verwenden Sie die Prozedur `mysql_rds_kill_query` und übergeben die ID des Threads, der die Abfrage ausführt. Die Prozedur beendet dann die Verbindung. Die Abfrage-ID erhalten Sie mithilfe der MySQL-Tabelle [INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) oder des MySQL-Befehls [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). Der Wert in der ID-Spalte von `SHOW PROCESSLIST` oder `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` ist die *processID*. Weitere Informationen zu Einschränkungen finden Sie unter [Einschränkungen bei gespeicherten MySQL-Prozeduren](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures). ### Beispiele Im folgenden Beispiel wird eine Abfrage mit der Thread-ID 230040 beendet: ``` CALL mysql.rds_kill_query(230040); ``` # Verwalten von Aktiv/Aktiv-Clustern Mit den folgenden gespeicherten Prozeduren werden Aktiv/Aktiv-Cluster von RDS für MySQL eingerichtet und verwaltet. Weitere Informationen finden Sie unter [Konfigurieren von Aktiv/Aktiv-Clustern von RDS für MySQL](mysql-active-active-clusters.md). Diese gespeicherten Prozeduren sind nur für DB-Instances von RDS für MySQL verfügbar, auf denen die folgenden Versionen ausgeführt werden: + Alle MySQL 8.4-Versionen + MySQL 8.0.35 und höhere Unterversionen **Topics** + [ ## mysql.rds\$1group\$1replication\$1advance\$1gtid ](#mysql_rds_group_replication_advance_gtid) + [ ## mysql.rds\$1group\$1replication\$1create\$1user ](#mysql_rds_group_replication_create_user) + [ ## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel ](#mysql_rds_group_replication_set_recovery_channel) + [ ## mysql.rds\$1group\$1replication\$1start ](#mysql_rds_group_replication_start) + [ ## mysql.rds\$1group\$1replication\$1stop ](#mysql_rds_group_replication_stop) ## mysql.rds\$1group\$1replication\$1advance\$1gtid Erstellt Platzhalter-GTIDs für die aktuelle DB-Instance. ### Syntax ``` CALL mysql.rds_group_replication_advance_gtid( begin_id , end_id , server_uuid ); ``` ### Parameter *begin\$1id* Die zu erstellende Start-Transaktions-ID. *end\$1id* Die zu erstellende Ende-Transaktions-ID. *begin\$1id* Der Parameter `group_replication_group_name` für die zu erstellende Transaktion. Der Parameter `group_replication_group_name` ist als UUID in der DB-Parametergruppe angegeben, die der DB-Instance zugeordnet ist. ### Nutzungshinweise In einem Aktiv/Aktiv-Cluster müssen alle GTID-Transaktionen, die auf der neuen DB-Instance ausgeführt werden, auf den anderen Mitgliedern des Clusters vorhanden sein, damit eine DB-Instance einer Gruppe hinzugefügt werden kann. In ungewöhnlichen Situationen kann eine neue DB-Instance mehr Transaktionen haben, wenn diese ausgeführt werden, bevor die Instance der Gruppe hinzugefügt wird. In diesem Fall können Sie keine vorhandenen Transaktionen entfernen. Sie können jedoch diese Prozedur anwenden, um die entsprechenden Platzhalter-GTIDs auf den anderen DB-Instances in der Gruppe zu erstellen. Vergewissern Sie sich vorher, dass sich die Transaktionen *nicht auf die replizierten Daten auswirken*. Wenn Sie diese Prozedur aufrufen, werden GTID-Transaktionen von `server_uuid:begin_id-end_id` mit leerem Inhalt erstellt. Um Replikationsprobleme zu vermeiden, sollten Sie diese Prozedur unter keinen anderen Bedingungen anwenden. **Wichtig** Rufen Sie diese Prozedur nicht auf, wenn der Aktiv/Aktiv-Cluster einwandfrei funktioniert. Rufen Sie diese Prozedur nur auf, wenn Sie sich der möglichen Konsequenzen der von Ihnen erstellten Transaktionen bewusst sind. Der Aufruf dieser Prozedur kann zu inkonsistenten Daten führen. ### Beispiel Im folgenden Beispiel werden Platzhalter-GTIDs für die aktuelle DB-Instance erstellt: ``` CALL mysql.rds_group_replication_advance_gtid(5, 6, '11111111-2222-3333-4444-555555555555'); ``` ## mysql.rds\$1group\$1replication\$1create\$1user Erstellt den Replikationsbenutzer `rdsgrprepladmin` für die Gruppenreplikation auf der DB-Instance. ### Syntax ``` CALL mysql.rds_group_replication_create_user( replication_user_password ); ``` ### Parameter *replication\$1user\$1password* Das Passwort des Replikationsbenutzers `rdsgrprepladmin`. ### Nutzungshinweise + Das Passwort des Replikationsbenutzers `rdsgrprepladmin` muss auf allen DB-Instances in einem Aktiv/Aktiv-Cluster identisch sein. + Der Benutzername `rdsgrprepladmin` ist für Gruppenreplikationsverbindungen reserviert. Kein anderer Benutzer, einschließlich des Masterbenutzers, darf diesen Benutzernamen haben. ### Beispiel Im folgenden Beispiel wird der Replikationsbenutzer `rdsgrprepladmin` für die Gruppenreplikation auf der DB-Instance erstellt: ``` CALL mysql.rds_group_replication_create_user('password'); ``` ## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel Legt den Kanal `group_replication_recovery` für einen Aktiv/Aktiv-Cluster fest. Die Prozedur verwendet den reservierten Benutzer `rdsgrprepladmin`, um den Kanal zu konfigurieren. ### Syntax ``` CALL mysql.rds_group_replication_set_recovery_channel( replication_user_password); ``` ### Parameter *replication\$1user\$1password* Das Passwort des Replikationsbenutzers `rdsgrprepladmin`. ### Nutzungshinweise Das Passwort des Replikationsbenutzers `rdsgrprepladmin` muss auf allen DB-Instances in einem Aktiv/Aktiv-Cluster identisch sein. Durch Aufrufen von `mysql.rds_group_replication_create_user` wird das Passwort festgelegt. ### Beispiel Im folgenden Beispiel wird der Kanal `group_replication_recovery` für einen Aktiv/Aktiv-Cluster festgelegt: ``` CALL mysql.rds_group_replication_set_recovery_channel('password'); ``` ## mysql.rds\$1group\$1replication\$1start Startet die Gruppenreplikation auf der aktuellen DB-Instance. ### Syntax ``` CALL mysql.rds_group_replication_start( bootstrap ); ``` ### Parameter *bootstrap* Dieser Wert gibt an, ob eine neue Gruppe initialisiert oder einer vorhandenen Gruppe hinzugefügt werden soll. `1` initialisiert eine neue Gruppe mit der aktuellen DB-Instance. `0` verbindet die aktuelle DB-Instance mit einer vorhandenen Gruppe, indem eine Verbindung mit den Endpunkten hergestellt wird, die im Parameter `group_replication_group_seeds` der DB-Parametergruppe definiert sind, die der DB-Instance zugeordnet ist. ### Beispiel Im folgenden Beispiel wird eine neue Gruppe mit der aktuellen DB-Instance initialisiert: ``` CALL mysql.rds_group_replication_start(1); ``` ## mysql.rds\$1group\$1replication\$1stop Stoppt die Gruppenreplikation auf der aktuellen DB-Instance. ### Syntax ``` CALL mysql.rds_group_replication_stop(); ``` ### Nutzungshinweise Wenn Sie die Replikation auf einer DB-Instance stoppen, hat dies keine Auswirkungen auf andere DB-Instances im Aktiv/Aktiv-Cluster. # Verwalten der Multi-Source-Replikation Mit den folgenden gespeicherten Prozeduren werden Replikationskanäle auf einem Multi-Source-Replikat von RDS für MySQL eingerichtet und verwaltet. Weitere Informationen finden Sie unter [Konfiguration multi-source-replication für Amazon RDS for MySQL](mysql-multi-source-replication.md). Diese gespeicherten Prozeduren sind nur für DB-Instances von RDS für MySQL verfügbar, auf denen die folgenden Engine-Versionen ausgeführt werden: + Alle 8.4-Versionen + 8.0.35 und höhere Nebenversionen + 5.7.44 und höhere Nebenversionen Wenn Sie gespeicherte Prozeduren verwenden, um die Replikation mit einem mit `caching_sha2_passwword` konfigurierten Replikationsbenutzer zu verwalten, müssen Sie TLS konfigurieren, indem Sie `SOURCE_SSL=1` festlegen. `caching_sha2_password` ist das Standard-Authentifizierungs-Plugin für RDS für MySQL 8.4. **Anmerkung** Obwohl in dieser Dokumentation Quell-DB-Instances als RDS-für-MySQL-DB-Instances bezeichnet werden, funktionieren diese Prozeduren auch für MySQL-Instances, die außerhalb von Amazon RDS ausgeführt werden. **Topics** + [ ## mysql.rds\$1next\$1source\$1log\$1for\$1channel ](#mysql_rds_next_source_log_for_channel) + [ ## mysql.rds\$1reset\$1external\$1source\$1for\$1channel ](#mysql_rds_reset_external_source_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1for\$1channel ](#mysql_rds_set_external_source_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel ](#mysql_rds_set_external_source_with_auto_position_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel ](#mysql_rds_set_external_source_with_delay_for_channel) + [ ## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel ](#mysql_rds_set_source_auto_position_for_channel) + [ ## mysql.rds\$1set\$1source\$1delay\$1for\$1channel ](#mysql_rds_set_source_delay_for_channel) + [ ## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel ](#mysql_rds_skip_repl_error_for_channel) + [ ## mysql.rds\$1start\$1replication\$1for\$1channel ](#mysql_rds_start_replication_for_channel) + [ ## mysql.rds\$1start\$1replication\$1until\$1for\$1channel ](#mysql_rds_start_replication_until_for_channel) + [ ## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel ](#mysql_rds_start_replication_until_gtid_for_channel) + [ ## mysql.rds\$1stop\$1replication\$1for\$1channel ](#mysql_rds_stop_replication_for_channel) ## mysql.rds\$1next\$1source\$1log\$1for\$1channel Ändert die Position des Protokolls für die Quell-DB-Instance in den Anfang des nächsten Binärprotokolls auf der Quell-DB-Instance für den Kanal. Verwenden Sie diese Prozedur nur dann, wenn Sie für ein Multi-Source-Replikat bei der Replikation einen I/O-Fehler mit der Fehlernummer 1236 erhalten. ### Syntax ``` CALL mysql.rds_next_source_log_for_channel( curr_master_log, channel_name ); ``` ### Parameter *curr\$1master\$1log* Der Index der aktuellen Quell-Protokolldatei. Der Index ist im Dateinamen codiert. Eine aktuelle Datei mit dem Namen `mysql-bin-changelog.012345` hat beispielsweise den Index 12345. Um den Namen der aktuellen Quell-Protokolldatei zu ermitteln, führen Sie den Befehl `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'` aus. Sie finden den Namen anschließend im Feld `Source_Log_File`. *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_next_source_log_for_channel` muss vom Hauptbenutzer ausgeführt werden. Wenn beispielsweise ein IO\$1Thread-Fehler auftritt, können Sie diese Prozedur verwenden, um alle Ereignisse in der aktuellen Binärprotokolldatei zu überspringen und die Replikation von der nächsten Binärprotokolldatei für den in `channel_name` angegebenen Kanal aus fortzusetzen. ### Beispiel Angenommen, dass die Replikation auf einem Kanal für ein Multi-Source-Replikat fehlschlägt. Die Ausführung von `SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G` für das Multi-Source-Replikat gibt das folgende Ergebnis zurück: ``` mysql> SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G *************************** 1. row *************************** Replica_IO_State: Waiting for source to send event Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: ReplicationUser Source_Port: 3306 Connect_Retry: 60 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: replica-relay-bin.000003 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB:. . . Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: . . Channel_name: channel_1 . . -- Some fields are omitted in this example output ``` Den Angeben im Feld `Last_IO_Errno` ist zu entnehmen, dass die Instance eine I/O-Fehlermeldung mit der Nummer 1236 erhalten hat. Dem Feld `Source_Log_File` ist zudem zu entnehmen, dass die betroffene Protokolldatei den Namen `mysql-bin-changelog.012345` aufweist und ihr Index folglich `12345` lautet. Zur Behebung des Fehlers können Sie `mysql.rds_next_source_log_for_channel` mit den folgenden Parametern aufrufen: ``` CALL mysql.rds_next_source_log_for_channel(12345,'channel_1'); ``` ## mysql.rds\$1reset\$1external\$1source\$1for\$1channel Stoppt den Replikationsvorgang auf dem angegebenen Kanal und entfernt den Kanal und die zugehörigen Konfigurationen vom Multi-Source-Replikat. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_reset_external_source_for_channel (channel_name); ``` ### Parameter *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_reset_external_source_for_channel` muss vom Hauptbenutzer ausgeführt werden. Bei dieser Prozedur werden alle Relay-Protokolle gelöscht, die zu dem zu entfernenden Kanal gehören. ## mysql.rds\$1set\$1external\$1source\$1for\$1channel Konfiguriert einen Replikationskanal in einer DB-Instance von RDS für MySQL, um die Daten aus einer anderen DB-Instance von RDS für MySQL zu replizieren. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). **Anmerkung** Sie können stattdessen die gespeicherte Prozedur [mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel](#mysql_rds_set_external_source_with_delay_for_channel) verwenden, um diesen Kanal mit verzögerter Replikation zu konfigurieren. ### Syntax ``` CALL mysql.rds_set_external_source_for_channel ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , channel_name ); ``` ### Parameter *host\$1name* Der Hostname bzw. die IP-Adresse der Quell-DB-Instance von RDS für MySQL. *host\$1port* Der von der Quell-DB-Instance von RDS für MySQL verwendete Port. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der Quell-DB-Instance von RDS für MySQL. Es wird empfohlen, ein Konto bereitzustellen, das ausschließlich für die Replikation mit der Quell-DB-Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quell-DB-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position in der binären Protokolldatei `mysql_binary_log_file_name`, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binärprotokolldatei ermitteln, indem Sie `SHOW BINARY LOG STATUS` auf der Quell-DB-Instance ausführen. Frühere Versionen von MySQL verwenden `SHOW MASTER STATUS` anstelle von `SHOW BINARY LOG STATUS`. Wenn Sie eine MySQL-Version vor 8.4 verwenden, nutzen Sie `SHOW MASTER STATUS`. *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 `SOURCE_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. *channel\$1name* Der Name des Replikationskanals. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_set_external_source_for_channel` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der Ziel-DB-Instance von RDS für MySQL ausgeführt werden, auf der Sie den Replikationskanal erstellen. Konfigurieren Sie vor der Ausführung von `mysql.rds_set_external_source_for_channel` einen Replikationsbenutzer auf der Quell-DB-Instance mit den für das Multi-Source-Replikat erforderlichen Berechtigungen. Um eine Verbindung des Multi-Source-Replikats mit der Quell-DB-Instance herzustellen, müssen Sie die Werte `replication_user_name` und `replication_user_password` eines Replikationsbenutzers angeben, der über die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die Quell-DB-Instance verfügt. **So konfigurieren Sie einen Replikationsbenutzer auf der Quell-DB-Instance** 1. Stellen Sie mithilfe eines MySQL-Clients Ihrer Wahl eine Verbindung mit der Quell-DB-Instance her und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. **Wichtig** Geben Sie als bewährte Sicherheitsmethode ein anderes Passwort als im Platzhalterwert in den folgenden Beispielen angegeben an. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Erteilen Sie dem Replikationsbenutzer auf der Quell-DB-Instance die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer 'repl\$1user' für Ihre Domäne die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Um die verschlüsselte Replikation zu verwenden, konfigurieren Sie die Quell-DB-Instance für die Verwendung von SSL-Verbindungen. Nachdem Sie `mysql.rds_set_external_source_for_channel` aufgerufen haben, um diesen Replikationskanal zu konfigurieren, können Sie [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) auf dem Replikat aufrufen, um den Replikationsvorgang auf dem Kanal zu starten. Sie können [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) aufrufen, um die Replikation auf dem Kanal zu beenden und die Kanalkonfiguration vom Replikat zu entfernen. Beim Aufrufen von `mysql.rds_set_external_source_for_channel` werden in Amazon RDS die Uhrzeit, der Benutzer und eine Aktion von `set channel source` in der Tabelle `mysql.rds_history` ohne kanalspezifische Details und in der Tabelle `mysql.rds_replication_status` mit dem Kanalnamen aufgezeichnet. Diese Informationen werden nur für die interne Verwendung und zu Überwachungszwecken aufgezeichnet. Um den gesamten Prozeduraufruf zu Audit-Zwecken aufzuzeichnen, sollten Sie je nach den spezifischen Anforderungen Ihrer Anwendung die Aktivierung von Audit-Protokollen oder allgemeinen Protokollen in Betracht ziehen. ### Beispiele Bei der Ausführung auf einer DB-Instance von RDS für MySQL wird im folgenden Beispiel der Replikationskanal `channel_1` auf dieser DB-Instance konfiguriert, um Daten von der durch den Host `sourcedb.example.com` und Port `3306` angegebenen Quelle zu replizieren. ``` call mysql.rds_set_external_source_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 0, 'channel_1'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel Konfiguriert einen Replikationskanal auf einer DB-Instance von RDS für MySQL mit einer optionalen Replikationsverzögerung. Dies Replikation basiert auf globalen Transaktionskennungen (GTIDs). **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_source_with_auto_position_for_channel ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay , channel_name ); ``` ### Parameter *host\$1name* Der Hostname bzw. die IP-Adresse der Quell-DB-Instance von RDS für MySQL. *host\$1port* Der von der Quell-DB-Instance von RDS für MySQL verwendete Port. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der Quell-DB-Instance von RDS für MySQL. Es wird empfohlen, ein Konto bereitzustellen, das ausschließlich für die Replikation mit der Quell-DB-Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *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 `SOURCE_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. *Verzögerung* Die Mindestanzahl von Sekunden, um die die Replikation von der Quell-DB-Instance verzögert werden soll. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). *channel\$1name* Der Name des Replikationskanals. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_set_external_source_with_auto_position_for_channel` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der Ziel-DB-Instance von RDS für MySQL ausgeführt werden, auf der Sie den Replikationskanal erstellen. Konfigurieren Sie vor der Ausführung von `rds_set_external_source_with_auto_position_for_channel` einen Replikationsbenutzer auf der Quell-DB-Instance mit den für das Multi-Source-Replikat erforderlichen Berechtigungen. Um eine Verbindung des Multi-Source-Replikats mit der Quell-DB-Instance herzustellen, müssen Sie die Werte `replication_user_name` und `replication_user_password` eines Replikationsbenutzers angeben, der über die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die Quell-DB-Instance verfügt. **So konfigurieren Sie einen Replikationsbenutzer auf der Quell-DB-Instance** 1. Stellen Sie mithilfe eines MySQL-Clients Ihrer Wahl eine Verbindung mit der Quell-DB-Instance her und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. **Wichtig** Geben Sie als bewährte Sicherheitsmethode ein anderes Passwort als im Platzhalterwert in den folgenden Beispielen angegeben an. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Erteilen Sie dem Replikationsbenutzer auf der Quell-DB-Instance die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer 'repl\$1user' für Ihre Domäne die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Um die verschlüsselte Replikation zu verwenden, konfigurieren Sie die Quell-DB-Instance für die Verwendung von SSL-Verbindungen. Stellen Sie vor dem Aufrufen von `mysql.rds_set_external_source_with_auto_position_for_channel` sicher, dass Sie [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_gtid_purged) aufrufen, um die Systemvariable `gtid_purged` mit einem bestimmten GTID-Bereich aus einer externen Quelle aufrufen. Nachdem Sie `mysql.rds_set_external_source_with_auto_position_for_channel` aufgerufen haben, um eine Amazon-RDS-DB-Instance als Lesereplikat auf einem bestimmten Kanal zu konfigurieren, können Sie [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) für das Lesereplikat aufrufen, um die Replikation auf diesem Kanal zu starten. Nachdem Sie `mysql.rds_set_external_source_with_auto_position_for_channel` aufgerufen haben, um diesen Replikationskanal zu konfigurieren, können Sie [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) auf dem Replikat aufrufen, um den Replikationsvorgang auf dem Kanal zu starten. Sie können [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) aufrufen, um die Replikation auf dem Kanal zu beenden und die Kanalkonfiguration vom Replikat zu entfernen. ### Beispiele Bei der Ausführung auf einer DB-Instance von RDS für MySQL wird im folgenden Beispiel der Replikationskanal `channel_1` auf dieser DB-Instance konfiguriert, um Daten von der durch den Host `sourcedb.example.com` und Port `3306` angegebenen Quelle zu replizieren. Die minimale Replikationsverzögerung wird auf eine Stunde (3 600 Sekunden) festgelegt. Dies bedeutet, dass eine Änderung an der Quell-DB-Instance von RDS für MySQL frühestens nach einer Stunde auf das Multi-Source-Replikat angewendet wird. ``` call mysql.rds_set_external_source_with_auto_position_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 1, 3600, 'channel_1'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel Konfiguriert einen Replikationskanal auf einer DB-Instance von RDS für MySQL mit einer angegebenen Replikationsverzögerung. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_source_with_delay_for_channel ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay , channel_name ); ``` ### Parameter *host\$1name* Der Hostname bzw. die IP-Adresse der Quell-DB-Instance von RDS für MySQL. *host\$1port* Der von der Quell-DB-Instance von RDS für MySQL verwendete Port. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der Quell-DB-Instance von RDS für MySQL. Es wird empfohlen, ein Konto bereitzustellen, das ausschließlich für die Replikation mit der Quell-DB-Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quell-DB-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position innerhalb der für `mysql_binary_log_file_name` angegebenen binären Protokolldatei, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binlog-Datei ermitteln, indem Sie `SHOW BINARY LOG STATUS` auf der Quelldatenbank-Instance starten. Frühere Versionen von MySQL verwenden `SHOW MASTER STATUS` anstelle von `SHOW BINARY LOG STATUS`. Wenn Sie eine MySQL-Version vor 8.4 verwenden, nutzen Sie `SHOW MASTER STATUS`. *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 `SOURCE_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. *Verzögerung* Die Mindestanzahl von Sekunden, um die die Replikation von der Quell-DB-Instance verzögert werden soll. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). *channel\$1name* Der Name des Replikationskanals. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_set_external_source_with_delay_for_channel` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der Ziel-DB-Instance von RDS für MySQL ausgeführt werden, auf der Sie den Replikationskanal erstellen. Konfigurieren Sie vor der Ausführung von `mysql.rds_set_external_source_with_delay_for_channel` einen Replikationsbenutzer auf der Quell-DB-Instance mit den für das Multi-Source-Replikat erforderlichen Berechtigungen. Um eine Verbindung des Multi-Source-Replikats mit der Quell-DB-Instance herzustellen, müssen Sie die Werte `replication_user_name` und `replication_user_password` eines Replikationsbenutzers angeben, der über die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die Quell-DB-Instance verfügt. **So konfigurieren Sie einen Replikationsbenutzer auf der Quell-DB-Instance** 1. Stellen Sie mithilfe eines MySQL-Clients Ihrer Wahl eine Verbindung mit der Quell-DB-Instance her und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. **Wichtig** Geben Sie als bewährte Sicherheitsmethode ein anderes Passwort als im Platzhalterwert in den folgenden Beispielen angegeben an. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Erteilen Sie dem Replikationsbenutzer auf der Quell-DB-Instance die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer 'repl\$1user' für Ihre Domäne die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Um die verschlüsselte Replikation zu verwenden, konfigurieren Sie die Quell-DB-Instance für die Verwendung von SSL-Verbindungen. Nachdem Sie `mysql.rds_set_external_source_with_delay_for_channel` aufgerufen haben, um diesen Replikationskanal zu konfigurieren, können Sie [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) auf dem Replikat aufrufen, um den Replikationsvorgang auf dem Kanal zu starten. Sie können [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) aufrufen, um die Replikation auf dem Kanal zu beenden und die Kanalkonfiguration vom Replikat zu entfernen. Beim Aufrufen von `mysql.rds_set_external_source_with_delay_for_channel` werden in Amazon RDS die Uhrzeit, der Benutzer und eine Aktion von `set channel source` in der Tabelle `mysql.rds_history` ohne kanalspezifische Details und in der Tabelle `mysql.rds_replication_status` mit dem Kanalnamen aufgezeichnet. Diese Informationen werden nur für die interne Verwendung und zu Überwachungszwecken aufgezeichnet. Um den gesamten Prozeduraufruf zu Audit-Zwecken aufzuzeichnen, sollten Sie je nach den spezifischen Anforderungen Ihrer Anwendung die Aktivierung von Audit-Protokollen oder allgemeinen Protokollen in Betracht ziehen. ### Beispiele Bei der Ausführung auf einer DB-Instance von RDS für MySQL wird im folgenden Beispiel der Replikationskanal `channel_1` auf dieser DB-Instance konfiguriert, um Daten von der durch den Host `sourcedb.example.com` und Port `3306` angegebenen Quelle zu replizieren. Die minimale Replikationsverzögerung wird auf eine Stunde (3 600 Sekunden) festgelegt. Dies bedeutet, dass eine Änderung an der Quell-DB-Instance von RDS für MySQL frühestens nach einer Stunde auf das Multi-Source-Replikat angewendet wird. ``` call mysql.rds_set_external_source_with_delay_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000777', 120, 1, 3600, 'channel_1'); ``` ## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel Legt den Replikationsmodus für den angegebenen Kanal als auf Binärprotokolldateipositionen oder globalen Transaktionskennungen (GTIDs) basierend fest. ### Syntax ``` CALL mysql.rds_set_source_auto_position_for_channel ( auto_position_mode , channel_name ); ``` ### Parameter *auto\$1position\$1mode* Ein Wert, der angibt, ob die Replikation auf Basis der Protokolldateiposition oder der GTID verwendet werden soll: + `0` – Verwendung der auf der Binärprotokolldateiposition basierenden Replikationsmethode. Der Standardwert ist `0`. + `1` – Verwendung der auf GTID basierenden Replikationsmethode. *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_set_source_auto_position_for_channel` muss vom Hauptbenutzer ausgeführt werden. Mit dieser Prozedur wird die Replikation auf dem festgelegten Kanal neu gestartet, um den angegebenen automatischen Positionierungsmodus anzuwenden. ### Beispiele Im folgenden Beispiel wird der automatischen Positionierungsmodus für channel\$11 so eingestellt, dass er die GTID-basierte Replikationsmethode verwendet. ``` call mysql.rds_set_source_auto_position_for_channel(1,'channel_1'); ``` ## mysql.rds\$1set\$1source\$1delay\$1for\$1channel Legt die Mindestanzahl von Sekunden fest, um die die Replikation von der Quelldatenbank-Instance auf das Multi-Source-Replikat für den angegebenen Kanal verzögert werden soll. ### Syntax ``` CALL mysql.rds_set_source_delay_for_channel(delay, channel_name); ``` ### Parameter *Verzögerung* Die Mindestanzahl von Sekunden, um die die Replikation von der Quell-DB-Instance verzögert werden soll. Die Obergrenze für diesen Parameter beträgt einen Tag (86 400 Sekunden). *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_set_source_delay_for_channel` muss vom Hauptbenutzer ausgeführt werden. Um diese Prozedur zu verwenden, rufen Sie zuerst `mysql.rds_stop_replication_for_channel` auf, um die Replikation zu stoppen. Rufen Sie dann diese Prozedur auf, um den Wert für die Replikationsverzögerung festzulegen. Wenn die Verzögerung festgelegt wurde, rufen Sie `mysql.rds_start_replication_for_channel` auf, um die Replikation neu zu starten. ### Beispiele Im folgenden Beispiel wird die Verzögerung für die Replikation von der Quelldatenbank-Instance auf `channel_1` des Multi-Source-Replikats auf mindestens eine Stunde (3 600 Sekunden) festgelegt. ``` CALL mysql.rds_set_source_delay_for_channel(3600,'channel_1'); ``` ## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel Überspringt ein Binärprotokollereignis und löscht einen Replikationsfehler auf einem MySQL-DB-Multi-Source-Replikat für den angegebenen Kanal. ### Syntax ``` CALL mysql.rds_skip_repl_error_for_channel(channel_name); ``` ### Parameter *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Der Hauptbenutzer muss die Prozedur `mysql.rds_skip_repl_error_for_channel` auf einem Lesereplikat ausführen. Sie können diese Prozedur in ähnlicher Weise verwenden, wie `mysql.rds_skip_repl_error` zum Überspringen eines Fehlers in einem Lesereplikat genutzt wird. Weitere Informationen finden Sie unter [Aufrufen der Prozedur mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure). **Anmerkung** Um Fehler bei der GTID-basierten Replikation zu überspringen, wird empfohlen, stattdessen die Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) zu verwenden. Führen Sie den MySQL-Befehl `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G` aus, um festzustellen, ob Fehler aufgetreten sind. Wenn ein Replikationsfehler nicht als kritisch eingestuft, ist, können Sie `mysql.rds_skip_repl_error_for_channel` ausführen, um den Fehler zu überspringen. Wenn mehrere Fehler aufgetreten sind, löscht `mysql.rds_skip_repl_error_for_channel` den ersten Fehler im angegebenen Replikationskanal und weist darauf hin, dass es weitere Fehlermeldungen gibt. In diesem Fall können Sie mithilfe von `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G` die angemessene Vorgehensweise bei der Handhabung des nächsten Fehlers ermitteln. Informationen zu den zurückgegebenen Werten finden Sie unter [SHOW REPLICA STATUS-Anweisung](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) in der MySQL-Dokumentation. ## mysql.rds\$1start\$1replication\$1for\$1channel Initiiert die Replikation von einer DB-Instance von RDS für MySQL zu einem Multi-Source-Replikat auf dem angegebenen Kanal. **Anmerkung** Sie können die gespeicherte Prozedur [mysql.rds\$1start\$1replication\$1until\$1for\$1channel](#mysql_rds_start_replication_until_for_channel) oder [mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel](#mysql_rds_start_replication_until_gtid_for_channel) verwenden, um die Replikation von einer RDS für MySQL-DB-Instance zu initiieren und die Replikation an der angegebenen Position der Binärprotokolldatei zu stoppen. ### Syntax ``` CALL mysql.rds_start_replication_for_channel(channel_name); ``` ### Parameter *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication_for_channel` muss vom Hauptbenutzer ausgeführt werden. Nachdem Sie die Daten aus der Quell-DB-Instance von RDS für MySQL importiert haben, führen Sie diesen Befehl für das Multi-Source-Replikat aus, um die Replikation auf dem angegebenen Kanal zu starten. ### Beispiele Im folgenden Beispiel wird die Replikation auf `channel_1` des Multi-Source-Replikats gestartet. ``` CALL mysql.rds_start_replication_for_channel('channel_1'); ``` ## mysql.rds\$1start\$1replication\$1until\$1for\$1channel Initiiert die Replikation von einer DB-Instance von RDS für MySQL auf dem festgelegten Kanal und stoppt die Replikation an der angegebenen Position in der Binärprotokolldatei. ### Syntax ``` CALL mysql.rds_start_replication_until_for_channel ( replication_log_file , replication_stop_point , channel_name ); ``` ### Parameter *replication\$1log\$1file* Der Name des Binärprotokolls auf der Quell-DB-Instance, die die Replikationsinformationen enthält. *replication\$1stop\$1point * Die Position im `replication_log_file`-Binärprotokoll, an der die Replikation stoppt. *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication_until_for_channel` muss vom Hauptbenutzer ausgeführt werden. Bei dieser Prozedur wird die Replikation gestartet und dann beendet, wenn die angegebene Position in der Binärprotokolldatei erreicht wurde. Mit dieser Prozedur wird sowohl der `SQL_THREAD` als auch der `IO_THREAD` beendet. Der für den Parameter `replication_log_file` angegebene Dateiname muss mit dem Namen der Binärprotokolldatei der Quell-DB-Instance übereinstimmen. Wenn der Parameter `replication_stop_point` eine Stoppposition angibt, die in der Vergangenheit liegt, wird die Replikation sofort gestoppt. ### Beispiele Das folgende Beispiel initiiert die Replikation auf `channel_1` und repliziert die Änderungen, bis die Position `120` in der Binärprotokolldatei `mysql-bin-changelog.000777` erreicht wurde. ``` call mysql.rds_start_replication_until_for_channel( 'mysql-bin-changelog.000777', 120, 'channel_1' ); ``` ## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel Initiiert die Replikation auf dem angegebenen Kanal von einer DB-Instance von RDS für MySQL und stoppt die Replikation an der angegebenen globalen Transaktionskennung (GTID). ### Syntax ``` CALL mysql.rds_start_replication_until_gtid_for_channel(gtid,channel_name); ``` ### Parameter *gtid* Die GTID, nach der die Replikation stoppen soll. *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication_until_gtid_for_channel` muss vom Hauptbenutzer ausgeführt werden. Die Prozedur startet die Replikation auf dem festgelegten Kanal und wendet alle Änderungen bis zum angegebenen GTID-Wert an. Anschließend wird die Replikation auf dem Kanal beendet. Wenn der Parameter `gtid` eine Transaktion angibt, die bereits von dem Replikat ausgeführt wurde, wird die Replikation sofort gestoppt. Bevor Sie diese Prozedur ausführen, müssen Sie die Multi-Thread-Replikation deaktivieren, indem Sie den Wert `replica_parallel_workers` oder `slave_parallel_workers` auf `0` festlegen. ### Beispiele Das folgende Beispiel initiiert die Replikation auf `channel_1` und repliziert die Änderungen, bis die GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` erreicht wurde. ``` call mysql.rds_start_replication_until_gtid_for_channel('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','channel_1'); ``` ## mysql.rds\$1stop\$1replication\$1for\$1channel Stoppt die Replikation von einer MySQL-DB-Instance auf dem angegebenen Kanal. ### Syntax ``` CALL mysql.rds_stop_replication_for_channel(channel_name); ``` ### Parameter *channel\$1name* Der Name des Replikationskanals auf dem Multi-Source-Replikat. Jeder Replikationskanal empfängt die binären Protokollereignisse von einer einzigen DB-Instance von RDS für MySQL, die auf einem bestimmten Host und Port ausgeführt wird. ### Nutzungshinweise Die Prozedur `mysql.rds_stop_replication_for_channel` muss vom Hauptbenutzer ausgeführt werden. ### Beispiele Im folgenden Beispiel wird die Replikation auf `channel_1` des Multi-Source-Replikats beendet. ``` CALL mysql.rds_stop_replication_for_channel('channel_1'); ``` # Transaktionen replizieren mit GTIDs Die folgenden gespeicherten Prozeduren steuern, wie Transaktionen mithilfe von globalen Transaktions-Identifikatoren (GTIDs) mit RDS for MySQL repliziert werden. Weitere Hinweise zur Replikation auf GTIDs Basis von RDS for MySQL finden Sie unter[Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). Wenn Sie gespeicherte Verfahren verwenden, um die Replikation mit einem mit `caching_sha2_password` konfigurierten Replikationsbenutzer zu verwalten, müssen Sie TLS konfigurieren, indem Sie `SOURCE_SSL=1` festlegen. `caching_sha2_password` ist das Standard-Authentifizierungs-Plugin für RDS für MySQL 8.4. **Topics** + [ ## ](#mysql_rds_skip_transaction_with_gtid) + [ ## ](#mysql_rds_start_replication_until_gtid) ## Überspringt die Replikation einer Transaktion mit der angegebenen globalen Transaktionskennung (GTID) in einer MySQL-DB-Instance. Sie können dieses Verfahren für die Notfallwiederherstellung verwenden, wenn eine bestimmte GTID-Transaktion bekanntermaßen ein Problem verursacht. Verwenden Sie diese gespeicherte Prozedur, um die problematische Transaktion zu überspringen. Problematisch sind beispielsweise Transaktionen, die die Replikation deaktivieren, wichtige Daten löschen oder dafür sorgen, dass die DB-Instance nicht mehr verfügbar ist. ### Syntax ``` CALL mysql.rds_skip_transaction_with_gtid ( gtid_to_skip ); ``` ### Parameters *gtid\$1to\$1skip* Die GTID der zu überspringenden Replikationstransaktion. ### Nutzungshinweise Die Prozedur `mysql.rds_skip_transaction_with_gtid` muss vom Hauptbenutzer ausgeführt werden. Dieses Verfahren wird für alle Versionen von RDS für MySQL 5.7, alle Versionen von RDS für MySQL 8.0 sowie alle Versionen von RDS für MySQL 8.4 unterstützt. ### Beispiele Im folgenden Beispiel wird die Replikation der Transaktion mit der GTID übersprunge `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## Initiiert die Replikation von einer/einem RDS-für-MySQL-DB-Instance und stoppt die Replikation unmittelbar nach der angegebenen globalen Transaktionskennung (GTID). ### Syntax ``` CALL mysql.rds_start_replication_until_gtid(gtid); ``` ### Parameters *gtid* Die GTID, nach der die Replikation stoppen soll. ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication_until_gtid` muss vom Hauptbenutzer ausgeführt werden. Dieses Verfahren wird für alle Versionen von RDS für MySQL 5.7, alle Versionen von RDS für MySQL 8.0 sowie alle Versionen von RDS für MySQL 8.4 unterstützt. Sie können diese Prozedur mit verzögerter Replikation für die Notfallwiederherstellung verwenden. Wenn Sie die verzögerte Replikation konfiguriert haben, können Sie diese Prozedur verwenden, um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen. Nachdem diese Prozedur die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md). Sie können die verzögerte Replikation mit den folgenden gespeicherten Prozeduren konfigurieren: + [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) + [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) + [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) + [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) Wenn der Parameter `gtid` eine Transaktion angibt, die bereits von dem Replikat ausgeführt wurde, wird die Replikation sofort gestoppt. ### Beispiele Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die GTID erreicht wir `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` # Rotieren der Abfrageprotokolle Die folgenden gespeicherten Prozeduren rotieren MySQL-Protokolle in Backup-Tabellen. Weitere Informationen finden Sie unter [ MySQL-Datenbank-Logdateien](USER_LogAccess.Concepts.MySQL.md). **Topics** + [ ## mysql.rds\$1rotate\$1general\$1log ](#mysql_rds_rotate_general_log) + [ ## mysql.rds\$1rotate\$1slow\$1log ](#mysql_rds_rotate_slow_log) ## mysql.rds\$1rotate\$1general\$1log Rotiert die Tabelle `mysql.general_log` in eine Sicherungstabelle. ### Syntax ``` CALL mysql.rds_rotate_general_log; ``` ### Nutzungshinweise Sie können die Tabelle `mysql.general_log` in eine Sicherungstabelle rotieren, indem Sie die Prozedur `mysql.rds_rotate_general_log` aufrufen. Beim Rotieren von Protokolldateien wird die aktuelle Protokolltabelle in eine Sicherungsprotokolltabelle kopiert, und die Einträge in der aktuellen Protokolltabelle werden entfernt. Sofern bereits eine Sicherungsprotokolltabelle vorhanden ist, wird diese gelöscht, bevor die aktuelle Protokolltabelle in die Sicherungsprotokolltabelle kopiert wird. Sie können die Sicherungsprotokolltabelle abfragen, wenn dies nötig ist. Die Backup-Protokolltabelle für die `mysql.general_log`-Tabelle ist als `mysql.general_log_backup` benannt. Sie können dieses Verfahren nur ausführen, wenn der Parameter `log_output` auf `TABLE` eingestellt ist. ## mysql.rds\$1rotate\$1slow\$1log Rotiert die Tabelle `mysql.slow_log` in eine Sicherungstabelle. ### Syntax ``` CALL mysql.rds_rotate_slow_log; ``` ### Nutzungshinweise Sie können die Tabelle `mysql.slow_log` in eine Sicherungstabelle rotieren, indem Sie die Prozedur `mysql.rds_rotate_slow_log` aufrufen. Beim Rotieren von Protokolldateien wird die aktuelle Protokolltabelle in eine Sicherungsprotokolltabelle kopiert, und die Einträge in der aktuellen Protokolltabelle werden entfernt. Sofern bereits eine Sicherungsprotokolltabelle vorhanden ist, wird diese gelöscht, bevor die aktuelle Protokolltabelle in die Sicherungsprotokolltabelle kopiert wird. Sie können die Sicherungsprotokolltabelle abfragen, wenn dies nötig ist. Die Backup-Protokolltabelle für die `mysql.slow_log`-Tabelle ist als `mysql.slow_log_backup` benannt. # Festlegen und Anzeigen der Konfiguration des Binärprotokolls Die folgenden gespeicherten Prozeduren legen Konfigurationsparameter fest und zeigen sie an, z. B. für die Aufbewahrung binärer Protokolldateien. **Topics** + [ ## mysql.rds\$1set\$1configuration ](#mysql_rds_set_configuration) + [ ## mysql.rds\$1show\$1configuration ](#mysql_rds_show_configuration) ## mysql.rds\$1set\$1configuration Gibt die Anzahl an Stunden an, für die die Binärprotokolle aufbewahrt werden sollen, oder die Anzahl Sekunden, um die die Replikation verzögert werden soll. ### Syntax ``` CALL mysql.rds_set_configuration(name,value); ``` ### Parameters *name* Der Name des festzulegenden Konfigurationsparameters *value* Der Wert des Konfigurationsparameters ### Nutzungshinweise Die Prozedur `mysql.rds_set_configuration` unterstützt die folgenden Konfigurationsparameter: + [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours) + [Quellenverzögerung](#mysql_rds_set_configuration-usage-notes.source-delay) + [target delay](#mysql_rds_set_configuration-usage-notes.target-delay) Die Konfigurationsparameter werden dauerhaft gespeichert und überstehen jeden Neustart oder Failover der DB-Instance. #### binlog retention hours Der Parameter `binlog retention hours` wird verwendet, um die Anzahl der Stunden anzugeben, die Binärprotokolldateien aufbewahrt werden sollen. In der Regel werden binäre Protokolldateien von Amazon RDS so schnell wie möglich bereinigt. Eine binäre Protokolldatei ist möglicherweise für die Replikation mit einer außerhalb von RDS ausgeführten MySQL-Datenbank erforderlich. Der Standardwert von `binlog retention hours` ist `NULL`. Für RDS für MySQL bedeutet `NULL`, dass binäre Protokolle nicht aufbewahrt werden (0 Stunden). Um die Anzahl der Stunden zu bestimmen, für die Binärprotokolle auf einer/einem DB-Instance aufbewahrt werden sollen, verwenden Sie die gespeicherte Prozedur `mysql.rds_set_configuration` und geben Sie, wie in dem folgenden Beispiel gezeigt, einen ausreichend großen Zeitraum für die gewünschte Replikation an. `call mysql.rds_set_configuration('binlog retention hours', 24);` **Anmerkung** Sie können den Wert `0` nicht für `binlog retention hours` verwenden. Für MySQL-DB-Instances beträgt der maximal zulässige Wert für `binlog retention hours` 168 (entspricht 7 Tagen). Nachdem Sie den Aufbewahrungszeitraum festgelegt haben, überwachen Sie die Speichernutzung für die DB-Instance, um sicherzustellen, dass die aufbewahrten binären Protokolle nicht zu viel Speicherplatz beanspruchen. Bei Multi-AZ-DB-Cluster-Bereitstellungen können Sie die Aufbewahrung von Binärprotokollen nur über die Writer-DB-Instance konfigurieren und die Einstellung wird asynchron an alle Reader-DB-Instances weitergegeben. Wenn Binärprotokolle auf dem DB-Cluster die Hälfte des gesamten lokalen Speicherplatzes überschreiten, verschiebt Amazon RDS automatisch veraltete Protokolle auf das EBS-Volume. Die neuesten Protokolle verbleiben jedoch im lokalen Speicher, sodass sie verloren gehen können, wenn ein Fehler auftritt, der einen Host-Austausch erfordert, oder wenn Sie die Datenbank nach oben oder unten skalieren. #### Quellenverzögerung Verwenden Sie den Parameter `source delay` in einem Lesereplikat zur Angabe der Sekundenzahl, um die die Replikation vom Lesereplikat zur entsprechenden Quelldatenbank-Instance verzögert werden soll. Amazon RDS repliziert Änderungen normalerweise so schnell wie möglich, in einigen Umgebungen ist aber eine Verzögerung der Replikation sinnvoll. Wenn die Replikation verzögert wird, können Sie alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherstellen. Wenn eine Tabelle versehentlich entfernt wurde, können Sie sie aufgrund der verzögerten Replikation schnell wiederherstellen. Der Standardwert von `target delay` ist `0` (Replikation nicht verzögern). Wenn Sie diesen Parameter verwenden, wird [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) ausgeführt und „CHANGE primary TO MASTER\$1DELAY = input value“ angewendet. Bei Erfolg speichert die Prozedur den Parameter `source delay` in der Tabelle `mysql.rds_configuration`. Verwenden Sie zum Angeben der Anzahl der Sekunden für Amazon RDS, um die die Replikation in eine Quell-DB-Instance verzögert werden soll, die gespeicherte Prozedur `mysql.rds_set_configuration`. Im folgenden Beispiel wird die Replikation um mindestens eine Stunde (3 600 Sekunden) verzögert. `call mysql.rds_set_configuration('source delay', 3600);` Die Prozedur führt dann `mysql.rds_set_source_delay(3600)` aus. Die Obergrenze für den Parameter `source delay` beträgt einen Tag (86 400 Sekunden). #### target delay Verwenden Sie den Parameter `target delay` zur Angabe der Sekundenzahl, um die die Replikation zwischen einer DB-Instance und künftigen von RDS verwalteten Lesereplikaten, die anhand dieser Instance erstellt werden, verzögert werden soll. Dieser Parameter wird für non-RDS-managed Read Replicas ignoriert. Amazon RDS repliziert Änderungen normalerweise so schnell wie möglich, in einigen Umgebungen ist aber eine Verzögerung der Replikation sinnvoll. Wenn die Replikation verzögert wird, können Sie alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherstellen. Wenn eine Tabelle versehentlich entfernt wurde, können Sie sie mithilfe der verzögerten Replikation schnell wiederherstellen. Der Standardwert von `target delay` ist `0` (Replikation nicht verzögern). Für die Notfallwiederherstellung können Sie diesen Konfigurationsparameter mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden. Um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen, können Sie die Prozedur `mysql.rds_set_configuration` mit diesem Parametersatz ausführen. Nachdem die Prozedur `mysql.rds_start_replication_until` oder `mysql.rds_start_replication_until_gtid` die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md)). Um die Prozedur `mysql.rds_rds_start_replication_until_gtid` verwenden zu können, muss die GTID-basierte Replikation aktiviert sein. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie einen Notfall verursacht, können Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). Verwenden Sie zum Angeben der Anzahl der Sekunden für Amazon RDS, um die die Replikation in ein Lesereplikat verzögert werden soll, die gespeicherte Prozedur `mysql.rds_set_configuration`. Das folgende Beispiel gibt an, dass die Replikation um mindestens eine Stunde (3600 Sekunden) verzögert wird. `call mysql.rds_set_configuration('target delay', 3600);` Die Obergrenze für den Parameter `target delay` beträgt einen Tag (86 400 Sekunden). ## mysql.rds\$1show\$1configuration Die Anzahl der Stunden, während der binäre Protokolldateien aufbewahrt werden sollen. ### Syntax ``` CALL mysql.rds_show_configuration; ``` ### Nutzungshinweise Mit der gespeicherten Prozedur `mysql.rds_show_configuration` überprüfen Sie, wie viele Stunden Amazon RDS die binären Protokolldateien aufbewahrt werden. ### Beispiele Nachfolgend sehen Sie ein Beispiel für die Anzeige des Aufbewahrungszeitraums: ``` call mysql.rds_show_configuration; name value description binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted. ``` # Wärmen des InnoDB-Caches Die folgenden gespeicherten Prozeduren speichern, laden oder brechen das Laden des InnoDB-Pufferpools auf RDS-für-MySQL-DB-Instances ab. Weitere Informationen finden Sie unter [InnoDB-Cache-Warming für MySQL in Amazon RDS](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.InnoDBCacheWarming). **Topics** + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now ](#mysql_rds_innodb_buffer_pool_dump_now) + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort ](#mysql_rds_innodb_buffer_pool_load_abort) + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now ](#mysql_rds_innodb_buffer_pool_load_now) ## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now Speichert den aktuellen Zustand des Pufferpools auf der Festplatte. ### Syntax ``` CALL mysql.rds_innodb_buffer_pool_dump_now(); ``` ### Nutzungshinweise Die Prozedur `mysql.rds_innodb_buffer_pool_dump_now` muss vom Hauptbenutzer ausgeführt werden. ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort Bricht das Laden des gespeicherten Zustands des Pufferpools ab, während der Vorgang läuft. ### Syntax ``` CALL mysql.rds_innodb_buffer_pool_load_abort(); ``` ### Nutzungshinweise Die Prozedur `mysql.rds_innodb_buffer_pool_load_abort` muss vom Hauptbenutzer ausgeführt werden. ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now Lädt den gespeicherten Zustand des Pufferpools von der Festplatte. ### Syntax ``` CALL mysql.rds_innodb_buffer_pool_load_now(); ``` ### Nutzungshinweise Die Prozedur `mysql.rds_innodb_buffer_pool_load_now` muss vom Hauptbenutzer ausgeführt werden.