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 Amazon RDS per MariaDB.
Puoi utilizzare diverse tecniche per importare i dati in un'istanza database RDS for MariaDB. L’approccio migliore dipende da una serie di fattori:
+ Origine dei dati
+ Quantità di dati
+ Importazione continua o eseguita una sola volta
+ Durata del tempo di inattività
Se si esegue la migrazione di un’applicazione insieme a tutti i relativi dati, la quantità del tempo di inattività è un fattore importante da considerare.
Nella seguente tabella sono riportate le varie tecniche per importare i dati in un’istanza database RDS per MariaDB:
**Nota**
Amazon RDS non supporta `mariadb-backup` né l’importazione da Amazon S3 per MariaDB.
| Origine | Quantità di dati | Una volta o continua | Tempo di inattività delle applicazioni | Tecnica | Ulteriori informazioni |
| --- | --- | --- | --- | --- | --- |
| Database MariaDB esistente on-premises oppure in Amazon EC2 | Qualsiasi | Continua | Minima | Configurare la replica utilizzando un database MariaDB esistente come origine della replica. Puoi configurare la replica in un'istanza MariaDB utilizzando gli identificatori di transazione globali di MariaDB GTIDs () quando l'istanza esterna è MariaDB versione 10.0.24 o successiva o utilizzando coordinate di log binarie per istanze MariaDB su versioni precedenti alla 10.0.24. GTIDs MariadB è implementato in modo diverso rispetto a GTIDs MySQL, che non è supportato da Amazon RDS. | [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.ReplMariaDB.md) [Importazione dei dati in un’istanza database Amazon RDS per MariaDB riducendo il tempo di inattività](mariadb-importing-data-reduced-downtime.md) |
| Qualsiasi database esistente | Qualsiasi | Una volta o continua | Minima | Utilizzali AWS Database Migration Service per migrare il database con tempi di inattività minimi e, per molti motori di database DB, continuare la replica continua. | [Cos'è AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) e [Utilizzo di un database compatibile con MySQL come destinazione per AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) nella *Guida per l’utente di AWS Database Migration Service * |
| Istanza database MariaDB 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. | [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md) |
| Database MariaDB esistente | Small | Una volta | Medio | Copiare i dati direttamente nell’istanza database MariaDB tramite un’utilità a riga di comando. | [Importazione di dati da un database MariaDB esterno in un’istanza database Amazon RDS per MariaDB](mariadb-importing-data-external-database.md) |
| Dati non salvati in un database esistente | Medium | Una volta | Medio | Creare file flat e importarli con le istruzioni `LOAD DATA LOCAL INFILE` di MariaDB. | [Importazione di dati da qualsiasi origine in un’istanza database Amazon RDS per MariaDB](mariadb-importing-data-any-source.md) |
**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 errori e rendere inaccessibili dati e istanza database. In tal caso, è possibile ripristinare l'istanza DB da un'istantanea utilizzando il comando. AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) Puoi ripristinare l’istanza database tramite il comando [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html).
# Considerazioni sull’importazione di dati per MariaDB
Il contenuto seguente include informazioni tecniche relative al caricamento dei dati in MariaDB. Il contenuto è rivolto a utenti con una buona conoscenza dell’architettura server MariaDB.
## Registrazione di log binari
L’abilitazione della registrazione di log binari riduce le prestazioni di caricamento dei dati e richiede uno spazio su disco quattro volte superiore rispetto alla registrazione di log disabilitata. Le dimensioni delle transazioni utilizzate per caricare i dati influiscono direttamente sulle prestazioni del sistema e sulle esigenze di spazio su disco – transazioni di grandi dimensioni richiedono un numero maggiore di risorse.
## Dimensioni delle transazioni
Le dimensioni delle transazioni influenzano i seguenti aspetti dei caricamenti di dati MariaDB:
+ Consumo di risorse
+ Utilizzo dello spazio su disco
+ Processo di ripresa
+ Tempo di ripristino
+ Formato di 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 log binario durante il caricamento di grandi quantità di dati. Per abilitare e disabilitare la registrazione di log binari, impostare il periodo di conservazione dei backup automatici di Amazon RDS. Un valore pari a zero disattiva il log binario, mentre qualsiasi altro valore lo attiva. Per ulteriori informazioni, consulta [Periodo di conservazione dei backup](USER_WorkingWithAutomatedBackups.BackupRetention.md).
Questa sezione descrive anche l’impatto delle transazioni di grandi dimensioni in InnoDB nonché i motivi 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. La riduzione delle prestazioni dipende in parte dai seguenti fattori:
+ Velocità di caricamento
+ Altre attività del database in esecuzione durante il caricamento
+ 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 ne viene effettuato il backup e i dati non vengono rimossi. Amazon RDS attenua il problema grazie a backup frequenti e alla rimozione dei log binari.
### Transazioni di grandi dimensioni
Per transazioni di grandi dimensioni, la registrazione di log binari triplica il numero di IOPS e l’utilizzo del disco per i seguenti motivi:
+ La cache del log binario archivia temporaneamente i dati delle transazioni su disco.
+ Le dimensioni della cache aumentano in base a quelle della transazione, consumando spazio su disco.
+ Al termine della transazione (commit o rollback), il sistema copia la cache nel log binario.
Il processo crea tre copie dei dati:
+ Dati originali
+ Cache su disco
+ Ultima voce del log binario
Ogni operazione di scrittura comporta un I/O aggiuntivo, con un ulteriore impatto sulle prestazioni.
Per questo motivo, la registrazione di log binari richiede uno spazio su disco tre volte maggiore rispetto al caso in cui sia disabilitata. Ad esempio, il caricamento di 10 GiB di dati come singola transazione crea tre copie:
+ 10 GiB per i dati della tabella
+ 10 GiB per la cache del log binario
+ 10 GiB per il file di log binario
Lo spazio su disco totale richiesto temporaneamente è di 30 GiB.
Considerazioni importanti sullo spazio su disco:
+ Il file di cache persiste fino al termine della sessione o fino alla creazione di un’altra cache da parte di una nuova transazione.
+ Il log binario rimane attivo fino a quando non ne viene eseguito il backup e può contenere 20 GiB di dati (cache e log) per un periodo prolungato.
Se si utilizza `LOAD DATA LOCAL INFILE` per caricare i dati, durante il ripristino viene creata una quarta copia dei dati qualora il database debba essere ripristinato da un backup eseguito prima del caricamento. Durante il ripristino, MariaDB estrae i dati dal log binario e li inserisce in un file flat. MariaDB esegue quindi `LOAD DATA LOCAL INFILE`. In base all’esempio precedente, questo ripristino richiede uno spazio su disco temporaneo totale di 40 GiB o di 10 GiB ciascuno per tabella, cache, log e file locale. Se non sono disponibili almeno 40 GiB di spazio su disco, il ripristino non può essere eseguito.
### Ottimizzazione di carichi di dati di grandi dimensioni
Per carichi di dati di grandi dimensioni, disabilitare la registrazione di log binari per ridurre il sovraccarico e i requisiti di spazio su disco. È possibile disabilitare la registrazione di log binari impostando il periodo di conservazione dei backup su 0. Al termine del caricamento, ripristinare il periodo di conservazione dei backup sul valore diverso da zero appropriato. Per ulteriori informazioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md) e [Periodo di conservazione dei backup](USER_ModifyInstance.Settings.md) nella tabella delle impostazioni.
**Nota**
Non è possibile impostare il periodo di conservazione dei backup su zero se l’istanza database è un’origine per le repliche di lettura.
Prima di caricare i dati, è consigliabile creare uno snapshot di database. Per ulteriori informazioni, consulta [Gestione dei backup manuali](USER_ManagingManualBackups.md).
## InnoDB
Le seguenti informazioni sulla registrazione di log di undo e sulle opzioni di ripristino prevedono di mantenere ridotte le dimensioni delle transazioni InnoDB per ottimizzare le prestazioni del database.
### Informazioni sulla registrazione di log di undo InnoDB
L’annullamento (undo) è un meccanismo della registrazione di log che consente il rollback delle transazioni e supporta il controllo della concorrenza multiversione (MVCC).
In MariaDB 10.11 e versioni precedenti, i log di undo vengono archiviati nel tablespace del sistema InnoDB (in genere ibdata1) e mantenuti fino a quando il thread di eliminazione non li rimuove. Di conseguenza, le transazioni di caricamento di dati di grandi dimensioni possono causare un aumento significativo delle dimensioni del tablespace del sistema, con un consumo di spazio su disco che non si può recuperare senza ricreare il database da zero.
Per tutte le versioni di MariaDB, il thread di eliminazione deve attendere la rimozione dei log di undo fino al commit o al rollback della transazione attiva meno recente. Se il database elabora altre transazioni durante il caricamento, anche i relativi log di undo si accumulano e non possono essere rimossi, anche nel caso di commit delle transazioni e in quello in cui nessun’altra transazione richieda log di undo per MVCC. In questa situazione, tutte le transazioni, incluse quelle di sola lettura, rallentano. Il rallentamento si verifica perché tutte le transazioni accedono a tutte le righe modificate da qualsiasi transazione, non solo da quella di caricamento. In effetti, le transazioni devono eseguire la scansione dei log di undo che le transazioni di caricamento di lunga durata hanno impedito di eliminare durante una pulizia dei log di undo stessi. Ciò influisce sulle prestazioni di tutte le operazioni di accesso alle righe modificate.
### Opzioni di ripristino delle transazioni InnoDB
Sebbene InnoDB ottimizzi le operazioni di commit, i rollback delle transazioni di grandi dimensioni sono lenti. Per un ripristino più rapido, esegui un point-in-time ripristino o ripristina un'istantanea del DB. Per ulteriori informazioni, consultare [Point-in-time recupero](USER_PIT.md) e [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md).
## Formati di importazione dei dati
MariaDB supporta due formati di importazione di dati, ovvero file flat e SQL. Consultare le informazioni su ciascun formato per determinare l’opzione migliore per le proprie esigenze.
### File flat
Per transazioni di piccole dimensioni, caricare file flat con `LOAD DATA LOCAL INFILE`. Rispetto all’utilizzo di SQL, questo formato di importazione dati può comportare i seguenti vantaggi:
+ Minor traffico di rete
+ Riduzione dei costi di trasmissione dei dati
+ Riduzione del sovraccarico di elaborazione del database
+ Elaborazione più rapida
`LOAD DATA LOCAL INFILE` carica l’intero file flat come un’unica transazione. Mantenere ridotte le dimensioni dei singoli file per ottenere i seguenti vantaggi:
+ **Capacità di ripristino**: si può tenere facilmente traccia dei file caricati. In caso di problemi durante il caricamento, si può riprendere l’operazione dal punto in cui era stata interrotta. Potrebbe essere necessario trasmettere nuovamente alcuni file ad Amazon RDS, ma nel caso di file di piccole dimensioni la quantità di dati ritrasmessa è minima.
+ **Caricamento di dati in parallelo**: se si dispone di IOPS e di larghezza di banda della rete sufficienti per caricare un file singolo, il caricamento in parallelo potrebbe consentire di risparmiare tempo.
+ **Controllo della velocità di caricamento**: se il caricamento dei dati ha un impatto negativo su altri processi, è possibile controllarne la velocità aumentando l’intervallo tra i file.
Le transazioni di grandi dimensioni riducono i vantaggi dell’utilizzo di `LOAD DATA LOCAL INFILE` per importare i dati. Se non si riesce a suddividere una grande quantità di dati in file di dimensioni minori, prendere in considerazione l’utilizzo di SQL.
### SQL
Rispetto ai file flat, SQL presenta un grande vantaggio perché consente di mantenere ridotte le dimensioni delle transazioni, sebbene i tempi di caricamento siano significativamente più lunghi. Dopo un errore, inoltre, può essere difficile determinare il punto da cui riprendere perché non è possibile riavviare i file mariadb-dump. In caso di errore durante il caricamento di un file mariadb-dump, quest’ultimo dovrà essere modificato o sostituito prima che sia possibile riprendere il caricamento. In alternativa, dopo aver corretto la causa dell’errore, è possibile tornare al punto temporale precedente al caricamento e inviare nuovamente il file. Per ulteriori informazioni, consulta [Point-in-time recupero](USER_PIT.md).
## Utilizzo degli snapshot di database di Amazon RDS per i checkpoint di database
Se si caricano dati per lunghi periodi, ad esempio ore o giorni, senza registrazione di log binari, utilizzare gli snapshot di database per fornire checkpoint periodici per la sicurezza dei dati. Ogni snapshot di database crea una copia coerente dell’istanza database che funge da punto di ripristino in caso di errori di sistema o di eventi di danneggiamento dei dati. Poiché gli snapshot di database sono veloci, i checkpoint frequenti hanno un impatto minimo sulle prestazioni del caricamento. È possibile eliminare gli snapshot di database precedenti senza influire sulla durabilità o sulle funzionalità di ripristino del database. Per ulteriori informazioni sugli snapshot di database, consulta [Gestione dei backup manuali](USER_ManagingManualBackups.md).
## Riduzione dei tempi di caricamento del database
Di seguito sono indicati alcuni suggerimenti per ridurre i tempi di caricamento:
+ Creare tutti gli indici secondari prima di caricare i dati nei database MariaDB. A differenza di altri sistemi di database, quando si aggiungono o si modificano gli indici secondari MariaDB ricostruisce l’intera tabella. Questo processo consente di creare una nuova tabella con modifiche agli indici, di copiare tutti i dati e di eliminare la tabella originale.
+ Caricare i dati in base all’ordine della chiave primaria. Per le tabelle InnoDB, questa operazione può ridurre i tempi di caricamento del 75%-80% e le dimensioni dei file di dati del 50%.
+ Disabilitare i vincoli di chiave esterna impostando `foreign_key_checks` su `0`. Questa operazione è spesso necessaria per i file flat caricati con `LOAD DATA LOCAL INFILE`. Per qualsiasi carico, la disabilitazione dei controlli di chiave esterna accelera il caricamento dei dati. Dopo aver completato il caricamento, riabilitare i vincoli impostando `foreign_key_checks` su `1` e verificare i dati.
+ Caricare i dati in parallelo a meno che non si stia raggiungendo il limite di risorse. Per consentire il caricamento simultaneo su più segmenti di tabella, se necessario utilizzare tabelle partizionate.
+ Per ridurre il sovraccarico di esecuzione SQL, combinare più istruzioni `INSERT` in singole operazioni `INSERT` con più valori. `mariadb-dump` implementa questa ottimizzazione in modo automatico.
+ Ridurre le operazioni di I/O dei log InnoDB impostando `innodb_flush_log_at_trx_commit` su `0`. Al termine del caricamento, ripristinare il valore di `innodb_flush_log_at_trx_commit` su `1`.
**avvertimento**
Se si imposta `innodb_flush_log_at_trx_commit` su `0`, InnoDB cancella i log ogni secondo anziché a ogni commit. Questa impostazione aumenta le prestazioni, ma può comportare il rischio di perdita delle transazioni durante i guasti del sistema.
+ Se si caricano i dati in un’istanza database che non include repliche di lettura, impostare `sync_binlog` su `0`. Al termine del caricamento, ripristinare il valore di `sync_binlog parameter` su `1`.
+ Caricare i dati in un’istanza database Single-AZ prima di convertire l’istanza database in un’implementazione Multi-AZ. Se l’istanza database utilizza già un’implementazione Multi-AZ, non è consigliabile passare a un’implementazione Single-AZ per il caricamento dei dati. In tal modo si otterrebbero solo miglioramenti marginali.
# Importazione di dati da un database MariaDB esterno in un’istanza database Amazon RDS per MariaDB
È possibile importare i dati da un database MariaDB esistente in un’istanza database RDS per MariaDB. A tale scopo, copia il database con [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) o [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) e reindirizzalo direttamente all’istanza database RDS per MariaDB. L’utilità a riga di comando `mysqldump` o `mariadb-dump` viene spesso usata per creare backup e trasferire dati da un server MariaDB a un altro. ed è inclusa nel software client MariaDB.
A partire da MariaDB 11.0.1, è necessario utilizzare `mariadb-dump` anziché `mysqldump`.
Un tipico comando `mysqldump` per spostare dati da un database esterno a un’istanza database Amazon RDS è simile al seguente. Sostituisci i valori con le tue informazioni. Per MariaDB 11.0.1 e versioni successive, sostituisci `mysqldump` con `mariadb-dump`.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**Importante**
Assicurati di non lasciare spazi tra l'opzione `-p` e la password immessa.
Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio.
Assicurati di essere a conoscenza dei seguenti suggerimenti e considerazioni:
+ Escludi gli schemi seguenti dal file di dump:
+ `sys`
+ `performance_schema`
+ `information_schema`
Per impostazione predefinita, l’utilità `mysqldump` e `mariadb-dump` esclude questi schemi.
+ Se devi migrare utenti e privilegi, prendi in considerazione l'utilizzo di uno strumento che genera il linguaggio di controllo dei dati (DCL) per ricrearli, come l'utilità. [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)
+ L’utente che esegue l'importazione deve avere accesso all'istanza database. Per ulteriori informazioni, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md).
I parametri utilizzati sono i seguenti:
+ `-u local_user`: specifica un nome utente. La prima volta si utilizza questo parametro, specificare il nome di un account utente nel database MariaDB locale, identificato dal parametro `--databases`.
+ `--databases database_name`: specifica il nome del database nell’istanza database MariaDB locale da importare in Amazon RDS.
+ `--single-transaction` – Verifica che tutti i dati caricati dal database locale siano coerenti a un singolo punto temporale. Nel caso in cui vi siano altri processi che modificano i dati mentre `mysqldump` o `mariadb-dump` li legge, l’utilizzo di questo parametro consente di preservare l’integrità dei dati.
+ `--compress` – Riduce il consumo della larghezza di banda di rete comprimendo i dati dal database locale prima di inviarli ad Amazon RDS.
+ `--order-by-primary`: riduce il tempo di caricamento ordinando i dati di ogni tabella in base alla chiave primaria.
+ `--routines`: parametro utilizzato se nel database da copiare sono presenti routine, ad esempio stored procedure o funzioni. Imposta il parametro su `0` per escludere le routine durante il processo di importazione. Successivamente, ricrea manualmente le routine nel database Amazon RDS.
+ `--triggers`: parametro utilizzato se nel database da copiare sono presenti trigger. Imposta il parametro su `0` per escludere i trigger durante il processo di importazione. Successivamente, ricrea manualmente i trigger nel database Amazon RDS.
+ `--events`: parametro utilizzato se nel database da copiare sono presenti eventi. Imposta il parametro su `0` per escludere gli eventi durante il processo di importazione. Successivamente, ricrea manualmente gli eventi nel database Amazon RDS.
+ `-plocal_password` – Specifica una password. La prima volta che si utilizza questo parametro, specificare la password per l’account utente identificato dal primo parametro `-u`.
+ `-u RDS_user`: specifica un nome utente. La seconda volta che si utilizza questo parametro, specificare il nome di un account utente nel database predefinito per l’istanza database MariaDB identificata dal parametro `--host`.
+ `--port port_number`: specifica la porta per l’istanza database MariaDB. Il valore predefinito è 3306, che può essere modificato al momento della creazione dell’istanza database.
+ `--host host_name` – Specifica il nome del sistema dei nomi di dominio (DNS) dall'endpoint dell'istanza database Amazon RDS, ad esempio `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Il valore dell’endpoint è disponibile nei dettagli dell’istanza database nella console Amazon RDS.
+ `-pRDS_password` – Specifica una password. La seconda volta che usi questo parametro, devi specificare la password per l'account utente identificato dal secondo parametro `-u`.
Eventuali procedure, trigger, funzioni o eventi devono essere creati manualmente nel database Amazon RDS. Se nel database da copiare sono presenti questi tipi di oggetti, è necessario escluderli quando si esegue `mysqldump` o `mariadb-dump`. A tale scopo, includi i seguenti parametri con il comando `mysqldump` o `mariadb-dump`:
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**Esempio**
Di seguito il database di esempio `world` viene copiato nell’host locale in un’istanza database RDS per MariaDB. Sostituisci i valori con le tue informazioni.
Per Linux, macOS o Unix:
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Per Windows:
Apri un prompt dei comandi facendo clic con il pulsante destro del mouse su **Prompt dei comandi** del menu dei programmi di Windows e selezionando **Esegui come amministratore** ed esegui il comando seguente. Sostituisci i valori con le tue informazioni.
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**Nota**
Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio.
# Importazione dei dati in un’istanza database Amazon RDS per MariaDB riducendo il tempo di inattività
In alcuni casi, potrebbe essere necessario importare dati da un database MariaDB esterno che supporti un’applicazione attiva in un’istanza database RDS per MariaDB. Usa la seguente procedura per ridurre l'impatto sulla disponibilità delle applicazioni. Questa procedura può risultare utile anche quando utilizzi un database di dimensioni particolarmente elevate. Utilizzando questa procedura, è possibile ridurre i costi di importazione riducendo la quantità di dati trasmessi attraverso la rete a AWS.
Con questa procedura trasferisci una copia dei dati del database in un'istanza Amazon EC2 e li importi in un nuovo database Amazon RDS. Utilizza quindi la replica per portare il database Amazon RDS up-to-date con la tua istanza esterna attiva, prima di reindirizzare l'applicazione al database Amazon RDS. Se l'istanza esterna è MariaDB 10.0.24 o versione successiva e l'istanza di destinazione è RDS for MariaDB, configura la replica di MariaDB in base agli identificatori di transazione globali (). GTIDs In alternativa, è possibile configurare la replica in base alle coordinate del log binario. Si consiglia la replica basata su GTID se supportata dal database esterno perché è un metodo più affidabile. Per ulteriori informazioni, consulta [ID globali di transazione](http://mariadb.com/kb/en/mariadb/global-transaction-id/) nella documentazione di MariaDB.
Il diagramma seguente mostra l’importazione di un database MariaDB esterno in un database MariaDB in Amazon RDS.
![\[Flusso di lavoro che mostra l’importazione di un database MariaDB esterno in un database MariaDB in Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_1.png)
## Attività 1: creazione di una copia del database esistente
Il primo passaggio da eseguire nella migrazione di grandi quantità di dati in un database RDS per MariaDB riducendo al minimo il tempo di inattività consiste nella creazione di una copia dei dati di origine.
Il diagramma seguente mostra la creazione di un backup del database MariaDB.
![\[Flusso di lavoro che mostra la creazione di un backup del database MariaDB.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
Per creare un backup di database in formato SQL o con testo delimitato, è possibile utilizzare l’utilità `mysqldump` o `mariadb-dump`. In MariaDB 10.5, il client è denominato [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/). A partire da MariaDB 11.0.1, è necessario utilizzare `mariadb-dump` anziché `mysqldump`. Si consiglia di eseguire un test con ciascun formato, fuori dall’ambiente di produzione, per capire quale metodo consenta di ridurre maggiormente il tempo di esecuzione di `mysqldump` o `mariadb-dump`.
Si consiglia anche di valutare le prestazioni di `mysqldump` o `mariadb-dump` e i vantaggi offerti dal caricamento nel formato con testo delimitato. Un backup eseguito con testo delimitato crea un file di testo separato da tabulazioni per ciascuna tabella eliminata. Per ridurre il tempo di importazione del database, puoi caricare questi file in parallelo con il comando `LOAD DATA LOCAL INFILE`. Per ulteriori informazioni, consulta [Fase 5: Caricamento dei dati](mariadb-importing-data-any-source.md#mariadb-importing-data-any-source-load-data) nella procedura Importazione di dati da qualsiasi origine.
Prima di iniziare l’operazione di backup, imposta le opzioni di replica nel database MariaDB da copiare in Amazon RDS. Le opzioni di replica includono l’attivazione del log binario e l’impostazione di un ID server univoco. L'impostazione di tali opzioni porta il server ad avviare la registrazione delle transazioni del database e lo prepara per diventare l'istanza di replica di origine in una fase successiva del processo.
Assicurati di essere a conoscenza dei seguenti suggerimenti e considerazioni:
+ utilizza l’opzione `--single-transaction` con `mysqldump` o `mariadb-dump` perché esegue il dump di uno stato coerente del database. Per garantire un file di dump valido, non eseguire istruzioni DDL (Data Definition Language) durante l’esecuzione di `mysqldump` o `mariadb-dump`. È possibile pianificare una finestra di manutenzione per queste operazioni.
+ Escludi gli schemi seguenti dal file di dump:
+ `sys`
+ `performance_schema`
+ `information_schema`
Per impostazione predefinita, le utilità `mysqldump` e `mariadb-dump` escludono questi schemi.
+ Se devi migrare utenti e privilegi, prendi in considerazione l'utilizzo di uno strumento che genera il linguaggio di controllo dei dati (DCL) per ricrearli, come l'utilità. [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)
### Per impostare le opzioni di autenticazione
1. Modificare il file `my.cnf`. Il file si trova in genere in `/etc`.
```
sudo vi /etc/my.cnf
```
Aggiungere le opzioni `log_bin` e `server_id` alla sezione `[mysqld]`. L'opzione `log_bin` fornisce un identificatore di nome file per i file di log binari. L'opzione `server_id` fornisce un identificatore univoco per il server in relazioni master-replica.
L’esempio seguente mostra la sezione `[mariadb]` aggiornata di un file `my.cnf`:
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
Per ulteriori informazioni, consulta [Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication) nella documentazione MariaDB.
1. Per la replica con un cluster di database Multi-AZ, abilita `gtid_strict_mode`. Per ulteriori informazioni, consulta [gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode) nella documentazione MariaDB.
L’abilitazione di `gtid_strict_mode` non è richiesta per la replica con un’istanza database.
1. Riavvia il servizio `mariadb`.
```
sudo service mariadb restart
```
### Per creare una copia di backup del database esistente
1. Crea un backup dei dati con l’utilità `mysqldump` o `mariadb-dump`, specificando il formato SQL o con testo delimitato.
Per migliorare le prestazioni e garantire l’integrità dei dati, utilizza le opzioni `--order-by-primary` e `--single-transaction` per `mysqldump` e `mariadb-dump`.
Per non includere il database di sistema MySQL nel backup, non utilizzare l’opzione `--all-databases` con `mysqldump` o `mariadb-dump`. Per ulteriori informazioni, consulta [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) nella documentazione MySQL.
Se necessario, utilizza `chmod` per avere la certezza che sia possibile scrivere nella directory in cui viene creato il file di backup.
**Importante**
In Windows, eseguire la finestra di comando come amministratore.
+ Per produrre un output SQL, utilizzare il comando seguente. Per MariaDB 10.11 e versioni precedenti, sostituisci `mariadb-dump` con `mysqldump`.
Per Linux, macOS o Unix:
```
sudo mariadb-dump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**Nota**
Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio.
Per Windows:
```
mariadb-dump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**Nota**
Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio.
+ Per produrre un output in testo delimitato, utilizzare il comando seguente. Per MariaDB 11.01 e versioni successive, sostituisci `mysqldump` con `mariadb-dump`.
Per Linux, macOS o Unix:
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Per Windows:
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**Nota**
Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio.
Eventuali procedure, trigger, funzioni o eventi devono essere creati manualmente nel database Amazon RDS. Se nel database da copiare sono presenti questi tipi di oggetti, è necessario escluderli quando si esegue `mysqldump` o `mariadb-dump`. A tale scopo, includi gli argomenti seguenti con il comando `mysqldump` o `mariadb-dump`:
`--routines=0`
`--triggers=0`
`--events=0`
Quando si esegue `mysqldump` e si specifica il formato con testo delimitato, viene restituito un comando `CHANGE MASTER TO`. Tale commento contiene il nome e la posizione del file log principale. Se l’istanza esterna è diversa da MariaDB versione 10.0.23 o precedente, annota i valori per `MASTER_LOG_FILE` e `MASTER_LOG_POS`. Questi valori sono necessari durante l'impostazione della replica.
Per le versioni di MariaDB, viene restituito l’output seguente.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. Se l’istanza esterna è MariaDB versione 10.0.24 o successiva, utilizza la replica basata su GTID. Esegui `SHOW MASTER STATUS` nell’istanza MariaDB esterna per ottenere il nome e la posizione del file di log binario e convertirli in un GTID utilizzando `BINLOG_GTID_POS` nell’istanza MariaDB esterna.
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
Annota il GTID restituito perché sarà necessario per configurare la replica.
1. Comprimi i dati copiati per ridurre la quantità di risorse di rete necessarie per copiare i dati nell'istanza database Amazon RDS. Annota la dimensione del file di backup. Questa informazione è necessaria per determinare le dimensioni dell'istanza Amazon EC2 da creare. Al termine, comprimere il file di backup con GZIP o un'altra utility simile.
+ Per comprimere un output SQL, utilizza il comando seguente:
```
gzip backup.sql
```
+ Per comprimere un output in testo delimitato, utilizza il comando seguente:
```
tar -zcvf backup.tar.gz target_directory
```
## Attività 2: creazione di un’istanza Amazon EC2 e copia del database compresso
La copia del file di backup del database compresso in un'istanza Amazon EC2 richiede una quantità di risorse di rete inferiore rispetto alla copia diretta di dati non compressi da un'istanza database a un'altra. Quando i dati sono presenti in Amazon EC2, puoi copiarli direttamente nell’istanza database MariaDB. Per risparmiare sul costo delle risorse di rete, l'istanza Amazon EC2 deve essere la Regione AWS stessa dell'istanza Amazon RDS DB. La presenza dell'istanza Amazon EC2 nello Regione AWS stesso database Amazon RDS riduce anche la latenza di rete durante l'importazione.
Il seguente diagramma mostra la copia del backup del database in un’istanza Amazon EC2.
![\[Flusso di lavoro che mostra la copia del backup del database in un’istanza Amazon EC2.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_3.png)
### Per creare un'istanza Amazon EC2 e copiare i dati
1. Nel luogo in Regione AWS cui prevedi di creare il database Amazon RDS, crea un cloud privato virtuale (VPC), un gruppo di sicurezza VPC e una sottorete VPC. Verificare che le regole in entrata del gruppo di sicurezza VPC consentano agli indirizzi IP necessari per l'applicazione di connettersi ad AWS. È possibile specificare un intervallo di indirizzi IP, ad esempio `203.0.113.0/24`, oppure un altro gruppo di sicurezza VPC. Puoi utilizzare la [console Amazon VPC](https://console.aws.amazon.com/vpc) per creare e gestire VPCs sottoreti e gruppi di sicurezza. Per ulteriori informazioni, consulta [Nozioni di base su Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) nella *Guida per l’utente di Amazon Virtual Private Cloud*.
1. Apri la [console Amazon EC2](https://console.aws.amazon.com/ec2) e scegli di contenere sia Regione AWS l'istanza Amazon EC2 che il database Amazon RDS. Avviare un'istanza di Amazon EC2 utilizzando il VPC, la sottorete e il gruppo di sicurezza creati nella fase 1. Assicurarsi di selezionare un tipo di istanza con spazio di storage sufficiente per il file di backup del database decompresso. Per informazioni sulle istanze Amazon EC2, consulta [Nozioni di base su Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) nella *Guida per l’utente di Amazon Elastic Compute Cloud*.
1. Per connetterti al database Amazon RDS dall'istanza Amazon EC2, modifica il gruppo di sicurezza VPC. Aggiungere una regola in entrata specificando l'indirizzo IP privato e l'istanza EC2. L'indirizzo IP privato è indicato nella scheda **Details (Dettagli)** del riquadro **Instance (Istanza)** della finestra della console EC2. Per modificare il gruppo di sicurezza VPC e aggiungere una regola in entrata, selezionare **Security Groups (Gruppi di sicurezza)** nel riquadro di navigazione della console di EC2, selezionare il gruppo di sicurezza e aggiungere una regola in entrata per MySQL/Aurora specificando l'indirizzo IP privato dell'istanza EC2. Per ulteriori informazioni sull’aggiunta di una regola in entrata a un gruppo di sicurezza VPC, consulta [Regole del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) nella *Guida per l’utente di Amazon Virtual Private Cloud*.
1. Copiare il file compresso con il backup del database dal sistema locale all'istanza Amazon EC2. Se necessario, utilizza `chmod` per ottenere l’autorizzazione di scrittura per la directory di destinazione dell’istanza Amazon EC2. Il file può essere copiato con `scp` oppure con un client Secure Shell (SSH). Di seguito è riportato un comando `scp` di esempio:
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**Importante**
Quando si copiano dati sensibili, utilizzare un protocollo di trasferimento di rete sicuro.
1. Connettiti all’istanza Amazon EC2 e installa gli ultimi aggiornamenti e gli strumenti del client MariaDB con i comandi seguenti:
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -y
```
Per ulteriori informazioni, consulta [Connessione all’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) per le istanze Linux nella *Guida per l’utente di Amazon Elastic Compute Cloud* e [MariaDB Connectors](https://mariadb.com/docs/connectors) nella documentazione di MariaDB.
1. Durante la connessione all'istanza Amazon EC2 decomprimere il file di backup del database. I comandi seguenti sono esempi.
+ Per decomprimere l'output SQL, utilizzare il comando seguente:
```
gzip backup.sql.gz -d
```
+ Per decomprimere un output in testo delimitato, utilizzare il comando seguente:
```
tar xzvf backup.tar.gz
```
## Attività 3: creazione di un database MariaDB e importazione dei dati dall’istanza Amazon EC2
Creando un'istanza DB RDS per MariaDB nella stessa istanza Amazon EC2, puoi importare Regione AWS il file di backup del database da Amazon EC2 più velocemente che su Internet.
Il seguente diagramma mostra l’importazione del backup da un’istanza Amazon EC2 in un database MariaDB.
![\[Flusso di lavoro che mostra l’importazione del backup dall’istanza EC2 nel database MariaDB.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### Per creare un database MariaDB e importare i dati
1. Determina la classe di istanza database e la quantità di spazio di archiviazione necessaria per supportare il carico di lavoro previsto per il database Amazon RDS. Come parte di questo processo, è necessario valutare la quantità di spazio richiesta e la capacità di elaborazione per le procedure di caricamento dati. Valuta anche gli elementi necessari per gestire il carico di lavoro di produzione. È possibile produrre una stima sulla base delle dimensioni e delle risorse del database MariaDB di origine. Per ulteriori informazioni, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md).
1. Crea un'istanza DB Regione AWS che contiene la tua istanza Amazon EC2. Segui le istruzioni in [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md) e utilizza le linee guida seguenti:
+ Specifica una versione del motore di database compatibile con l’istanza database di origine.
+ Specifica lo stesso cloud privato virtuale (VPC) e lo stesso gruppo di sicurezza VPC dell'istanza Amazon EC2. Questo approccio garantisce che l’istanza Amazon EC2 e l’istanza Amazon RDS siano visibili una all’altra in rete. Assicurati che l'istanza database sia accessibile pubblicamente. Per impostare la replica con il database di origine, come descritto in una sezione seguente, l’istanza database deve essere accessibile pubblicamente.
+ Non configurare più zone di disponibilità, retention dei backup o repliche di lettura fino a quando non è stato importato il backup del database. Al termine dell'importazione, puoi configurare le varie zone di disponibilità e la conservazione dei backup per l'istanza di produzione.
1. Esamina le opzioni di configurazione predefinite per il database Amazon RDS. Se il gruppo di parametri predefinito per il database non include le opzioni di configurazione desiderate, cercane uno che le contenga oppure crea un gruppo di parametri nuovo. Per ulteriori informazioni sulla creazione di un gruppo di parametri, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md).
1. Connettiti al nuovo database Amazon RDS come utente master. Crea gli utenti necessari per supportare gli amministratori, le applicazioni e i servizi che devono accedere all’istanza database. Il nome host per il database Amazon RDS corrisponde al valore di **Endpoint** per l’istanza database senza il numero di porta, ad esempio `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Il valore dell’endpoint è disponibile nei dettagli del database nella console Amazon RDS.
1. Esegui la connessione all'istanza Amazon EC2. Per ulteriori informazioni, consulta [Connessione all’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) per le istanze Linux nella *Guida per l’utente di Amazon Elastic Compute Cloud*.
1. Connettiti al database Amazon RDS come host remoto dall'istanza Amazon EC2 usando il comando `mysql`. Il comando seguente è un esempio:
```
mysql -h host_name -P 3306 -u db_master_user -p
```
*host\$1name*È l'endpoint del database Amazon RDS.
1. Al prompt `mysql`, esegui il comando `source` e passa il nome del file di dump del database. Il comando carica i dati nell’istanza database Amazon RDS.
+ Per il formato SQL, utilizza il comando seguente:
```
MariaDB [(none)]> source backup.sql;
```
+ Per il formato con testo delimitato, crea innanzitutto il database se non utilizzi il database predefinito creato al momento dell’impostazione del database Amazon RDS,
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
quindi crea le tabelle
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
e infine importa i dati.
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
Per migliorare le prestazioni, puoi eseguire queste operazioni in parallelo da più connessioni, in modo che tutte le tabelle vengano create e caricate contemporaneamente.
**Nota**
Se nel dump iniziale della tabella sono state utilizzate opzioni di formattazione dati con `mysqldump` o `mariadb-dump`, è necessario utilizzare le stesse opzioni con `LOAD DATA LOCAL INFILE` per assicurare una corretta interpretazione del contenuto del file dati.
1. Esegui una semplice query `SELECT` in una o due tabelle del database importato, per verificare che l’operazione sia stata eseguita correttamente.
Se non hai più bisogno dell'istanza Amazon EC2 utilizzata in questa procedura, interrompi l'istanza EC2 per ridurre l'utilizzo delle risorse. AWS Per terminare un’istanza EC2, consulta [Terminare un’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) nella *Guida per l’utente di Amazon Elastic Compute Cloud*.
## Attività 4: replica dei dati dal database esterno al nuovo database Amazon RDS
È probabile che il database di origine sia stato aggiornato durante la copia e il trasferimento dei dati nel database MariaDB. Puoi utilizzare la replica per portare il database copiato con il database up-to-date di origine.
![\[Flusso di lavoro che mostra la replica dei dati dal database MariaDB esterno al database in Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_5.png)
Le autorizzazioni necessarie per avviare la replica in un database Amazon RDS sono limitate e non disponibili per l’utente master di Amazon RDS. Per questo motivo, utilizza la stored procedure Amazon RDS appropriata:
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) per configurare la replica e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per avviarla
### Per avviare la replica
Nell’Attività 1, [quando si impostano le opzioni di replica](#mariadb-importing-data-reduced-downtime-set-replication-options) si attiva la registrazione di log binari e si imposta un ID server univoco per il database di origine. Ora è possibile impostare il database Amazon RDS come replica, utilizzando il database attivo come istanza di replica di origine.
1. Nella console Amazon RDS aggiungi l’indirizzo IP del server che ospita il database di origine al gruppo di sicurezza VPC per il database Amazon RDS. Per ulteriori informazioni sui gruppi di sicurezza VPC, consulta [Configurazione delle regole per i gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) nella *Guida per l’utente di Amazon Virtual Private Cloud*.
Potrebbe essere necessario configurare anche la rete locale per consentire le connessioni dall’indirizzo IP del database Amazon RDS, in modo da comunicare con l’istanza di origine. Per individuare l’indirizzo IP del database Amazon RDS, utilizza il comando `host`:
```
host host_name
```
*host\$1name*È il nome DNS dell'endpoint del database Amazon RDS, ad esempio. `myinstance.123456789012.us-east-1.rds.amazonaws.com` Il valore dell’endpoint è disponibile nei dettagli dell’istanza database nella console Amazon RDS.
1. Utilizzando il client scelto, eseguire la connessione all'istanza di origine e creare un utente da utilizzare per la replica. Questo account viene utilizzato unicamente per la replica e deve essere limitato al dominio personale per aumentare la sicurezza. Il comando seguente è un esempio:
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Nota**
Specifica credenziali diverse dai prompt mostrati qui come best practice per la sicurezza.
1. Per l'istanza di origine, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente di replica. Per concedere ad esempio i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "`repl_user`" del proprio dominio, eseguire questo comando:
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Se per creare il file di backup è stato utilizzato il formato SQL e l’istanza esterna non è MariaDB 10.0.24 o versione successiva, esegui questo comando seguente per controllare il contenuto del file:
```
cat backup.sql
```
Il file include un commento `CHANGE MASTER TO` che contiene il nome e la posizione del file di log principale. Il commento si trova nel file di backup, se è stata utilizzata l'opzione `--master-data` con `mysqldump`. Prendere nota dei valori per `MASTER_LOG_FILE` e `MASTER_LOG_POS`.
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
Se per creare il file di backup è stato utilizzato il formato con testo delimitato e l’istanza esterna non è MariaDB 10.0.24 o versione successiva, si dovrebbe già disporre delle coordinate del log binario dalla fase 1 dell’Attività 1 [quando è stata creata una copia di backup del database esistente](#mariadb-importing-data-reduced-downtime-create-backup).
Se l’istanza esterna è MariaDB 10.0.24 o versione successiva, si dovrebbe già disporre del GTID da cui avviare la replica dalla fase 2 dell’Attività 1 [quando è stata creata una copia di backup del database esistente](#mariadb-importing-data-reduced-downtime-create-backup).
1. Definisci il database Amazon RDS come replica. Se l’istanza esterna non è MariaDB 10.0.24 o versione successiva, connettiti al database Amazon RDS come utente master e identifica il database di origine come istanza di replica di origine utilizzando la stored procedure [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master).
Se si dispone di un file di backup in formato SQL, utilizza il nome e la posizione del file di log principale, recuperati nella fase 4. Se invece è stato utilizzato il formato con testo delimitato, usa il nome e la posizione determinati al momento di creare i file di backup. Il comando seguente è un esempio:
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Nota**
Specifica credenziali diverse dai prompt mostrati qui come best practice per la sicurezza.
Se l’istanza esterna è MariaDB 10.0.24 o versione successiva, connettiti al database Amazon RDS come utente master e identifica il database di origine come istanza di replica di origine utilizzando la stored procedure [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md). Utilizza il GTID determinato nella fase 2 dell’Attività 1 [quando è stata creata una copia di backup del database esistente](#mariadb-importing-data-reduced-downtime-create-backup). Il comando seguente è un esempio:
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
`source_server_ip_address` è l' indirizzo IP dell'istanza di replica di origine. Al momento, gli indirizzi DNS privati di EC2 non sono supportati.
**Nota**
Specifica credenziali diverse dai prompt mostrati qui come best practice per la sicurezza.
1. Nel database Amazon RDS, per avviare la replica esegui questo comando che utilizza la stored procedure [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication):
```
CALL mysql.rds_start_replication;
```
1. Nel database Amazon RDS, per determinare quando la replica è up-to-date con l'istanza di replica di origine, esegui il comando [SHOW REPLICA](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) STATUS. I risultati del comando `SHOW REPLICA STATUS` includono il campo `Seconds_Behind_Master`. Quando il `Seconds_Behind_Master` campo restituisce 0, la replica si trova up-to-date con l'istanza di replica di origine.
Per un’istanza database MariaDB 10.5, 10.6, 10.11, 11.4 o 11.8, esegui la stored procedure [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) anziché il comando MySQL.
1. Una volta installato il database Amazon RDS up-to-date, attiva i backup automatici in modo da poter ripristinare il database, se necessario. È possibile attivare o modificare i backup automatici per il database Amazon RDS tramite la [console Amazon RDS](https://console.aws.amazon.com/rds/). Per ulteriori informazioni, consulta [Introduzione ai backup](USER_WorkingWithAutomatedBackups.md).
## Attività 5: reindirizzamento di un’applicazione attiva all’istanza Amazon RDS
Dopo che il database MariaDB up-to-date è con l'istanza di replica di origine, ora puoi aggiornare la tua applicazione live per utilizzare l'istanza Amazon RDS.
![\[Flusso di lavoro che mostra l’arresto della replica e l’indirizzamento dell’applicazione attiva al database in Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_6.png)
### Per reindirizzare l’applicazione attiva al database MariaDB e arrestare la replica
1. Per aggiungere il gruppo di sicurezza VPC per il database Amazon RDS, aggiungi l’indirizzo IP del server che ospita l’applicazione. Per ulteriori informazioni sui gruppi di sicurezza VPC, consulta [Configurazione delle regole per i gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) nella *Guida per l’utente di Amazon Virtual Private Cloud*.
1. Verifica che il `Seconds_Behind_Master` campo nei risultati del comando [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) sia 0, il che indica che la replica è up-to-date con l'istanza di replica di origine.
```
SHOW REPLICA STATUS;
```
Per un’istanza database MariaDB 10.5, 10.6, 10.11, 11.4 o 11.8, esegui la procedura [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) anziché il comando MySQL.
1. Chiudere tutte le connessioni all'origine quando le loro transazioni sono complete.
1. Aggiorna l'applicazione per usare il database Amazon RDS. In genere, l'aggiornamento prevede la modifica delle impostazioni di connessione per identificare il nome host e la porta del database Amazon RDS, l'account utente e la password per eseguire la connessione e il database da utilizzare.
1. Effettua la connessione all'istanza database.
1. Arresta la replica per l’istanza Amazon RDS eseguendo questo comando che utilizza la stored procedure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication):
```
CALL mysql.rds_stop_replication;
```
1. Esegui la stored procedure [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) nel database Amazon RDS per reimpostare la configurazione della replica in modo che l’istanza non venga più identificata come replica.
```
CALL mysql.rds_reset_external_master;
```
1. Attivare le caratteristiche aggiuntive di Amazon RDS, quali il supporto Multi-AZ e le repliche di lettura. Per ulteriori informazioni, consultare [Configurazione e gestione di un’implementazione Multi-AZ per Amazon RDS](Concepts.MultiAZ.md) e [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md).
# Importazione di dati da qualsiasi origine in un’istanza database Amazon RDS per MariaDB
Amazon RDS consente di migrare dati di MariaDB esistenti da qualsiasi origine a un’istanza database RDS per MariaDB. È possibile trasferire dati da database on-premises, altri provider cloud o istanze database RDS per MariaDB esistenti all’istanza database RDS per MariaDB di destinazione. La funzionalità permette di consolidare i database, implementare soluzioni di disaster recovery o eseguire il passaggio da database autogestiti. Gli scenari più comuni includono il passaggio da server MariaDB in hosting autonomo a istanze database Amazon RDS completamente gestite, il consolidamento di più database MariaDB in una singola istanza database o la creazione di ambienti di test con dati di produzione. Le seguenti sezioni forniscono step-by-step istruzioni per importare i dati MariadB utilizzando metodi `mariadb-dump` come file di backup o replica.
## Fase 1: Creazione di file flat contenenti i dati da caricare
Per salvare i dati da caricare, utilizza un formato comune, come ad esempio valori separati da virgola (CSV). Ciascuna tabella deve possedere il proprio file. Non è possibile combinare i dati di più tabelle nello stesso file. Devi fornire a ciascun file lo stesso nome della tabella corrispondente. Il file può avere qualsiasi estensione. Ad esempio, se il nome della tabella è `sales`, il nome del file potrebbe essere `sales.csv` o `sales.txt`.
Se possibile, ordina i dati in base alla chiave primaria della tabella da caricare. In questo modo i tempi di caricamento risultano significativamente più rapidi e si riduce il consumo di spazio su disco.
La velocità e l'efficienza di questa procedura dipende dalla capacità di mantenere contenute le dimensioni dei file. Se le dimensioni di un qualsiasi file (non compresso) superano 1 GiB, suddividilo in più file da caricare separatamente.
Nei sistemi di tipo Unix (incluso Linux), puoi utilizzare il comando `split`. Ad esempio, il comando seguente divide il file `sales.csv` in vari file con dimensioni inferiori a 1 GiB. Le divisioni vengono effettuate solo sulle interruzioni di riga (-C 1024m). I nomi dei nuovi file includono suffissi numerici crescenti. Il comando seguente genera file con nomi come `sales.part_00` e `sales.part_01`.
```
split -C 1024m -d sales.csv sales.part_
```
Utility simili sono disponibili anche per altri sistemi operativi.
È possibile archiviare i file flat ovunque. Tuttavia, quando si caricano i dati nella [Fase 5](#mariadb-importing-data-any-source-load-data), è necessario invocare la shell `mysql` dalla stessa posizione in cui si trovano i file o utilizzare il percorso assoluto dei file quando si esegue `LOAD DATA LOCAL INFILE`.
## Fase 2: arrestare le applicazioni che accedono all’istanza database di destinazione
Prima di avviare il caricamento di grandi quantità di dati, arresta le attività di tutte le applicazioni che accedono all’istanza database in cui intendi eseguire il caricamento. Questa operazione è particolarmente consigliata se le altre sessioni modificano le tabelle caricate o quelle di riferimento. In questo modo, puoi ridurre i rischi di violazione dei vincoli e ottimizzare le prestazioni durante il caricamento. Inoltre, diventa possibile ripristinare l'istanza database al punto immediatamente precedente il caricamento, senza perdere le modifiche apportate dai processi che non sono coinvolti nell'operazione di caricamento.
Ovviamente, ci sono casi in cui l'esecuzione di questa operazione risulta impossibile o poco pratica. Se puoi evitare che alcune applicazioni accedano all'istanza database prima del caricamento, prendi tutte le misure necessarie per assicurare la disponibilità e l'integrità dei dati. Tali misure dipendono in larga parte dal tipo specifico di utilizzo e dai requisiti del sito.
## Fase 3: Creazione di una snapshot DB
Se desideri caricare i dati in una nuova istanza database priva di dati, puoi ignorare questa parte. In caso contrario, si consiglia di creare snapshot di database dell’istanza database di destinazione Amazon RDS immediatamente prima e dopo il caricamento dei dati. Gli snapshot di database di Amazon RDS sono backup completi dell’istanza database che consentono di ripristinarla in uno stato noto. Quando si avvia uno snapshot DB, I/O le operazioni sull'istanza DB vengono momentaneamente sospese durante il backup del database.
Creando una snapshot DB immediatamente prima di caricare i dati ti consente di ripristinare il database allo stato precedente il caricamento, se fosse necessario. Una snapshot DB ottenuta immediatamente dopo il caricamento consente di non dover caricare nuovamente i dati in caso di problemi. È inoltre possibile utilizzare gli snapshot di database dopo il caricamento per importare dati in nuove istanze database.
L'esempio seguente esegue il AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html)comando per creare uno snapshot DB dell'`AcmeRDS`istanza e assegnare allo snapshot DB l'identificatore. `"preload"`
Per Linux, macOS o Unix:
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Per Windows:
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
Puoi utilizzare anche la funzione di ripristino da snapshot DB per creare istanze database di prova in cui eseguire test o annullare modifiche apportate durante il caricamento.
Ricorda che il ripristino di un database da una snapshot DB crea una nuova istanza database che, come tutte le istanze database, possiede un identificatore e un endpoint univoci. Per ripristinare l'istanza database senza modificare l'endpoint, devi innanzitutto eliminare l'istanza database, in modo da poter riutilizzare l'endpoint.
Ad esempio, per creare un'istanza database in cui eseguire test di vario tipo, devi assegnare all'istanza database il proprio identificatore. Nell’esempio, l'identificatore è `AcmeRDS-2`". L'esempio si connette all'istanza database utilizzando l'endpoint associato a `AcmeRDS-2`. [Per ulteriori informazioni, vedere -db-snapshot. restore-db-instance-from](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
Per Linux, macOS o Unix:
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Per Windows:
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
Per riutilizzare l'endpoint esistente, innanzitutto elimina l'istanza database e fornisci al database ripristinato lo stesso identificatore. Per ulteriori informazioni, consulta [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html).
L’esempio seguente crea uno snapshot di database finale dell’istanza database prima di eliminarla. Questo passaggio è facoltativo, ma è consigliato.
Per Linux, macOS o Unix:
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Per Windows:
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## Fase 4 (facoltativa): disattivare i backup automatici di Amazon RDS
**avvertimento**
Non disattivare i backup automatici se è necessario eseguire il ripristino. point-in-time
La disattivazione dei backup automatici è utile per ottimizzare le prestazioni, ma non è indispensabile per il caricamento dei dati. La disattivazione dei backup automatici comporta l’eliminazione di tutti i backup esistenti. Di conseguenza, dopo aver disattivato i backup automatici, il point-in-time ripristino non è possibile. Gli snapshot DB manuali non sono influenzati dalla disattivazione dei backup automatici. Tutti gli snapshot DB esistenti rimangono disponibili per il ripristino.
La disattivazione dei backup automatici velocizza il tempo di caricamento di circa il 25% e riduce la quantità di spazio richiesto. Se devi caricare dati in una nuova istanza database che non contiene altri dati, la disattivazione dei backup rappresenta un'ottima soluzione per velocizzare il caricamento ed evitare di occupare troppo spazio con i backup. Tuttavia, in alcuni casi, potresti pianificare di caricare i dati in un'istanza database che contiene già altri dati. In tal caso, valuta i vantaggi della disattivazione dei backup rispetto all'impatto della perdita della capacità di esecuzione. point-in-time-recovery
Per impostazione predefinita, i backup sono attivati per le istanze database (con un periodo di conservazione di un giorno). Per disabilitare i backup automatici, imposta il periodo di conservazione del backup su zero. Dopo il caricamento potrai riattivare i backup automatici impostando il periodo di conservazione su un valore diverso da zero. Per attivare o disattivare i backup, Amazon RDS chiude l’istanza database e la riavvia in modo da attivare o disattivare la registrazione di log MariaDB.
Esegui il AWS CLI `modify-db-instance` comando per impostare la conservazione dei backup su zero e applica immediatamente la modifica. Per impostare il periodo di retention su zero è necessario riavviare l'istanza database, quindi prima di continuare dovrai attendere il completamento del riavvio. Per ulteriori informazioni, consulta [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html).
Per Linux, macOS o Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Per Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
Puoi controllare lo stato della tua istanza DB con il AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)comando. Nell’esempio seguente viene visualizzato lo stato dell’istanza database `AcmeRDS`.
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
Quando lo stato dell’istanza database è `available`, si può passare alla fase successiva.
## Fase 5: Caricamento dei dati
Per leggere le righe dai file flat nelle tabelle del database, usa l’istruzione `LOAD DATA LOCAL INFILE` di MariaDB.
**Nota**
È necessario invocare la shell `mariadb` dalla stessa posizione in cui si trovano i file flat o utilizzare il percorso assoluto dei file quando si esegue `LOAD DATA LOCAL INFILE`.
L’esempio seguente mostra come caricare i dati da un file denominato `sales.txt` in una tabella denominata `Sales` nel database:
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
Per ulteriori informazioni sull’istruzione `LOAD DATA`, consulta [LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile) nella documentazione MariaDB.
## Fase 6: riattivare i backup automatici di Amazon RDS
Se nella [Fase 4](#mariadb-importing-data-any-source-turn-off-automated-backups) sono stati disattivati, al termine del caricamento riattiva i backup automatici di Amazon RDS impostando il periodo di conservazione del backup sul valore originale. Come indicato nella Fase 4, Amazon RDS riavvia l’istanza database, interrompendo brevemente le attività.
L'esempio seguente esegue il AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)comando per attivare i backup automatici per l'istanza `AcmeRDS` DB e impostare il periodo di conservazione su un giorno:
Per Linux, macOS o Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Per Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```