View a markdown version of this page

Vergleich von Aurora MySQL Version 8.4 und MySQL 8.4 Community Edition - Amazon Aurora

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.

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_password sofern keines angegeben ist)

  • *:mysql_native_password(Erlaubt jedes Ein-Faktor-Authentifizierungs-Plugin, mysql_native_password wenn 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:

  • ALTER

  • ALLOW_NONEXISTENT_DEFINER

  • APPLICATION_PASSWORD_ADMIN

  • ALTER ROUTINE

  • CONNECTION_ADMIN

  • CREATE

  • CREATE ROLE

  • CREATE ROUTINE

  • CREATE TEMPORARY TABLES

  • CREATE USER

  • CREATE VIEW

  • DELETE

  • DROP

  • DROP ROLE

  • EVENT

  • EXECUTE

  • FLUSH_OPTIMIZER_COSTS

  • FLUSH_PRIVILEGES

  • FLUSH_STATUS

  • FLUSH_TABLES

  • FLUSH_USER_RESOURCES

  • INDEX

  • INSERT

  • LOCK TABLES

  • OPTIMIZE_LOCAL_TABLE

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • ROLE_ADMIN

  • SELECT

  • SET_ANY_DEFINER

  • SHOW DATABASES

  • SHOW_ROUTINE

  • SHOW VIEW

  • TRIGGER

  • UPDATE

  • XA_RECOVER_ADMIN

Unterstützung für Komponenten zur Passwortvalidierung in Aurora MySQL Version 8.4

  • Die validate_password Komponente wird unterstützt, einschließlich ihrer Anpassungen. Die Komponente wird über den Datenbankparameter aurora_enable_validate_password_component anstelle von INSTALL COMPONENT UNINSTALL COMPONENT AND-Befehlen verwaltet.

  • Das validate_password Plugin 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.