Database
 sql >> Database >  >> RDS >> Database

Alter on Big Table in RDS Solution to table full Error

Alter su Big Table in RDS Soluzione alla tabella piena Errore. Facciamo un esempio, tabelle di dimensioni molto grandi (~> da 100 GB a 600 GB). Modificare su tabelle così grandi è un'attività ad alta intensità di memoria e CPU. Quando si tenta di modificare la query su una delle tabelle, viene visualizzato "ERRORE 1114 (HY000):tabella piena ” errore...

Perché si è verificato questo problema anche se il volume di storage di Amazon Aurora aumenterà automaticamente fino a 64 TB.?

Innanzitutto, capiremo lo spazio di archiviazione in RDS Aurora. Ci sono 2 tipi di archiviazione in Aurora. Negozio di istanze è la memoria locale in cui sono archiviati gli oggetti temporanei e la memoria principale per i dati. Pertanto, quando esegui ALTER su una tabella, verrà generata una tabella temporanea e RDS aurora utilizzerà l'archiviazione dell'istanza per archiviare la tabella temporanea. Per la tua istanza, che è db.r3.large, ha 1 × 32 GB di archiviazione locale, quindi se i tuoi oggetti temporanei sull'istanza diventano più grandi di questa dimensione, viene visualizzato l'errore "tabella piena". Inoltre, il limite di archiviazione locale è diverso dal volume di archiviazione totale disponibile per la tua istanza Aurora e, in base all'utilizzo del database, il volume di storage di Amazon Aurora aumenterà automaticamente, fino a 64 TB, con incrementi di 10 GB.

Alter on big table in RDS  soluzione all'errore completo della tabella

  1. Per superare il problema, puoi aumentare l'istanza per ottenere più spazio di archiviazione locale per eseguire ALTER, modificare la tabella e quindi ridimensionare il tipo di istanza. Ciò si traduce in alcuni tempi di inattività durante l'aggiornamento/downgrade del tipo di istanza.
  2. Puoi anche usare:il comando "pt-online-schema-change", se usi questo comando rende la tabella originale ancora disponibile per l'uso senza tempi di inattività o nessun blocco del tavolo.
Se non puoi permetterti di avere tempi di inattività nel sistema, utilizza il comando pt-online-schema-change invece di ridimensionare l'istanza. Tuttavia, la documentazione di pt-online-schema-change  dice, dovremmo fare un backup prima di eseguire questo comando. Pertanto, per evitare blocchi e errori di tabella durante la modifica della tabella di produzione, è possibile testare questo comando su una copia esatta del database dell'applicazione, con lo stesso tipo di istanza RDS. Inoltre, prova ad aggiungere un carico di scrittura pesante sulla tabella per simulare il traffico . Per ottenere ciò, crea uno script bash che inserisca continuamente una nuova riga nella tabella. Per avere una copia rapida e esatta del tuo database attuale, fai uno snapshot del DB RDS e ripristinalo dallo snapshot per il test.  Prima di eseguire questo comando, è necessario impostare log_bin_trust_function_creators su 1 nel gruppo di parametri RDS DB. Dopo aver finito con il processo ALTER, puoi cambiare di nuovo la variabile su "0".
Risultati:
Se stai modificando la tabella con pt -cambio-schema-online  comando su  un tavolo di dimensioni 35-40 GB potrebbe richiedere circa 30 ore.

Perché utilizzare il comando pt-online-schema-change e perché abilitarlo  "log_bin_trust_function_creators "  nel gruppo di parametri DB? ?

pt-online-schema-change  non blocca il tavolo. Questo comando crea trigger sulla tabella originale. Ma per questo, ha bisogno dei privilegi di superutente. quando stai usando la procedura del negozio, riceverai l'errore:
#1419 – Non hai il privilegio SUPER e la registrazione binaria è abilitata (potresti* voler usare la variabile log_bin_trust_function_creators meno sicura
Motivo:  Questo errore si verifica nelle istanze RDS quando si tenta di utilizzare le "procedure memorizzate". Scoprirai presto che concedere il super privilegio per un utente non funzionerà. Quindi l'unico modo per far funzionare le cose è impostare log_bin_trust_function_creators su 1.   Come per i documenti Percona: La conclusione è che la creazione di trigger su un server con log binari abilitati richiede un utente con privilegi SUPER (cosa impossibile in Amazon RDS). Il messaggio di errore specifica la soluzione. Dobbiamo abilitare la variabile nel gruppo di parametri DB "log_bin_trust_function_creators". Abilitarlo è come dire al server: "Mi fido dei trigger e delle funzioni degli utenti regolari e del fatto che non causeranno problemi, quindi consenti ai miei utenti di crearli." Dato che la funzionalità del database non cambierà, diventa una questione di fiducia nei tuoi utenti. log_bin_trust_function_creators è una variabile globale che può essere modificata in modo dinamico. Cercando di trovare maggiori dettagli su "Super_priv", quando controlli i permessi degli utenti nella tabella utente del database MySQL. potresti vedere che Super_priv non è impostato per nessuno tranne l'utente rdsadmin. 
MySQL> select User,Super_priv from user;
+-----------+------------+
| User | Super_priv |
+-----------+------------+
| rdsadmin | Y |
| root | N |
| dbuser | N |
+-----------+------------+
3 rows in set (0.00 sec)

Qui "root" è l'utente principale e "dbuser" è l'utente DB, questi utenti sono creati da noi e l'utente "rdsadmin" viene creato automaticamente da AWS a cui non abbiamo accesso per questo utente. L'utente rdsadmin MySQL viene utilizzato da Amazon per lavori di manutenzione e gestione.

Questa è la fine del tutorial, come modificare su Big Table nella soluzione RDS per visualizzare l'errore completo.