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.
| Origine | Quantità di dati | Una volta o continua | Tempo di inattività delle applicazioni | Tecnica | Ulteriori informazioni |
|---|---|---|---|---|---|
|
Database MySQL esistente in locale o su Amazon EC2 |
Qualsiasi |
Una volta |
Medio |
Crea un backup del database locale, archivialo in Amazon S3 e quindi ripristina il file di backup in una nuova istanza database Amazon RDS che esegue MySQL. |
|
|
Qualsiasi database esistente |
Qualsiasi |
Una volta o continua |
Minima |
AWS Database Migration Service Utilizzatelo per migrare il database con tempi di inattività minimi e, per molti motori di database di database, continuare la replica continua. |
Cos'è AWS Database Migration Service e Utilizzo di un database compatibile con MySQL come destinazione per AWS DMS nella Guida per l’utente di AWS Database Migration Service |
|
Istanza database MySQL esistente |
Qualsiasi |
Una volta o continua |
Minima |
Creare una replica di lettura per la replica continua. Promuovere la replica di lettura per la creazione una tantum di una nuova istanza database. |
|
|
Database MariaDB o MySQL esistente |
Small |
Una volta |
Medio |
Copiare i dati direttamente nell'istanza database MySQL utilizzando un'utilità a riga di comando. | |
|
Dati non salvati in un database esistente |
Medium |
Una volta |
Medio |
Crea file flat e importali utilizzando istruzioni LOAD DATA LOCAL
INFILE MySQL. |
Importazione dei dati da qualsiasi origine a un'istanza database MariaDB o MySQL |
|
Database MariaDB o MySQL esistente in locale o su Amazon EC2 |
Qualsiasi |
Continua |
Minima |
Configurare la replica utilizzando un database MariaDB o MySQL esistente come origine della replica. |
Importazione dei dati in un database Amazon RDS MariaDB o MySQL con tempi di inattività ridotti |
Nota
Il database di sistema 'mysql' contiene le informazioni di autenticazione e autorizzazione necessarie per accedere all'istanza database e ai dati. L'eliminazione, la modifica, la ridenominazione o il troncamento di tabelle, dati o altro contenuto del database 'mysql' nell'istanza database può causare un errore e rendere inaccessibili dati e istanza database. In tal caso, è possibile ripristinare l'istanza DB da un'istantanea utilizzando il comando. AWS CLI
restore-db-instance-from-db-snapshot È possibile ripristinare l'istanza DB utilizzando il AWS CLI restore-db-instance-to-point-in-time comando.
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:
Capacità di ripristino – si può tenere facilmente traccia dei file caricati. In caso di problemi durante il caricamento, puoi riprendere l'operazione dal punto in cui era stata interrotta. Potrebbe essere necessario trasmettere nuovamente alcuni file a Amazon RDS, ma se le loro dimensioni sono piccole il tempo per la ritrasmissione sarà minimo.
Caricamento dati in parallelo – se disponi di IOPS e larghezza di banda sufficienti per eseguire il caricamento con file singolo, lavorare in parallelo potrebbe aiutarti a risparmiare tempo.
Ridurre la velocità di caricamento – se il caricamento produce effetti negativi sugli altri processi, puoi ridurne la velocità, aumentando l'intervallo fra i file.
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:
Crea tutti gli indici secondari prima del caricamento. Se sei abituato a utilizzare altri database, questa operazione potrebbe apparire illogica. Quando aggiungi o modifichi un indice secondario, MySQL crea una nuova tabella con le modifiche, copia i dati dalla tabella esistente alla nuova ed elimina la tabella originale.
Carica i dati nell'ordine della chiave primaria. Questa operazione risulta particolarmente utile con le tabelle InnoDB, perché consente di abbreviare i tempi di caricamento del 75–80 percento e di dimezzare le dimensioni dei file di dati.
Disattiva le limitazioni relative alla chiave esterna (foreign_key_checks=0). Spesso, quando i file flat sono caricati con LOAD DATA LOCAL INFILE, questa operazione è obbligatoria. La disattivazione dei controlli della chiave esterna in tutti i carichi ti permette di migliorare sensibilmente le prestazioni. Tuttavia, ricorda di attivare le limitazioni e verificare i dati dopo il caricamento.
Esegui il caricamento in parallelo, a meno di non essere già in vicinanza di un limite di risorse. Se possibile, usa tabelle partitionate.
Durante il caricamento con SQL utilizza inserimento con valori multipli per ridurre il carico dell'esecuzione delle istruzioni. Se utilizzi mysqldump, questa operazione viene eseguita in modo automatico.
Riduci l'I/O del log InnoDB (innodb_flush_log_at_trx_commit=0)
Se carichi i dati in un'istanza database che non include repliche di lettura, imposta il parametro sync_binlog su 0 durante il caricamento dei dati. Al termine del caricamento, reimposta il parametro sync_binlog su 1.
Carica i dati prima di convertire l'istanza database in un'implementazione Multi-AZ. Tuttavia, se l'istanza database utilizza già un'implementazione Multi-AZ, non è consigliabile passare a un'implementazione Single-AZ per il caricamento dei dati, perché i vantaggi sarebbero minimi.
Nota
Se utilizzi innodb_flush_log_at_trx_commit=0, InnoDB cancellerà is log ogni secondo, senza attendere la conferma. Tale impostazione velocizza sensibilmente il processo, ma in caso di errori potrebbe portare alla perdita di dati. Utilizza questa soluzione con cautela.
Argomenti
- Ripristino di un backup in un'istanza My SQL DB
- Importazione di dati da un database MariaDB o MySQL esterno in un'istanza RDS per MariaDB o RDS per MySQL DB
- Importazione dei dati in un database Amazon RDS MariaDB o MySQL con tempi di inattività ridotti
- Importazione dei dati da qualsiasi origine a un'istanza database MariaDB o MySQL
