Controlli preliminari per gli aggiornamenti a versioni principali per Aurora MySQL

L’aggiornamento di MySQL da una versione principale a un’altra, ad esempio da MySQL 5.7 a MySQL 8.0, comporta alcune significative modifiche architetturali che richiedono un’attenta pianificazione e preparazione. A differenza degli aggiornamenti a versioni secondarie, in cui l’attenzione si concentra principalmente sull’aggiornamento del software del motore di database e in alcuni casi sulle tabelle di sistema, gli aggiornamenti principali di MySQL spesso introducono modifiche fondamentali al modo in cui il database archivia e gestisce i propri metadati.

Per aiutarti a identificare tali incompatibilità, durante l’aggiornamento da Aurora MySQL versione 2 alla versione 3, Aurora esegue automaticamente controlli di compatibilità degli aggiornamenti (controlli preliminari) per esaminare gli oggetti nel cluster di database e identificare le incompatibilità note che possono impedire il proseguimento dell’aggiornamento. Per informazioni dettagliate sui controlli preliminari di Aurora MySQL, consulta Informazioni di riferimento per le descrizioni dei controlli preliminari per Aurora MySQL. I controlli preliminari di Aurora vengono eseguiti in aggiunta a quelli eseguiti dall’utilità di controllo aggiornamenti di Community MySQL.

Questi controlli preliminari sono obbligatori. Non puoi scegliere di saltarli. I controlli preliminari offrono i seguenti vantaggi:

• Possono ridurre la possibilità di incorrere in errori di aggiornamento che possono portare a tempi di inattività prolungati.

• Se sono presenti incompatibilità, Amazon Aurora impedisce la prosecuzione dell’aggiornamento e fornisce un log per ottenere informazioni sulle stesse. Puoi quindi utilizzare il log per preparare il database per l’aggiornamento alla versione 3 risolvendo le incompatibilità. Per informazioni dettagliate sulla risoluzione delle incompatibilità, consulta l’argomento relativo alla preparazione dell’installazione per l’aggiornamento nella documentazione di MySQL e il post relativo alle informazioni sull’aggiornamento a MySQL 8.0 di MySQL 8.0 nel blog di MySQL Server.

  Per ulteriori informazioni sull’aggiornamento a MySQL 8.0, consulta Upgrading MySQL nella documentazione di MySQL.

I controlli preliminari vengono eseguiti prima che il cluster di database venga messo offline per l’aggiornamento alla versione principale. Se i controlli preliminari rilevano un’incompatibilità, Aurora annulla automaticamente l’aggiornamento prima che l’istanza database venga arrestata. Aurora genera anche un evento per l’incompatibilità. Per ulteriori informazioni sugli eventi di Amazon Aurora, consulta Utilizzo della notifica degli eventi di Amazon RDS.

Una volta completati i controlli preliminari, Aurora memorizza le informazioni dettagliate su ciascuna incompatibilità nel file upgrade-prechecks.log. Nella maggior parte dei casi, la voce di log include un collegamento alla documentazione MySQL utile per correggere l'incompatibilità. Per ulteriori informazioni sulla visualizzazione dei file di log, consultare Visualizzazione ed elenco dei file di log del database.

Nota

A causa della natura dei controlli preliminari, questi analizzano gli oggetti nel database. Questa analisi comporta il consumo di risorse e incrementa il tempo di completamento dell'aggiornamento. Per ulteriori informazioni sulle considerazioni relative alle prestazioni del controllo preliminare, consulta Processo di controllo preliminare per Aurora MySQL.

Indice

• Processo di controllo preliminare per Aurora MySQL

• Formato dei log dei controlli preliminari per Aurora MySQL

• Esempi di output di log dei controlli preliminari per Aurora MySQL

• Verifica preliminare delle prestazioni per Aurora MySQL

• Riepilogo dei controlli preliminari per l’aggiornamento di Community MySQL

• Riepilogo dei controlli preliminari per l’aggiornamento di Aurora MySQL

