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.
Vergleich von Aurora MySQL Version 8.4 und MySQL 8.4 Community Edition
In diesem Thema werden die Unterschiede zwischen Aurora MySQL Version 8.4 und MySQL 8.4 Community Edition beschrieben.
Themen
Authentifizierung
Aurora MySQL Version 8.4 unterstützt nur die folgenden Werte für den authentication_policy Parameter:
-
*:caching_sha2_password(Standardwert. Erlaubt jedes Ein-Faktor-Authentifizierungs-Plugin,caching_sha2_passwordsofern keines angegeben ist) -
*:mysql_native_password(Erlaubt jedes Ein-Faktor-Authentifizierungs-Plugin,mysql_native_passwordwenn keines angegeben ist)
Anmerkung
Multi-factor Authentifizierungskonfigurationen werden in Aurora MySQL nicht unterstützt.
Reservierte Benutzer
Aurora MySQL reserviert bestimmte Benutzernamen für interne Funktionen. Diese Benutzernamen können nicht für Ihre Datenbankbenutzerkonten verwendet werden. Weitere Informationen finden Sie unter Reservierte Benutzer in Aurora MySQL.
Ab Aurora MySQL Version 8.4.7 schützt die Engine, rdsproxyadmin weil sie der Monitoring-Benutzer für RDS Proxy ist. Aurora erstellt das rdsproxyadmin Konto automatisch, wenn Sie ein Proxyziel registrieren. Einzelheiten zu den abgelehnten Vorgängen und der Fehlerausgabe finden Sie unterReservierte Benutzer in Aurora MySQL.
rds_superuser_role
Aurora MySQL Version 8.4 enthält eine spezielle Rolle mit allen folgenden Rechten. Der Name der Rolle lautet rds_superuser_role. Dem Master-Benutzer für jeden Cluster wurde diese Rolle bereits zugewiesen. Dierds_superuser_roleenthält die folgenden Berechtigungen für alle Datenbankobjekte:
ALTERALLOW_NONEXISTENT_DEFINERAPPLICATION_PASSWORD_ADMINALTER ROUTINECONNECTION_ADMINCREATECREATE ROLECREATE ROUTINECREATE TEMPORARY TABLESCREATE USERCREATE VIEWDELETEDROPDROP ROLEEVENTEXECUTEFLUSH_OPTIMIZER_COSTSFLUSH_PRIVILEGESFLUSH_STATUSFLUSH_TABLESFLUSH_USER_RESOURCESINDEXINSERTLOCK TABLESOPTIMIZE_LOCAL_TABLEPROCESSREFERENCESRELOADREPLICATION CLIENTREPLICATION SLAVEROLE_ADMINSELECTSET_ANY_DEFINERSHOW DATABASESSHOW_ROUTINESHOW VIEWTRIGGERUPDATEXA_RECOVER_ADMIN
Unterstützung für Komponenten zur Passwortvalidierung in Aurora MySQL Version 8.4
-
Die
validate_passwordKomponente wird unterstützt, einschließlich ihrer Anpassungen. Die Komponente wird über den Datenbankparameteraurora_enable_validate_password_componentanstelle vonINSTALL COMPONENTUNINSTALL COMPONENTAND-Befehlen verwaltet. -
Das
validate_passwordPlugin wird teilweise unterstützt, um die Migration zur Komponente zu ermöglichen.
Weitere Informationen finden Sie unter Passwortrichtlinien und Passwortvalidierung in Aurora MySQL.
Die Standardwerte der Parameter ändern sich
temptable_max_mmap
In MySQL 8.4 Community Edition temptable_max_mmap ist der Standardwert von0, wodurch temporäre Tabellen mit Speicherzuweisung deaktiviert werden.
Aurora MySQL Version 8.4.7 und höher überschreibt diese Standardeinstellung. Aurora legt einen Wert festtemptable_max_mmap, der anhand des zugewiesenen Speichers des Clusters berechnet wird, wobei die folgende Formel verwendet wird:
LEAST(4294967296, {AllocatedStorage*3/100})
Dies legt den Standardwert auf 3% des zugewiesenen Speichers fest, begrenzt auf maximal 4 GiB. Memory-mapped Temporäre Tabellen bleiben in Aurora MySQL Version 8.4.7 und höher standardmäßig aktiviert, im Gegensatz zu Community-MySQL 8.4.
Den Referenzeintrag für den Parameter finden Sie unterAurora MySQL Konfigurationsparameter.