Confronto tra Aurora MySQL versione 3 e MySQL 8.0 Community Edition

È possibile utilizzare le seguenti informazioni per conoscere le modifiche di cui essere a conoscenza quando si converte da un sistema diverso compatibile con MySQL 8.0 a Aurora MySQL versione 3.

In generale, Aurora MySQL versione 3 supporta il set di funzionalità della community MySQL 8.0.23. Alcune nuove funzionalità dell'edizione della community di MySQL 8.0 non si applicano ad Aurora MySQL. Alcune di queste funzionalità non sono compatibili con alcuni aspetti di Aurora, come l'architettura di archiviazione Aurora. Non sono necessarie altre funzionalità perché il servizio di gestione Amazon RDS offre funzionalità equivalenti. Le seguenti funzionalità della community MySQL 8.0 non sono supportate o funzionano in modo diverso in Aurora MySQL versione 3.

Per le note di rilascio di tutte le release di Aurora MySQL versione 3, consultare Aggiornamenti del motore del database per Amazon Aurora MySQL versione 3 nelle Note di rilascio di Aurora MySQL.

Funzionalità di MySQL 8.0 non disponibili in Aurora MySQL versione 3

Le seguenti funzionalità della community MySQL 8.0 non sono disponibili o funzionano in modo diverso in Aurora MySQL versione 3.

Privilegio basato sui ruoli

Con Aurora MySQL versione 3, non è possibile modificare le tabelle direttamente nel database mysql. In particolare, non è possibile configurare gli utenti inserendoli nella tabella mysql.user. Invece, si utilizzano istruzioni SQL per concedere privilegi basati sui ruoli. Inoltre, nel database mysql, non è possibile creare altri tipi di oggetti come le stored procedure. È comunque possibile interrogare le tabelle di mysql. Se si utilizza la replica del registro binario, le modifiche apportate direttamente alle tabelle di mysql sul cluster fonte non vengono replicate nel cluster di destinazione.

In alcuni casi, l'applicazione potrebbe utilizzare scorciatoie per creare utenti o altri oggetti inserendoli nelle tabelle di mysql. In tal caso, modifica il codice dell'applicazione per utilizzare le istruzioni corrispondenti come CREATE USER. Se l'applicazione crea stored procedure o altri oggetti nel database mysql, utilizzare un database di tipo diverso.

Per esportare i metadati per gli utenti del database durante la migrazione da un database MySQL esterno, è possibile utilizzare il comando MySQL Shell anziché mysqldump. Per ulteriori informazioni, consulta Instance Dump Utility, Schema Dump Utility, and Table Dump Utility.

Per semplificare la gestione delle autorizzazioni per molti utenti o applicazioni, è possibile utilizzare l'istruzione CREATE ROLE per creare un ruolo con una serie di autorizzazioni. Puoi quindi utilizzare le istruzioni GRANT e SET ROLE e la funzione current_role per assegnare ruoli a utenti o applicazioni, cambiare il ruolo corrente e verificare quali ruoli sono in vigore. Per ulteriori informazioni sul sistema di autorizzazione basato sui ruoli in MySQL 8.0, consultare Utilizzo di ruoli nel Manuale di riferimento di MySQL.

rds_superuser_role

Aurora MySQL versione 3 include un ruolo speciale che ha tutti i seguenti privilegi. Il ruolo è denominato rds_superuser_role. L'utente amministrativo principale per ciascun cluster ha già concesso questo ruolo. Il ruolo rds_superuser_role include i seguenti privilegi per tutti gli oggetti del database:

La definizione del ruolo include anche la WITH GRANT OPTION in modo che un utente amministrativo possa concedere tale ruolo ad altri utenti. In particolare, l'amministratore deve concedere tutti i privilegi necessari per eseguire la replica del log binario con il cluster Aurora MySQL come destinazione.

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

Utente con ruolo di controllo dei privilegi per la replica di log binari

Aurora MySQL versione 3 include un utente con ruolo di controllo dei privilegi per la replica dei log binari (binlog), ossia rdsrepladmin_priv_checks_user. Oltre ai privilegi di rds_superuser_role, questo utente dispone del privilegio replication_applier.

Quando si attiva la replica binlog chiamando la stored procedure mysql.rds_start_replication, viene creato rdsrepladmin_priv_checks_user.

L’utente rdsrepladmin_priv_checks_user@localhost è un utente riservato. Non modificarlo.

Ruoli per l’accesso ad altri servizi AWS

Aurora MySQL versione 3 include ruoli che è possibile utilizzare per accedere ad altri servizi AWS. È possibile impostare molti di questi ruoli come alternativa alla concessione di privilegi. Ad esempio, specificare GRANT AWS_LAMBDA_ACCESS TO user anzichéGRANT INVOKE LAMBDA ON *.* TO user. Per le procedure di accesso ad altri servizi AWS, vedere Integrazione di Amazon Aurora MySQL con altri servizi AWS. Aurora MySQL versione 3 include i seguenti ruoli relativi all'accesso ad altri servizi AWS:

Quando si concede l'accesso utilizzando i ruoli in Aurora MySQL versione 3, si attiva anche il ruolo utilizzando l'istruzione SET ROLE role_name o SET ROLE ALL. L’esempio seguente mostra come. Sostituire il nome del ruolo appropriato per 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`@`%` |
+-----------------------------------------------------+

Individuazione dell’ID server del database

L’ID del server del database (server_id) è necessario per la replica di log binari (binlog). Il metodo per l’individuazione dell’ID server è diverso in Aurora MySQL e in Community MySQL.

In Community MySQL, l’ID server è un numero, che si ottiene utilizzando la seguente sintassi durante la connessione al server:

mysql> select @@server_id;

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

In Aurora MySQL, l’ID server è l’ID dell’istanza database, che si ottiene utilizzando la seguente sintassi durante la connessione all’istanza database:

mysql> select @@aurora_server_id;

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

Per ulteriori informazioni sulla replica binlog, consulta Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari).

Autenticazione

Nella community MySQL 8.0, il plug-in di autenticazione di default è caching_sha2_password. Aurora MySQL versione 3 utilizza ancora il plug-in mysql_native_password. Non è possibile modificare l'impostazione default_authentication_plugin. Tuttavia, è possibile creare nuovi utenti e modificare gli utenti correnti; le password individuali degli utenti utilizzano il nuovo plugin di autenticazione. Di seguito è riportato un esempio.

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