• Informazioni di riferimento per le descrizioni dei controlli preliminari per Aurora MySQL

  • Errori

    • Controlli preliminari MySQL che restituiscono errori

    • Controlli preliminari Aurora MySQL che restituiscono errori

  • Avvisi

    • Controlli preliminari MySQL che restituiscono avvisi

    • Controlli preliminari Aurora MySQL che restituiscono avvisi

  • Note

  • Errori, avvisi o notifiche

Processo di controllo preliminare per Aurora MySQL

Come descritto in precedenza, il processo di aggiornamento di Aurora MySQL prevede l’esecuzione di controlli di compatibilità (controlli preliminari) sul database prima di procedere all’aggiornamento a una versione principale.

Per gli aggiornamenti in loco, i controlli preliminari vengono eseguiti sull’istanza database di scrittura mentre è online. Se il controllo preliminare ha esito positivo, l’aggiornamento procede. Se vengono rilevati errori, vengono registrati i relativi log nel file upgrade-prechecks.log e l’aggiornamento viene annullato. Prima di tentare nuovamente l’aggiornamento, risolvi gli eventuali errori restituiti nel file upgrade-prechecks.log.

Per gli aggiornamenti con ripristino tramite snapshot, il controllo preliminare viene eseguito durante il processo di ripristino. In caso di esito positivo, il database verrà aggiornato alla nuova versione di Aurora MySQL. Se vengono rilevati errori, vengono registrati i relativi log nel file upgrade-prechecks.log e l’aggiornamento viene annullato. Prima di tentare nuovamente l’aggiornamento, risolvi gli eventuali errori restituiti nel file upgrade-prechecks.log.

Per ulteriori informazioni, consultare Individuazione delle cause degli errori di aggiornamento a una versione principale di Aurora MySQL e Informazioni di riferimento per le descrizioni dei controlli preliminari per Aurora MySQL.

Per monitorare lo stato del controllo preliminare, puoi visualizzare i seguenti eventi nel cluster di database.

Controllo preliminare dello stato	Messaggio di evento	Azione
Avviato	Preparazione dell’aggiornamento in corso: avvio dei controlli preliminari di aggiornamento online.	Nessuno
Non riuscito	Il cluster di database si trova in uno stato che non consente l’aggiornamento: esito negativo dei controlli preliminari di aggiornamento. Per ulteriori dettagli, consulta il file upgrade-prechecks.log. Per ulteriori informazioni sulla risoluzione della causa dell’errore di aggiornamento, consulta https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html	Controlla upgrade-prechecks.log per verificare la presenza di eventuali errori. Risolvi gli errori. Tenta di eseguire nuovamente l’aggiornamento.
Riuscito	Preparazione dell’aggiornamento in corso: completamento dei controlli preliminari di aggiornamento online.	Il controllo preliminare ha avuto esito positivo e non sono stati restituiti errori. Controlla upgrade-prechecks.log per verificare la presenza di eventuali avvisi e notifiche.

Per ulteriori informazioni sulla visualizzazione degli eventi, consulta Visualizzazione di eventi Amazon RDS.

Formato dei log dei controlli preliminari per Aurora MySQL

Una volta completati i controlli di compatibilità dell’aggiornamento (controlli preliminari), puoi esaminare il file upgrade-prechecks.log. Il file di log contiene i risultati, gli oggetti interessati e le informazioni di correzione per ogni controllo preliminare.

Gli errori bloccano l’aggiornamento. È necessario risolverli prima di tentare di eseguire nuovamente l’aggiornamento.

Gli avvisi e le notifiche hanno un livello meno critico, ma è comunque consigliabile esaminarli attentamente per assicurarsi che non vi siano problemi di compatibilità con il carico di lavoro dell’applicazione. Risolvi tempestivamente gli eventuali problemi identificati.

Il file di log presenta il formato seguente:

• targetVersion: versione compatibile con MySQL dell’aggiornamento di Aurora MySQL.

