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à.

Importazione di dati in un'istanza database MySQL

Puoi utilizzare diverse tecniche per importare i dati in un'istanza database RDS for MySQL. L'approccio migliore dipende dall'origine e dalla quantità dei dati e dal fatto che l'importazione venga eseguita in modo occasionale o continuo. Se stai migrando un'applicazione insieme a tutti i suoi dati, dovrai valutare per quanto tempo il sistema può rimanere inattivo.

Panoramica

La tabella di seguito riporta le varie tecniche per importare i dati in un'istanza database RDS for MySQL.

Importazione delle considerazioni sui dati

Di seguito sono riportate informazioni tecniche aggiuntive relative al caricamento dei dati in MySQL. Tali informazioni sono indirizzate a utenti esperti, con una buona conoscenza dell'architettura server MySQL.

Log binario

Quando il log binario è attivo, il caricamento dei dati ha un impatto negativo sulle prestazioni e richiede spazio aggiuntivo su disco (fino a quattro volte maggiore) rispetto al caricamento degli stessi dati con il log binario disattivato. L'impatto sulle prestazioni e la quantità di spazio su disco richiesta è direttamente proporzionale alle dimensioni delle transazioni usate per il caricamento dei dati.

Dimensioni delle transazioni

Le dimensioni delle transazioni ricoprono un ruolo importante nel caricamento dei dati MySQL e incidono in modo significativo sull'utilizzo delle risorse e dello spazio su disco, sui tempi di ripristino dei processi e di ritorno alle attività e sul formato dell'input (file flat o SQL). Questa sezione descrive in che modo le dimensioni della transazione incidono sul log binario e spiega perché sia conveniente disattivare il logo binario durante il caricamento di grandi quantità di dati. Come detto in precedenza, i log binari vengono attivati e disattivati impostando il periodo di retention dei backup automatico di Amazon RDS. Un valore pari a zero disattiva il log binario, mentre qualsiasi altro valore lo attiva. Descriveremo anche l'impatto delle transazioni di grandi dimensioni su InnoDB e analizzeremo le motivazioni per cui è importante contenere le dimensioni delle transazioni.

Transazioni di piccole dimensioni

Nel caso delle transazioni di piccole dimensioni, i log binari raddoppiano il numero di scritture su disco richieste per il caricamento dei dati. Tale effetto può incidere molto negativamente sulle prestazioni di altre sessioni di database e allungare i tempi richiesti per il caricamento dei dati. Il calo prestazionale dipende in parte dalla velocità di caricamento, da altre attività del database in esecuzione durante il caricemento e dalla capacità dell'istanza database Amazon RDS.

I log binari consumano una quantità di spazio su disco approssimativamente pari alla quantità di dati caricati, fino a quando non viene effettuato il backup e i dati non vengono rimossi. Fortunatamente, Amazon RDS riduce questo problema al minimo mediante backup frequenti e la conseguente rimozione dei log binari.

Transazioni di grandi dimensioni

Le transazioni di grandi dimensioni triplicano la penalità IOPS e il consumo di spazio su disco se il log binario è attivo. Tale effetto è dovuto al riversamento della cache del log binario nel disco, con un conseguente consumo di spazio e un aumento dell'utilizzo dell'IO ad ogni scrittura. La cache non può essere scritta nel binlog fino a quando la transazione non è aggiornata o non viene eseguito il rollback, pertanto consuma una quantità di disco proporzionale alla quantità di dati caricati. Quando la transazione viene aggiornata, la cache deve essere copiata nel binlog, creando una terza copia dei dati all'interno del disco.

Per tale ragione, per il caricamento dei dati è necessario disporre di una quantità di spazio su disco tripla rispetto alla stessa attività eseguita con il log binario disattivato. Ad esempio, il caricamento di 10 GiB di dati con un'unica transazione richiede almeno 30 GiB di spazio su disco durante l'operazione: 10 GiB per la tabella + 10 GiB per la cache del log binario + 10 GiB per il log binario vero e proprio. Il file della cache rimane nel disco fino alla terminazione della sessione per cui è stato creato oppure fino a quando la sessione non riempie nuovamente la cache del log binario durante un'altra transazione. Il log binario deve restare nel disco fino al backup, per cui potrebbe passare diverso tempo prima che i 20 GiB aggiuntivi vengano resi di nuovo disponibili.

Se i dati sono caricati utilizzando LOAD DATA LOCAL INFILE, e il database deve essere recuperato da un backup eseguito prima del caricamento, verrà creata una copia ulteriore dei dati. Durante il recupero, MySQL estrae i dati dal log binario in un file flat. A quel punto, MySQL esegue LOAD DATA LOCAL INFILE, come nella transazione originale. Tuttavia, questa volta il file di input è locale rispetto al server del database. Continuando con l'esempio precedente, il recupero non potrà essere eseguito correttamente se non vi sono almeno 40 GiB di spazio disponibile su disco.

Disattivazione del log binario

