' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
Il controllo preliminare segnala che nella tabella `test.test` sono presenti operazioni Fast DDL in sospeso.
Per consentire il proseguimento dell’aggiornamento, è possibile creare nuovamente la tabella, quindi tentare di eseguire di nuovo l’aggiornamento.
Prima di creare nuovamente i tablespace, consulta le [operazioni Online DDL](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) nella documentazione di MySQL per comprendere gli effetti del blocco e dello spostamento dei dati sulle transazioni in primo piano.
```
mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status | OK |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)
```
Dopo aver creato nuovamente la tabella, il controllo preliminare ha esito positivo.
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"detectedProblems": []
}
```
**auroraGetDanglingFulltextIndex**
**Livello di controllo preliminare: errore**
**Tabelle con riferimento all’indice `FULLTEXT` dangling**
Prima di MySQL 5.6.26, era possibile che, dopo aver eliminato un indice di ricerca full-text, le colonne nascoste `FTS_DOC_ID` e `FTS_DOC_ID_INDEX` diventassero orfane. Per ulteriori informazioni, consulta [Bug \$176012](https://bugs.mysql.com/bug.php?id=76012).
Se sono presenti tabelle create in versioni precedenti di MySQL per cui è stato riscontrato quanto descritto sopra, l’aggiornamento ad Aurora MySQL versione 3 può non riuscire. Questo controllo preliminare verifica che nel cluster di database non esistano tali indici full-text orfani o dangling prima dell’aggiornamento a MySQL 8.0. Se questo controllo preliminare ha esito negativo, crea nuovamente tutte le tabelle che contengono tali indici full-text dangling.
**Output di esempio:**
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.table_with_fts_index",
"description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
}
]
},
```
Il controllo preliminare segnala un errore per la tabella `test.table_with_fts_index` perché contiene un indice full-text dangling. Per consentire il proseguimento dell’aggiornamento, crea nuovamente la tabella per eseguire la pulizia delle tabelle ausiliarie con indice full-text. Utilizza `OPTIMIZE TABLE test.table_with_fts_index` o `ALTER TABLE test.table_with_fts_index, ENGINE=INNODB`.
Dopo aver creato nuovamente la tabella, il controllo preliminare ha esito positivo.
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**Livello di controllo preliminare: errore**
**Verifica l’eventuale presenza di incoerenze relative al percorso di file `ibd`**
Questo controllo preliminare si applica solo ad Aurora MySQL versione 3.03.0 e precedenti. Se si verifica un errore con questo controllo preliminare, esegui l’aggiornamento ad Aurora MySQL versione 3.04 o successive.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**Livello di controllo preliminare: errore**
**Verifica la presenza di un indice full-text con ID di spazio pari a zero**
In MySQL, quando si aggiunge un [indice full-text](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html) a una tabella InnoDB, vengono creati alcuni tablespace di indici ausiliari. A causa di un [bug](https://bugs.mysql.com/bug.php?id=72132) nelle versioni precedenti di MySQL, poi corretto nella versione 5.6.20, era possibile che queste tabelle di indici ausiliari fossero state create nel [tablespace di sistema](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace), anziché nel tablespace InnoDB.
Se esistono tablespace ausiliari di questo tipo, l’aggiornamento non riesce. Crea nuovamente gli indici full-text indicati nell’errore del controllo preliminare, quindi tenta di eseguire di nuovo l’aggiornamento.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.fts_space_zero_check",
"description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
},
```
Il controllo preliminare segnala un errore per la tabella `test.fts_space_zero_check`, poiché include tabelle ausiliarie di ricerca full-text (FTS) nel tablespace di sistema.
Dopo aver eliminato e creato nuovamente gli indici FTS associati a questa tabella, il controllo preliminare ha esito positivo.
Prima di creare nuovamente i tablespace, consulta le [operazioni di partizionamento](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning) nella documentazione di MySQL per comprendere gli effetti del blocco e dello spostamento dei dati sulle transazioni in primo piano.
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**Livello di controllo preliminare: errore**
**Verifica la presenza di transazioni XA in stato preparato**
Durante l’esecuzione del processo di aggiornamento a una versione principale, è essenziale che l’istanza database Aurora MySQL versione 2 sia sottoposta a un [arresto pulito](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). Ciò garantisce che tutte le transazioni vengano eseguite o ripristinate e che InnoDB abbia eliminato tutti i record del log di undo. Poiché il rollback delle transazioni è necessario, se il database contiene [transazioni XA](https://dev.mysql.com/doc/refman/5.7/en/xa.html) in stato preparato, può impedire il proseguimento dell’arresto pulito. Per questo motivo, se vengono rilevate transazioni XA preparate, l’aggiornamento non potrà procedere finché non si interverrà per eseguirne il commit o il rollback.
Per ulteriori informazioni sulla ricerca di transazioni XA in stato preparato utilizzando `XA RECOVER`, consulta [XA transaction SQL statements](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html) nella documentazione di MySQL. Per ulteriori informazioni sugli stati delle transazioni XA, consulta [XA transaction states](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html) nella documentazione di MySQL.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
}
]
}
```
Questo controllo preliminare segnala un errore perché vi sono transazioni in stato preparato di cui deve essere eseguito il commit o il rollback.
Dopo aver effettuato l’accesso al database, puoi controllare la tabella [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) e l’output `XA RECOVER` per ulteriori informazioni.
Prima di eseguire il commit o il rollback di una transazione, è consigliabile consultare la [documentazione di MySQL](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html) e i requisiti dell’applicazione.
```
mysql> select trx_started,
trx_mysql_thread_id,
trx_id,trx_state,
trx_operation_state,
trx_rows_modified,
trx_rows_locked
from
information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started | trx_mysql_thread_id | trx_id | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 | 0 | 2849470 | RUNNING | NULL | 1 | 0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)
mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+--------+
| 1 | 6 | 0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)
```
In questo esempio, viene eseguito il rollback della transazione preparata.
```
mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)
```
Dopo il rollback della transazione XA, il controllo preliminare ha esito positivo.
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**Livello di controllo preliminare: errore**
**Verifica se l’aggiornamento è supportato nella classe di istanza corrente**
L’esecuzione di un aggiornamento in loco da Aurora MySQL versione 2.12.0 o 2.12.1, in cui la [classe di istanza database](Concepts.DBInstanceClass.md) di scrittura è db.r6i.32xlarge, al momento non è supportata. In questo caso, il controllo preliminare restituisce un errore. Per consentire il proseguimento dell’aggiornamento, puoi modificare la classe dell’istanza database impostandola su db.r6i.24xlarge o una versione precedente. Altrimenti puoi eseguire l’aggiornamento ad Aurora MySQL versione 2.12.2 o successiva, in cui l’aggiornamento in loco ad Aurora MySQL versione 3 è supportato su db.r6i.32xlarge.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForInstanceLimit",
"title": "Checks if upgrade is supported on the current instance class",
"status": "OK",
"description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
}
]
},
```
Il controllo preliminare restituisce un errore perché l’istanza database di scrittura utilizza la classe di istanza db.r6i.32xlarge ed è in esecuzione su Aurora MySQL versione 2.12.1.
**auroraUpgradeCheckForInternalUsers**
**Livello di controllo preliminare: errore**
**Verifica la presenza di utenti interni 8.0**
Questo controllo preliminare si applica solo ad Aurora MySQL versione 3.03.0 e precedenti. Se si verifica un errore con questo controllo preliminare, esegui l’aggiornamento ad Aurora MySQL versione 3.04 o successive.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews**
**Livello di controllo preliminare: errore**
**Verifica la presenza di caratteri utf8mb3 non validi nella definizione della vista**
Questo controllo preliminare identifica le viste che contengono commenti con codifica dei caratteri non validi `utf8mb3`. In MySQL 8.0, viene applicata una convalida più rigorosa alla codifica dei caratteri nei metadati, inclusi i commenti delle viste. Se la definizione di una vista contiene caratteri che non sono validi nel set di caratteri `utf8mb3`, l’aggiornamento non riesce.
Per risolvere questo problema, modifica la definizione della vista per rimuovere o sostituire eventuali caratteri non BMP prima di tentare l’aggiornamento.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews",
"title": "Check for invalid utf8mb3 character string.",
"status": "OK",
"description": "Definition of following view(s) has/have invalid utf8mb3 character string.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_invalid_char_view",
"description": "Definition of view precheck.utf8mb3_invalid_char_view contains an invalid utf8mb3 character string. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify the view definition to not use non-BMP characters and try the upgrade again."
}
]
},
```
Il controllo preliminare segnala che la definizione della vista `utf8mb3_invalid_char_view` contiene caratteri `utf8mb3` non validi nella relativa definizione.
Per risolvere questo problema, identifica la vista che contiene i caratteri non supportati e aggiorna i commenti. Innanzitutto, esamina la struttura della vista e identifica i commenti.
```
MySQL> SHOW CREATE VIEW precheck.utf8mb3_invalid_char_view\G
*************************** 1. row ***************************
View: utf8mb3_invalid_char_view
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`admin`@`%` SQL SECURITY DEFINER VIEW `utf8mb3_invalid_char_view` AS select 'This row contains a dolphin 🐬' AS `message`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set, 1 warning (0.00 sec)
```
Dopo aver identificato la vista che contiene l’errore, sostituisci la vista con l’istruzione `CREATE OR REPLACE VIEW`.
```
MySQL> CREATE OR REPLACE VIEW precheck.utf8mb3_invalid_char_view AS select 'This view definition to not use non-BMP characters' AS message;
```
Dopo aver aggiornato tutte le definizioni di viste che contengono caratteri non supportati, il controllo preliminare viene superato e l’aggiornamento può procedere.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**Livello di controllo preliminare: errore**
**Verifica la presenza di commenti non validi nella colonna utf8mb3**
Questo controllo preliminare identifica le tabelle che contengono commenti delle colonne con codifica dei caratteri non validi `utf8mb3`. In MySQL 8.0, viene applicata una convalida più rigorosa alla codifica dei caratteri nei metadati, inclusi i commenti delle colonne. Se un commento di colonna contiene caratteri che non sono validi nel set di caratteri utf8mb3, l’aggiornamento non riuscirà.
Per risolvere questo problema, è necessario modificare i commenti delle colonne per rimuovere o sostituire eventuali caratteri non BMP prima di tentare l’aggiornamento. È possibile utilizzare l’istruzione `ALTER TABLE` per aggiornare i commenti della colonna.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.t2",
"description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
}
```
Il controllo preliminare segnala che la tabella `test.t2` contiene caratteri `utf8mb3` non validi in uno o più commenti della colonna, in particolare a causa della presenza di caratteri non BMP.
Per risolvere il problema, è possibile identificare le colonne problematiche e aggiornare i relativi commenti. Innanzitutto, esamina la struttura della tabella per identificare le colonne con commenti:
```
mysql> SHOW CREATE TABLE test.t2\G
```
Dopo aver identificato le colonne con commenti problematici, aggiornale utilizzando l’istruzione `ALTER TABLE`. Per esempio:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
In alternativa, è possibile rimuovere completamente il commento:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
Dopo aver aggiornato tutti i commenti delle colonne problematiche, il controllo preliminare verrà superato e l’aggiornamento potrà procedere:
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
Prima di modificare i commenti delle colonne, assicurati che eventuale documentazione o codice dell’applicazione che si basa su questi commenti siano aggiornati di conseguenza. Valuta la possibilità di eseguire la migrazione al set di caratteri utf8mb4 per un migliore supporto Unicode se l’applicazione richiede caratteri non BMP.
**auroraUpgradeCheckForInvalidUtf8mb3IndexComments**
**Livello di controllo preliminare: errore**
**Verifica la presenza di commenti non validi nell’indice utf8mb3**
Questo controllo preliminare identifica le tabelle che contengono commenti degli indici con codifica dei caratteri non validi `utf8mb3`. In MySQL 8.0, viene applicata una convalida più rigorosa alla codifica dei caratteri nei metadati, inclusi i commenti degli indici. Se i commenti degli indici contengono caratteri che non sono validi nel set di caratteri `utf8mb3`, l’aggiornamento non riesce.
Per risolvere questo problema, è necessario modificare i commenti degli indici per rimuovere o sostituire eventuali caratteri non BMP prima di tentare l’aggiornamento.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the index.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_tab_index_comment",
"description": "Table precheck.utf8mb3_tab_index_comment has invalid utf8mb3 comments in it's index. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
Il controllo preliminare segnala che la tabella `utf8mb3_tab_index_comment` contiene caratteri `utf8mb3` non validi in uno o più commenti della colonna, in particolare a causa della presenza di caratteri non BMP.
Per risolvere questo problema, esamina innanzitutto la struttura della tabella per identificare l’indice con commenti problematici.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_tab_index_comment\G
*************************** 1. row ***************************
Table: utf8mb3_tab_index_comment
Create Table: CREATE TABLE `utf8mb3_tab_index_comment` (
`id` int(11) DEFAULT NULL,
`name` varchar(100) DEFAULT NULL,
KEY `idx_name` (`name`) COMMENT 'Name index 🐬'
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.01 sec)
```
Una volta identificato l’indice che contiene commenti che utilizzano caratteri non supportati, eliminalo e crealo di nuovo.
L’eliminazione e la nuova creazione di un indice della tabella possono causare tempi di inattività. Si consiglia di pianificare e programmare l’operazione durante la manutenzione.
```
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment DROP INDEX idx_name;
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment ADD INDEX idx_name(name);
```
L’esempio seguente mostra un altro modo per creare nuovamente l’indice.
```
MySQL> ALTER TABLE utf8mb3_tab_index_comment DROP INDEX idx_name, ADD INDEX idx_name (name) COMMENT 'Updated comment without non-BMP characters';
```
Dopo aver rimosso o aggiornato tutti i commenti degli indici non supportati, il controllo preliminare viene superato e l’aggiornamento può procedere.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForInvalidUtf8mb3TableComments**
**Livello di controllo preliminare: errore**
**Verifica la presenza di caratteri utf8mb3 non validi nella definizione della tabella**
Questo controllo preliminare identifica le tabelle che contengono commenti con codifica dei caratteri non validi `utf8mb3`. In MySQL 8.0, viene applicata una convalida più rigorosa alla codifica dei caratteri nei metadati, inclusi i commenti delle tabelle. Se i commenti delle tabelle contengono caratteri che non sono validi nel set di caratteri `utf8mb3`, l’aggiornamento non riesce.
Per risolvere questo problema, è necessario modificare i commenti delle tabelle per rimuovere o sostituire eventuali caratteri non BMP prima di tentare l’aggiornamento.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_table_with_comment",
"description": "Table precheck.utf8mb3_table_with_comment has invalid utf8mb3 comments. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
Il controllo preliminare segnala i commenti `utf8mb3` non validi definiti per le tabelle `utf8mb3_table_with_comment` nel database di test.
Per risolvere questo problema, identifica la tabella che contiene i caratteri non supportati e aggiorna i commenti. Innanzitutto, esamina la struttura della tabella vista e identifica i commenti.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_table_with_comment\G
*************************** 1. row ***************************
Table: utf8mb3_table_with_comment
Create Table: CREATE TABLE `utf8mb3_table_with_comment` (
`id` int(11) NOT NULL,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='This table comment contains flag 🏳️'
1 row in set (0.00 sec)
```
Dopo aver identificato i commenti delle tabelle che contengono caratteri non supportati, aggiorna i commenti con l’istruzione `ALTER TABLE`.
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='Updated comment without non-BMP characters';
```
In alternativa, è possibile rimuovere il commento.
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='';
```
Dopo aver rimosso tutti i caratteri non supportati da tutti i commenti delle tabelle, il controllo preliminare ha esito positivo.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForMasterUser**
**Livello di controllo preliminare: errore**
**Verifica se esiste un utente master RDS**
MySQL 8 ha aggiunto un nuovo modello di privilegi con supporto per il [ruolo](https://dev.mysql.com/doc/refman/8.0/en/roles.html) e i [privilegi dinamici](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges) per rendere la gestione dei privilegi più semplice e dettagliata. Come parte di questa modifica, Aurora MySQL ha introdotto il nuovo `rds_superuser_role`, che viene automaticamente concesso all’utente master del database al momento dell’aggiornamento da Aurora MySQL versione 2 alla versione 3.
Per ulteriori informazioni sui ruoli e i privilegi assegnati all’utente master in Aurora MySQL, consulta [Privilegi dell'account utente master](UsingWithRDS.MasterAccounts.md). Per ulteriori informazioni sul modello di privilegi basato su ruolo in Aurora MySQL versione 3, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Questo controllo preliminare verifica che l’utente master esista nel database. Se l’utente master non esiste, il controllo preliminare avrà esito negativo. Per consentire il proseguimento dell’aggiornamento, crea nuovamente l’utente master reimpostando la password dell’utente principale o creando manualmente l’utente. Prova quindi a eseguire nuovamente l’aggiornamento. Per ulteriori informazioni sulla reimpostazione della password dell’utente master, consulta [Modifica della password per l’utente master del database](Aurora.Modifying.md#Aurora.Modifying.Password).
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForMasterUser",
"title": "Check if master user exists",
"status": "OK",
"description": "Throws error if master user has been dropped!",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
}
]
}
```
Dopo aver reimpostato la password dell’utente master, il controllo preliminare verrà superato e potrai tentare di eseguire nuovamente l’aggiornamento.
L’esempio seguente utilizza l’interfaccia AWS CLI per reimpostare la password. Le modifiche alla password vengono applicate immediatamente.
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
Quindi il controllo preliminare ha esito positivo.
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**Livello di controllo preliminare: errore**
**Verifica la presenza di colonne di geometria negli indici dei prefissi**
A partire da [MySQL 8.0.12](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support), non è più possibile creare un indice [con prefisso](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) in una colonna utilizzando il tipo di dati [GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html). Per ulteriori informazioni, consulta [WL\$111808](https://dev.mysql.com/worklog/task/?id=11808).
Se esistono indici di questo tipo, l’aggiornamento non riesce. Per risolvere il problema, elimina gli indici `GEOMETRY` con prefisso nelle tabelle menzionate nell’errore del controllo preliminare.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.geom_index_prefix",
"description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
}
]
}
```
Il controllo preliminare segnala un errore perché la tabella `test.geom_index_prefix` contiene un indice con un prefisso in una colonna `GEOMETRY`.
Dopo aver eliminato questo indice, il controllo preliminare ha esito positivo.
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**Livello di controllo preliminare: errore**
**Verifica l’eventuale presenza di incoerenze relative ai caratteri speciali nelle stored procedure**
Prima di MySQL 8.0, i nomi dei database, i nomi delle tabelle e altri oggetti corrispondevano ai file nella directory dei dati, ossia a metadati basati su file. Nell’ambito dell’aggiornamento a MySQL 8.0, viene eseguita la migrazione di tutti gli oggetti del database nelle nuove tabelle interne del dizionario dei dati, che sono archiviate nello schema `mysql` per supportare l’[Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) appena implementato. Nell’ambito della migrazione delle stored procedure, la definizione e il corpo di ciascuna procedura vengono convalidati man mano che vengono acquisiti nel nuovo dizionario di dati.
Prima di MySQL 8, in alcuni casi era possibile creare routine memorizzate o inserire direttamente nella tabella `mysql.proc` procedure che contenevano caratteri speciali. Ad esempio, era possibile creare una stored procedure contenente un commento con il [carattere spazio non divisibile](https://en.wikipedia.org/wiki/Non-breaking_space) non conforme `\xa0`. Se viene rilevata una di queste procedure, l’aggiornamento non riesce.
Questo controllo preliminare verifica che i corpi e le definizioni delle stored procedure non contengano tali caratteri. Per consentire il proseguimento dell’aggiornamento, crea nuovamente queste stored procedure senza caratteri nascosti o speciali.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"description": "Following procedure(s) has special characters inconsistency.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "information_schema.routines",
"description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
}
]
}
```
Il controllo preliminare segnala che il cluster di database contiene una procedura denominata `get_version_proc` nel database `test` che contiene caratteri speciali nel corpo della procedura.
Dopo aver eliminato e creato nuovamente la stored procedure, il controllo preliminare ha esito positivo e consente di procedere con l’aggiornamento.
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**Livello di controllo preliminare: errore**
**Verifica l’eventuale mancata corrispondenza del tipo di oggetto per lo schema `sys`**
Lo [schema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) è un set di oggetti e viste in un database MySQL che aiuta gli utenti a eseguire la risoluzione dei problemi, l’ottimizzazione e il monitoraggio per le relative istanze database. Quando si esegue un aggiornamento di versione principale da Aurora MySQL versione 2 alla versione 3, le viste dello schema `sys` vengono create nuovamente e aggiornate alle nuove definizioni di Aurora MySQL versione 3.
Nell’ambito dell’aggiornamento, se alcuni oggetti dello schema `sys` vengono definiti utilizzando i motori di archiviazione (`sys_config/BASE TABLE` in [INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)) anziché le viste, l’aggiornamento non riesce. Tali tabelle si trovano nella tabella `information_schema.tables`. Questo non è un comportamento previsto, ma in alcuni casi può verificarsi a causa di un errore dell’utente.
Questo controllo preliminare convalida tutti gli oggetti dello schema `sys` per garantire che utilizzino le definizioni di tabella corrette e che le viste non vengano erroneamente definite come tabelle InnoDB o MyISAM. Per risolvere il problema, correggi manualmente gli oggetti restituiti rinominandoli o eliminandoli. Prova quindi a eseguire nuovamente l’aggiornamento.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"description": "Database contains objects with type mismatch for sys schema.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sys.waits_global_by_latency",
"description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
}
]
}
```
Il controllo preliminare segnala che la vista [sys.waits\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) nello schema `sys` presenta una mancata corrispondenza del tipo che impedisce il proseguimento dell’aggiornamento.
Dopo aver effettuato l’accesso all’istanza database, puoi vedere che questo oggetto è definito come una tabella InnoDB, mentre invece dovrebbe essere una vista.
```
mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
`events` varchar(128) DEFAULT NULL,
`total` bigint(20) unsigned DEFAULT NULL,
`total_latency` text,
`avg_latency` text,
`max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Per risolvere questo problema, è possibile eliminare e creare nuovamente la vista con la [definizione corretta](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql) o rinominarla. Durante il processo di aggiornamento, la vista viene creata automaticamente con la definizione di tabella corretta.
```
mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)
```
A questo punto, il controllo preliminare viene superato.
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**Livello di controllo preliminare: errore**
**Controlla il limite massimo per il nome della colonna nella vista**
La [lunghezza massima consentita per un nome di colonna](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) in MySQL è di 64 caratteri. Prima di MySQL 8.0, in alcuni casi era possibile creare una vista con un nome di colonna più lungo di 64 caratteri. Se nell’istanza database sono presenti viste di questo tipo, viene restituito un errore di controllo preliminare e l’aggiornamento non riesce. Per consentire il proseguimento dell’aggiornamento, è necessario creare nuovamente le viste in questione, assicurandosi che la lunghezza delle colonne sia inferiore a 64 caratteri. Prova quindi a eseguire nuovamente l’aggiornamento.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"description": "Following view(s) has column(s) with length greater than 64.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
"description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
}
]
}
```
Il controllo preliminare segnala che la vista `test.colname_view_test` contiene una colonna `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` che supera la lunghezza massima consentita di 64 caratteri.
Osservando la definizione della vista, possiamo individuare la colonna che causa l’errore.
```
mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11) | YES | | NULL | |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
Per consentire il proseguimento dell’aggiornamento, crea nuovamente la vista, assicurandoti che la lunghezza delle colonne non superi i 64 caratteri.
```
mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)
mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)
mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_nopad | int(11) | YES | | NULL | |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
A questo punto, il controllo preliminare viene superato.
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**Livello di controllo preliminare: errore**
**Verifica la presenza di tabelle con indici definiti con una lunghezza del prefisso superiore a 255 byte in colonne di dimensioni piccolissime**
Quando si crea un indice su una colonna utilizzando un [tipo di dati binario](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html) in MySQL, è necessario aggiungere una lunghezza del [prefisso](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) nella definizione dell’indice. Prima di MySQL 8.0, in alcuni casi era possibile specificare una lunghezza del prefisso superiore alle dimensioni massime consentite per tali tipi di dati. Un esempio è rappresentato dalle colonne `TINYTEXT` e `TINYBLOB`, in cui le dimensioni massime consentite dei dati sono di 255 byte, ma sono consentiti prefissi di indice di dimensioni superiori. Per ulteriori informazioni, consulta [InnoDB limits](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) nella documentazione di MySQL.
Se questo controllo preliminare ha esito negativo, elimina l’indice che causa l’errore o riduci la lunghezza del prefisso delle colonne `TINYTEXT` e `TINYBLOB` dell’indice a meno di 255 byte. Prova quindi a eseguire nuovamente l’aggiornamento.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.tintxt_prefixed_index.col1",
"description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
}
]
}
```
Il controllo preliminare segnala un errore per la tabella `test.tintxt_prefixed_index`, poiché ha un indice `PRIMARY` con un prefisso di dimensioni superiori a 255 byte in una colonna TINYTEXT o TINYBLOB.
Osservando la definizione di questa tabella, possiamo vedere che la chiave primaria ha un prefisso 65 sulla colonna `TINYTEXT` `col1`. Poiché la tabella è definita utilizzando il set di caratteri `utf8mb4`, che memorizza 4 byte per carattere, il prefisso supera il limite di 255 byte.
```
mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
`col1` tinytext NOT NULL,
`col2` tinytext,
`col_id` tinytext,
PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)
```
Modificando il prefisso dell’indice su 63 durante l’utilizzo del set di caratteri `utf8mb4`, l’aggiornamento potrà proseguire.
```
mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0 Duplicates: 0 Warnings: 0
```
A questo punto, il controllo preliminare viene superato.
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**Livello di controllo preliminare: errore**
**Verifica eventuali incoerenze nei metadati InnoDB mancanti per la tabella `mysql.host`**
Si tratta di un controllo preliminare solo interno eseguito dal servizio RDS. Eventuali errori vengono gestiti automaticamente durante l’aggiornamento e possono essere ignorati senza problemi.
Se riscontri errori con questo controllo preliminare, apri un caso con il [Supporto AWS](https://aws.amazon.com/support) per richiedere che l’incoerenza dei metadati venga risolta. In alternativa, puoi tentare nuovamente l’aggiornamento eseguendo un dump logico, quindi effettuando il ripristino su un nuovo cluster di database Aurora MySQL versione 3.
## Avvisi
In caso di esito negativo, i seguenti controlli preliminari generano avvisi ma l’aggiornamento può comunque essere eseguito.
**Topics**
+ [Controlli preliminari MySQL che restituiscono avvisi](#precheck-descriptions-warnings.mysql)
+ [Controlli preliminari Aurora MySQL che restituiscono avvisi](#precheck-descriptions-warnings.aurora)
### Controlli preliminari MySQL che restituiscono avvisi
I seguenti controlli preliminari sono forniti da Community MySQL:
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**Livello di controllo preliminare: avviso**
**Nuove considerazioni sul plugin di autenticazione predefinito**
In MySQL 8.0, è stato introdotto il plugin di autenticazione `caching_sha2_password`, che offre una crittografia delle password più sicura e prestazioni migliori rispetto al plugin `mysql_native_password` obsoleto. Per Aurora MySQL versione 3, il plugin di autenticazione predefinito utilizzato per gli utenti del database è il plugin `mysql_native_password`.
Questo controllo preliminare avverte che tale plugin verrà rimosso e l’impostazione predefinita verrà modificata in una futura versione principale. Prendi in considerazione la possibilità di valutare la compatibilità dei client e degli utenti delle applicazioni prima di questa modifica.
Per ulteriori informazioni, consulta [caching\$1sha2\$1password compatibility issues and solutions](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues) nella documentazione di MySQL.
**Output di esempio:**
```
{
"id": "defaultAuthenticationPlugin",
"title": "New default authentication plugin considerations",
"description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},
```
**maxdbFlagCheck**
**Livello di controllo preliminare: avviso**
**Utilizzo di un flag `sql_mode` `MAXDB` obsoleto**
In MySQL 8.0, sono state [rimosse](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) alcune opzioni di variabili di sistema [sql\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) obsolete, una delle quali era `MAXDB`. Questo controllo preliminare esamina tutte le sessioni attualmente connesse, insieme alle routine e ai trigger, per garantire che `sql_mode` non sia impostato su una combinazione contenente `MAXDB` in alcun caso.
**Output di esempio:**
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.maxdb_stored_routine",
"description": "PROCEDURE uses obsolete MAXDB sql_mode",
"dbObjectType": "Routine"
}
]
}
```
Il controllo preliminare segnala che la routine `test.maxdb_stored_routine` contiene un’opzione `sql_mode` non supportata.
Dopo aver effettuato l’accesso al database, è possibile visualizzare la definizione di routine in cui `sql_mode` contiene `MAXDB`.
```
> SHOW CREATE PROCEDURE test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Per risolvere il problema, crea nuovamente la procedura dopo aver impostato l’opzione `sql_mode` corretta sul client.
Secondo la [documentazione di MySQL](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html), MySQL memorizza l’impostazione `sql_mode` attiva quando una routine viene creata o modificata. Esegue sempre la routine con questa impostazione, indipendentemente dall’impostazione `sql_mode` al momento dell’avvio della routine.
Prima di modificare `sql_mode`, consulta [Server SQL modes](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) nella documentazione di MySQL. Valuta attentamente qualsiasi potenziale impatto di questa operazione sulla tua applicazione.
Crea nuovamente la procedura senza l’opzione `sql_mode` non supportata.
```
mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
-> SQL SECURITY DEFINER
-> BEGIN
-> SELECT * FROM test;
-> END$$
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Il controllo preliminare ha esito positivo.
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**Livello di controllo preliminare: avviso**
**Verifica l’utilizzo obsoleto dei simboli del dollaro singoli nei nomi degli oggetti**
A partire da [MySQL 8.0.32](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal), l’utilizzo del simbolo del dollaro (`$`) come primo carattere di un identificatore senza virgolette è obsoleto. Se sono presenti schemi, tabelle, viste, colonne o routine contenenti un `$` come primo carattere, il controllo preliminare restituisce un avviso. Sebbene questo avviso non impedisca il proseguimento dell’aggiornamento, è consigliabile agire subito per risolvere il problema. A partire da [MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) qualsiasi identificatore di questo tipo restituisce un errore di sintassi anziché un avviso.
**Output di esempio:**
```
{
"id": "mysqlDollarSignNameCheck",
"title": "Check for deprecated usage of single dollar signs in object names",
"status": "OK",
"description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.$deprecated_syntx",
"description": " name starts with $ sign."
}
]
},
```
Il controllo preliminare segnala un avviso perché la tabella `$deprecated_syntx` nello schema `test` contiene un `$` come primo carattere.
**reservedKeywordsCheck**
**Livello di controllo preliminare: avviso**
**Utilizzo di oggetti di database con nomi in conflitto con nuove parole chiave riservate**
Questo controllo è simile a [routineSyntaxCheck](#routineSyntaxCheck), in quanto verifica l’utilizzo di oggetti di database con nomi in conflitto con nuove parole chiave riservate. Sebbene i due controlli non impediscano gli aggiornamenti, è necessario valutare attentamente gli avvisi.
**Output di esempio:**
Utilizzando l’esempio precedente con la tabella denominata `except`, il controllo preliminare restituisce un avviso:
```
{
"id": "reservedKeywordsCheck",
"title": "Usage of db objects with names conflicting with new reserved keywords",
"status": "OK",
"description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.except",
"description": "Table name",
"dbObjectType": "Table"
}
]
}
```
Questo avviso segnala che potrebbero esserci alcune query dell’applicazione da esaminare. Se le query dell’applicazione non eseguono correttamente l’[escape dei valori letterali delle stringhe](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html), potrebbero verificarsi degli errori dopo l’aggiornamento a MySQL 8.0. Esamina le tue applicazioni per verificare, eseguendo test rispetto a un clone o uno snapshot del cluster di database Aurora MySQL in esecuzione sulla versione 3.
Esempio di una query dell’applicazione senza escape che avrà esito negativo dopo l’aggiornamento:
```
SELECT * FROM escape;
```
Esempio di una query dell’applicazione con escape corretto che avrà esito positivo dopo l’aggiornamento:
```
SELECT * FROM 'escape';
```
**utf8mb3Check**
**Livello di controllo preliminare: avviso**
**Utilizzo del set di caratteri `utf8mb3`**
In MySQL 8.0, il set di caratteri `utf8mb3` è obsoleto e verrà rimosso in una futura versione principale di MySQL. Questo controllo preliminare è implementato per generare un avviso se vengono rilevati oggetti di database che utilizzano tale set di caratteri. Anche se ciò non impedisce il proseguimento dell’aggiornamento, si consiglia vivamente di valutare la possibilità di eseguire la migrazione delle tabelle al set di caratteri `utf8mb4`, che è l’impostazione predefinita a partire da MySQL 8.0. Per ulteriori informazioni su [utf8mb3](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) e [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html), consulta [Converting between 3-byte and 4-byte Unicode character sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) nella documentazione di MySQL.
**Output di esempio:**
```
{
"id": "utf8mb3",
"title": "Usage of utf8mb3 charset",
"status": "OK",
"description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.t1.col1",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
},
{
"level": "Warning",
"dbObject": "test.t1.col2",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
}
]
}
```
Per risolvere il problema, è necessario creare nuovamente gli oggetti e le tabelle a cui si fa riferimento. Per ulteriori informazioni e prerequisiti prima di procedere, consulta [Converting between 3-byte and 4-byte Unicode character sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) nella documentazione di MySQL.
**zeroDatesCheck**
**Livello di controllo preliminare: avviso**
**Valori zero in date, datetime e timestamp**
MySQL ora applica regole più rigide per quanto riguardo l’uso di valori zero nelle colonne di date, datetime e timestamp. Si consiglia di utilizzare le modalità `NO_ZERO_IN_DATE` e `NO_ZERO_DATE SQL` insieme alla modalità `strict`, poiché verranno unite alla modalità `strict` in una futura versione di MySQL.
Se, al momento dell’esecuzione del controllo preliminare, l’impostazione `sql_mode` per una qualsiasi delle connessioni al database non include queste modalità, viene generato un avviso nel controllo preliminare. Gli utenti potrebbero comunque essere in grado di inserire valori di date, datetime e timestamp contenenti valori zero. Tuttavia, si consiglia vivamente di sostituire i valori zero con valori validi, poiché potrebbero avere un comportamento diverso in futuro e non funzionare correttamente. Poiché si tratta di un avviso, non impedisce l’esecuzione degli aggiornamenti, ma si consiglia di iniziare a pianificare le azioni necessarie.
**Output di esempio:**
```
{
"id": "zeroDatesCheck",
"title": "Zero Date, Datetime, and Timestamp values",
"status": "OK",
"description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
"documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "global.sql_mode",
"description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
},
{
"level": "Warning",
"dbObject": "session.sql_mode",
"description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
}
]
}
```
### Controlli preliminari Aurora MySQL che restituiscono avvisi
I seguenti controlli preliminari sono specifici di Aurora MySQL:
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**Livello di controllo preliminare: avviso**
**Verifica se la lunghezza dell’elenco della cronologia dei segmenti di rollback per il cluster è elevata**
Come indicato in [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), durante l’esecuzione del processo di aggiornamento a una versione principale, è essenziale che venga eseguito un [arresto pulito](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) dell’istanza database Aurora MySQL versione 2. Ciò garantisce che tutte le transazioni vengano eseguite o ripristinate e che InnoDB abbia eliminato tutti i record del log di undo.
Se l’elenco della cronologia dei segmenti di rollback (HLL) del cluster di database ha una lunghezza elevata, il cluster può prolungare il tempo impiegato da InnoDB per completare l’eliminazione dei record del log di undo, con conseguenti tempi di inattività prolungati durante il processo di aggiornamento alla versione principale. Se il controllo preliminare rileva che l’HLL del cluster di database è elevata, genera un avviso. Sebbene ciò non impedisca il proseguimento dell’aggiornamento, ti consigliamo di monitorare attentamente l’HLL del tuo cluster di database. Mantenendola bassa, è possibile ridurre i tempi di inattività necessari per un aggiornamento a una versione principale. Per ulteriori informazioni sul monitoraggio dell’HLL, consulta [La lunghezza dell'elenco della cronologia di InnoDB è aumentata in modo significativo](proactive-insights.history-list.md).
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
"title": "Checks if the rollback segment history length for the cluster is high",
"status": "OK",
"description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_metrics",
"description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
}
]
}
```
Il controllo preliminare restituisce un avviso perché ha rilevato che l’HLL di undo di InnoDB era elevata nel cluster di database (82989114). Sebbene l’aggiornamento proceda, a seconda della quantità di operazioni di undo da eliminare, i tempi di inattività necessari durante il processo di aggiornamento vengono prolungati.
Ti consigliamo di [esaminare le transazioni aperte](proactive-insights.history-list.md) nel tuo cluster di database prima di eseguire l’aggiornamento nell’ambiente di produzione, per assicurarti che l’HLL rimanga di dimensioni gestibili.
**auroraUpgradeCheckForUncommittedRowModifications**
**Livello di controllo preliminare: avviso**
**Verifica se ci sono numerose modifiche alle righe di cui non è stato eseguito il commit**
Come indicato in [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), durante l’esecuzione del processo di aggiornamento a una versione principale, è essenziale che venga eseguito un [arresto pulito](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) dell’istanza database Aurora MySQL versione 2. Ciò garantisce che tutte le transazioni vengano eseguite o ripristinate e che InnoDB abbia eliminato tutti i record del log di undo.
Se il cluster di database ha transazioni che hanno modificato un elevato numero di righe, può prolungare il tempo impiegato da InnoDB per completare un rollback della transazione nell’ambito del processo di arresto pulito. Se il controllo preliminare rileva transazioni di lunga durata, con un elevato numero di righe modificate nel cluster di database, genera un avviso. Sebbene ciò non impedisca il proseguimento dell’aggiornamento, ti consigliamo di monitorare attentamente le dimensioni delle transazioni attive del tuo cluster di database. Mantenendola bassa, è possibile ridurre i tempi di inattività necessari per un aggiornamento a una versione principale.
**Output di esempio:**
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_trx",
"description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
}
]
},
```
Il controllo preliminare segnala che il cluster di database contiene una transazione con 11.000.000 di modifiche alle righe senza commit, di cui dovrà essere eseguito il rollback durante il processo di arresto pulito. L’aggiornamento proseguirà, ma per ridurre i tempi di inattività durante il processo di aggiornamento, si consiglia di monitorare ed esaminare la situazione prima di eseguire l’aggiornamento sui cluster di produzione.
Per visualizzare le transazioni attive nell’istanza database di scrittura, puoi utilizzare la tabella [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html). La seguente query dell’istanza database di scrittura mostra le transazioni correnti, il tempo di esecuzione, lo stato e le righe modificate per il cluster di database.
```
# Example of uncommitted transaction
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 | 1592 | 20041 | 52866130 | RUNNING | 11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)
# Example of transaction rolling back
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 | 1719 | 20041 | 52866130 | ROLLING BACK | 10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)
```
Dopo il commit o il rollback della transazione, il controllo preliminare non restituisce più un avviso. Consulta la documentazione di MySQL e contatta il tuo team applicativo prima di eseguire il rollback di transazioni di grandi dimensioni, poiché il completamento del rollback può richiedere tempo, a seconda delle dimensioni delle transazioni.
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"detectedProblems": []
},
```
Per ulteriori informazioni sull’ottimizzazione della gestione delle transazioni InnoDB e sul potenziale impatto dell’esecuzione e del rollback di transazioni di grandi dimensioni sulle istanze database MySQL, consulta [Optimizing InnoDB transaction management](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) nella documentazione di MySQL.
## Note
In caso di esito negativo, i seguenti controlli preliminari generano notifiche ma l’aggiornamento può comunque procedere.
**sqlModeFlagCheck**
**Livello di controllo preliminare: notifica**
**Utilizzo di flag `sql_mode` obsoleti**
Oltre a `MAXDB`, altre opzioni `sql_mode` sono state [rimosse](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html): `DB2`, `MSSQL`, `MYSQL323`, `MYSQL40`, `ORACLE`, `POSTGRESQL`, `NO_FIELD_OPTIONS`, `NO_KEY_OPTIONS` e `NO_TABLE_OPTIONS`. A partire da MySQL 8.0, nessuno di questi valori può essere assegnato alla variabile di sistema `sql_mode`. Se questo controllo preliminare rileva sessioni aperte che utilizzano queste impostazioni `sql_mode`, assicurati che l’istanza database e i gruppi di parametri del cluster di database, nonché le applicazioni e le configurazioni client, siano aggiornati per disabilitarle. Per ulteriori informazioni, consulta la [documentazione di MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html).
**Output di esempio:**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
Per risolvere questi errori di controllo preliminare, consulta [maxdbFlagCheck](#maxdbFlagCheck).
## Errori, avvisi o notifiche
Il seguente controllo preliminare può restituire un errore, un avviso o una notifica a seconda dell’output del controllo preliminare.
**checkTableOutput**
**Livello di controllo preliminare: errore, avviso o notifica**
**Problemi segnalati dal comando `check table x for upgrade`**
Prima di avviare l’aggiornamento ad Aurora MySQL versione 3, `check table for upgrade` viene eseguito su ogni tabella degli schemi utente del cluster di database. Questo controllo preliminare non equivale a [checkTableMysqlSchema](#checkTableMysqlSchema).
Il comando `check table for upgrade` esamina le tabelle per individuare eventuali problemi che potrebbero verificarsi durante l’aggiornamento a una versione più recente di MySQL. L’esecuzione di questo comando prima di tentare un aggiornamento può aiutare a identificare e risolvere eventuali incompatibilità in anticipo, rendendo più agevole l’effettivo processo di aggiornamento.
Questo comando esegue diversi controlli su ogni tabella, come i seguenti:
+ Verifica della compatibilità della struttura della tabella e dei metadati con la versione MySQL di destinazione
+ Verifica della presenza di eventuali funzionalità obsolete o rimosse utilizzate dalla tabella
+ Garanzia che la tabella possa essere aggiornata correttamente senza perdita di dati
A differenza di altri controlli preliminari, questo può restituire un errore, un avviso o una notifica a seconda dell’output di `check table`. Se questo controllo preliminare restituisce delle tabelle, esaminale attentamente insieme al messaggio e al codice restituito prima di iniziare l’aggiornamento. Per ulteriori informazioni, consulta [CHECK TABLE statement](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) nella documentazione di MySQL.
Vengono riportati un esempio di errore e un esempio di avviso.
**Esempio di errore:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.parent",
"description": "Table 'test.parent' doesn't exist"
}
]
},
```
Il controllo preliminare segnala un errore che indica che la tabella `test.parent` non esiste.
Il file `mysql-error.log` per l’istanza database di scrittura mostra che c’è un errore di chiave esterna.
```
2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
```
Accedi all’istanza database di scrittura ed esegui `show engine innodb status\G` per ottenere maggiori informazioni sull’errore della chiave esterna.
```
mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.
```
Il messaggio `LATEST FOREIGN KEY ERROR` segnala che il vincolo di chiave esterna `fk_pname` nella tabella `test.child`, che fa riferimento alla tabella `test.parent`, presenta un indice mancante o una mancata corrispondenza del tipo di dati. La documentazione di MySQL sui [vincoli di chiave esterna](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) spiega che le colonne a cui si fa riferimento in una chiave esterna devono avere un indice associato e che le colonne principale/secondaria devono utilizzare lo stesso tipo di dati.
Per verificare se il problema è correlato a un indice mancante o a una mancata corrispondenza del tipo di dati, accedi al database e controlla le definizioni della tabella disabilitando temporaneamente la variabile di sessione [foreign\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks). Una volta fatto ciò, possiamo vedere che il vincolo secondario in questione (`fk_pname`) utilizza `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL` per fare riferimento alla tabella principale `name varchar(20) NOT NULL`. La tabella principale utilizza `DEFAULT CHARSET=utf8`, ma la colonna `p_name` della tabella secondaria utilizza `latin1`, quindi viene generato l’errore di mancata corrispondenza del tipo di dati.
```
mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)
mysql> show create table parent\G
*************************** 1. row ***************************
Table: parent
Create Table: CREATE TABLE `parent` (
`name` varchar(20) NOT NULL,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Per risolvere questo problema, possiamo modificare la tabella secondaria in modo che utilizzi lo stesso set di caratteri della tabella principale oppure modificare la tabella principale in modo che utilizzi lo stesso set di caratteri della tabella secondaria. In questo esempio, poiché la tabella secondaria utilizza esplicitamente `latin1` nella definizione della colonna `p_name`, viene eseguito `ALTER TABLE` per modificare il set di caratteri in `utf8`.
```
mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)
```
Una volta fatto ciò, il controllo preliminare viene superato e l’aggiornamento può procedere.
**Esempio di avviso:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.orders",
"description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
}
]
}
```
Il controllo preliminare segnala un avviso per il trigger `delete_audit_trigg` sulla tabella `test.orders` perché non ha un attributo `CREATED`. Secondo quanto riportato in [Checking version compatibility](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility) nella documentazione di MySQL, questo messaggio è informativo e viene stampato per i trigger creati prima di MySQL 5.7.2.
Poiché si tratta di un avviso, non impedisce il proseguimento dell’aggiornamento. Tuttavia, se desideri risolvere il problema, puoi creare nuovamente il trigger in questione; una volta fatto ciò, il controllo preliminare ha esito positivo senza avvisi.
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# Come eseguire un aggiornamento in loco
Ti consigliamo di rivedere il materiale di background in [Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence).
Esegui eventuali operazioni di pianificazione e test pre-aggiornamento, come descritto in [Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning).
## Console
Nell'esempio seguente viene aggiornato il cluster database `mydbcluster-cluster` ad Aurora MySQL versione 3.04.1.
**Per aggiornare la versione principale di un cluster di database Aurora MySQL**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Se è stato utilizzato un gruppo di parametri personalizzato con il cluster di database originale, crea un gruppo di parametri corrispondente compatibile con la nuova versione principale. Apportare le modifiche necessarie ai parametri di configurazione nel nuovo gruppo di parametri. Per ulteriori informazioni, consulta [Come gli aggiornamenti in loco influiscono sui gruppi di parametri per un cluster](#AuroraMySQL.Upgrading.ParamGroups).
1. Nel riquadro di navigazione, scegliere **Databases (Database)**.
1. Scegliere il cluster di database che si desidera modificare.
1. Scegliere **Modify (Modifica)**.
1. Per **Versione**, scegli una versione principale di Aurora MySQL.
In genere consigliamo di utilizzare la versione secondaria più recente della versione principale. In questo caso viene scelta la versione predefinita corrente.
![\[Aggiornamento locale di un cluster di database Aurora MySQL da versione 2 a versione 3\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. Scegli **Continua**.
1. Nella pagina successiva specificare quando eseguire l'aggiornamento. Scegliere **During the next scheduled maintenance window (Durante la successiva finestra di manutenzione programmata)** o **Immediately (Immediatamente)**.
1. (Facoltativo) Esaminare periodicamente la pagina **Events (Eventi)** nella console RDS durante l'aggiornamento. In questo modo è possibile monitorare lo stato di avanzamento dell'aggiornamento e identificare eventuali problemi. Se l'aggiornamento incontra dei problemi, consulta [Risoluzione dei problemi relativi all'aggiornamento in loco di Aurora MySQL](AuroraMySQL.Upgrading.Troubleshooting.md) per la procedura da intraprendere.
1. Se all'inizio di questa procedura è stato creato un nuovo gruppo di parametri, associa il gruppo di parametri personalizzati al cluster aggiornato. Per ulteriori informazioni, consulta [Come gli aggiornamenti in loco influiscono sui gruppi di parametri per un cluster](#AuroraMySQL.Upgrading.ParamGroups).
**Nota**
Per eseguire questo passaggio, è necessario riavviare nuovamente il cluster per applicare il nuovo gruppo di parametri.
1. (Facoltativo) Dopo avere completato i test successivi all'aggiornamento, eliminare lo snapshot manuale che Aurora ha creato all'inizio dell'aggiornamento.
## AWS CLI
Per aggiornare la versione principale di un cluster di database Aurora MySQL, utilizzare il comando AWS CLI CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) con i seguenti parametri obbligatori:
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` o `--no-apply-immediately`
Se il cluster utilizza gruppi di parametri personalizzati, includere anche una o entrambe le opzioni seguenti:
+ `--db-cluster-parameter-group-name`, se il cluster utilizza un gruppo di parametri cluster personalizzato
+ `--db-instance-parameter-group-name`, se alcune istanze del cluster utilizzano un gruppo di parametri database personalizzato
Nell'esempio seguente viene aggiornato il cluster database `sample-cluster` ad Aurora MySQL versione 3.04.1. L'aggiornamento avviene immediatamente, invece di attendere la successiva finestra di manutenzione.
**Example**
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
È possibile combinare altri comandi della CLI con `modify-db-cluster` per creare un processo end-to-end automatizzato per l'esecuzione e la verifica degli aggiornamenti. Per maggiori informazioni ed esempi, vedi [Esercitazione sull'aggiornamento in loco di Aurora MySQL](AuroraMySQL.Upgrading.Tutorial.md).
**Nota**
Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione del comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) invece di `modify-db-cluster`. Per ulteriori informazioni, consulta [Principali aggiornamenti in loco per database globali](#AuroraMySQL.Upgrading.GlobalDB).
## API RDS
Per aggiornare la versione principale di un cluster di database Aurora MySQL, utilizza l'operazione [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) dell'API RDS con i seguenti parametri obbligatori:
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` ( impostato su `true` o `false`)
**Nota**
Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) invece di `ModifyDBCluster`. Per ulteriori informazioni, consulta [Principali aggiornamenti in loco per database globali](#AuroraMySQL.Upgrading.GlobalDB).
## Come gli aggiornamenti in loco influiscono sui gruppi di parametri per un cluster
I gruppi di parametri di Aurora hanno diversi insiemi di impostazioni di configurazione per i cluster compatibili con MySQL 5.7 o 8.0. Quando si esegue un aggiornamento locale, il cluster aggiornato e tutte le relative istanze devono utilizzare i corrispondenti gruppi di parametri cluster e istanza corrispondenti.
Il cluster e le istanze potrebbero utilizzare i gruppi di parametri compatibili con 5.7 predefiniti. In tal caso, il cluster e l'istanza aggiornati iniziano con i gruppi di parametri compatibili con 8.0 predefiniti. Se il cluster e le istanze utilizzano gruppi di parametri personalizzati, accertarsi di creare i gruppi di parametri compatibili con 8.0 corrispondenti. Accertarsi inoltre di specificarli durante il processo di aggiornamento.
**Nota**
Per la maggior parte delle impostazioni dei parametri, è possibile scegliere il gruppo di parametri personalizzati in due punti. Quando si crea il cluster o quando si associa il gruppo di parametri al cluster in un secondo momento.
Tuttavia, se si utilizza un'impostazione non predefinita per il parametro `lower_case_table_names`, è necessario impostare il gruppo di parametri personalizzati con questa impostazione in anticipo. Quindi specificare il gruppo di parametri quando si esegue il ripristino dello snapshot per creare il cluster. Qualsiasi modifica al parametro `lower_case_table_names` non ha effetto dopo la creazione del cluster.
È opportuno utilizzare la stessa impostazione per `lower_case_table_names` durante l'aggiornamento da Aurora MySQL versione 2 alla versione 3.
Con un Database globale Aurora basato su Aurora MySQL, è possibile eseguire un aggiornamento in loco da Aurora MySQL versione 2 alla versione 3 solo se il parametro `lower_case_table_names` è impostato sull’opzione predefinita e il database globale viene riavviato. Per ulteriori informazioni sui metodi disponibili all'uso, consulta [Aggiornamenti di una versione principale](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
## Modifiche delle proprietà del cluster tra versioni di Aurora MySQL
Quando esegui l'aggiornamento da Aurora MySQL versione 2 alla versione 3, assicurati di modificare le applicazioni o gli script utilizzati per configurare o gestire i cluster e le istanze database Aurora MySQL.
Inoltre, modifica il codice che manipola i gruppi di parametri per tenere conto del fatto che i nomi dei gruppi di parametri predefiniti sono diversi per i cluster compatibili con 5.7 e 8.0. I nomi dei gruppi di parametri predefiniti per i cluster di Aurora MySQL versione 2 e 3 sono `default.aurora-mysql5.7` e `default.aurora-mysql8.0`, rispettivamente.
Ad esempio, è possibile che si disponga di codice simile al seguente applicabile al cluster prima di un aggiornamento.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
Dopo avere aggiornato la versione principale del cluster, è necessario modificare tale codice nel modo seguente.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## Principali aggiornamenti in loco per database globali
Per un database globale Aurora, è possibile aggiornare il cluster di database globale. Aurora aggiorna automaticamente tutti i cluster nello stesso momento e assicura che tutti eseguano la stessa versione del motore. Questo requisito è dovuto al fatto che tutte le modifiche apportate alle tabelle di sistema, ai formati di file di dati e così via vengono replicate automaticamente in tutti i cluster secondari.
Segui le istruzioni in [Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence). Quando specifichi cosa aggiornare, assicurati di scegliere il cluster di database globale anziché uno dei cluster in esso contenuti.
Se utilizzi il plugin Console di gestione AWS, scegli l'articolo con il ruolo **Global database (Database globale)**.
![\[Aggiornamento del cluster di database globale\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
Se si utilizza la AWS CLI o l'API RDS, avviare il processo di aggiornamento chiamando il comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) o l'operazione [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html). Utilizzare uno di questi anziché `modify-db-cluster` o `ModifyDBCluster`.
**Nota**
Non è possibile specificare un gruppo di parametri personalizzato per il cluster di database globale mentre si esegue un aggiornamento della versione principale del database globale Aurora. Creare i gruppi di parametri personalizzati in ciascuna regione del cluster globale. Applicarli quindi manualmente ai cluster regionali dopo l'aggiornamento.
Per aggiornare la versione principale di un cluster database globale Aurora MySQL mediante la AWS CLI, utilizza il comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) con i seguenti parametri obbligatori:
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
Nell'esempio seguente il cluster database globale viene aggiornato ad Aurora MySQL versione 3.04.2.
**Example**
Per Linux, macOS o Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.04.2 \
--allow-major-version-upgrade
```
Per Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 8.0.mysql_aurora.3.04.2 ^
--allow-major-version-upgrade
```
## Aggiornamenti in loco per cluster di database con repliche di lettura tra Regioni
È possibile aggiornare un cluster di database Aurora con una replica di lettura tra Regioni utilizzando la procedura di aggiornamento in loco, ma occorre tenere a mente alcune considerazioni:
+ È necessario prima aggiornare il cluster di database della replica di lettura. Se si tenta di eseguire prima l’aggiornamento del cluster primario, si riceverà un messaggio di errore del tipo seguente:
Unable to upgrade DB cluster test-xr-primary-cluster because the associated Aurora cross-Region replica test-xr-replica-cluster isn’t patched yet. Upgrade the Aurora cross-Region replica and try again.
Ciò significa che il cluster di database primario non può avere una versione del motore di database superiore a quella del cluster di replica.
+ Prima di aggiornare il cluster di database primario, interrompi il carico di lavoro di scrittura e disabilita tutte le nuove richieste di connessione all’istanza database di scrittura del cluster primario.
+ Quando aggiorni il cluster primario, scegli un gruppo di parametri del cluster di database personalizzato con il parametro `binlog_format` impostato su un valore che supporti la replica con registrazione di log binari, ad esempio `MIXED`.
Per ulteriori informazioni sull'utilizzo di registrazione binaria con Aurora, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Per ulteriori informazioni sulla modifica dei parametri di configurazione di Aurora MySQL, consulta [Parametri di configurazione Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md) e [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md).
+ Non lasciar passare troppo tempo tra l’aggiornamento del cluster di replica e l’aggiornamento del cluster di database primario. Si consiglia di non attendere oltre la finestra di manutenzione successiva.
+ Dopo aver aggiornato il cluster di database primario, riavvia la relativa istanza database di scrittura. Il gruppo di parametri del cluster di database personalizzato che abilita la replica binlog non ha effetto finché l’istanza database di scrittura non viene riavviata.
+ Non riavviare il carico di lavoro di scrittura e non abilitare le connessioni all’istanza database di scrittura prima di aver verificato che la replica tra Regioni sia stata riavviata e che il ritardo di replica nella Regione AWS sia pari a 0.
# Esercitazione sull'aggiornamento in loco di Aurora MySQL
I seguenti esempi di Linux mostrano come è possibile eseguire i passaggi generali della procedura di aggiornamento in loco utilizzando la AWS CLI.
Questo primo esempio crea un cluster di database Aurora che esegue una versione 2.x di Aurora MySQL. Il cluster include un'istanza database di scrittura e un'istanza database di lettura. Il comando `wait db-instance-available` si interrompe fino a quando l'istanza database di scrittura non è disponibile. Questo è il momento in cui il cluster è pronto per essere aggiornato.
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Le versioni Aurora MySQL 3.x alle quali è possibile aggiornare il cluster dipendono dalla versione 2.x attualmente in esecuzione sul cluster e dalla Regione AWS in cui si trova il cluster. Il primo comando, con `--output text`, mostra soltanto la versione di destinazione disponibile. Il secondo comando mostra l'output JSON completo della risposta. Questa risposta contiene dettagli quali il valore `aurora-mysql` utilizzato per il parametro `engine`. Inoltre, indica che l'aggiornamento a 3.04.0 rappresenta un aggiornamento della versione principale.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
Questo esempio mostra che se si immette un numero di versione di destinazione che non è una destinazione di aggiornamento valida per il cluster, Aurora non esegue l'aggiornamento. Aurora non esegue un aggiornamento della versione principale a meno che non si includa il parametro `--allow-major-version-upgrade`. In questo modo, non è possibile eseguire accidentalmente un aggiornamento che potrebbe richiedere modifiche e test estesi al codice dell'applicazione.
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
Sono necessari alcuni istanti prima che lo stato del cluster e le istanze database associate vengano modificati in `upgrading`. I numeri di versione per il cluster e le istanze database cambiano solo al termine dell'aggiornamento. Ancora una volta, è possibile utilizzare il comando `wait db-instance-available` perché l'istanza database di scrittura attenda il completamento dell'aggiornamento prima di procedere.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
A questo punto, il numero di versione del cluster corrisponde a quello specificato per l'aggiornamento.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
L'esempio precedente ha eseguito un aggiornamento immediato specificando il parametro `--apply-immediately`. Per consentire l'aggiornamento in un momento opportuno, quando si prevede che il cluster non sia occupato, è possibile specificare il parametro `--no-apply-immediately`. In questo modo l'aggiornamento viene avviato durante la successiva finestra di manutenzione del cluster. La finestra di manutenzione definisce il periodo durante il quale possono iniziare le operazioni di manutenzione. Un'operazione di lunga durata potrebbe non terminare durante la finestra di manutenzione. Pertanto, non è necessario definire una finestra di manutenzione più ampia anche se si prevede che l'aggiornamento potrebbe richiedere molto tempo.
Nell'esempio seguente viene aggiornato un cluster che esegue inizialmente Aurora MySQL versione 2.11.2. Nell’output di `describe-db-engine-versions`, i valori `False` e `True` rappresentano la proprietà `IsMajorVersionUpgrade`. Dalla versione 2.11.2, è possibile eseguire l'aggiornamento ad altre versioni 2.\$1. Questi aggiornamenti non sono considerati aggiornamenti di versione principali e quindi non richiedono un aggiornamento in loco. L'aggiornamento locale è disponibile solo per gli aggiornamenti alle versioni 3.\$1 visualizzate nell'elenco.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
Quando un cluster viene creato senza una finestra di manutenzione specificata, Aurora seleziona un giorno casuale della settimana. In questo caso, il comando `modify-db-cluster` viene inviato un lunedì. Pertanto, modifichiamo la finestra di manutenzione affinché sia di martedì mattina. Tutti gli orari sono rappresentati nel fuso orario UTC. La finestra `tue:10:00-tue:10:30` indica dalle 2:00 alle 2:30 ora del Pacifico. La modifica della finestra di manutenzione ha effetto immediato.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
Nell'esempio seguente viene illustrato come ottenere un report degli eventi generati dall'aggiornamento. L'argomento `--duration` rappresenta il numero di minuti per recuperare le informazioni sull'evento. Questo argomento è necessario perché, per impostazione predefinita, `describe-events` restituisce solo gli eventi dell’ultima ora.
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Individuazione delle cause degli errori di aggiornamento a una versione principale di Aurora MySQL
Nel [tutorial](AuroraMySQL.Upgrading.Tutorial.md), l’aggiornamento dalla versione 2 alla versione 3 di Aurora MySQL è riuscito. Ma se l’aggiornamento non fosse riuscito, vorresti sapere perché.
È possibile iniziare utilizzando il comando `describe-events` dell’interfaccia AWS CLI per esaminare gli eventi del cluster di database. Questo esempio mostra gli eventi delle ultime 10 ore di `mydbcluster`.
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
In questo caso, si è verificato un errore nei controlli preliminari dell’aggiornamento.
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
Per diagnosticare la causa esatta del problema, esaminare i log del database per l’istanza database di scrittura. Quando un aggiornamento alla versione 3 di Aurora MySQL non riesce, l’istanza di scrittura contiene un file di log denominato `upgrade-prechecks.log`. Questo esempio mostra come rilevare la presenza di quel log e quindi scaricarlo in un file locale per l’analisi.
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--log-file-name upgrade-prechecks.log \
--starting-token 0 \
--output text >upgrade_prechecks.log
```
Il file `upgrade-prechecks.log` è in formato JSON. Lo scarichiamo usando l’opzione `--output text` per evitare la codifica dell’output JSON all’interno di un altro wrapper JSON. Per gli aggiornamenti di Aurora MySQL versione 3, questo log include sempre alcuni messaggi informativi e di avviso. Include messaggi di errore solo se l’aggiornamento non riesce. Se l’aggiornamento riesce, il file di log non viene prodotto.
Per riepilogare tutti gli errori e visualizzare i campi oggetto e descrizione associati, è possibile eseguire il comando `grep -A 2 '"level": "Error"'` sul contenuto del file `upgrade-prechecks.log`. In questo modo viene visualizzata ogni riga di errore e le due righe successive. Queste contengono il nome dell’oggetto di database corrispondente e le indicazioni su come correggere il problema.
```
$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
```
In questo esempio, è possibile eseguire il seguente comando SQL sulla tabella che causa il problema per cercare di risolvere il problema oppure è possibile ricreare la tabella senza l’indice inesatto.
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
Provare quindi a eseguire nuovamente l’aggiornamento.
# 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).
# Pulizia post-aggiornamento per Aurora MySQL versione 3
Dopo aver completato l'aggiornamento di un cluster Aurora MySQL versione 2 ad Aurora MySQL versione 3, è possibile eseguire queste altre azioni di pulizia:
+ Crea nuove versioni compatibili con MySQL 8.0 di qualsiasi gruppo di parametri personalizzati. Applicare i valori dei parametri personalizzati necessari ai nuovi gruppi di parametri.
+ Aggiorna eventuali allarmi di CloudWatch, script di configurazione e così via per utilizzare i nuovi nomi per tutte le metriche i cui nomi sono stati influenzati da modifiche linguistiche inclusive. Per un elenco di parametri, consultare [Cambiamenti linguistici inclusivi per Aurora MySQL versione 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
+ Aggiornare qualsiasi modello CloudFormation per utilizzare i nuovi nomi per qualsiasi parametro di configurazione i cui nomi sono stati influenzati da modifiche linguistiche inclusive. Per l'elenco completo dei parametri, consultare [Cambiamenti linguistici inclusivi per Aurora MySQL versione 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
## Indici spaziali
Dopo l'aggiornamento a Aurora MySQL versione 3, verificare se è necessario eliminare o ricreare oggetti e indici relativi agli indici spaziali. Prima di MySQL 8.0, Aurora poteva ottimizzare le query spaziali utilizzando indici che non contengono un identificatore delle risorse spaziali (SRID). Aurora MySQL versione 3 utilizza solo indici spaziali contenenti SRID. Durante un aggiornamento, Aurora rilascia automaticamente tutti gli indici spaziali senza SRID e stampa i messaggi di avviso nel registro del database. Se si osservano tali messaggi di avviso, creare nuovi indici spaziali con SRID dopo l'aggiornamento. Per ulteriori informazioni sulle modifiche alle funzioni spaziali e ai tipi di dati in MySQL 8.0, consultare [Changes in MySQL 8.0 (Modifiche in MySQL 8.0)](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)nel *Manuale di riferimento MySQL*.