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à.
# Opzioni di migrazione per database MySQL e MariaDB di grandi dimensioni
Puoi scegliere tra un'ampia gamma di opzioni per migrare da database MySQL o MariaDB locali a istanze di database Amazon Relational Database Service (Amazon RDS) o istanze di database Edition compatibili con Amazon Aurora MySQL. La scelta dell'approccio e dello strumento di migrazione giusti è essenziale per una migrazione di successo e in questa guida valuterai le opzioni in base ai tuoi requisiti di usabilità, dimensione dei dati e tempi di inattività.
Di seguito sono riportati gli strumenti e gli approcci di migrazione più comuni disponibili per migrare in modo efficiente database MySQL autogestiti da più terabyte verso istanze di database Amazon RDS, Aurora o Amazon Elastic Compute Cloud (Amazon EC2):
+ [Percona XtraBackup](percona-xtrabackup.md)(Fisico)
+ [MyDumper](mydumper.md)(Logico)
+ [mysqldump e mysqlpump](mysqldump-and-mysqlpump.md)(Logico)
+ [Backup diviso](split-backup.md)(Fisico, logico o entrambi)
Di seguito sono riportati gli strumenti e gli approcci di migrazione più comuni disponibili per migrare in modo efficiente database compatibili con MySQL di più terabyte (come MariaDB) verso istanze di database Amazon RDS, Aurora o Amazon EC2:
+ [MyDumper](mydumper.md)(Logico)
+ [mysqldump e mysqlpump](mysqldump-and-mysqlpump.md)(Logico)
+ [Backup diviso](split-backup.md)(Fisico, logico o entrambi)
Per ogni strumento di migrazione, esistono diversi approcci che è possibile utilizzare per trasferire il file di backup del database di grandi dimensioni su Cloud AWS. Sono disponibili opzioni per ogni strumento e puoi anche utilizzare Amazon S3 File Gateway. Per ulteriori informazioni sul tagging, consulta [Utilizzo di Amazon S3 File Gateway per trasferire file di backup](amazon-s3-file-gateway.md)in questa guida.
# Percona XtraBackup
**Importante**
Percona non XtraBackup è supportato per le versioni 10.3 o successive di MariadB ed è supportato solo parzialmente per le versioni 10.1 e 10.2.
[Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/index.html) è un comune software di backup caldo open source per MySQL e MariaDB che esegue backup non bloccanti per i motori di archiviazione InnoDB e XtraDB. Funziona con server MySQL o MariadB. Per ulteriori informazioni sullo strumento e su alcune delle sue caratteristiche e vantaggi, consulta [Informazioni su Percona nella documentazione di Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html). XtraBackup
Questo strumento utilizza l'approccio della migrazione fisica. Copia direttamente la directory dei dati MySQL o MariaDB e i file al suo interno. Per database di grandi dimensioni, come quelli più grandi di 100 GB, questo può fornire tempi di ripristino significativamente migliori rispetto ad altri strumenti. È necessario creare un backup del database di origine locale, migrare i file di backup nel cloud e quindi ripristinare il backup sulla nuova istanza del database di destinazione.
Il diagramma seguente mostra i passaggi di alto livello coinvolti nella migrazione di un database utilizzando un file di backup Percona. XtraBackup A seconda della dimensione del file di backup, sono disponibili due opzioni per trasferire il backup in un bucket Amazon Simple Storage Service (Amazon S3) nel. Cloud AWS
![\[Diagramma della migrazione di un XtraBackup file Percona e del suo ripristino su un'istanza DB. AWS\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)
Di seguito sono riportati i passaggi per utilizzare Percona per XtraBackup migrare un database verso: Cloud AWS
1. Installa Percona XtraBackup sul server locale. [Se utilizzi Amazon Aurora MySQL versione 2 o Amazon RDS, consulta Installazione di Percona 2.4. XtraBackup](https://docs.percona.com/percona-xtrabackup/2.4/installation.html) Se utilizzi Amazon Aurora MySQL versione 3, consulta Installazione di Percona 8.0 nella documentazione di [ XtraBackupPercona](https://docs.percona.com/percona-xtrabackup/8.0/installation.html). XtraBackup
1. Crea un backup completo del database MySQL o MariaDB di origine. [Per istruzioni su Percona XtraBackup 2.4, vedi Backup completo.](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html) Per istruzioni per Percona XtraBackup 8.0, vedi [Creare un](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html) backup completo.
1. Trasferisci i file di backup su Internet utilizzando un servizio o uno strumento approvato dalla tua organizzazione, come il seguente:
+ [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-user-what-is.html)
+ [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ [Amazon S3 File Gateway](https://docs.aws.amazon.com/filegateway/latest/files3/what-is-file-s3.html) (per ulteriori informazioni, consulta [Utilizzo di Amazon S3 File Gateway per trasferire file di backup](amazon-s3-file-gateway.md) questa guida).
+ [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)
1. Dal bucket Amazon S3, ripristina i file di backup nell'istanza del database di destinazione. Per le istruzioni, consulta quanto segue:
+ Per l'edizione compatibile con Aurora MySQL, consulta Migrazione [dei dati da MySQL utilizzando un bucket Amazon S3 nella documentazione di Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) RDS.
+ Per Amazon RDS for MySQL o per Amazon EC2, [consulta Importazione di dati in un'istanza DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html) MySQL.
+ Per Amazon RDS for MariaDB o per Amazon EC2, [consulta Importazione di dati in un'istanza](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html) DB MariaDB.
1. (Facoltativo) Puoi configurare la replica tra il database di origine e l'istanza del database di destinazione. È possibile utilizzare la replica con log binario (binlog) per ridurre i tempi di inattività. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Impostazione della configurazione della sorgente di replica](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) nella documentazione MySQL
+ Per Amazon Aurora, consulta quanto segue:
+ [Sincronizzazione del cluster Amazon Aurora MySQL DB con il database MySQL utilizzando la replica nella documentazione](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) di Aurora
+ [Utilizzo della replica binlog in Amazon Aurora nella](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) documentazione di Aurora
+ Per Amazon RDS, consulta quanto segue:
+ [Utilizzo della replica MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) nella documentazione di Amazon RDS
+ [Utilizzo della replica MariadB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) nella documentazione di Amazon RDS
+ Per Amazon EC2, consulta quanto segue:
+ [Configurazione della replica basata sulla posizione dei file di log binari nella documentazione](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) MySQL
+ [Configurazione delle repliche](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) nella documentazione MySQL
+ [Configurazione della replica nella documentazione](https://mariadb.com/kb/en/setting-up-replication/) di MariadB
## Vantaggi
+ Poiché Percona XtraBackup utilizza un approccio di migrazione fisica, il processo di ripristino è in genere più veloce degli strumenti che utilizzano un approccio di migrazione logico. Questo perché le prestazioni sono limitate dalla velocità effettiva del disco o della rete piuttosto che dalle risorse di calcolo necessarie per l'elaborazione dei dati.
+ Poiché il processo di ripristino è una copia diretta dei file dal bucket S3 all'istanza del database di destinazione, i file Percona in genere si ripristinano più rapidamente XtraBackup dei file di backup creati con altri strumenti.
+ Percona è adattabile XtraBackup . Ad esempio, supporta più thread per aiutarti a copiare i file più velocemente e supporta la compressione per ridurre le dimensioni del backup.
## Limitazioni
+ Il backup offline non è possibile perché Percona XtraBackup deve avere accesso al server del database di origine.
+ Percona XtraBackup può essere utilizzato solo su sistemi con architetture di sistema identiche. Ad esempio, non è possibile ripristinare un backup di un database di origine in esecuzione su Intel per Windows Server su un server di destinazione ARM per Linux.
+ Percona XtraBackup non è supportato per MariaDB versione 10.3 o successiva ed è supportato solo parzialmente per MariaDB versione 10.2 e versione 10.1. Per ulteriori informazioni, vedere [ XtraBackup Panoramica di Percona: compatibilità con MariaDB nella knowledge](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb) base di MariaDB.
+ Non è possibile utilizzare Percona XtraBackup per ripristinare un database MariaDB di origine su un'istanza di database MySQL di destinazione, ad esempio Amazon RDS for MySQL o Aurora MySQL compatibile.
+ Il volume totale di dati e il numero di oggetti che è possibile archiviare in un bucket S3 sono illimitati, tuttavia la dimensione massima del file è di 5 TB. Se il file di backup supera i 5 TB, puoi suddividerlo in più file più piccoli.
+ Quando l'`innodb_file_per_table`impostazione è disattivata, Percona XtraBackup non supporta backup parziali che utilizzano`--tables`,,, `--tables-exclude` `--tables-file``--databases`, `--databases-exclude` o. `--databases-file` [Per ulteriori informazioni sulla XtraBackup versione 2.4 di Percona, vedere Backup parziali.](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html) Per ulteriori informazioni sulla XtraBackup versione 8.0 di Percona, consulta [Creare un](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html) backup parziale.
## Best practice
+ Per migliorare le prestazioni del processo di backup, procedi come segue:
+ Copia più file in parallelo usando [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel)
+ [Comprimi più file in parallelo usando --compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads)
+ Aumenta la memoria [usando](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory) --use-memory=
+ [Crittografa più file in parallelo usando --encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads)
+ Assicurati che ci sia spazio sufficiente sul server di origine per archiviare i file di backup del database.
+ Genera il backup del database con il file in formato Percona xbstream (.xbstream). Per ulteriori informazioni, vedere [La panoramica binaria di xbstream nella documentazione](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html) di Percona. XtraBackup
# MyDumper
[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper)(GitHub) è uno strumento di migrazione logica open source composto da due utilità:
+ MyDumper esporta un backup coerente dei database MySQL. Supporta il backup del database utilizzando più thread paralleli, fino a un thread per core della CPU disponibile.
+ myloader legge i file di backup creati da MyDumper, si connette all'istanza del database di destinazione e quindi ripristina il database.
Il diagramma seguente mostra i passaggi di alto livello necessari per la migrazione di un database utilizzando un file di backup. MyDumper Questo diagramma di architettura include tre opzioni per la migrazione del file di backup dal data center locale a un'istanza EC2 in. Cloud AWS
![\[Diagramma della migrazione di un file di MyDumper backup e dell'utilizzo di myloader per ripristinarlo sull'istanza DB. AWS\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)
Di seguito sono riportati i passaggi da utilizzare per MyDumper migrare un database verso: Cloud AWS
1. Install MyDumper e myloader. Per istruzioni, vedi [Come installare mydumper/myloader (](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader)). GitHub
1. MyDumper Da utilizzare per creare un backup del database MySQL o MariaDB di origine. [Per istruzioni, vedi Come usare. MyDumper](https://github.com/mydumper/mydumper#how-to-use-mydumper)
1. Sposta il file di backup in un'istanza EC2 Cloud AWS utilizzando uno dei seguenti approcci:
**Approccio 3A**: monta un file system [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [o Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) sul server locale che esegue l'istanza del database. È possibile utilizzare AWS Direct Connect o Site-to-Site VPN stabilire la connessione. È possibile eseguire il backup direttamente del database nella condivisione di file montata oppure eseguire il backup in due passaggi eseguendo il backup del database su un file system locale e quindi caricandolo sul volume FSx o EFS montato. Successivamente, monta il file system Amazon FSx o Amazon EFS, anch'esso montato sul server locale, su un'istanza EC2.
**Approccio 3B**: utilizza l' AWS CLI AWS SDK o l'API REST di Amazon S3 per spostare direttamente il file di backup dal server locale a un bucket S3. Se il bucket S3 di destinazione si trova in un Regione AWS ambiente molto lontano dal data center, puoi utilizzare [Amazon S3 Transfer Acceleration per trasferire](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) il file più rapidamente. Usa il file system [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) per montare il bucket S3 sull'istanza EC2.
**Approccio 3C**: installa l' AWS DataSync agente nel data center locale, quindi utilizzalo [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)per spostare il file di backup in un bucket Amazon S3. Usa il file system [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) per montare il bucket S3 sull'istanza EC2.
**Nota**
Puoi anche utilizzare Amazon S3 File Gateway per trasferire i file di backup del database di grandi dimensioni in un bucket S3 nel. Cloud AWS Per ulteriori informazioni sul tagging, consulta [Utilizzo di Amazon S3 File Gateway per trasferire file di backup](amazon-s3-file-gateway.md)in questa guida.
1. Usa myloader per ripristinare il backup sull'istanza del database di destinazione. Per istruzioni, consulta [myloader](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst) usage (). GitHub
1. (Facoltativo) È possibile impostare la replica tra il database di origine e l'istanza del database di destinazione. È possibile utilizzare la replica con log binario (binlog) per ridurre i tempi di inattività. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Impostazione della configurazione della sorgente di replica](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) nella documentazione MySQL
+ Per Amazon Aurora, consulta quanto segue:
+ [Sincronizzazione del cluster Amazon Aurora MySQL DB con il database MySQL utilizzando la replica nella documentazione](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) di Aurora
+ [Utilizzo della replica binlog in Amazon Aurora nella](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) documentazione di Aurora
+ Per Amazon RDS, consulta quanto segue:
+ [Utilizzo della replica MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) nella documentazione di Amazon RDS
+ [Utilizzo della replica MariadB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) nella documentazione di Amazon RDS
+ Per Amazon EC2, consulta quanto segue:
+ [Configurazione della replica basata sulla posizione dei file di log binari nella documentazione](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) MySQL
+ [Configurazione delle repliche](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) nella documentazione MySQL
+ [Configurazione della replica nella documentazione](https://mariadb.com/kb/en/setting-up-replication/) di MariadB
## Vantaggi
+ MyDumper supporta il parallelismo utilizzando il multithreading, che migliora la velocità delle operazioni di backup e ripristino.
+ MyDumper evita costose routine di conversione dei set di caratteri, il che contribuisce a garantire l'elevata efficienza del codice.
+ MyDumper semplifica la visualizzazione e l'analisi dei dati utilizzando il dumping di file separati per tabelle e metadati.
+ MyDumper mantiene le istantanee su tutti i thread e fornisce posizioni accurate dei log primari e secondari.
+ È possibile utilizzare Perl Compatible Regular Expressions (PCRE) per specificare se includere o escludere tabelle o database.
## Limitazioni
+ È possibile scegliere uno strumento diverso se i processi di trasformazione dei dati richiedono file di dump intermedi in formato flat anziché in formato SQL.
+ myloader non importa automaticamente gli account utente del database. Se stai ripristinando il backup su Amazon RDS o Aurora, ricrea gli utenti con le autorizzazioni richieste. Per ulteriori informazioni, consulta [Privilegi dell'account utente principale](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html) nella documentazione di Amazon RDS. Se stai ripristinando il backup su un'istanza di database Amazon EC2, puoi esportare manualmente gli account utente del database di origine e importarli nell'istanza EC2.
## Best practice
+ Configura MyDumper per dividere ogni tabella in segmenti, ad esempio 10.000 righe in ogni segmento, e scrivere ogni segmento in un file separato. In questo modo è possibile importare i dati in parallelo in un secondo momento.
+ Se si utilizza il motore InnoDB, utilizzare l'`--trx-consistency-only`opzione per ridurre al minimo il blocco.
+ L'utilizzo MyDumper per esportare il database può richiedere molte letture e il processo può influire sulle prestazioni complessive del database di produzione. Se disponi di un'istanza di database di replica, esegui il processo di esportazione dalla replica. Prima di eseguire l'esportazione dalla replica, interrompi il thread SQL di replica. Ciò consente di velocizzare l'esecuzione del processo di esportazione.
+ Non esportare il database durante le ore lavorative di punta. Evitare le ore di punta può stabilizzare le prestazioni del database di produzione principale durante l'esportazione del database.
+ Amazon RDS for MySQL non supporta il plug-in. `keyring_aws` Per ulteriori informazioni, consulta [Problemi noti](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing) e limitazioni. Per migrare le tabelle crittografate locali all'istanza Amazon RDS, negli script di backup, è necessario rimuovere `ENCRYPTION` o `DEFAULT ENCRYPTION` eliminare la sintassi. `CREATE TABLE` Per la crittografia a riposo, puoi usare una chiave (). AWS Key Management Service AWS KMS Per ulteriori informazioni, consulta [Crittografia delle risorse Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).
# mysqldump e mysqlpump
[mysqldump e mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) [sono](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) strumenti nativi di backup del database per MySQL. MariaDB supporta mysqldump ma non supporta mysqlpump. Entrambi questi strumenti creano backup logici e fanno parte dei programmi client MySQL. mysqldump supporta l'elaborazione a thread singolo. mysqlpump supporta l'elaborazione parallela di database e oggetti all'interno dei database, per accelerare il processo di dump. È stato introdotto nella versione 5.7.8 di MySQL. mysqlpump è stato rimosso nella versione 8.4 di MySQL.
Il diagramma seguente mostra i passaggi di alto livello coinvolti nella migrazione di un database utilizzando un file di backup mysqldump o mysqlpump.
![\[Diagramma della migrazione di un file di backup mysqldump o mysqlpump e del suo ripristino su un'istanza DB. AWS\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)
Di seguito sono riportati i passaggi per utilizzare mysqldump o mysqlpump per migrare un database verso: Cloud AWS
1. Installa MySQL Shell sul server locale. Per istruzioni, consulta [Installazione di MySQL Shell nella documentazione di MySQL](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html). Questo installa sia mysqldump che mysqlpump.
1. Usando mysqldump o mysqlpump, crea un backup del database di origine locale. [Per istruzioni, consulta [mysqldump e [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html)](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) nella documentazione di MySQL, oppure vedi Fare backup con mysqldump nella documentazione di MariaDB.](https://mariadb.com/kb/en/making-backups-with-mysqldump/) [Per ulteriori informazioni su come richiamare i programmi MySQL e specificare le opzioni, vedere Uso dei programmi MySQL.](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html)
1. Sposta il file di backup in un'istanza EC2 utilizzando uno dei Cloud AWS seguenti approcci:
**Approccio** **3A**: monta un file system [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [o Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) sul server locale che esegue l'istanza del database. È possibile utilizzare AWS Direct Connect o Site-to-Site VPN stabilire la connessione. È possibile eseguire il backup direttamente del database nella condivisione di file montata oppure eseguire il backup in due passaggi eseguendo il backup del database su un file system locale e quindi caricandolo sul volume FSx o EFS montato. Successivamente, monta il file system Amazon FSx o Amazon EFS, anch'esso montato sul server locale, su un'istanza EC2.
**Approccio 3B**: utilizza l' AWS CLI AWS SDK o l'API REST di Amazon S3 per spostare direttamente il file di backup dal server locale a un bucket S3. Se il bucket S3 di destinazione si trova in un Regione AWS ambiente molto lontano dal data center, puoi utilizzare [Amazon S3 Transfer Acceleration per trasferire](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) il file più rapidamente. Usa il file system [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) per montare il bucket S3 sull'istanza EC2.
**Approccio 3C**: installa l' AWS DataSync agente nel data center locale, quindi utilizzalo [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)per spostare il file di backup in un bucket Amazon S3. Usa il file system [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) per montare il bucket S3 sull'istanza EC2.
**Nota**
Puoi anche utilizzare Amazon S3 File Gateway per trasferire i file di backup del database di grandi dimensioni in un bucket S3 nel. Cloud AWS Per ulteriori informazioni sul tagging, consulta [Utilizzo di Amazon S3 File Gateway per trasferire file di backup](amazon-s3-file-gateway.md)in questa guida.
1. Utilizza il metodo di ripristino nativo per ripristinare il backup sul database di destinazione. Per istruzioni, consulta [Reloading di backup in formato SQL nella](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) documentazione di MySQL o vedi Ripristino [dei dati dai file di dump](https://mariadb.com/kb/en/restoring-data-from-dump-files/) nella documentazione di MariaDB.
1. (Facoltativo) È possibile impostare la replica tra il database di origine e l'istanza del database di destinazione. È possibile utilizzare la replica con log binario (binlog) per ridurre i tempi di inattività. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Impostazione della configurazione della sorgente di replica](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) nella documentazione MySQL
+ Per Amazon Aurora, consulta quanto segue:
+ [Sincronizzazione del cluster Amazon Aurora MySQL DB con il database MySQL utilizzando la replica nella documentazione](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) di Aurora
+ [Utilizzo della replica binlog in Amazon Aurora nella](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) documentazione di Aurora
+ Per Amazon RDS, consulta quanto segue:
+ [Utilizzo della replica MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) nella documentazione di Amazon RDS
+ [Utilizzo della replica MariadB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) nella documentazione di Amazon RDS
+ Per Amazon EC2, consulta quanto segue:
+ [Configurazione della replica basata sulla posizione dei file di log binari nella documentazione](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) MySQL
+ [Configurazione delle repliche](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) nella documentazione MySQL
+ [Configurazione della replica nella documentazione](https://mariadb.com/kb/en/setting-up-replication/) di MariadB
## Vantaggi
+ mysqldump e mysqlpump sono inclusi nell'installazione di MySQL Server
+ I file di backup generati da questi strumenti sono in un formato più leggibile.
+ Prima di ripristinare il file di backup, è possibile modificare il file.sql risultante utilizzando un editor di testo standard.
+ È possibile eseguire il backup di una tabella, di un database o anche di una particolare selezione di dati.
+ mysqldump e mysqlpump sono indipendenti dall'architettura della macchina.
## Limitazioni
+ mysqldump è un processo di backup a thread singolo. Le prestazioni per l'esecuzione di un backup sono buone per i database di piccole dimensioni, ma possono diventare inefficienti quando le dimensioni del backup superano i 10 GB.
+ I file di backup in formato logico sono voluminosi, soprattutto se salvati come testo, e spesso sono lenti da creare e ripristinare.
+ Il ripristino dei dati può essere lento perché la riapplicazione delle istruzioni SQL nell'istanza DB di destinazione comporta un'elaborazione intensiva del disco I/O e della CPU per l'inserimento, la creazione di indici e l'applicazione dei vincoli di integrità referenziale.
+ L'utilità mysqlpump non è supportata per le versioni di MySQL precedenti alla 5.7.8 o per le versioni 8.4 e successive.
+ Per impostazione predefinita, mysqlpump non esegue un backup dei database di sistema, ad esempio o. `performance_schema` `sys` Per eseguire il backup di parte del database di sistema, denominalo esplicitamente nella riga di comando.
+ mysqldump non esegue il backup delle istruzioni InnoDB. `CREATE TABLESPACE`
**Nota**
I backup delle istruzioni CREATE TABLESPACE e dei database di sistema sono utili solo quando si ripristinano i backup del database MySQL o MariadB su un'istanza EC2. Questi backup non vengono utilizzati per Amazon RDS o Aurora.
## Best practice
+ Quando ripristini il backup del database, disabilita i controlli chiave, ad esempio a livello di sessione nel database di destinazione. `FOREIGN_KEY_CHECKS` Ciò aumenta la velocità di ripristino.
+ Assicurati che l'utente del database disponga di [privilegi](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html) sufficienti per creare e ripristinare il backup.
# Backup diviso
Una strategia *di backup suddiviso* consiste nella migrazione di un server di database di grandi dimensioni dividendo il backup in più parti. È possibile utilizzare approcci diversi per migrare ogni parte del backup. Questa può essere l'opzione migliore per i seguenti casi d'uso:
+ **Server di database di grandi dimensioni ma database singoli di piccole** dimensioni: questo è un buon approccio quando le dimensioni del server di database totale sono multiple TBs ma le dimensioni di ogni singolo database utente indipendente sono inferiori a 1 TB. Per ridurre il periodo di migrazione complessivo, è possibile migrare i singoli database separatamente e in parallelo.
Usiamo un esempio di un server di database locale da 2 TB. Questo server è composto da quattro database da 0,5 TB ciascuno. È possibile eseguire i backup di ogni singolo database separatamente. Quando si ripristina il backup, è possibile ripristinare tutti i database su un'istanza in parallelo oppure, se i database sono indipendenti, è possibile ripristinare ogni backup su un'istanza separata. È consigliabile ripristinare database indipendenti su istanze separate, anziché ripristinarli sulla stessa istanza. Per ulteriori informazioni, consulta le procedure consigliate in questa guida.
+ **Server di database di grandi dimensioni ma piccole tabelle di database singole**: questo è un buon approccio quando le dimensioni del server di database totale sono multiple TBs ma le dimensioni di ogni tabella di database indipendente sono inferiori a 1 TB. Per ridurre il periodo di migrazione complessivo, è possibile migrare le tabelle indipendenti singolarmente.
Usiamo un esempio di database per utente singolo di 1 TB, l'unico database in un server di database locale. Il database contiene 10 tabelle, ognuna delle quali è di 100 GB. È possibile eseguire i backup di ogni singola tabella separatamente. Quando si ripristina il backup, è possibile ripristinare tutte le tabelle su un'istanza in parallelo.
+ **Un database contiene tabelle di carichi di lavoro transazionali e non transazionali**: analogamente al caso d'uso precedente, è possibile utilizzare un approccio di backup suddiviso quando nello stesso database sono presenti tabelle di carichi di lavoro transazionali e non transazionali.
Prendiamo un esempio di database da 2 TB composto da 0,5 TB di tabelle di carichi di lavoro critiche utilizzate per l'elaborazione delle transazioni online (OLTP) e una singola tabella da 1,5 TB utilizzata per l'archiviazione di vecchi dati. È possibile eseguire il backup di tutti gli oggetti del database ad eccezione della tabella di archiviazione come backup coerente e a transazione singola. Quindi, si esegue solo un altro backup separato della tabella di archiviazione. Per il backup della tabella di archiviazione, puoi anche prendere in considerazione l'idea di eseguire più backup paralleli utilizzando condizioni per dividere il numero di righe nel file di backup. Di seguito è riportato un esempio:
```
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1 and 1000000 " > your_table1_part1.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql
```
Quando si ripristinano i file di backup, è possibile ripristinare il backup del carico di lavoro transazionale e il backup della tabella di archiviazione in parallelo.
+ **Limitazioni delle risorse di elaborazione**: se nel server locale sono disponibili risorse di elaborazione limitate, ad esempio CPU, memoria o I/O del disco, ciò può influire sulla stabilità e sulle prestazioni durante l'esecuzione del backup. Invece di eseguire un backup completo, è possibile dividerlo in parti.
Ad esempio, un server di produzione locale potrebbe essere sovraccarico di carichi di lavoro e disporre di risorse CPU limitate. Se si esegue un backup in un'unica esecuzione di un database di più terabyte su questo server, può consumare risorse CPU aggiuntive e influire negativamente sul server di produzione. Invece di eseguire il backup completo del database, suddividetelo in più parti, ad esempio 2-3 tabelle ciascuna.