As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Opções de migração para grandes bancos de dados MySQL e MariaDB
Você pode escolher entre uma ampla variedade de opções para migrar de bancos de dados MySQL ou MariaDB on-premises para instâncias de banco de dados do Amazon Relational Database Service (Amazon RDS) ou da edição do Amazon Aurora compatível com MySQL. Escolher a abordagem e a ferramenta de migração corretas é essencial para uma migração bem-sucedida e, neste guia, você avalia as opções com base em sua usabilidade, tamanho dos dados e requisitos de tempo de inatividade.
Confira abaixo as ferramentas e abordagens de migração comuns que estão disponíveis para migrar bancos de dados MySQL autogerenciados de vários terabytes de forma eficiente para instâncias de banco de dados do Amazon RDS, Aurora ou Amazon Elastic Compute Cloud (Amazon EC2):
+ [Percona XtraBackup](percona-xtrabackup.md) (físico)
+ [MyDumper](mydumper.md) (lógico)
+ [mysqldump e mysqlpump](mysqldump-and-mysqlpump.md) (lógico)
+ [Dividir o backup](split-backup.md) (físico, lógico ou ambos)
Confira abaixo as ferramentas e abordagens de migração comuns que estão disponíveis para migrar bancos de dados de vários terabytes compatíveis com MySQL (como MariaDB) de forma eficiente para instâncias de banco de dados do Amazon RDS, Aurora ou Amazon EC2:
+ [MyDumper](mydumper.md) (lógico)
+ [mysqldump e mysqlpump](mysqldump-and-mysqlpump.md) (lógico)
+ [Dividir o backup](split-backup.md) (físico, lógico ou ambos)
Para cada ferramenta de migração, há várias abordagens que você pode usar para transferir o grande arquivo de backup do banco de dados para a Nuvem AWS. As opções são fornecidas para cada ferramenta, e você também pode usar o Gateway de Arquivos do Amazon S3. Para obter mais informações, consulte [Uso do Gateway de Arquivos do Amazon S3 para transferir arquivos de backup](amazon-s3-file-gateway.md) neste guia.
# Percona XtraBackup
**Importante**
O Percona não XtraBackup é compatível com as versões 10.3 ou posteriores do MariaDB e é suportado apenas parcialmente nas versões 10.1 e 10.2.
O [Percona XtraBackup é um](https://docs.percona.com/percona-xtrabackup/8.0/index.html) software comum de backup quente de código aberto para MySQL e MariaDB que faz backups sem bloqueio para os mecanismos de armazenamento InnoDB e XtraDB. Ele funciona com servidores MySQL ou MariaDB. Para obter mais informações sobre a ferramenta e alguns de seus recursos e benefícios, consulte [Sobre a Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html) na documentação da XtraBackup Percona.
Essa ferramenta usa a abordagem de migração física. Ela copia diretamente o diretório de dados MySQL ou MariaDB e os arquivos dentro dele. Para bancos de dados grandes, como aqueles maiores que 100 GB, isso pode proporcionar um tempo de restauração significativamente melhor do que algumas outras ferramentas. Você cria um backup do banco de dados de origem on-premises, migra os arquivos de backup para a nuvem e, em seguida, restaura o backup na nova instância do banco de dados de destino.
O diagrama a seguir mostra as etapas de alto nível envolvidas na migração de um banco de dados usando um arquivo de backup da XtraBackup Percona. Dependendo do tamanho do arquivo de backup, há duas opções disponíveis para transferir o backup para um bucket do Amazon Simple Storage Service (Amazon S3) na Nuvem AWS.
![\[Diagrama da migração de um XtraBackup arquivo Percona e sua restauração em uma instância de banco de dados. AWS\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)
A seguir estão as etapas para usar o Percona para XtraBackup migrar um banco de dados para o: Nuvem AWS
1. Instale o Percona XtraBackup no servidor local. [Se você estiver usando o Amazon Aurora MySQL versão 2 ou o Amazon RDS, consulte Instalação do Percona 2.4. XtraBackup](https://docs.percona.com/percona-xtrabackup/2.4/installation.html) Se você estiver usando o Amazon Aurora MySQL versão 3, consulte Instalação do Percona 8.0 na documentação do [Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/installation.html). XtraBackup
1. Crie um backup completo do banco de dados MySQL ou MariaDB de origem. Para obter instruções sobre o Percona XtraBackup 2.4, consulte Backup [completo](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html). Para obter instruções sobre o Percona XtraBackup 8.0, consulte [Criar um backup completo](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html).
1. Transfira os arquivos de backup pela Internet usando um serviço ou ferramenta aprovado em sua organização, como o seguinte:
+ [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)
+ [Gateway de Arquivos do Amazon S3](https://docs.aws.amazon.com/filegateway/latest/files3/what-is-file-s3.html) (Para obter mais informações, consulte [Uso do Gateway de Arquivos do Amazon S3 para transferir arquivos de backup](amazon-s3-file-gateway.md) neste guia.)
+ [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)
1. No bucket do Amazon S3, restaure os arquivos de backup na instância do banco de dados de destino. Para instruções, consulte:
+ Para a edição compatível com MySQL do Aurora, consulte [Migrating data from MySQL by using an Amazon S3 bucket](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) na documentação do Amazon RDS.
+ Para o Amazon RDS para MySQL ou para o Amazon EC2, consulte [Importar dados para uma instância de banco de dados MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html).
+ Para o Amazon RDS para MariaDB ou para o Amazon EC2, consulte [Importar dados para uma instância de banco de dados MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html).
1. (Opcional) Você pode configurar a replicação entre o banco de dados de origem e a instância do banco de dados de destino. Você pode usar a replicação de log binário (binlog) para reduzir o tempo de inatividade. Para saber mais, consulte:
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) na documentação do MySQL
+ Para o Amazon Aurora, consulte o seguinte:
+ [Synchronizing the Amazon Aurora MySQL DB cluster with the MySQL database using replication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) na documentação do Aurora
+ [Using binlog replication in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) na documentação do Aurora
+ Para o Amazon RDS, consulte o seguinte:
+ [Trabalhar com a replicação do MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) na documentação do Amazon RDS
+ [Trabalhar com a replicação do MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) na documentação do Amazon RDS
+ Para o Amazon EC2, consulte o seguinte:
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) na documentação do MySQL
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) na documentação do MySQL
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/) na documentação do MariaDB
## Vantagens
+ Como a Percona XtraBackup usa uma abordagem de migração física, o processo de restauração geralmente é mais rápido do que as ferramentas que usam uma abordagem de migração lógica. Isso ocorre porque a performance é limitada pelo throughput do disco ou da rede, e não pelos recursos computacionais necessários para o processamento de dados.
+ Como o processo de restauração é uma cópia direta dos arquivos do bucket do S3 para a instância do banco de dados de destino, os XtraBackup arquivos Percona geralmente são restaurados mais rapidamente do que os arquivos de backup criados com outras ferramentas.
+ Percona XtraBackup é adaptável. Por exemplo, ele é compatível com vários threads para ajudar você a copiar arquivos mais rapidamente, e é compatível com compactação para reduzir o tamanho do backup.
## Limitações
+ O backup off-line não é possível porque o Percona XtraBackup deve ter acesso ao servidor do banco de dados de origem.
+ O Percona só XtraBackup pode ser usado em sistemas com arquiteturas de sistema idênticas. Por exemplo, não é possível restaurar um backup de um banco de dados de origem executado no Intel para Windows Server em um servidor de destino ARM para Linux.
+ O Percona XtraBackup não é compatível com o MariaDB versão 10.3 ou posterior e é apenas parcialmente compatível com o MariaDB versão 10.2 e versão 10.1. Para obter mais informações, consulte [ XtraBackup Visão geral da Percona: compatibilidade com o MariaDB na base de conhecimento do MariaDB](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb).
+ Você não pode usar o XtraBackup Percona para restaurar um banco de dados MariaDB de origem para uma instância de banco de dados MySQL de destino, como Amazon RDS for MySQL ou compatível com Aurora MySQL.
+ O volume total de dados e o número de objetos que você pode armazenar em um bucket do S3 são ilimitados, no entanto, o tamanho máximo do arquivo é de 5 TB. Se o arquivo de backup exceder 5 TB, você poderá dividir o arquivo em vários arquivos menores.
+ Quando a `innodb_file_per_table` configuração está desativada, o Percona XtraBackup não oferece suporte a backups parciais que usam`--tables`,`--tables-exclude`,`--tables-file`, `--databases``--databases-exclude`, ou. `--databases-file` Para obter mais informações sobre o Percona XtraBackup versão 2.4, consulte Backups [parciais](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html). Para obter mais informações sobre o Percona XtraBackup versão 8.0, consulte [Criar um backup parcial](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html).
## Práticas recomendadas
+ Para melhorar a performance do processo de backup, faça o seguinte:
+ Copie vários arquivos em paralelo usando [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel)
+ Compacte vários arquivos em paralelo usando [--compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads)
+ Aumente a memória usando [--use-memory=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory)
+ Criptografe vários arquivos em paralelo usando [--encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads)
+ Verifique se há espaço suficiente no servidor de origem para armazenar os arquivos de backup do banco de dados.
+ Gere o backup do banco de dados com o arquivo de formato Percona xbstream (.xbstream). Para obter mais informações, consulte [A visão geral do binário xbstream na documentação do](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html) XtraBackup Percona.
# MyDumper
[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper)(GitHub) é uma ferramenta de migração lógica de código aberto que consiste em dois utilitários:
+ MyDumper exporta um backup consistente dos bancos de dados MySQL. Ele é compatível com o backup do banco de dados usando vários threads paralelos, até um thread por núcleo de CPU disponível.
+ myloader lê os arquivos de backup criados por MyDumper, se conecta à instância do banco de dados de destino e, em seguida, restaura o banco de dados.
O diagrama a seguir mostra as etapas de alto nível envolvidas na migração de um banco de dados usando um arquivo de MyDumper backup. Esse diagrama de arquitetura inclui três opções para migrar o arquivo de backup do data center on-premises para uma instância do EC2 na Nuvem AWS.
![\[Diagrama da migração de um arquivo de MyDumper backup e do uso do myloader para restaurá-lo na instância de banco de dados. AWS\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)
A seguir estão as etapas a serem usadas MyDumper para migrar um banco de dados para o Nuvem AWS:
1. Instale MyDumper e meu carregador. Para obter instruções, consulte [Como instalar mydumper/myloader](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader) (). GitHub
1. Use MyDumper para criar um backup do banco de dados MySQL ou MariaDB de origem. Para obter instruções, consulte [Como usar MyDumper](https://github.com/mydumper/mydumper#how-to-use-mydumper).
1. Mova o arquivo de backup para uma instância do EC2 no Nuvem AWS usando uma das seguintes abordagens:
**Abordagem 3A** — Monte um sistema de arquivos [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [ou Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) no servidor local que executa sua instância de banco de dados. Você pode usar AWS Direct Connect ou Site-to-Site VPN para estabelecer a conexão. Você pode fazer backup diretamente do banco de dados no compartilhamento de arquivos montado, ou pode realizar o backup em duas etapas, fazendo backup do banco de dados em um sistema de arquivos local e, em seguida, carregando-o no volume do FSx ou EFS montado. Em seguida, monte o sistema de arquivos Amazon FSx ou Amazon EFS, que também é montado no servidor on-premises, em uma instância do EC2.
**Abordagem 3B** — Use o AWS CLI AWS SDK ou a API REST do Amazon S3 para mover diretamente o arquivo de backup do servidor local para um bucket do S3. Se o bucket do S3 de destino estiver em um Região da AWS local distante do data center, você poderá usar o [Amazon S3 Transfer Acceleration para transferir](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) o arquivo mais rapidamente. Use o sistema de arquivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar o bucket do S3 na instância do EC2.
**Abordagem 3C**: instale o agente do AWS DataSync no data center on-premises e use o [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) para mover o arquivo de backup para um bucket do Amazon S3. Use o sistema de arquivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar o bucket do S3 na instância do EC2.
**nota**
Você também pode usar o Gateway de Arquivos do Amazon S3 para transferir os grandes arquivos de backup do banco de dados para um bucket do S3 na Nuvem AWS. Para obter mais informações, consulte [Uso do Gateway de Arquivos do Amazon S3 para transferir arquivos de backup](amazon-s3-file-gateway.md) neste guia.
1. Use o myloader para restaurar o backup na instância do banco de dados de destino. Para obter instruções, consulte [myloader usage](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst) ()GitHub.
1. (Opcional) Você pode configurar a replicação entre o banco de dados de origem e a instância do banco de dados de destino. Você pode usar a replicação de log binário (binlog) para reduzir o tempo de inatividade. Para saber mais, consulte:
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) na documentação do MySQL
+ Para o Amazon Aurora, consulte o seguinte:
+ [Synchronizing the Amazon Aurora MySQL DB cluster with the MySQL database using replication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) na documentação do Aurora
+ [Using binlog replication in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) na documentação do Aurora
+ Para o Amazon RDS, consulte o seguinte:
+ [Trabalhar com a replicação do MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) na documentação do Amazon RDS
+ [Trabalhar com a replicação do MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) na documentação do Amazon RDS
+ Para o Amazon EC2, consulte o seguinte:
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) na documentação do MySQL
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) na documentação do MySQL
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/) na documentação do MariaDB
## Vantagens
+ MyDumper suporta paralelismo usando multiencadeamento, o que melhora a velocidade das operações de backup e restauração.
+ MyDumper evita rotinas caras de conversão de conjuntos de caracteres, o que ajuda a garantir que o código seja altamente eficiente.
+ MyDumper simplifica a visualização e a análise de dados usando o despejo de arquivos separados para tabelas e metadados.
+ MyDumper mantém instantâneos em todos os segmentos e fornece posições precisas dos registros primários e secundários.
+ Você pode usar expressões regulares compatíveis com Perl (PCRE) para especificar se deseja incluir ou excluir tabelas ou bancos de dados.
## Limitações
+ Você poderá escolher outra ferramenta se seus processos de transformação de dados exigirem arquivos de despejo intermediários em formato simples, em vez do formato SQL.
+ O myloader não importa contas de usuário do banco de dados automaticamente. Se você estiver restaurando o backup no Amazon RDS ou no Aurora, recrie os usuários com as permissões necessárias. Para obter mais informações, consulte [Privilégios da conta de usuário mestre](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html) na documentação do Amazon RDS. Se você estiver restaurando o backup em uma instância de banco de dados do Amazon EC2, poderá exportar manualmente as contas de usuário do banco de dados de origem e importá-las para a instância do EC2.
## Práticas recomendadas
+ Configure MyDumper para dividir cada tabela em segmentos, como 10.000 linhas em cada segmento, e gravar cada segmento em um arquivo separado. Isso possibilita a importação de dados em paralelo posteriormente.
+ Se você estiver usando o mecanismo InnoDB, use a opção `--trx-consistency-only` para minimizar o bloqueio.
+ O uso MyDumper para exportar o banco de dados pode exigir muita leitura, e o processo pode afetar o desempenho geral do banco de dados de produção. Se você tiver uma instância de banco de dados de réplica, execute o processo de exportação da réplica. Antes de executar a exportação da réplica, interrompa o thread SQL de replicação. Isso ajuda o processo de exportação a ser executado mais rapidamente.
+ Não exporte o banco de dados durante o horário comercial de pico. Evitar os horários de pico pode estabilizar a performance do seu banco de dados primário de produção durante a exportação do banco de dados.
+ O Amazon RDS para MySQL não é compatível com o plug-in `keyring_aws`. Para obter mais informações, consulte [Problemas conhecidos e limitações](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing). Para migrar as tabelas criptografadas on-premises para a instância do Amazon RDS, nos scripts de backup, você precisa remover `ENCRYPTION` ou `DEFAULT ENCRYPTION` da sintaxe `CREATE TABLE`. Para criptografia em repouso, você pode usar uma chave do AWS Key Management Service (AWS KMS). Para ter mais informações, consulte [Criptografar recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).
# mysqldump e mysqlpump
O [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) e [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) são ferramentas nativas de backup de banco de dados para MySQL. O MariaDB é compatível com o mysqldump, mas não com o mysqlpump. Ambas as ferramentas criam backups lógicos e fazem parte dos programas do cliente MySQL. O mysqldump é compatível com o processamento de thread único. O mysqlpump é compatível com o processamento paralelo de bancos de dados e objetos dentro de bancos de dados para acelerar o processo de despejo. Foi introduzido na versão 5.7.8 do MySQL. O mysqlpump foi removido na versão 8.4 do MySQL.
O diagrama a seguir mostra as etapas de alto nível envolvidas na migração de um banco de dados usando um arquivo de backup mysqldump ou mysqlpump.
![\[Diagrama de como migrar um arquivo de backup mysqldump ou mysqlpump e restaurá-lo em uma instância de banco de dados. AWS\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)
Confira abaixo as etapas para usar o mysqldump ou o mysqlpump para migrar um banco de dados para a Nuvem AWS:
1. Instale o MySQL Shell no servidor on-premises. Para obter instruções, consulte [Installing MySQL Shell](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html) ina documentação do MySQL. Isso instala tanto o mysqldump como o mysqlpump.
1. Usando o mysqldump ou o mysqlpump, crie um backup do banco de dados on-premises de origem. Para obter instruções, consulte [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) e [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) na documentação do MySQL, ou consulte [Making Backups with mysqldump](https://mariadb.com/kb/en/making-backups-with-mysqldump/) na documentação do MariaDB. Para obter mais informações sobre como invocar programas MySQL e especificar opções, consulte [Using MySQL programs](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html).
1. Mova o arquivo de backup para uma instância do EC2 no Nuvem AWS usando uma das seguintes abordagens:
**Abordagem** **3A** — Monte um sistema de arquivos [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [ou Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) no servidor local que executa sua instância de banco de dados. Você pode usar AWS Direct Connect ou Site-to-Site VPN para estabelecer a conexão. Você pode fazer backup diretamente do banco de dados no compartilhamento de arquivos montado, ou pode realizar o backup em duas etapas, fazendo backup do banco de dados em um sistema de arquivos local e, em seguida, carregando-o no volume do FSx ou EFS montado. Em seguida, monte o sistema de arquivos Amazon FSx ou Amazon EFS, que também é montado no servidor on-premises, em uma instância do EC2.
**Abordagem 3B** — Use o AWS CLI AWS SDK ou a API REST do Amazon S3 para mover diretamente o arquivo de backup do servidor local para um bucket do S3. Se o bucket do S3 de destino estiver em um Região da AWS local distante do data center, você poderá usar o [Amazon S3 Transfer Acceleration para transferir](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) o arquivo mais rapidamente. Use o sistema de arquivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar o bucket do S3 na instância do EC2.
**Abordagem 3C**: instale o agente do AWS DataSync no data center on-premises e use o [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) para mover o arquivo de backup para um bucket do Amazon S3. Use o sistema de arquivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar o bucket do S3 na instância do EC2.
**nota**
Você também pode usar o Gateway de Arquivos do Amazon S3 para transferir os grandes arquivos de backup do banco de dados para um bucket do S3 na Nuvem AWS. Para obter mais informações, consulte [Uso do Gateway de Arquivos do Amazon S3 para transferir arquivos de backup](amazon-s3-file-gateway.md) neste guia.
1. Use o método de restauração nativo para restaurar o backup no banco de dados de destino. Para obter instruções, consulte [Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) na documentação do MySQL, ou consulte [Restoring Data from Dump Files](https://mariadb.com/kb/en/restoring-data-from-dump-files/) na documentação do MariaDB.
1. (Opcional) Você pode configurar a replicação entre o banco de dados de origem e a instância do banco de dados de destino. Você pode usar a replicação de log binário (binlog) para reduzir o tempo de inatividade. Para saber mais, consulte:
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) na documentação do MySQL
+ Para o Amazon Aurora, consulte o seguinte:
+ [Synchronizing the Amazon Aurora MySQL DB cluster with the MySQL database using replication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) na documentação do Aurora
+ [Using binlog replication in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) na documentação do Aurora
+ Para o Amazon RDS, consulte o seguinte:
+ [Trabalhar com a replicação do MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) na documentação do Amazon RDS
+ [Trabalhar com a replicação do MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) na documentação do Amazon RDS
+ Para o Amazon EC2, consulte o seguinte:
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) na documentação do MySQL
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) na documentação do MySQL
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/) na documentação do MariaDB
## Vantagens
+ O mysqldump e o mysqlpump estão incluídos na instalação do servidor MySQL
+ Os arquivos de backup gerados por essas ferramentas estão em um formato mais legível.
+ Antes de restaurar o arquivo de backup, você pode modificar o arquivo.sql resultante usando um editor de texto padrão.
+ Você pode fazer backup de uma tabela, banco de dados ou até mesmo de uma seleção de dados específica.
+ O mysqldump e o mysqlpump são independentes da arquitetura da máquina.
## Limitações
+ O mysqldump é um processo de backup de thread único. A performance para realizar um backup é boa para bancos de dados pequenos, mas pode se tornar ineficiente quando o tamanho do backup é maior que 10 GB.
+ Os arquivos de backup em formato lógico são volumosos, especialmente quando salvos como texto, e geralmente demoram para criar e restaurar.
+ A restauração de dados pode ser lenta porque a reaplicação de instruções SQL na instância de banco de dados de destino envolve processamento intensivo de disco I/O e CPU para inserção, criação de índices e imposição de restrições de integridade referencial.
+ O utilitário mysqlpump não é compatível com as versões do MySQL anteriores à 5.7.8 ou com as versões 8.4 e posteriores.
+ Por padrão, o mysqlpump não faz backup dos bancos de dados do sistema, como `performance_schema` ou `sys`. Para fazer backup de parte do banco de dados do sistema, nomeie-o explicitamente na linha de comando.
+ O mysqldump não faz backup de instruções `CREATE TABLESPACE` do InnoDB.
**nota**
Os backups das instruções CREATE TABLESPACE e dos bancos de dados do sistema são úteis somente quando você está restaurando backups do banco de dados MySQL ou MariaDB em uma instância do EC2. Esses backups não são usados para o Amazon RDS ou Aurora.
## Práticas recomendadas
+ Ao restaurar o backup do banco de dados, desabilite as verificações de chave, como `FOREIGN_KEY_CHECKS`, no nível da sessão no banco de dados de destino. Isso aumenta a velocidade de restauração.
+ Verifique se o usuário do banco de dados tem [privilégios](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html) suficientes para criar e restaurar o backup.
# Dividir o backup
Uma estratégia de *backup dividido* é quando você migra um grande servidor de banco de dados, dividindo o backup em várias partes. Você pode usar abordagens diferentes para migrar cada parte do backup. Esta pode ser a melhor opção para os seguintes casos de uso:
+ **Servidor de banco de dados grande, mas bancos de dados individuais pequenos** — Essa é uma boa abordagem quando o tamanho total do servidor de banco de dados é múltiplo, TBs mas o tamanho de cada banco de dados de usuário individual e independente é inferior a 1 TB. Para reduzir o período geral de migração, você pode migrar bancos de dados individuais separada e paralelamente.
Vamos usar um exemplo de um servidor de banco de dados on-premises de 2 TB. Esse servidor consiste em quatro bancos de dados, cada um com 0,5 TB. Você pode fazer backups de cada banco de dados individual separadamente. Ao restaurar o backup, você pode restaurar todos os bancos de dados em uma instância em paralelo ou, se os bancos de dados forem independentes, você poderá restaurar cada backup em uma instância separada. É uma prática recomendada restaurar bancos de dados independentes em instâncias separadas, em vez de restaurá-los na mesma instância. Para obter mais informações, consulte as práticas recomendadas neste guia.
+ **Servidor de banco de dados grande, mas pequenas tabelas de banco de dados individuais** — Essa é uma boa abordagem quando o tamanho total do servidor de banco de dados é múltiplo TBs , mas o tamanho de cada tabela de banco de dados independente é menor que 1 TB. Para reduzir o período geral de migração, você pode migrar tabelas independentes individualmente.
Vamos usar um exemplo de um único banco de dados de usuário de 1 TB e ele é o único banco de dados em um servidor de banco de dados on-premises. Há dez tabelas no banco de dados, e cada uma tem 100 GB. Você pode fazer backups de cada tabela individual separadamente. Ao restaurar o backup, você pode restaurar todas as tabelas em uma instância em paralelo.
+ **Um banco de dados contém tabelas de workloads transacionais e não transacionais**: semelhante ao caso de uso anterior, você pode usar uma abordagem de backup dividido quando você tem tabelas de workloads transacionais e não transacionais no mesmo banco de dados.
Vamos usar um exemplo de um banco de dados de 2 TB que consiste em 0,5 TB de tabelas de workloads críticas usadas para processamento de transações on-line (OLTP) e uma única tabela de 1,5 TB usada para arquivar dados antigos. Você pode fazer o backup de todos os objetos do banco de dados, exceto da tabela de arquivamento, como um backup consistente e de transação única. Em seguida, você faz outro backup separado somente da tabela de arquivamento. Para o backup da tabela de arquivamento, você também pode considerar fazer vários backups paralelos usando condições para dividir o número de linhas no arquivo de backup. Este é um exemplo:
```
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
```
Ao restaurar os arquivos de backup, você pode restaurar o backup da workload transacional e o backup da tabela de arquivamento em paralelo.
+ **Limitações de recursos computacionais**: se você tiver recursos computacionais limitados no servidor on-premises, como CPU, memória ou E/S de disco, isso pode afetar a estabilidade e a performance ao fazer o backup. Em vez de fazer um backup completo, você pode dividi-lo em partes.
Por exemplo, um servidor de produção on-premises pode estar sobrecarregado com workloads e ter recursos de CPU limitados. Se você fizer um backup de execução única de um banco de dados de vários terabytes nesse servidor, ele poderá consumir recursos adicionais da CPU e afetar adversamente o servidor de produção. Em vez de fazer o backup completo do banco de dados, divida o backup em várias partes, como duas a três tabelas cada.