Controlli preliminari di aggiornamento delle versioni principali per Aurora My SQL - Amazon Aurora
Procedura di precontrollo per Aurora My SQLFormato di registro di Precheck per Aurora My SQLEsempi di output del log di Precheck per Aurora My SQLVerifica preliminare le prestazioni di Aurora My SQLRiepilogo dei controlli preliminari di Community My upgrade SQLRiepilogo dei controlli preliminari di Aurora My upgrade SQL

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Controlli preliminari di aggiornamento delle versioni principali per Aurora My SQL

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

Per aiutarvi a identificare tali incompatibilità, durante l'aggiornamento da Aurora SQL My versione 2 alla versione 3, Aurora esegue automaticamente controlli di compatibilità degli aggiornamenti (precontrolli) per esaminare gli oggetti nel cluster di database e identificare le incompatibilità note che possono impedire il proseguimento dell'aggiornamento. Per informazioni dettagliate sui SQL precheck di Aurora My, consulta. Riferimento alle descrizioni di precontrollo per Aurora My SQL I precontrolli Aurora vengono eseguiti in aggiunta a quelli eseguiti dall'utilità Community My SQL upgrade checker.

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

I precontrolli vengono eseguiti prima che il cluster DB venga messo offline per l'aggiornamento della versione principale. Se i precontrolli rilevano un'incompatibilità, Aurora annulla automaticamente l'aggiornamento prima che l'istanza DB venga interrotta. Aurora genera anche un evento per l'incompatibilità. Per ulteriori informazioni sugli eventi di Amazon Aurora, consulta. Utilizzo delle notifiche di RDS eventi di Amazon

Una volta completati i precontrolli, Aurora registra informazioni dettagliate su ogni incompatibilità nel file. upgrade-prechecks.log Nella maggior parte dei casi, la voce di registro include un collegamento alla SQL documentazione My 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, vedere. Procedura di precontrollo per Aurora My SQL

Indice

Procedura di precontrollo per Aurora My SQL

Come descritto in precedenza, il processo di SQL aggiornamento di Aurora My prevede l'esecuzione di controlli di compatibilità (precontrolli) sul database prima di procedere con l'aggiornamento della versione principale.

Per gli aggiornamenti in loco, i precontrolli vengono eseguiti sull'istanza Writer DB mentre è online. Se il precontrollo ha esito positivo, l'aggiornamento procede. Se vengono rilevati errori, questi vengono registrati nel upgrade-prechecks.log file e l'aggiornamento viene annullato. Prima di tentare nuovamente l'aggiornamento, risolvete gli eventuali errori restituiti nel file. upgrade-prechecks.log

Per gli aggiornamenti con ripristino tramite snapshot, il precontrollo viene eseguito durante il processo di ripristino. In caso di successo, il database verrà aggiornato alla nuova versione di Aurora MySQL. Se vengono rilevati errori, questi vengono registrati nel upgrade-prechecks.log file e l'aggiornamento viene annullato. Prima di tentare nuovamente l'aggiornamento, risolvete gli eventuali errori restituiti nel file. upgrade-prechecks.log

Per ulteriori informazioni, consulta Individuazione dei motivi degli errori di aggiornamento di Aurora My SQL major version e Riferimento alle descrizioni di precontrollo per Aurora My SQL.

Per monitorare lo stato del precontrollo, è possibile visualizzare i seguenti eventi sul cluster DB.

Precontrolla lo 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 può essere aggiornato: i controlli preliminari di aggiornamento non sono riusciti. Per ulteriori dettagli, consulta il file upgrade-prechecks.log.

Per ulteriori informazioni sulla risoluzione della causa dell'errore di aggiornamento, vedere

https://docs.aws.amazon.com/AmazonRDS/più recente//AuroraUserGuide.upgrading.Troubleshooting.html AuroraMy SQL

Verifica la upgrade-prechecks.log presenza di errori.

Correggere gli errori.

Riprova a eseguire l'aggiornamento.

Riuscito

Preparazione dell'aggiornamento in corso: precontrolli preliminari di aggiornamento online completati.

Il precontrollo è riuscito e non sono stati restituiti errori.

Verifica upgrade-prechecks.log la presenza di avvisi e avvisi.

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

Formato di registro di Precheck per Aurora My SQL

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

Gli errori bloccano l'aggiornamento. È necessario risolverli prima di riprovare l'aggiornamento.

Gli avvisi e gli avvisi sono meno importanti, ma consigliamo comunque di esaminarli attentamente per assicurarsi che non vi siano problemi di compatibilità con il carico di lavoro dell'applicazione. Risolvete presto eventuali problemi identificati.

