View a markdown version of this page

Confronto tra Aurora MySQL versione 8.4 e MySQL 8.4 Community Edition - Amazon Aurora

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Confronto tra Aurora MySQL versione 8.4 e MySQL 8.4 Community Edition

Questo argomento descrive le differenze tra Aurora MySQL versione 8.4 e MySQL 8.4 Community Edition.

Autenticazione

Aurora MySQL versione 8.4 supporta solo i seguenti valori per il parametro: authentication_policy

  • *:caching_sha2_password(Valore predefinito. Consente qualsiasi plug-in di autenticazione a fattore singolo, utilizzandolo caching_sha2_password se non ne è specificato nessuno)

  • *:mysql_native_password(Consente qualsiasi plug-in di autenticazione a fattore singolo, utilizzandolo mysql_native_password se non ne è specificato nessuno)

Nota

Multi-factor le configurazioni di autenticazione non sono supportate in Aurora MySQL.

Utenti riservati

Aurora MySQL riserva determinati nomi utente per le funzionalità interne. Questi nomi utente non possono essere utilizzati per gli account utente del database. Per ulteriori informazioni, consulta Utenti riservati in Aurora MySQL.

A partire dalla versione 8.4.7 di Aurora MySQL, il motore protegge rdsproxyadmin perché è l'utente di monitoraggio per RDS Proxy. Aurora crea l'rdsproxyadminaccount automaticamente quando registri un target proxy. Per informazioni dettagliate sulle operazioni rifiutate e sull'output degli errori, consultaUtenti riservati in Aurora MySQL.

rds_superuser_role

Aurora MySQL versione 8.4 include un ruolo speciale con tutti i seguenti privilegi. Il ruolo è denominato rds_superuser_role. Questo ruolo è già concesso all'utente principale di ogni cluster. Il ruolo rds_superuser_role include i seguenti privilegi per tutti gli oggetti del database:

  • 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

Supporto del componente di convalida della password in Aurora MySQL versione 8.4

  • Il validate_password componente è supportato, incluse le relative personalizzazioni. Il componente viene gestito tramite il parametro del database aurora_enable_validate_password_component anziché UNINSTALL COMPONENT i comandi INSTALL COMPONENT and.

  • Il validate_password plugin è parzialmente supportato per consentire la migrazione al componente.

Per ulteriori informazioni, consulta Politiche e convalida delle password in Aurora MySQL.

Modifiche ai parametri predefiniti

temptable_max_mmap

In MySQL 8.4 Community Edition, il valore predefinito di 0 è, che disabilita le tabelle temporanee temptable_max_mmap mappate in memoria.

Aurora MySQL versione 8.4.7 e successive sostituisce questa impostazione predefinita. Aurora imposta temptable_max_mmap un valore calcolato dallo storage allocato del cluster, utilizzando la seguente formula:

LEAST(4294967296, {AllocatedStorage*3/100})

Questo imposta il valore predefinito al 3% dello storage allocato, con un limite massimo di 4 GiB. Memory-mapped le tabelle temporanee rimangono abilitate per impostazione predefinita in Aurora MySQL versione 8.4.7 e successive, a differenza della community MySQL 8.4.

Per la voce di riferimento del parametro, vedere. Parametri di configurazione Aurora MySQL