Vergleich von Aurora-MySQL-Version 3 und MySQL 8.0 Community Edition

Sie können die folgenden Informationen verwenden, um mehr über die Änderungen zu erfahren, die Sie beachten müssen, wenn Sie von einem anderen MySQL 8.0-kompatiblen System zu Aurora-MySQL-Version 3 konvertieren.

Im Allgemeinen unterstützt Aurora MySQL Version 3 den Feature-Set der Community MySQL 8.0.23. Einige neue Funktionen der MySQL 8.0 Community Edition gelten nicht für Aurora MySQL. Einige dieser Funktionen sind mit einigen Aurora-Aspekten, wie der Aurora-Speicherarchitektur, nicht kompatibel. Andere Funktionen sind nicht erforderlich, da der Amazon-RDS-Verwaltungsservice gleichwertige Funktionen bietet. Die folgenden Funktionen in der Community MySQL 8.0 werden in Aurora-MySQL-Version 3 nicht unterstützt oder funktionieren anders.

Die Versionshinweise für alle Versionen von Aurora MySQL Version 3 finden Sie unter Aktualisierungen der Datenbank-Engine für Amazon Aurora MySQL Version 3 in den Versionshinweisen für Aurora MySQL.

MySQL-8.0-Funktionen sind in Aurora-MySQL-Version 3 nicht verfügbar

Die folgenden Funktionen der Community MySQL 8.0 sind in Aurora MySQL Version 3 nicht verfügbar oder funktionieren anders.

Rollenbasiertes Berechtigungsmodell

Mit Aurora MySQL Version 3 können Sie die Tabellen immysql-Datenbank direkt. Insbesondere können Sie Benutzer nicht einrichten, indem Sie in diemysql.user-Tabelle Stattdessen verwenden Sie SQL-Anweisungen, um 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 ammysqlTabellen im Quellcluster werden 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 diemysql-Tabellen Wenn ja, ändern Sie Ihren Anwendungscode, um die entsprechenden Anweisungen wie CREATE USER zu verwenden. Wenn Ihre Anwendung gespeicherte Prozeduren oder andere Objekte in der mysql-Datenbank erstellt, verwenden Sie stattdessen eine andere Datenbank.

Um Metadaten für Datenbankbenutzer während der Migration aus einer externen MySQL-Datenbank zu exportieren, können Sie einen MySQL-Shell-Befehl anstelle von mysqldump verwenden. Weitere Informationen finden Sie unter Dienstprogramme für Instance-, Schema- und Tabellen-Dumps.

Um die Verwaltung von Berechtigungen für viele Benutzer oder Anwendungen zu vereinfachen, können SieCREATE ROLE-Anweisung zum Erstellen einer Rolle mit einer Reihe von Berechtigungen. Dann können Sie dieGRANTundSET ROLE-Anweisungen und diecurrent_roleFunktion, 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 im MySQL-Referenzhandbuch.

rds_superuser_role

Aurora-MySQL-Version 3 enthält eine spezielle Rolle, die alle folgenden Berechtigungen besitzt. Der Name der Rolle lautet rds_superuser_role. Dem primären Administratorbenutzer für jeden Cluster wurde diese Rolle bereits gewährt. Dierds_superuser_roleenthält die folgenden Berechtigungen für alle Datenbankobjekte:

Die Rollendefinition umfasst auchWITH GRANT OPTIONdamit 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 Aurora MySQL-Cluster als Ziel erforderlich sind.

SHOW GRANTS FOR rds_superuser_role@'%';
SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%';

Benutzer zur Berechtigungsprüfung für die Replikation von Binärprotokollen

Aurora-MySQL-Version 3 enthält einen Benutzer zur Berechtigungsprüfung für die Replikation von Binärprotokollen (Binlog), rdsrepladmin_priv_checks_user. Zusätzlich zu den Berechtigungen einer rds_superuser_role verfügt dieser Benutzer über die replication_applier-Berechtigung.

Wenn Sie die Binlog-Replikation aktivieren, indem Sie die gespeicherte Prozedur mysql.rds_start_replication aufrufen, wird rdsrepladmin_priv_checks_user erstellt.

Der Benutzer rdsrepladmin_priv_checks_user@localhost ist ein reservierter Benutzer. Ändern Sie ihn nicht.

Rollen für den Zugriff auf andere AWS Dienste

Aurora MySQL Version 3 enthält Rollen, mit denen Sie auf andere AWS Dienste zugreifen können. Viele dieser Rollen lassen sich alternativ zur Vergabe von Berechtigungen festlegen. Sie geben beispielsweiseGRANT AWS_LAMBDA_ACCESS TO userINSTEAD OFGRANT INVOKE LAMBDA ON *.* TO useraus. Die Verfahren für den Zugriff auf andere AWS Dienste finden Sie unterIntegrieren von Amazon Aurora MySQL in anderen AWS-Services. Aurora MySQL Version 3 umfasst die folgenden Rollen im Zusammenhang mit dem Zugriff auf andere AWS Dienste:

Wenn Sie Zugriff mithilfe von Rollen in Aurora MySQL Version 3 gewähren, aktivieren Sie die Rolle auch mithilfe derSET ROLE role_nameoderSET ROLE ALLstatement. Im folgenden Beispiel wird gezeigt, wie dies geschieht. Ersetzen Sie den entsprechenden Rollennamen für AWS_SELECT_S3_ACCESS.

# Grant role to user.

mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address'

# Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS 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()                                      |
+-----------------------------------------------------+
| `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` |
+-----------------------------------------------------+

Finden der Datenbankserver-ID

Die Datenbankserver-ID (server_id) ist für die Replikation von Binärprotokollen (Binlog) erforderlich. Die Methode, die Server-ID zu finden, unterscheidet sich in Aurora MySQL von Community MySQL.

In Community MySQL ist die Server-ID eine Zahl, die Sie mithilfe der folgenden Syntax erhalten, während Sie beim Server angemeldet sind:

mysql> select @@server_id;

+-------------+
| @@server_id |
+-------------+
| 2           |
+-------------+
1 row in set (0.00 sec)

In Aurora MySQL ist die Server-ID die DB-Instance-ID, die Sie mithilfe der folgenden Syntax erhalten, während Sie bei der DB-Instance angemeldet sind:

mysql> select @@aurora_server_id;

+------------------------+
| @@aurora_server_id     |
+------------------------+
| mydbcluster-instance-2 |
+------------------------+
1 row in set (0.00 sec)

Weitere Informationen zur Binlog-Replikation finden Sie unter Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation).

Authentifizierung

In Community MySQL 8.0 ist das Standard-Authentifizierungs-Plugin caching_sha2_password. Aurora MySQL Version 3 verwendet immer nochmysql_native_password-Plugin. Sie können die default_authentication_plugin-Einstellung nicht ändern. Sie können jedoch neue Benutzer erstellen und aktuelle Benutzer sowie deren individuelle Passwörter ändern, indem Sie das neue Authentifizierungs-Plugin verwenden. Im Folgenden sehen Sie ein Beispiel.

mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword';
Query OK, 0 rows affected (0.74 sec)