Il file di registro ha il seguente formato:

  • targetVersion— La versione SQL compatibile con My dell'aggiornamento Aurora SQL My.

  • auroraServerVersion— La SQL versione Aurora My su cui è stato eseguito il precheck.

  • auroraTargetVersion— La SQL versione Aurora My a cui stai effettuando l'aggiornamento.

  • checksPerformed— Contiene l'elenco dei precontrolli eseguiti.

  • id— Il nome del precontrollo in esecuzione.

  • title— Una descrizione del precontrollo in corso.

  • status— Ciò non indica se il precontrollo è riuscito o meno, ma mostra lo stato della richiesta di precontrollo:

    • OK— La query di precontrollo è stata eseguita e completata correttamente.

    • ERROR— La query di precontrollo non è stata eseguita. Ciò può verificarsi a causa di problemi quali vincoli di risorse, riavvii imprevisti dell'istanza o interruzione della query di precontrollo della compatibilità.

      Per ulteriori informazioni, consulta questo esempio.

  • description— Una descrizione generale dell'incompatibilità e di come risolvere il problema.

  • documentationLink— Ove applicabile, qui è riportato un collegamento alla SQL documentazione pertinente di Aurora My SQL o My. Per ulteriori informazioni, consulta Riferimento alle descrizioni di precontrollo per Aurora My SQL.

  • detectedProblems— Se il precontrollo restituisce un errore, un avviso o un avviso, mostra i dettagli dell'incompatibilità e, ove applicabile, degli oggetti incompatibili:

    • level— Il livello di incompatibilità rilevato dal precontrollo. I livelli validi sono i seguenti:

      • Error— L'aggiornamento non può procedere finché non viene risolta l'incompatibilità.

      • Warning— L'aggiornamento può continuare, ma è stato rilevato 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ò continuare, ma è stato rilevato un oggetto, una sintassi o una configurazione obsoleti. Esamina attentamente gli avvisi e risolvili al più presto per evitare problemi nelle versioni future.

    • dbObject— Il nome dell'oggetto del database in cui è stata rilevata l'incompatibilità.

    • description— Una descrizione dettagliata dell'incompatibilità e di come risolvere il problema.

  • errorCount— Il numero di errori di incompatibilità rilevati. Questi bloccano l'aggiornamento.

  • warningCount— Il numero di avvisi di incompatibilità rilevati. Questi non bloccano l'aggiornamento, ma li risolvono presto per evitare problemi nelle versioni future.

  • noticeCount— Il numero di avvisi di incompatibilità rilevati. Questi problemi non bloccano l'aggiornamento, ma risolvili al più presto per evitare problemi nelle versioni future.

  • Summary— Un riepilogo del conteggio degli errori di compatibilità, degli avvisi e degli avvisi di precontrollo.

Esempi di output del log di Precheck per Aurora My SQL

Gli esempi seguenti mostrano l'output del registro di precontrollo che potresti vedere. Per i dettagli sui precontrolli eseguiti, vedere. Riferimento alle descrizioni di precontrollo per Aurora My SQL

Stato di precontrollo OK, non è stata rilevata alcuna incompatibilità

L'interrogazione di precontrollo è 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 precontrollo OK, errore rilevato

L'interrogazione di precontrollo è 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 precontrollo OK, avviso rilevato

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

Qui la richiesta di precontrollo è stata completata con successo. 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"
      }
    ]
}
Verifica preliminare lo statoERROR, nessuna incompatibilità segnalata

La query di precontrollo non è riuscita 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 precontrollo della compatibilità sul database durante l'esecuzione. Ad esempio, su classi di istanze DB più piccole, questo problema potrebbe verificarsi quando la memoria disponibile sull'istanza si esaurisce.

Puoi utilizzare il CloudWatch parametro FreeableMemory Amazon per verificare la memoria disponibile sull'istanza durante l'esecuzione dei precontrolli. Se l'istanza ha esaurito la memoria, consigliamo di riprovare l'aggiornamento su una classe di istanza DB più grande. In alcuni casi, è possibile utilizzare una distribuzione Blue/Green. Ciò consente l'esecuzione di precontrolli e aggiornamenti sul cluster DB «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 My SQL.

Riepilogo del precontrollo, sono stati rilevati un errore e tre avvisi

I controlli preliminari di compatibilità contengono anche informazioni sulle versioni di Aurora SQL My di origine e di destinazione e un riepilogo del conteggio degli errori, degli avvisi e degli avvisi alla fine dell'output del precontrollo.

Ad esempio, l'output seguente mostra che è stato effettuato un tentativo di aggiornamento da Aurora My SQL 2.11.6 ad Aurora My 3.07.1. SQL L'aggiornamento ha restituito un errore, tre avvisi e nessun avviso. Poiché gli aggiornamenti non possono procedere quando viene restituito un errore, è necessario risolvere il problema di routineSyntaxCheckcompatibilità e riprovare 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 le prestazioni di Aurora My SQL