• auroraServerVersion: versione di Aurora MySQL su cui è stato eseguito il controllo preliminare.

• auroraTargetVersion: versione di Aurora MySQL a cui stai effettuando l’aggiornamento.

• checksPerformed: contiene l’elenco dei controlli preliminari eseguiti.

• id: nome del controllo preliminare in esecuzione.

• title: descrizione del controllo preliminare in esecuzione.

• status: non indica se il controllo preliminare è riuscito o meno, ma mostra lo stato della query di controllo preliminare:

  • OK: query di controllo preliminare eseguita e completata correttamente.

  • ERROR: query di controllo preliminare non eseguita. Ciò può verificarsi a causa di problemi quali vincoli di risorse, riavvii imprevisti dell’istanza o interruzione della query per il controllo preliminare della compatibilità.

    Per ulteriori informazioni, consulta questo esempio.

• description: descrizione generale dell’incompatibilità e delle modalità per correggere l’errore.

• documentationLink: link alla documentazione pertinente di Aurora MySQL o MySQL (ove applicabile). Per ulteriori informazioni, consulta Informazioni di riferimento per le descrizioni dei controlli preliminari per Aurora MySQL.

• detectedProblems: se il controllo preliminare restituisce un errore, un avviso o una notifica, mostra i dettagli dell’incompatibilità e degli oggetti incompatibili (ove applicabile):

  • level: livello dell’incompatibilità rilevata dal controllo preliminare. I livelli validi sono i seguenti:

    • Error: l’aggiornamento non può proseguire finché non viene risolta l’incompatibilità.

    • Warning: l’aggiornamento può proseguire, ma sono stati rilevati un oggetto, una sintassi o una configurazione obsoleti. Esamina attentamente gli avvisi e risolvili al più presto per evitare problemi nelle versioni future.

    • Notice: l’aggiornamento può proseguire, ma sono stati rilevati un oggetto, una sintassi o una configurazione obsoleti. Esamina attentamente le notifiche e risolvile al più presto per evitare problemi nelle versioni future.

  • dbObject: nome dell’oggetto del database in cui è stata rilevata l’incompatibilità.

  • description: descrizione dettagliata dell’incompatibilità e delle modalità per correggere l’errore.

• errorCount: numero di errori di incompatibilità rilevati. Questi impediscono l’aggiornamento.

• warningCount: numero di avvisi di incompatibilità rilevati. Questi non impediscono l’aggiornamento, ma occorre risolverli tempestivamente per evitare problemi nelle versioni future.

• noticeCount: numero di notifiche di incompatibilità rilevate. Queste non impediscono l’aggiornamento, ma occorre risolverle tempestivamente per evitare problemi nelle versioni future.

• Summary: riepilogo del numero di errori, avvisi e notifiche relativi alla compatibilità del controllo preliminare.

Esempi di output di log dei controlli preliminari per Aurora MySQL

Gli esempi seguenti mostrano l’output del log dei controlli preliminari che potrebbe essere visualizzato. Per informazioni dettagliate sui controlli preliminari eseguiti, consulta Informazioni di riferimento per le descrizioni dei controlli preliminari per Aurora MySQL.

Stato di controllo preliminare OK, nessuna incompatibilità rilevata

La query di controllo preliminare è stata completata correttamente. Non sono state rilevate incompatibilità.

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinytext",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny text columns",
  "status": "OK",
  "detectedProblems": []
},

Stato di controllo preliminare OK, errore rilevato

La query di controllo preliminare è stata completata correttamente. È stato rilevato un errore.

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexes",
  "status": "OK",
  "description": "Consider dropping the prefix indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test25.sbtest1",
        "description": "Table `test25`.`sbtest1` has an index `idx_t1` 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 `idx_t1` ON `test25`.`sbtest1`;"
      },
 }

Stato di controllo preliminare OK, avviso rilevato

Gli avvisi possono essere restituiti quando un controllo preliminare ha esito positivo o negativo.

