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 un comando MySQL Shell anziché. mysqldump Per ulteriori informazioni, vedere Instance Dump Utility, Schema Dump Utility e 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@'%';

Privilege controlla l'utente per la replica dei log binari

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

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

L'rdsrepladmin_priv_checks_user@localhostutente è un utente riservato. Non modificarlo.

Ruoli per l'accesso ad altri AWS servizi

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 AWS servizi, vedere. Integrazione di Amazon Aurora SQL My 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 del server del database

L'ID del server di database (server_id) è necessario per la replica con registrazione binaria (binlog). Il modo per trovare l'ID del server è diverso in Aurora MySQL da Community MySQL.

In Community MySQL, l'ID del server è un numero, che si ottiene utilizzando la seguente sintassi mentre si è connessi 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 DB, che si ottiene utilizzando la seguente sintassi mentre si accede all'istanza DB:

mysql> select @@aurora_server_id;

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

Per ulteriori informazioni sulla replica binlog, vedere. Replica tra Aurora e SQL My o tra Aurora e un altro cluster Aurora DB (replica di 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 attuali, e le loro password individuali utilizzano il nuovo plug-in 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)