Risoluzione dei problemi relativi all'aggiornamento in loco di Aurora MySQL - Amazon Aurora

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

Risoluzione dei problemi relativi all'aggiornamento in loco di Aurora MySQL

Utilizza i seguenti suggerimenti per risolvere i problemi relativi agli aggiornamenti in loco di Aurora MySQL. Questi suggerimenti non si applicano a cluster di database Aurora Serverless.

Motivo dell'annullamento o della lentezza dell'aggiornamento in loco Effetto Soluzione per consentire il completamento dell'aggiornamento in loco all'interno della finestra di manutenzione
Non sono ancora state applicate patch alla replica tra Regioni Aurora associata Aurora annulla l'aggiornamento. Aggiorna la replica tra Regioni Aurora e riprova.
Il cluster ha transazioni XA nello stato preparato Aurora annulla l'aggiornamento. Salvare o eseguire il rollback di tutte le transazioni XA preparate.
Il cluster sta elaborando un'istruzione DDL (Data Definition Language) Aurora annulla l'aggiornamento. Prendere in considerazione di attendere il completamento di tutte le istruzioni DDL prima di eseguire l'aggiornamento.
Il cluster ha modifiche non salvate per molte righe L'aggiornamento potrebbe richiedere molto tempo.

Il processo di aggiornamento esegue il rollback delle modifiche non salvate. L'indicatore per questa condizione è il valore di TRX_ROWS_MODIFIED nella tabella INFORMATION_SCHEMA.INNODB_TRX.

Prendere in considerazione l'esecuzione dell'aggiornamento solo dopo avere salvato le modifiche o eseguito il rollback di tutte le transazioni di grandi dimensioni.
Il cluster ha un numero elevato di record di annullamento L'aggiornamento potrebbe richiedere molto tempo.

Anche se le transazioni non salvate non interessano un numero elevato di righe, potrebbero comportare un grande volume di dati. Ad esempio, è possibile che si inseriscano BLOB di grandi dimensioni. Aurora non rileva o genera automaticamente un evento per questo tipo di attività di transazione. L’indicatore per questa condizione è la lunghezza dell’elenco della cronologia (HLL). Il processo di aggiornamento esegue il rollback delle modifiche non salvate.

È possibile controllare l’HLL nell’output del comando SQL SHOW ENGINE INNODB STATUS o direttamente utilizzando la seguente query SQL:

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

Puoi monitorare la metrica RollbackSegmentHistoryListLength anche in Amazon CloudWatch.

Valuta la possibilità di eseguire l’aggiornamento solo dopo che la lunghezza dell’elenco della cronologia sarà diminuita.
Il cluster è in fase di salvataggio di una transazione di log binario di grandi dimensioni L'aggiornamento potrebbe richiedere molto tempo.

Il processo di aggiornamento attende fino a quando non vengono applicate le modifiche del log binario. Altre transazioni o istruzioni DDL potrebbero iniziare durante questo periodo, rallentando ulteriormente il processo di aggiornamento.

Pianificare il processo di aggiornamento quando il cluster non è occupato con la generazione di modifiche alla replica del log binario. Aurora non rileva o genera automaticamente un evento per questa condizione.
Incongruenze dello schema derivanti dalla rimozione o dal danneggiamento dei file Aurora annulla l'aggiornamento.

Cambiare il motore di archiviazione predefinito per le tabelle temporanee da MyISAM in InnoDB. Esegui queste fasi:

  1. Modificare il parametro database default_tmp_storage_engine impostandolo su InnoDB.

  2. Riavviare il cluster database.

  3. Dopo il riavvio, verificare che il parametro database default_tmp_storage_engine sia impostato su InnoDB. Utilizza il seguente comando:

    show global variables like 'default_tmp_storage_engine';

  4. Assicurarsi di non creare tabelle temporanee che utilizzino il motore di archiviazione MyISAM. È consigliabile sospendere qualsiasi carico di lavoro del database e non creare nuove connessioni al database perché l'aggiornamento verrà rilasciato a breve.

  5. Provare di nuovo l'aggiornamento sul posto.
L’utente master è stato eliminato Aurora annulla l'aggiornamento.
Importante

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:

È 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).