Qui la query di controllo preliminare è stata completata correttamente. Sono stati rilevati due avvisi.

{
  "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"
      }
    ]
}

Stato di controllo preliminare ERRORE, nessuna incompatibilità segnalata

La query di controllo preliminare ha avuto esito negativo con un errore, quindi non è stato possibile verificare le incompatibilità.

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "ERROR",
  "description": "Can't connect to MySQL server on 'localhost:3306' (111) at 13/08/2024 12:22:20 UTC. This failure can occur due to low memory available on the instance for executing upgrade prechecks. Please check 'FreeableMemory' Cloudwatch metric to verify the available memory on the instance while executing prechecks. If instance ran out of memory, we recommend to retry the upgrade on a higher instance class."
}

Questo errore può verificarsi a causa di un riavvio imprevisto dell’istanza o dell’interruzione di una query di controllo preliminare della compatibilità sul database durante l’esecuzione. Ad esempio, su classi di istanza database di dimensioni inferiori, questo problema potrebbe verificarsi quando la memoria disponibile nell’istanza si esaurisce.

Puoi utilizzare la metrica FreeableMemory di Amazon CloudWatch per verificare la memoria disponibile nell’istanza durante l’esecuzione dei controlli preliminari. Se l’istanza ha esaurito la memoria, si consiglia di tentare di eseguire nuovamente l’aggiornamento su una classe di istanza database di dimensioni maggiori. In alcuni casi, è possibile utilizzare un’implementazione blu/verde. Ciò consente l’esecuzione di controlli preliminari e aggiornamenti sul cluster di database “verde” indipendentemente dal carico di lavoro di produzione, che consuma anche risorse di sistema.

Per ulteriori informazioni, consulta Risoluzione dei problemi di utilizzo della memoria per i database Aurora MySQL.

Riepilogo del controllo preliminare, sono stati rilevati un errore e tre avvisi

I controlli preliminari di compatibilità contengono anche informazioni sulle versioni di origine e di destinazione di Aurora MySQL, nonché un riepilogo del numero di errori, avvisi e notifiche alla fine dell’output dei controlli preliminari.

Ad esempio, l’output seguente mostra che è stato effettuato un tentativo di aggiornamento da Aurora MySQL 2.11.6 ad Aurora MySQL 3.07.1. L’aggiornamento ha restituito un errore, tre avvisi e nessuna notifica. Poiché gli aggiornamenti non possono proseguire quando viene restituito un errore, è necessario risolvere il problema di compatibilità routineSyntaxCheck e tentare di eseguire nuovamente l’aggiornamento.

{
  "serverAddress": "/tmp%2Fmysql.sock",
  "serverVersion": "5.7.12 - MySQL Community Server (GPL)",
  "targetVersion": "8.0.36",
  "auroraServerVersion": "2.11.6",
  "auroraTargetVersion": "3.07.1",
  "outfilePath": "/rdsdbdata/tmp/PreChecker.log",
  "checksPerformed": [{
      ... output for each individual precheck ...
      .
      .
      {
        "id": "oldTemporalCheck",
        "title": "Usage of old temporal type",
        "status": "OK",
          "detectedProblems": []
      },
      {
        "id": "routinesSyntaxCheck",
        "title": "MySQL 8.0 syntax check for routine-like objects",
        "status": "OK",
        "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
        "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
        "detectedProblems": [{
            "level": "Error",
            "dbObject": "test.select_res_word",
            "description": "at line 2,18: unexpected token 'except'"
        }]
      },
      .
      .
      .
      {
        "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 8 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
            }
          ]
       },
       .
       .
       .
  }],
  "errorCount": 1,
  "warningCount": 3,
  "noticeCount": 0,
  "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues."
}

Verifica preliminare delle prestazioni per Aurora MySQL