I precontrolli di compatibilità vengono eseguiti prima che l'istanza DB venga messa offline per l'aggiornamento, quindi in circostanze normali non causano tempi di inattività dell'istanza DB durante l'esecuzione. Tuttavia, possono influire sul carico di lavoro dell'applicazione in esecuzione sull'istanza Writer DB. I precontrolli accedono al dizionario dei dati tramite le tabelle information_schema, che possono essere lente se ci sono molti oggetti del database. Considerate i seguenti fattori:

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

    Ad esempio, removedFunctionsCheckpossono richiedere più tempo e utilizzare più risorse in base al numero di oggetti archiviati.

  • Per gli aggiornamenti sul posto, l'utilizzo di una classe di istanza DB più grande (ad esempio, db.r5.24xlarge o db.r6g.16xlarge) può aiutare a completare l'aggiornamento più rapidamente utilizzandone di più. CPU È possibile ridurre le dimensioni dopo l'aggiornamento.

  • Le interrogazioni information_schema su più database possono essere lente, specialmente con molti oggetti e su istanze DB più piccole. In questi casi, prendi in considerazione l'utilizzo della clonazione, del ripristino delle istantanee o di una distribuzione Blue/Green per gli aggiornamenti.

  • Il precontrollo dell'utilizzo delle risorse (e della memoria) può aumentare con più oggettiCPU, con conseguenti tempi di esecuzione più lunghi su istanze DB più piccole. In questi casi, prendi in considerazione la possibilità di eseguire test utilizzando la clonazione, il ripristino delle istantanee o una distribuzione Blue/Green per gli aggiornamenti.

    Se i precontrolli falliscono a causa della mancanza di risorse, è possibile rilevarlo nel registro di precontrollo utilizzando l'output di stato:

    "status": "ERROR",

Per ulteriori informazioni, consulta 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 di Community My upgrade SQL

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

  • Il cluster DB SQL compatibile con My 5.7 non deve utilizzare funzionalità non supportate in My 8.0. SQL

    Per ulteriori informazioni, consulta Funzionalità rimosse in My SQL 8.0 nella documentazione personale. SQL

  • Non devono essere presenti violazioni di parole chiave o parole riservate. Alcune parole chiave potrebbero essere riservate in My SQL 8.0 che non lo erano in precedenza.

    Per ulteriori informazioni, consulta Parole chiave e parole riservate nella SQL documentazione My.

  • 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, vedete Il set di caratteri utf8mb3 (codifica unicode a 3 byte UTF -8) nella mia documentazione. SQL

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

  • Non devono essere presenti attributi di tipo «no» ZEROFILL o di tipo «displaylunghezza».

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

  • Nel database di mysql sistema My SQL 5.7 non devono esserci tabelle con lo stesso nome di una tabella utilizzata dal dizionario di dati My SQL 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 essere definite SQL modalità obsolete nelle impostazioni delle variabili di sql_mode sistema.

  • Non devono esserci tabelle o stored procedure con elementi singoli ENUM o di SET colonna che superino i 255 caratteri di lunghezza.

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

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

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

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

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

  • Non devono esserci incongruenze nello schema dovute alla rimozione o al danneggiamento dei file.

  • Non devono esserci nomi di tabella che contengano la stringa di FTS caratteri.

  • Non devono esserci tabelle InnoDB che appartengano a un motore diverso.

  • Non devono esserci nomi di tabelle o schemi non validi per My SQL 5.7.

Per i dettagli sui precontrolli eseguiti, vedere. Riferimento alle descrizioni di precontrollo per Aurora My SQL

Per ulteriori informazioni sull'aggiornamento a My SQL 8.0, consulta Upgrading My nella documentazione My. SQL SQL Per una descrizione generale delle modifiche apportate a My SQL 8.0, consulta Cosa c'è di nuovo in My 8.0 nella documentazione My SQL. SQL

Riepilogo dei controlli preliminari di Aurora My upgrade SQL

Aurora My SQL ha i propri requisiti specifici per l'aggiornamento dalla versione 2 alla versione 3, tra cui:

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

  • Nessuna FTS_DOC_ID colonna deve essere presente in nessuna tabella senza l'indice. FTS

  • Non deve esserci alcuna discrepanza nella definizione delle colonne tra il dizionario dei dati InnoDB e la definizione effettiva della tabella.

  • Tutti i nomi di database e tabelle devono essere in minuscolo quando il lower_case_table_names parametro è impostato su. 1

  • Gli eventi e i trigger non devono avere un definitore mancante o vuoto o un contesto di creazione non valido.

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

  • DDLrecovery e Fast DDL non sono supportati in Aurora My SQL versione 3. Non devono esserci artefatti nei database relativi a queste funzionalità.

  • Le tabelle con il formato di COMPACT riga REDUNDANT o non possono avere indici più grandi di 767 byte.

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

    Una lunghezza del prefisso maggiore era consentita in My SQL 5.7 utilizzando il parametro. innodb_large_prefix Questo parametro è obsoleto in My 8.0. SQL

  • Non deve esserci alcuna incoerenza dei metadati InnoDB nella tabella. mysql.host

  • Non deve esserci alcuna discrepanza tra i tipi di dati delle colonne nelle tabelle di sistema.

  • Non devono esserci transazioni XA nello prepared stato.

  • I nomi delle colonne nelle viste non possono superare i 64 caratteri.

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

  • Le tabelle non possono presentare incoerenze nel percorso dei file di dati.

Per i dettagli sui precontrolli eseguiti, consulta. Riferimento alle descrizioni di precontrollo per Aurora My SQL