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à.
# Risoluzione dei problemi relativi all'aggiornamento in loco di Aurora MySQL
Utilizza i seguenti suggerimenti per risolvere i problemi relativi agli aggiornamenti in loco di Aurora MySQL. Questi suggerimenti non si applicano a cluster di database Aurora Serverless.
| Motivo dell'annullamento o della lentezza dell'aggiornamento in loco | Effetto | Soluzione per consentire il completamento dell'aggiornamento in loco all'interno della finestra di manutenzione |
| --- | --- | --- |
| Non sono ancora state applicate patch alla replica tra Regioni Aurora associata | Aurora annulla l'aggiornamento. | Aggiorna la replica tra Regioni Aurora e riprova. |
| Il cluster ha transazioni XA nello stato preparato | Aurora annulla l'aggiornamento. | Salvare o eseguire il rollback di tutte le transazioni XA preparate. |
| Il cluster sta elaborando un'istruzione DDL (Data Definition Language) | Aurora annulla l'aggiornamento. | Prendere in considerazione di attendere il completamento di tutte le istruzioni DDL prima di eseguire l'aggiornamento. |
| Il cluster ha modifiche non salvate per molte righe | L'aggiornamento potrebbe richiedere molto tempo. | Il processo di aggiornamento esegue il rollback delle modifiche non salvate. L'indicatore per questa condizione è il valore di `TRX_ROWS_MODIFIED` nella tabella `INFORMATION_SCHEMA.INNODB_TRX`. Prendere in considerazione l'esecuzione dell'aggiornamento solo dopo avere salvato le modifiche o eseguito il rollback di tutte le transazioni di grandi dimensioni. |
| Il cluster ha un numero elevato di record di annullamento | L'aggiornamento potrebbe richiedere molto tempo. | Anche se le transazioni non salvate non interessano un numero elevato di righe, potrebbero comportare un grande volume di dati. Ad esempio, è possibile che si inseriscano BLOB di grandi dimensioni. Aurora non rileva o genera automaticamente un evento per questo tipo di attività di transazione. L’indicatore per questa condizione è la lunghezza dell’elenco della cronologia (HLL). Il processo di aggiornamento esegue il rollback delle modifiche non salvate. È possibile controllare l’HLL nell’output del comando SQL `SHOW ENGINE INNODB STATUS` o direttamente utilizzando la seguente query SQL: SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
Puoi monitorare la metrica `RollbackSegmentHistoryListLength` anche in Amazon CloudWatch. Valuta la possibilità di eseguire l’aggiornamento solo dopo che la lunghezza dell’elenco della cronologia sarà diminuita. |
| Il cluster è in fase di salvataggio di una transazione di log binario di grandi dimensioni | L'aggiornamento potrebbe richiedere molto tempo. | Il processo di aggiornamento attende fino a quando non vengono applicate le modifiche del log binario. Altre transazioni o istruzioni DDL potrebbero iniziare durante questo periodo, rallentando ulteriormente il processo di aggiornamento. Pianificare il processo di aggiornamento quando il cluster non è occupato con la generazione di modifiche alla replica del log binario. Aurora non rileva o genera automaticamente un evento per questa condizione. |
| Incongruenze dello schema derivanti dalla rimozione o dal danneggiamento dei file | Aurora annulla l'aggiornamento. | Cambiare il motore di archiviazione predefinito per le tabelle temporanee da MyISAM in InnoDB. Esegui queste fasi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| L’utente master è stato eliminato | Aurora annulla l'aggiornamento. | Non eliminare l’utente master. Tuttavia, se per qualche motivo dovessi eliminare l’utente master, ripristinalo utilizzando i seguenti comandi SQL: CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
Per ulteriori dettagli sulla risoluzione dei problemi che causano l’esito negativo dei controlli preliminari di aggiornamento, consulta i seguenti blog:
+ [Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 2](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
È possibile utilizzare la procedura seguente per eseguire controlli personalizzati per alcune delle condizioni della tabella precedente. In questo modo, è possibile pianificare l'aggiornamento in un momento in cui si sa che il database si trova in uno stato in cui l'aggiornamento può essere completato correttamente e con rapidità.
+ È possibile verificare la presenza di transazioni XA aperte eseguendo l'istruzione `XA RECOVER`. È quindi possibile salvare le modifiche o eseguire il rollback delle transazioni XA prima di iniziare l'aggiornamento.
+ È possibile verificare la presenza di istruzioni DDL eseguendo un'istruzione `SHOW PROCESSLIST` e cercando le istruzioni `CREATE`, `DROP`, `ALTER`, `RENAME` e `TRUNCATE` nell'output. Consentire il completamento di tutte le istruzioni DDL prima di iniziare l'aggiornamento.
+ È possibile controllare il numero totale di righe non salvate eseguendo una query sulla tabella `INFORMATION_SCHEMA.INNODB_TRX`. La tabella contiene una riga per ogni transazione. La colonna `TRX_ROWS_MODIFIED` contiene il numero di righe modificate o inserite dalla transazione.
+ È possibile controllare la lunghezza della lista della cronologia InnoDB eseguendo l'istruzione `SHOW ENGINE INNODB STATUS SQL` e cercando la `History list length` nell'output. È inoltre possibile controllare direttamente il valore eseguendo la seguente query:
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
La lunghezza dell'elenco cronologico corrisponde alla quantità di informazioni di annullamento memorizzate dal database per implementare il controllo della concorrenza multiversione (MVCC).