I controlli preliminari di compatibilità vengono eseguiti prima della disconnessione dell’istanza database per l’aggiornamento, quindi in circostanze normali non determinano alcun tempo di inattività dell’istanza database durante l’esecuzione. Tuttavia, possono influire sul carico di lavoro dell’applicazione in esecuzione sull’istanza database di scrittura. I controlli preliminari accedono al dizionario dei dati tramite le tabelle information_schema, che possono subire rallentamenti se vi sono molti oggetti del database. Considera i fattori seguenti:

• La durata del controllo preliminare varia in base al numero di oggetti del database come tabelle, colonne, routine e vincoli. L’esecuzione dei cluster di database con un numero elevato di oggetti può richiedere più tempo.

  Ad esempio, removedFunctionsCheck può richiedere più tempo e utilizzare più risorse in base al numero di oggetti memorizzati.

• Per gli aggiornamenti in loco, l’utilizzo di una classe di istanza database di dimensioni maggiori (ad esempio, db.r5.24xlarge o db.r6g.16xlarge) può aiutare a completare l’aggiornamento più rapidamente utilizzando più CPU. È possibile ridurre le dimensioni dopo l’aggiornamento.

• Le query su information_schema eseguite su più database possono subire rallentamenti, specialmente con molti oggetti e su istanze database di dimensioni inferiori. In questi casi, valuta la possibilità di eseguire la clonazione, il ripristino tramite snapshot o un’implementazione blu/verde per gli aggiornamenti.

• L’utilizzo delle risorse (CPU, memoria) per il controllo preliminare può aumentare se il numero di oggetti aumenta, determinando tempi di esecuzione più lunghi su istanze database di dimensioni inferiori. In questi casi, valuta la possibilità di effettuare dei test eseguendo la clonazione, il ripristino tramite snapshot o un’implementazione blu/verde per gli aggiornamenti.

  Se i controlli preliminari hanno esito negativo a causa della carenza di risorse, è possibile rilevare tale condizione nel log del controllo preliminare utilizzando l’output di stato:

  "status": "ERROR",

Per ulteriori informazioni, consultare Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco e Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL.

Riepilogo dei controlli preliminari per l’aggiornamento di Community MySQL

Di seguito è riportato un elenco generale delle incompatibilità tra MySQL 5.7 e 8.0:

• Il cluster di database compatibile con MySQL 5.7 non deve utilizzare funzionalità che non sono supportate in MySQL 8.0.

  Per ulteriori informazioni, consulta Features Removed in MySQL 8.0 nella documentazione MySQL.

• Non devono essere presenti violazioni di parole chiave o parole riservate. Alcune parole chiave, che non erano riservate in precedenza, possono essere riservate in MySQL 8.0.

  Per ulteriori informazioni, consulta Keywords and Reserved Words nella documentazione MySQL.

• Per supporto Unicode migliorato, valuta la conversione di oggetti che utilizzano il charset utf8mb3 per utilizzare il charset utf8mb4. Il set di caratteri utf8mb3 è obsoleto. Inoltre, valuta l'utilizzo di utf8mb4 per i riferimenti al set di caratteri anziché utf8, perché attualmente utf8 è un'alias per il charset utf8mb3.

  Per ulteriori informazioni, consulta The utf8mb3 Character Set (3-Byte UTF-8 Unicode Encoding) nella documentazione MySQL.

• Non devono essere presenti tabelle InnoDB con un formato di riga non predefinito.

• Non devono essere presenti attributi di tipo lunghezza ZEROFILL o display.

• Non devono essere presenti tabelle partizionate che utilizzano un motore di storage che non dispone di supporto di partizionamento nativo.

• Non devono essere presenti tabelle nel database di sistema MySQL 5.7 mysql che hanno lo stesso nome di una tabella utilizzata dal dizionario dati MySQL 8.0.

• Non devono essere presenti tabelle che utilizzano tipi di dati o funzioni obsolete.

• Non devono essere presenti nomi di vincoli della chiave più lunghi di 64 caratteri.

• Non devono esistere modalità SQL obsolete definite nell'impostazione della variabile di sistema sql_mode.

• Non devono essere presenti tabelle o stored procedure con singoli elementi di colonna ENUM o SET la cui lunghezza è superiore a 255 caratteri.

• Non devono essere presenti partizioni di tabella che risiedono in tablespace InnoDB condivisi.

• Non devono essere presenti riferimenti circolari nei percorsi dei file di dati del tablespace.

• Non devono essere presenti definizioni di query e di programmi memorizzati che utilizzano qualificatori ASC o DESC per clausole GROUP BY.

• Non devono essere presenti variabili di sistema rimosse e le variabili di sistema devono utilizzare i nuovi valori predefiniti per MySQL 8.0.

• Non devono essere presenti valori di date, datetime o timestamp pari a zero (0).

• Non devono essere presenti incoerenze di schema derivanti dalla rimozione o dal danneggiamento dei file.

• Non devono essere presenti nomi di tabella contenenti la stringa di caratteri FTS.

• Non devono essere presenti tabelle InnoDB appartenenti a un motore diverso.

• Non devono essere presenti nomi di tabelle o schemi non validi per MySQL 5.7.

Per informazioni dettagliate sui controlli preliminari eseguiti, consulta Informazioni di riferimento per le descrizioni dei controlli preliminari per Aurora MySQL.

Per ulteriori informazioni sull’aggiornamento a MySQL 8.0, consulta Upgrading MySQL nella documentazione di MySQL. Per una descrizione generale delle modifiche apportate in MySQL 8.0, consulta What is new in MySQL 8.0 nella documentazione di MySQL.

Riepilogo dei controlli preliminari per l’aggiornamento di Aurora MySQL

Aurora MySQL ha i propri requisiti specifici per l’aggiornamento dalla versione 2 alla versione 3, tra cui:

• Non deve essere presente alcuna sintassi SQL obsoleta, ad esempio SQL_CACHE, SQL_NO_CACHE e QUERY_CACHE nelle viste, nelle routine, nei trigger e negli eventi.

• Non deve essere presente alcuna colonna FTS_DOC_ID in nessuna tabella senza l’indice FTS.

• Non deve essere presente alcuna mancata corrispondenza delle definizioni delle colonne tra il dizionario dei dati InnoDB e la definizione effettiva della tabella.

• Tutti i nomi di database e tabelle devono avere lettere minuscole quando il parametro lower_case_table_names è impostato su 1.

• Trigger ed eventi non devono avere un definer mancante o vuoto oppure un contesto di creazione non valido.

• Tutti i nomi dei trigger in un database devono essere univoci.

• Il ripristino DDL e Fast DDL non sono supportati in Aurora MySQL versione 3. Non devono essere presenti artefatti nei database correlati a queste funzionalità.

• Le tabelle con il formato di riga REDUNDANT o COMPACT non possono avere indici di dimensioni superiori a 767 byte.

• La lunghezza dei prefissi degli indici definiti nelle colonne di testo tiny non può superare i 255 byte. Con il set di caratteri utf8mb4, ciò limita la lunghezza dei prefissi supportata a 63 caratteri.

  Una lunghezza maggiore era consentita in MySQL 5.7 utilizzando il parametro innodb_large_prefix. Questo parametro è obsoleto in MySQL 8.0.

• Non deve essere presente alcuna incoerenza di metadati InnoDB nella tabella mysql.host.

• Non deve essere presente alcuna mancata corrispondenza tra i tipi di dati delle colonne nelle tabelle di sistema.

• Non devono essere presenti transazioni XA nello stato prepared.

• I nomi delle colonne nelle viste non possono contenere più di 64 caratteri.

• I caratteri speciali nelle stored procedure non possono essere incoerenti.

• Le tabelle non possono presentare incoerenze nei percorsi dei file di dati.

Per informazioni dettagliate sui controlli preliminari eseguiti, consulta Informazioni di riferimento per le descrizioni dei controlli preliminari per Aurora MySQL.