Risoluzione dei problemi relativi all'aggiornamento in-place di Aurora My SQL - 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-place di Aurora My SQL

Utilizza i seguenti suggerimenti per risolvere i problemi relativi agli upgrade in-place di Aurora My. SQL Questi suggerimenti non si applicano a Aurora Serverless Cluster DB.

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
La replica interregionale Aurora associata non è ancora stata patchata Aurora annulla l'aggiornamento. Aggiorna la replica Aurora Cross-Region 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 tutte le istruzioni del linguaggio di definizione dei dati () DDL Aurora annulla l'aggiornamento. Valuta la possibilità di attendere ed eseguire l'aggiornamento dopo che tutte le DDL istruzioni sono state completate.
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 stiate inserendo caratteri grandiBLOBs. Aurora non rileva o genera automaticamente un evento per questo tipo di attività di transazione. L'indicatore di questa condizione è la lunghezza dell'elenco cronologico (HLL). Il processo di aggiornamento esegue il rollback delle modifiche non salvate.

È possibile verificarlo HLL nell'output del SHOW ENGINE INNODB STATUS SQL comando o direttamente utilizzando la seguente SQL query:

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

Puoi anche monitorare la RollbackSegmentHistoryListLength metrica in Amazon CloudWatch.

Valuta la possibilità di eseguire l'aggiornamento solo dopo che HLL è stato ridotto.
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. Durante questo periodo potrebbero iniziare altre transazioni o DDL rendiconti, 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.

Cambia il motore di archiviazione predefinito per le tabelle temporanee da My ISAM a 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. Assicurati di non creare tabelle temporanee che utilizzano il motore di ISAM archiviazione My. È 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 principale è stato eliminato Aurora annulla l'aggiornamento.
Importante

Non eliminare l'utente principale.

Tuttavia, se per qualche motivo dovessi eliminare l'utente master, ripristinalo utilizzando i seguenti SQL comandi:

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 il fallimento dei controlli preliminari di aggiornamento, consultate 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.

  • Puoi verificare la presenza di DDL istruzioni SHOW PROCESSLIST eseguendole e cercandoCREATE,, DROP ALTERRENAME, e TRUNCATE istruzioni nell'output. Consentite il completamento di tutte le DDL istruzioni 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 simultaneo di più versioni (). MVCC