Quando possibile, eseguire il caricamento di grandi dimensioni di dati con il log binario disattivato, per evitare di sovraccaricare le risorse e di occupare una quantità eccessiva di spazio su disco In Amazon RDS i log binari vengono disattivati semplicemente impostando il periodo di retention dei backup su zero. In questo caso, ti consigliamo di fare una snapshot DB dell'istanza database immediatamente prima di caricare i dati. In questo modo, se fosse necessario, potrai annullare rapidamente e con facilità tutte le modifiche apportate durante il caricamento.

Dopo il caricamento, imposta il periodo di retention dei backup su un valore appropriato, diverso da zero.

Non puoi impostare il periodo di retention dei backup su zero se l'istanza database è un'origine per le Repliche di lettura.

InnoDB

Le informazioni contenute in questa sezione spiegano perché è conveniente ridurre le dimensioni delle transazioni quando si utilizza InnoDB.

Annulla operazione

InnoDB genera annullamenti per supportare caratteristiche quali rollback delle transazioni e MVCC. L'annullamento viene salvato nello spazio tabella del sistema InnoDB (in genere ibdata1) e viene conservato fino a quando il thread di eliminazione non lo rimuove. Il thread di eliminazione non può procedere oltre l'annullamento della transazione attiva più vecchia, e viene quindi bloccato fino a quando la transazione non viene confermata o non completa un rollback. Se il database elabora altre transazioni durante il caricamento, tutti gli annullamenti si accumulano nello spazio tabella del sistema e non possono essere rimossi neanche in caso di conferma e se nessun altra transazione richiede l'annullamento per MVCC. In questa situazione, tutte le transazioni (incluse quelle di sola lettura) che accedono a righe modificate da qualsiasi transazione (non solo quella caricata) subiranno un rallentamento, perché saranno tutte sottoposte alla scansione da parte dell'annullamento che sarebbe stato eliminato se non fosse stato per la transazione il cui caricamento richiede un tempo lungo.

L'annullamento viene salvato nello spazio tabella del sistema, le cui dimensioni non si riducono mai. Per tale ragione, le transazioni di grandi quantità di dati possono causare l'aumento delle dimensioni dello spazio tabella del sistema, consumando spazio su disco che non può essere recuperato senza ricreare il database da zero.

Rollback

InnoDB è ottimizzato per le conferme. Il rollback di una transazione di grandi dimensioni può richiedere un tempo molto lungo. In alcuni casi, potrebbe essere più veloce eseguire un point-in-time ripristino o ripristinare un'istantanea del DB.

Formato dei dati di input

MySQL può accettare i dati in due forme: file flat e SQL. Questa sezione descrive i vantaggi e gli svantaggi di ciascun formato.

File flat

Caricare i file flat con LOAD DATA LOCAL INFILE può risultare il metodo più conveniente e rapido, se le dimensioni delle transazioni rimangono relativamente piccole. Rispetto al caricamento degli stessi dati con SQL, i file flat generano di solito un minore traffico di rete, con una riduzione dei costi di trasmissione, dei tempi di caricamento e del sovraccarico del database.

Transazione unica di grandi dimensioni

LOAD DATA LOCAL INFILE carica l'intero file flat come in un'unica transazione. Questa non è necessariamente una cosa negativa, al contrario, presenta una serie di vantaggi purché le dimensioni dei singoli file rimangano limitate:

Attenzione

I vantaggi offerti da LOAD DATA LOCAL INFILE diminuiscono rapidamente man mano che le dimensioni della transazione aumentano. Se non fosse possibile suddividere un set di dati voluminoso in parti più piccole, SQL potrebbe costituire una soluzione migliore.

SQL

SQL presenta un grande vantaggio rispetto ai file flat: consente di mantenere piccole le dimensioni delle transazioni. Tuttavia, SQL ha tempi di caricamento significativamente più lunghi rispetto ai file flat e, in caso di errore, può essere difficile determinare il punto da cui riprendere. Ad esempio, i file mysqldump non sono riavviabili. In caso di errore durante il caricamento di un file mysqldump, questo dovrà essere modificato o sostituito prima che sia possibile riprendere il caricamento. L'alternativa consiste nel ritornare al punto temporale precedente al caricamento e ripetere l'operazione dopo avere corretto la causa dell'errore.

Rilevamento dei checkpoint con snapshot Amazon RDS

Se devi eseguire un caricamento che richiede molte ore o addirittura giorni, non utilizzare i log binari potrebbe non essere un'idea particolarmente allettante, a meno che non ci sia la possibilità di rilevare periodicamente dei checkpoint. È proprio in queste situazioni che la caratteristica snapshot DB di Amazon RDS risulta particolarmente utile. Uno snapshot DB crea una copia point-in-time coerente dell'istanza del database che può essere utilizzata per ripristinare il database a quel momento dopo un arresto anomalo o un altro incidente.

Per creare un checkpoint è sufficiente eseguire unaa snapshot DB. Tutte le snapshot DB eseguite in precedenza possono essere rimosse senza ripercussioni sulla durata o sul tempo di ripristino.

Le snapshot sono rapide e l'aggiunta frequente di checkpoint non incide in modo significativo sui tempi di caricamento.

Riduzione dei tempi di caricamento

Di seguito sono riportati alcuni suggerimenti per ridurre i tempi di caricamento: