# Migrar dados para um cluster de banco de dados do Amazon Aurora MySQL Você tem várias opções para migrar dados do seu banco de dados existente para um cluster de banco de dados MySQL do Amazon Aurora. Suas opções de migração também dependem do banco de dados do qual você está migrando e do tamanho dos dados que você está migrando. Existem dois tipos diferentes de migração: física e lógica. A migração física significa que as cópias físicas dos arquivos de banco de dados serão usadas para migrar o banco de dados. A migração lógica significa que a migração será realizada aplicando mudanças de banco de dados lógicas, como inserções, atualizações e exclusões. A migração física tem as seguintes vantagens: + A migração física é mais rápida do que a migração lógica, especialmente para grandes bancos de dados. + O performance do banco de dados não é afetado quando um backup é feito por migração física. + A migração física pode migrar tudo no banco de dados de origem, incluindo componentes de banco de dados complexos. A migração física tem as seguintes limitações: + O parâmetro `innodb_page_size` precisa ser definido com o valor padrão (`16KB`). + O parâmetro `innodb_data_file_path` deve ser configurado com apenas um arquivo de dados que usa o nome de arquivo de dados padrão `"ibdata1:12M:autoextend"`. Bancos de dados com dois arquivos de dados ou com um arquivo de dados com um nome diferente não podem ser migrados usando esse método. Veja a seguir, exemplos de nomes de arquivos que não são permitidos: `"innodb_data_file_path=ibdata1:50M; ibdata2:50M:autoextend"` e `"innodb_data_file_path=ibdata01:50M:autoextend"`. + O parâmetro `innodb_log_files_in_group` precisa ser definido com o valor padrão (`2`). A migração lógica tem as seguintes vantagens: + Você pode migrar subconjuntos do banco de dados, como tabelas específicas ou partes de uma tabela. + Os dados podem ser migrados independentemente da estrutura de armazenamento físico. A migração lógica tem as seguintes limitações: + Geralmente, a migração lógica é mais lenta do que a migração física. + Os componentes complexos do banco de dados podem atrasar o processo de migração lógica. Em alguns casos, os componentes complexos do banco de dados podem até bloquear a migração lógica. A tabela a seguir detalha as opções disponíveis e o tipo de migração para cada uma delas. | Migrar a partir de | Migration type | Solução | | --- | --- | --- | | Uma instância de banco de dados RDS for MySQL | Físico | É possível migrar de uma instância de banco de dados RDS for MySQL criando antes uma réplica de leitura do Aurora MySQL de uma instância de banco de dados MySQL. Quando o atraso da réplica entre a instância de banco de dados MySQL e a réplica de leitura do Aurora MySQL é 0, você pode direcionar seus aplicativos clientes para leitura da réplica de leitura do Aurora e interromper a replicação, a fim de que a réplica de leitura do Aurora MySQL se torne um cluster de banco de dados autônomo do Aurora MySQL para leitura e gravação. Para obter mais detalhes, consulte [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md). | | Um snapshot de banco de dados RDS for MySQL | Físico | Você pode migrar dados diretamente de um snapshot de banco de dados RDS for MySQL para um cluster de banco de dados do Amazon Aurora MySQL. Para obter mais detalhes, consulte [Migrar de um snapshot do RDS for MySQL para o Aurora](AuroraMySQL.Migrating.RDSMySQL.Snapshot.md). | | Um banco de dados MySQL externo para o Amazon RDS | Lógico | Você pode criar um despejo dos seus dados usando o utilitário `mysqldump` e importando os dados para um cluster existente de banco de dados do Amazon Aurora MySQL. Para obter mais detalhes, consulte [Migração lógica do MySQL para o Amazon Aurora MySQL usando o mysqldump](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md). Para exportar metadados para usuários de banco de dados durante a migração de um banco de dados externo do MySQL, também é possível usar um comando do MySQL Shell em vez de `mysqldump`. Consulte mais informações em [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about). O utilitário [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) foi descontinuado desde o MySQL 8.0.34. | | Um banco de dados MySQL externo para o Amazon RDS | Físico | Você pode copiar arquivos de backup do seu banco de dados em um bucket do Amazon Simple Storage Service (Amazon S3) e restaurar um cluster de banco de dados do Amazon Aurora MySQL desses arquivos. Essa opção pode ser considerada mais rápida do que migrar dados usando `mysqldump`. Para obter mais detalhes, consulte [Migração física do MySQL usando o Percona XtraBackup e o Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md). | | Um banco de dados MySQL externo para o Amazon RDS | Lógico | Você pode economizar dados do banco de dados como arquivos de texto e copiar esses arquivos para um bucket do Amazon S3. Em seguida, você pode carregar os dados para um cluster existente de banco de dados do Aurora MySQL usando o comando `LOAD DATA FROM S3` do MySQL. Para ter mais informações, consulte [Carregar dados em um cluster de banco de dados do Amazon Aurora MySQL a partir de arquivos de texto em um bucket do Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). | | Um banco de dados que não compatível com MySQL | Lógico | Você pode usar AWS Database Migration Service (AWS DMS) para migrar dados de um banco de dados incompatível com MySQL. Para obter mais informações sobre o AWS DMS, consulte [O que é o serviço de migração de banco de dados da AWS?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) | **nota** Se você estiver migrando um banco de dados externo do MySQL para o Amazon RDS, as opções de migração descritas na tabela serão aceitas somente se seu banco de dados for compatível os espaços de tabela do InnoDB ou MyISAM. Se o banco de dados MySQL que você está migrando para o Aurora MySQL usar `memcached`, remova o `memcached` antes de migrá-lo. Não é possível migrar de algumas versões anteriores a 8.0 do MySQL para o Aurora MySQL 3.05, incluindo 8.0.11, 8.0.13 e 8.0.15. Recomendamos que você atualize para a versão 8.0.28 do MySQL antes da migração. # Migrar dados de um banco de dados MySQL externo para um cluster de banco de dados do Amazon Aurora MySQL Se o seu banco de dados é compatível com tablespaces InnoDB ou MyISAM, estas são as opções para migrar os dados para um cluster de banco de dados Amazon Aurora MySQL: + Você pode criar um despejo dos seus dados usando o utilitário `mysqldump` e importando os dados para um cluster existente de banco de dados do Amazon Aurora MySQL. Para obter mais informações, consulte [Migração lógica do MySQL para o Amazon Aurora MySQL usando o mysqldump](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md). + Você pode copiar arquivos de backup completos e incrementais do banco de dados para um bucket do Amazon S3 e restaurar para um cluster de banco de dados do Amazon Aurora MySQL usando esses arquivos. Essa opção pode ser considerada mais rápida do que migrar dados usando `mysqldump`. Para obter mais informações, consulte [Migração física do MySQL usando o Percona XtraBackup e o Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md). **Topics** + [Migração física do MySQL usando o Percona XtraBackup e o Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md) + [Migração lógica do MySQL para o Amazon Aurora MySQL usando o mysqldump](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md) # Migração física do MySQL usando o Percona XtraBackup e o Amazon S3 Você pode copiar os arquivos de backup completos e incrementais do banco de dados MySQL de origem, versão 5.7 ou 8.0, para um bucket do Amazon S3. Em seguida, você pode restaurar para um cluster de banco de dados do Amazon Aurora MySQL com a mesma versão principal do mecanismo de banco de dados desses arquivos. Essa opção pode ser considerada mais rápida do que migrar dados usando `mysqldump`, pois o uso de `mysqldump` repete todos os comandos para recriar o esquema e os dados do seu banco de dados de origem no novo cluster de banco de dados Aurora MySQL. Ao copiar os arquivos de dados de origem MySQL, o Aurora MySQL pode usá-los imediatamente como dados para um cluster de banco de dados do Aurora MySQL. Você pode também minimizar o tempo de inatividade usando a replicação de log binário durante o processo de migração. Se você usar a replicação de log binário, ao banco de dados externo de MySQL permanece aberta para transações enquanto os dados estão sendo migrados para o cluster de banco de dados Aurora MySQL. Depois do cluster de banco de dados do Aurora MySQL ter sido criado, você usa a replicação de log binário para sincronizar o cluster de banco de dados do Aurora MySQL com as transações que aconteceram depois do backup. Quando o cluster de banco de dados do Aurora MySQL é acessado com o banco de dados do MySQL, você conclui a migração trocando completamente para o cluster de banco de dados do Aurora MySQL para novas transações. Para obter mais informações, consulte [Sincronizar o cluster do banco de dados do Amazon Aurora MySQL com banco de dados MySQL usando a replicação](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync). **Contents** + [Limitações e considerações](#AuroraMySQL.Migrating.ExtMySQL.S3.Limits) + [Antes de começar](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs) + [Instalação do Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.XtraBackup) + [Permissões obrigatórias](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.Permitting) + [Criar a função de serviço do IAM](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.CreateRole) + [Fazer backup de arquivos a serem restaurados como um cluster de banco de dados do Amazon Aurora MySQL](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup) + [Criar um backup completo com o Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Full) + [Usar backups incrementais com o Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Incr) + [Considerações sobre backup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Considerations) + [Restaurar um cluster de banco de dados do Amazon Aurora MySQL de um bucket do Amazon S3](#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) + [Sincronizar o cluster do banco de dados do Amazon Aurora MySQL com banco de dados MySQL usando a replicação](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) + [Configurar seu banco de dados MySQL externo e seu cluster de banco de dados do Aurora MySQL para replicação criptografada](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.ConfigureEncryption) + [Sincronizar o cluster de banco de dados do Amazon Aurora MySQL com o banco de dados MySQL externo](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing) + [Reduzir o tempo de migração física para o Amazon Aurora MySQL](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md) + [Tipos de tabela não compatíveis](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Tables) + [Contas de usuário com privilégios não compatíveis](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Users) + [Privilégios dinâmicos no Aurora MySQL versão 3](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Dynamic) + [Objetos armazenados com ‘rdsadmin'@'localhost’ como definidor](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Objects) ## Limitações e considerações As limitações e considerações a seguir se aplicam à restauração para um cluster de banco de dados do Amazon Aurora MySQL usando um bucket do Amazon S3: + Você pode migrar os dados somente para um novo cluster de banco de dados e não para um cluster existente. + Use o Percona XtraBackup para fazer backup de dados no S3. Para obter mais informações, consulte [Instalação do Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.XtraBackup). + O bucket do Amazon S3 e o cluster de banco de dados do Aurora MySQL devem estar localizados na mesma região da AWS. + Não é possível restaurar nos seguintes casos: + De uma exportação de snapshot de cluster de banco de dados para o Amazon S3. Também não é possível migrar dados de uma exportação de snapshot de cluster de banco de dados para o bucket do S3. + De um banco de dados de origem criptografado. Mas é possível criptografar os dados que estão sendo migrados. Também é possível deixar os dados não criptografados durante o processo de migração. + De um banco de dados MySQL 5.5 ou 5.6. + O Percona Server para MySQL não é aceito como banco de dados de origem porque ele pode conter tabelas `compression_dictionary*` no esquema `mysql`. + Não é possível realizar uma restauração para um cluster de banco de dados do Aurora Serverless. + A reversão de migrações não é uma operação compatível com versões principais nem com secundárias. Por exemplo, não é possível migrar do MySQL versão 8.0 para o Aurora MySQL versão 2 (compatível com o MySQL 5.7) nem do MySQL versão 8.0.32 para o Aurora MySQL versão 3.03, que é compatível com a versão 8.0.26 da comunidade do MySQL. + Não é possível migrar de algumas versões anteriores a 8.0 do MySQL para o Aurora MySQL 3.05, incluindo 8.0.11, 8.0.13 e 8.0.15. Recomendamos que você atualize para a versão 8.0.28 do MySQL antes da migração. + Não é possível fazer importações do Amazon S3 na classe de instância de banco de dados db.t2.micro. Contudo, é possível restaurar para outra classe de instância de banco de dados e alterar a instância de banco de dados posteriormente. Para ter mais informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md). + O Amazon S3 limita o tamanho de um arquivo carregado para um bucket do S3 a 5 TB. Se um arquivo de backup exceder 5 TB, você deverá dividi o arquivo de backup em arquivos menores. + O Amazon RDS limita a 1 milhão o número de arquivos carregados para um bucket do S3. Se os dados de backup do banco de dados, incluindo todos os backups completos e incrementais, exceder 1 milhão de arquivos, use um arquivo Gzip (.gz), tar (.tar.gz) ou Percona xbstream (.xbstream) para armazenar arquivos de backup completos e incrementais no bucket do S3. O Percona XtraBackup 8.0 oferece suporte apenas ao Percona xbstream para compactação. + Para fornecer serviços de gerenciamento para cada cluster de banco de dados, o usuário `rdsadmin` é criado quando o cluster de banco de dados é criado. Como esse é um usuário reservado no RDS, as seguintes limitações se aplicam: + Funções, procedimentos, visualizações, eventos e acionadores com o `'rdsadmin'@'localhost'` como definidor não são importados. Para obter mais informações, consulte [Objetos armazenados com ‘rdsadmin'@'localhost’ como definidor](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Objects) e [Privilégios de usuário mestre com Amazon Aurora MySQL.](AuroraMySQL.Security.md#AuroraMySQL.Security.MasterUser). + Quando o cluster de banco de dados do Aurora MySQL é criado, um usuário principal é criado com os privilégios máximos aceitos. Na restauração por meio de backup, quaisquer privilégios incompatíveis atribuídos aos usuários que estão sendo importados são removidos automaticamente durante a importação. Para identificar usuários que possam ser afetados por isso, consulte[Contas de usuário com privilégios não compatíveis](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Users). Para obter mais informações sobre privilégios compatíveis no Aurora MySQL, consulte [Modelo de privilégios baseados em funções](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). + No Aurora MySQL versão 3, os privilégios dinâmicos não são importados. Os privilégios dinâmicos aceitos pelo Aurora podem ser importados após a migração. Para obter mais informações, consulte [Privilégios dinâmicos no Aurora MySQL versão 3](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Dynamic). + Tabelas criadas pelo usuário no esquema do `mysql` não são migradas. + O parâmetro `innodb_data_file_path` deve ser configurado com apenas um arquivo de dados que usa o nome de arquivo de dados padrão `ibdata1:12M:autoextend`. Bancos de dados com dois arquivos de dados ou com um arquivo de dados com um nome diferente não podem ser migrados usando esse método. Veja a seguir, exemplos de nomes de arquivos que não são permitidos: `innodb_data_file_path=ibdata1:50M`, `ibdata2:50M:autoextend` e `innodb_data_file_path=ibdata01:50M:autoextend`. + Não é possível migrar de um banco de dados de origem que tenha tabelas definidas fora do diretório de dados MySQL padrão. + No momento, o tamanho máximo aceito para backups não compactados usando esse método é 64 TiB. Para backups compactados, esse limite é menor para levar em conta os requisitos de espaço sem compactação. Nesses casos, o tamanho máximo de backup aceito seria `64 TiB – compressed backup size`. + O Aurora MySQL não é compatível com a importação do MySQL e de outros componentes e plug-ins externos. + O Aurora MySQL não restaura tudo do seu banco de dados. Recomendamos salvar o esquema do banco de dados e os valores dos itens do banco de dados MySQL de origem relacionados abaixo e adicioná-los ao cluster de banco de dados do Aurora MySQL restaurado depois que ele for criado: + Contas de usuário + Funções + Procedimentos armazenados + Informações de fuso horário. As informações de fuso horário são carregadas do sistema operacional local do cluster de banco de dados do Aurora MySQL. Para obter mais informações, consulte [Fuso horário local para os clusters de bancos de dados Amazon Aurora](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone). ## Antes de começar Antes de copiar os dados para um bucket do Amazon S3 e restaurar um cluster de banco de dados desses arquivos, faça o seguinte: + Instale o Percona XtraBackup no seu servidor local. + Permita que o Aurora MySQL acesse o seu bucket do Amazon S3 em seu nome. ### Instalação do Percona XtraBackup O Amazon Aurora pode restaurar um cluster de banco de dados a partir de arquivos criados com o Percona XtraBackup. Você pode instalar o Percona XtraBackup em [Software Downloads - Percona](https://www.percona.com/downloads). Para migração do MySQL 5.7, use o Percona XtraBackup 2.4. Para migração do MySQL 8.0, use o Percona XtraBackup 8.0. Verifique se a versão do Percona XtraBackup é compatível com a versão do mecanismo do banco de dados de origem. ### Permissões obrigatórias Para migrar os dados do MySQL para um cluster de banco de dados do Amazon Aurora MySQL, são necessárias várias permissões: + O usuário que está solicitando que o Aurora crie um novo cluster de um bucket do Amazon S3 deve ter permissão para listar os buckets da sua conta da AWS. Você concede essa permissão ao usuário usando uma política do AWS Identity and Access Management (IAM). + O Aurora exige permissão para atuar em seu nome e acessar o bucket do Amazon S3 em que você armazena os arquivos usados para criar o cluster de banco de dados do Amazon Aurora MySQL. Conceda ao Aurora as permissões necessárias usando uma função de serviço do IAM. + O usuário que faz a solicitação também deve ter permissão para indicar as funções do IAM de sua conta da AWS. + Se o usuário que faz a solicitação for criar a função de serviço do IAM ou solicitar que o Aurora crie a função de serviço do IAM (usando o console), ele deverá ter permissão para criar uma função do IAM para sua conta da AWS. + Se você pretende criptografar os dados durante o processo de migração, atualize a política do IAM do usuário responsável pela migração para conceder acesso do RDS às AWS KMS keys usadas para criptografar os backups. Para instruções, consulte [Criar uma política do IAM para acessar recursos do AWS KMS](AuroraMySQL.Integrating.Authorizing.IAM.KMSCreatePolicy.md). Por exemplo, a política do IAM a seguir concede a um usuário as permissões mínimas exigidas para usar o console para listar funções do IAM, criar uma função do IAM, listar os buckets do Amazon S3 para a sua conta e listar as chaves do KMS. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListRoles", "iam:CreateRole", "iam:CreatePolicy", "iam:AttachRolePolicy", "s3:ListBucket", "kms:ListKeys" ], "Resource": "*" } ] } ``` ------ Além disso, para um usuário associar uma função do IAM a um bucket do Amazon S3, o usuário do IAM deve ter a permissão `iam:PassRole` para aquela função do IAM. Essa permissão autoriza que um administrador restrinja as funções do IAM que um usuário pode associar a buckets do Amazon S3. Por exemplo, a seguinte política do IAM permite que um usuário associe a função chamada `S3Access` a um bucket do Amazon S3. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowS3AccessRole", "Effect":"Allow", "Action":"iam:PassRole", "Resource":"arn:aws:iam::123456789012:role/S3Access" } ] } ``` ------ Para obter mais informações sobre as permissões de usuário do IAM, consulte [Gerenciamento do acesso usando políticas](UsingWithRDS.IAM.md#security_iam_access-manage). ### Criar a função de serviço do IAM Para solicitar que o Console de gerenciamento da AWS crie uma função para você, selecione a opção **Create a New Role (Criar uma nova função)** (mostrada posteriormente neste tópico). Se você selecionar essa opção e especificar um nome para a nova função, o Aurora criará a função de serviço do IAM necessária para o Aurora acessar o bucket do Amazon S3 com o nome fornecido. Você também pode criar a função manualmente usando o procedimento seguinte. **Como criar uma função do IAM para o Aurora acessar o Amazon S3** 1. Siga as etapas em [Criar uma política do IAM para acessar recursos do Amazon S3](AuroraMySQL.Integrating.Authorizing.IAM.S3CreatePolicy.md). 1. Siga as etapas em [Criar uma função do IAM para permitir que o Amazon Aurora acesse produtos da AWS](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md). 1. Siga as etapas em [Associar uma função do IAM a um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md). ## Fazer backup de arquivos a serem restaurados como um cluster de banco de dados do Amazon Aurora MySQL Você pode criar um backup completo de seus arquivos de banco de dados MySQL usando o Percona XtraBackup e fazer upload dos arquivos de backup em um bucket do Amazon S3. Ou, se você já usa o Percona XtraBackup para fazer o backup dos arquivos do banco de dados MySQL, pode fazer upload dos arquivos e diretórios de backup completos e incrementais em um bucket do Amazon S3. **Topics** + [Criar um backup completo com o Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Full) + [Usar backups incrementais com o Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Incr) + [Considerações sobre backup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Considerations) ### Criar um backup completo com o Percona XtraBackup Para criar um backup completo dos arquivos do banco de dados MySQL que podem ser restaurados do Amazon S3 para criar um cluster de banco de dados do Aurora MySQL, use o utilitário Percona XtraBackup (`xtrabackup`) para fazer backup do banco de dados. Por exemplo, o seguinte comando cria um backup de um banco de dados MySQL e armazena os arquivos na pasta `/on-premises/s3-restore/backup`. ``` xtrabackup --backup --user= --password= --target-dir= ``` Se você deseja compactar o backup em um único arquivo (que pode ser dividido, se necessário), use a opção `--stream` para salvar o backup em um dos seguintes formatos: + Gzip (.gz) + tar (.tar) + Percona xbstream (.xbstream) O comando a seguir cria um backup do seu banco de dados MySQL dividido em vários arquivos Gzip. ``` xtrabackup --backup --user= --password= --stream=tar \ --target-dir= | gzip - | split -d --bytes=500MB \ - .tar.gz ``` O comando a seguir cria um backup do seu banco de dados MySQL dividido em vários arquivos tar. ``` xtrabackup --backup --user= --password= --stream=tar \ --target-dir= | split -d --bytes=500MB \ - .tar ``` O comando a seguir cria um backup do seu banco de dados MySQL dividido em vários arquivos xbstream. ``` xtrabackup --backup --user= --password= --stream=xbstream \ --target-dir= | split -d --bytes=500MB \ - .xbstream ``` **nota** Se você vir o erro a seguir, saiba que ele pode ser causado pela mistura de formatos de arquivo em seu comando: ``` ERROR:/bin/tar: This does not look like a tar archive ``` Após fazer o backup do seu banco de dados MySQL usando o utilitário Percona XtraBackup, você poderá copiar os arquivos e diretórios de backup para um bucket do Amazon S3. Para obter informações sobre a criação e o upload de um arquivo para um bucket do Amazon S3, consulte [Conceitos básicos do Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html), no *Guia de conceitos básicos do Amazon S3*. ### Usar backups incrementais com o Percona XtraBackup O Amazon Aurora MySQL oferece suporte a backups completos e incrementais criados com o Percona XtraBackup. Se você já usa o Percona XtraBackup para fazer backups completos e incrementais de seus arquivos de banco de dados MySQL, não precisa criar um backup completo e fazer upload dos arquivos de backup no Amazon S3. Em vez disso, você pode economizar muito tempo copiando os diretórios e arquivos de backup existentes para seus backups completos e incrementais para um bucket do Amazon S3. Para obter mais informações, consulte [Create an incremental backup](https://docs.percona.com/percona-xtrabackup/8.0/create-incremental-backup.html) no site da Percona. Quando copiar os arquivos existentes de backup completo e incremental para um bucket do Amazon S3, copie recursivamente o conteúdo do diretório de base. Esse conteúdo inclui o backup completo e também todo o backup incremental dos diretórios e arquivos. Essa cópia deve preservar a estrutura de diretórios no bucket do Amazon S3. O Aurora percorre todos os arquivos e diretórios. O Aurora usa o arquivo `xtrabackup-checkpoints` incluído em cada backup incremental para identificar o diretório de base e ordenar os backups incrementais por intervalo de número de sequência de log (LSN). Para obter informações sobre a criação e o upload de um arquivo para um bucket do Amazon S3, consulte [Conceitos básicos do Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html), no *Guia de conceitos básicos do Amazon S3*. ### Considerações sobre backup O Aurora não oferece suporte a backups parciais criados com o Percona XtraBackup. Você não pode usar as seguintes opções para criar um backup parcial quando faz backup dos arquivos de origem de seu banco de dados: `--tables`, `--tables-exclude`, `--tables-file`, `--databases`, `--databases-exclude` ou `--databases-file`. Para ter mais informações sobre como fazer backup do banco de dados com o Percona XtraBackup, consulte [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html) e [Work with binary logs](https://docs.percona.com/percona-xtrabackup/8.0/working-with-binary-logs.html) no site da Percona. O Aurora oferece suporte a backups incrementais criados com o Percona XtraBackup. Para obter mais informações, consulte [Create an incremental backup](https://docs.percona.com/percona-xtrabackup/8.0/create-incremental-backup.html) no site da Percona. O Aurora consome seus arquivos de backup com base no nome do arquivo. Renomeie seus arquivos de backup com a extensão de arquivo apropriada com base no formato do arquivo — por exemplo, `.xbstream` para arquivos armazenados usando o formato Percona xbstream. O Aurora consome os arquivos de backup em ordem alfabética assim como na ordem numérica natural. Sempre use a opção `split` ao emitir o comando `xtrabackup` para garantir que os arquivos de backup sejam gravados e nomeados na ordem apropriada. O Amazon S3 limita o tamanho de um arquivo carregado para um bucket do Amazon S3 a 5 TB. Se os dados de backup do seu banco de dados ultrapassarem 5 TB, use o comando `split` para dividir os arquivos de backup em vários arquivos com menos de 5 TB cada. O Aurora limita a 1 milhão o número de arquivos de origem enviados por upload para um bucket do Amazon S3. Em alguns casos, os dados de backup de seu banco de dados, incluindo todos os backups completos e incrementais, podem aumentar para um grande número de arquivos. Nesses casos, use um arquivo de tarball (.tar.gz) para armazenar arquivos completos e incrementais de backup no bucket Amazon S3. Quando você carrega um arquivo no bucket Amazon S3, você pode usar criptografia por parte do servidor para criptografar os dados. Então você pode restaurar o cluster de banco de dados do Amazon Aurora MySQL a partir desses arquivos criptografados. O Amazon Aurora MySQL pode restaurar um cluster de banco de dados com arquivos criptografados usando os seguintes tipos de criptografia do lado do servidor: + Criptografia de servidor com chaves gerenciadas pelo Amazon S3 (SSE-S3) – cada objeto é criptografado com uma chave única empregando uma criptografia multifator forte. + Criptografia do lado do servidor com chaves gerenciadas pelo AWS KMS (SSE-KMS): semelhante à SSE-S3, mas com a opção de você mesmo criar e gerenciar chaves de criptografia, além de outras diferenças. Para obter informações sobre como usar a criptografia do lado do servidor ao carregar arquivos para um bucket do Amazon S3, consulte [Proteger dados usando a criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) no *Guia de desenvolvedor do Amazon S3*. ## Restaurar um cluster de banco de dados do Amazon Aurora MySQL de um bucket do Amazon S3 É possível restaurar os arquivos de backup do bucket do Amazon S3 para criar um novo cluster de banco de dados do Amazon Aurora MySQL usando o console do Amazon RDS. **Para restaurar um cluster de banco de dados do Amazon Aurora MySQL a partir de arquivos em um bucket do Amazon S3** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No canto superior direito do console do console do Amazon RDS, escolha a região da AWS na qual deseja criar o cluster de banco de dados. Escolha o mesmo nome da região da AWS que o bucket Amazon S3 que contém o backup do banco de dados. 1. No painel de navegação, escolha **Databases (Bancos de dados)** e depois escolha **Restore from S3 (Restaurar de S3)**. 1. Escolha **Restore from S3 (Restaurar do S3)**. A página **Create database by restoring from S3 (Criar banco de dados restaurando a partir do S3)** é exibida. ![\[A página onde você especifica os detalhes para restaurar um cluster de banco de dados a partir do S3\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/AuroraMigrateS3_01.png) 1. Em **S3 destination (destino do S3)**: 1. Escolha o **bucket do S3** que contém seus arquivos backup. 1. (Opcional) Em **S3 folder path prefix (Prefixo do caminho da pasta do S3)**, digite um prefixo de caminho de arquivo para os arquivos armazenados no bucket do Amazon S3. Se você não especificar um prefixo, o RDS criará a instância de banco de dados usando todos os arquivos e as pastas na pasta raiz do bucket do S3. Se você especificar um prefixo, o RDS criará a instância de banco de dados usando os arquivos e as pastas no bucket do S3 no qual o caminho para o arquivo começa com o prefixo especificado. Por exemplo, suponha que você armazene seus arquivos de backup no S3 em uma subpasta denominada backups e que você tenha vários conjuntos de arquivos de backup, cada um em seu próprio diretório (gzip\$1backup1, gzip\$1backup2 e assim por diante). Nesse caso, especifique um prefixo de backups/gzip\$1backup1 para restaurar dos arquivos na pasta gzip\$1backup1. 1. Em **Engine options (Opções de mecanismo)**: 1. Para **Engine type (Tipo de mecanismo)**, escolha **Amazon Aurora**. 1. Em **Version (Versão)**, escolha a versão do Aurora MySQL mecanismo para sua instância de banco de dados restaurada. 1. Para **IAM role (Função do IAM)**, é possível escolher uma função existente do IAM. 1. (Opcional) Você também pode ter uma nova função do IAM escolhendo **Create a New Role (Criar uma nova função)**. Em caso afirmativo: 1. Insira o **IAM role name (Nome da função do IAM)**. 1. Escolha se deseja **Allow access to KMS key (Permitir acesso à chave do KMS)**: + Se você não criptografou os arquivos de backup, escolha **No** (Não). + Se você criptografou os arquivos de backup com AES-256 (SSE-S3) ao fazer upload para o Amazon S3, escolha **No (Não)**. Nesse caso, os dados são descriptografados automaticamente. + Se você criptografou os arquivos de backup com criptografia do lado do servidor do AWS KMS (SSE-KMS) ao fazer upload para o Amazon S3, escolha **Yes** (Sim). A seguir, escolha a chave do KMS correta para **AWS KMS key**. O Console de gerenciamento da AWS cria uma política do IAM que habilita o Aurora para descriptografar os dados. Para obter mais informações, consulte [Proteger dados usando criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) no *Guia do desenvolvedor do Amazon S3*. 1. Escolha configurações para o cluster de banco de dados, como a configuração do armazenamento do cluster de banco de dados, a classe de instância de banco de dados, o identificador do cluster de banco de dados e as credenciais de login. Para obter informações sobre cada configuração, consulte [Configurações de clusters de bancos de dados do Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). 1. Personalize configurações adicionais para o cluster de banco de dados do Aurora MySQL conforme necessário. 1. Escolha **Create database (Criar banco de dados)** para executar sua instância de banco de dados de Aurora. No console do Amazon RDS, a nova instância de banco de dados é exibida na lista de instâncias de banco de dados. A instância de banco de dados fica com o status **creating (criando)** até que esteja criada e pronta para uso. Quando o status for alterado para **available**, você poderá se conectar à instância primária do seu cluster de banco de dados. Dependendo da classe da instância de banco de dados e do armazenamento alocado, pode levar alguns minutos até que a nova instância fique disponível. Para visualizar o cluster recém-criado, escolha a visualização **Databases (Bancos de dados)** no console do Amazon RDS e escolha o cluster de banco de dados. Para obter mais informações, consulte [Visualizar um cluster de bancos de dados Amazon Aurora](accessing-monitoring.md#Aurora.Viewing). ![\[Lista de instâncias de banco de dados do Amazon Aurora\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/AuroraLaunch04.png) Anote a porta e o endpoint do gravador do cluster do banco de dados. Use o endpoint do gravador e a porta do cluster do banco de dados em suas strings de conexão JDBC e ODBC para qualquer aplicativo que realize operações de gravação ou leitura. ## Sincronizar o cluster do banco de dados do Amazon Aurora MySQL com banco de dados MySQL usando a replicação Para alcançar pouco ou quase nenhum tempo de inatividade durante a migração, você pode replicar transações que foram confirmadas em seu banco de dados do MySQL para seu cluster de banco de dados do Aurora MySQL. A replicação permite que o cluster do banco de dados recupere as transações no banco de dados do MySQL que aconteceram durante a migração. Quando o cluster do banco de dados é completamente recuperado, você pode interromper a replicação e terminar a migração para Aurora MySQL. **Topics** + [Configurar seu banco de dados MySQL externo e seu cluster de banco de dados do Aurora MySQL para replicação criptografada](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.ConfigureEncryption) + [Sincronizar o cluster de banco de dados do Amazon Aurora MySQL com o banco de dados MySQL externo](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing) ### Configurar seu banco de dados MySQL externo e seu cluster de banco de dados do Aurora MySQL para replicação criptografada Para replicar dados de forma segura, você pode usar a replicação criptografada. **nota** Se você não precisar usar a replicação criptografada, você pode passar essas etapas e seguir para as instruções em [Sincronizar o cluster de banco de dados do Amazon Aurora MySQL com o banco de dados MySQL externo](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing). Veja a seguir os pré-requisitos para usar a replicação criptografada: + O Secure Sockets Layer (SSL) deve ser habilitado no banco de dados primário do MySQL. + Uma chave e certificado de cliente devem estar preparados para o cluster do banco de dados do Aurora MySQL. Durante a replicação criptografada, o cluster do banco de dados de Aurora MySQL age como um cliente para o servidor de banco de dados do MySQL. Os certificados e chaves do cliente Aurora MySQL estão nos arquivos em formato .pem. **Para configurar seu banco de dados MySQL externo e seu cluster de banco de dados do Aurora MySQL para replicação criptografada** 1. Certifique-se de que você estará preparado para a replicação criptografada: + Se você não tem o SSL habilitado no banco de dados primário externo do MySQL e não tem uma chave de cliente e um certificado de cliente preparados, habilite o SSL no servidor de banco de dados MySQL e gere a chave de cliente e o certificado de cliente necessários. + Se o SSL estiver habilitado no primário externo, forneça uma chave e um certificado de cliente para o cluster de banco de dados do Aurora MySQL. Se você não os tiver, gere uma nova chave e certificado para o cluster de banco de dados do Aurora MySQL. Para assinar o certificado de cliente, é necessário ter a chave de autoridade de certificado usada para configurar o SSL no banco de dados primário externo do MySQL. Para obter mais informações, consulte [Creating SSL certificates and keys using openssl](https://dev.mysql.com/doc/refman/5.6/en/creating-ssl-files-using-openssl.html) na documentação do MySQL. Você precisa do certificado de autoridade de certificação, a chave do cliente e o certificado do cliente. 1. Conecte-se ao cluster de banco de dados do Aurora MySQL como o usuário primário usando SSL. Para obter informações sobre como se conectar ao cluster de banco de dados do Aurora MySQL com SSL, consulte [Conexões do TLS com clusters de banco de dados do Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). 1. Execute o procedimento armazenado [mysql.rds\$1import\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) para importar as informações de SSL para o cluster de banco de dados do Aurora MySQL. Para o parâmetro `ssl_material_value`, insira as informações dos arquivos em formato .pem no cluster de banco de dados do Aurora MySQL, na carga JSON correta. O exemplo a seguir importa informações SSL em um cluster de banco de dados Aurora MySQL. Em arquivos de formato .pem, o código do corpo geralmente é maior que o código de corpo exibido no exemplo. ``` call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}'); ``` Para obter mais informações, consulte [mysql.rds\$1import\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) e [Conexões do TLS com clusters de banco de dados do Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). **nota** Após executar o procedimento, os segredos são armazenados em arquivos. Para apagar os arquivos posteriormente, você pode executar o procedimento armazenado [mysql.rds\$1remove\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material). ### Sincronizar o cluster de banco de dados do Amazon Aurora MySQL com o banco de dados MySQL externo Você pode sincronizar seu cluster de banco de dados do Amazon Aurora MySQL com o banco de dados de MySQL usando replicação. **Para sincronizar seu cluster de banco de dados do Aurora MySQL com o banco de dados de MySQL usando replicação** 1. Certifique-se de que o arquivo /etc/my.cnf do banco de dados MySQL externo tem as entradas relevantes. Se a replicação criptografada não for necessária, assegure-se de que o banco de dados MySQL externo é iniciado com logs binários (binlogs) habilitados e SSL desabilitado. A seguir veja as entradas relevantes no arquivo /etc/my.cnf para obter dados não criptografados. ``` log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 ``` Se a replicação criptografada for necessária, assegure-se de que o banco de dados MySQL externo é iniciado SSL e logs binários estão habilitados. As entradas no arquivo /etc/my.cnf incluem os locais de arquivos .pem para servidor de banco de dados MySQL. ``` log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Setup SSL. ssl-ca=/home/sslcerts/ca.pem ssl-cert=/home/sslcerts/server-cert.pem ssl-key=/home/sslcerts/server-key.pem ``` Você pode verificar que o SSL está habilitado com o comando a seguir. ``` mysql> show variables like 'have_ssl'; ``` Sua saída deve ser similar à seguinte. ``` +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+ | Variable_name | Value | +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+ | have_ssl | YES | +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+ 1 row in set (0.00 sec) ``` 1. Determine a posição começando do log binário até a replicação. Especifique a posição para iniciar a replicação em uma etapa posterior. **Usar o Console de gerenciamento da AWS** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, selecione **Events**. 1. Na lista **Events** (Eventos), anote a posição no evento **Recovered from Binary log filename** (Recuperado do nome de arquivo de log binário). ![\[Visualizar MySQL primário\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-mysql-rep-binary-log-position.png) **Usar o AWS CLI** Você também pode obter o nome e a posição do arquivo de log binário usando o comando [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) da AWS CLI. O seguinte mostra um exemplo de comando `describe-events`. ``` PROMPT> aws rds describe-events ``` Na saída, identifique o evento que mostra a posição do log binário. 1. Quando conectado ao banco de dados MySQL externo, crie um usuário para ser usado na replicação. Esta conta é usada unicamente para replicação e deve estar restrita ao seu domínio para melhorar a segurança. Veja um exemplo a seguir. ``` mysql> CREATE USER ''@'' IDENTIFIED BY ''; ``` O usuário requer os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE`. Concede esses privilégios ao usuário. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO ''@''; ``` Se você precisar usar replicação criptografada, exija conexões SSL para o usuário de replicação. Você pode usar o seguinte comando, por exemplo, para solicitar conexões SSL na conta de usuário ``. ``` GRANT USAGE ON *.* TO ''@'' REQUIRE SSL; ``` **nota** Se `REQUIRE SSL` não estiver incluído, a conexão de replicação pode silenciosamente cair de volta para uma conexão não criptografada. 1. No console do Amazon RDS, adicione o endereço IP do servidor que hospeda o banco de dados MySQL externo ao grupo de segurança da VPC para o cluster de banco de dados do Aurora MySQL. Para obter mais informações sobre como modificar um grupo de segurança da VPC, consulte [Grupos de segurança para a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no *Manual do usuário da Amazon Virtual Private Cloud*. Você também pode precisar configurar sua rede local para permitir conexões com o endereço IP de seu cluster de banco de dados Aurora MySQL, para que ele possa se comunicar com seu banco de dados MySQL externo. Para encontrar o endereço IP do cluster de banco de dados do Aurora MySQL, use o comando `host`. ``` host ``` O nome do host é o nome de DNS do endpoint do cluster de banco de dados Aurora MySQL. 1. Habilite a replicação de log binário executando o procedimento [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) ou [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) armazenado. Esse procedimento armazenado tem a seguinte sintaxe. ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` Para obter informações sobre os parâmetros, consulte [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) e [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source). Para `mysql_binary_log_file_name` e `mysql_binary_log_file_location`, use a posição no evento **Recovered from Binary log filename** (Recuperado do nome de arquivo de log binário) que você anotou anteriormente. Se os dados no cluster de banco de dados do Aurora MySQL não estiverem criptografados, o parâmetro `ssl_encryption` deverá ser definido como `0`. Se os dados são criptografados, o parâmetro `ssl_encryption` deve ser definido como `1`. O exemplo a seguir executa o procedimento para um cluster de banco de dados de Aurora MySQL que tem dados criptografados. ``` CALL mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'password', 'mysql-bin.000010', 120, 1); CALL mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'password', 'mysql-bin.000010', 120, 1); ``` Esse procedimento armazenado define os parâmetros que o cluster de banco de dados de Aurora MySQL usa para conectar ao banco de dados MySQL externo e ler seu log binário. Se os dados são criptografados, ele também baixa o certificado de autoridade de certificação SSL, certificado e chave de cliente ao disco local. 1. Inicie a replicação de log binário executando o procedimento armazenado[mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). ``` CALL mysql.rds_start_replication; ``` 1. Monitore a distância do cluster do banco de dados de Aurora MySQL que está atrás do banco de dados MySQL primário de replicação. Para fazer isso, conecte ao cluster de banco de dados do Aurora MySQL e execute o comando a seguir. ``` Aurora MySQL version 2: SHOW SLAVE STATUS; Aurora MySQL version 3: SHOW REPLICA STATUS; ``` Na saída do comando, o campo `Seconds Behind Master` mostra a distância o cluster de banco de dados do Aurora MySQL está em relação ao MySQL primário. Quando esse valor for `0` (zero), o cluster de banco de dados do Aurora MySQL terá alcançado o primário e você poderá movê-lo para a próxima etapa, a fim de parar a replicação. 1. Conecte-se ao banco de dados primário de replicação do MySQL e pare a replicação. Para isso, execute o procedimento [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) armazenado. ``` CALL mysql.rds_stop_replication; ``` # Reduzir o tempo de migração física para o Amazon Aurora MySQL Você pode fazer as modificações a seguir no banco de dados para acelerar o processo de migração do banco de dados para o Amazon Aurora MySQL. **Importante** Realize essas atualizações em uma cópia do banco de dados de produção, e não no banco de dados de produção em si. Em seguida, você poderá fazer backup da cópia e restaurá-la no cluster de banco de dados do Aurora MySQL para evitar interrupções no serviço no banco de dados de produção. ## Tipos de tabela não compatíveis O Aurora MySQL comporta somente o mecanismo InnoDB para tabelas de banco de dados. Se houver tabelas MyISAM no banco de dados, elas deverão ser convertidas antes da migração para o Aurora MySQL. O processo de conversão exige espaço adicional para a conversão de MyISAM para InnoDB durante o procedimento de migração. Para reduzir as chances de ficar sem espaço ou para agilizar o processo de migração, converta todas as tabelas MyISAM para tabelas InnoDB antes de migrá-las. O tamanho da tabela InnoDB resultante é equivalente ao tamanho exigido pelo Aurora MySQL para aquela tabela. Para converter uma tabela MyISAM para InnoDB, execute o seguinte comando: ``` ALTER TABLE schema.table_name engine=innodb, algorithm=copy; ``` O Aurora MySQL não comporta tabelas ou páginas compactadas (isto é, tabelas criadas com `ROW_FORMAT=COMPRESSED` ou `COMPRESSION = {"zlib"|"lz4"}`). Para reduzir as chances de ficar sem espaço ou para agilizar o processo de migração, expanda suas tabelas compactadas definindo `ROW_FORMAT` como `DEFAULT`, `COMPACT`, `DYNAMIC` ou `REDUNDANT`. Para páginas compactadas, defina `COMPRESSION="none"`. Para ter mais informações, consulte [InnoDB row formats](https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html) e [InnoDB table and page compression](https://dev.mysql.com/doc/refman/8.0/en/innodb-compression.html) na documentação do MySQL. Use o seguinte script SQL na sua instância de banco de dados MySQL existente para listar as tabelas no seu banco de dados que são MyISAM ou compactadas. ``` -- This script examines a MySQL database for conditions that block -- migrating the database into Aurora MySQL. -- It must be run from an account that has read permission for the -- INFORMATION_SCHEMA database. -- Verify that this is a supported version of MySQL. select msg as `==> Checking current version of MySQL.` from ( select 'This script should be run on MySQL version 5.6 or higher. ' + 'Earlier versions are not supported.' as msg, cast(substring_index(version(), '.', 1) as unsigned) * 100 + cast(substring_index(substring_index(version(), '.', 2), '.', -1) as unsigned) as major_minor ) as T where major_minor <> 506; -- List MyISAM and compressed tables. Include the table size. select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`, round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)" from INFORMATION_SCHEMA.TABLES where ENGINE <> 'InnoDB' and ( -- User tables TABLE_SCHEMA not in ('mysql', 'performance_schema', 'information_schema') or -- Non-standard system tables ( TABLE_SCHEMA = 'mysql' and TABLE_NAME not in ( 'columns_priv', 'db', 'event', 'func', 'general_log', 'help_category', 'help_keyword', 'help_relation', 'help_topic', 'host', 'ndb_binlog_index', 'plugin', 'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log', 'tables_priv', 'time_zone', 'time_zone_leap_second', 'time_zone_name', 'time_zone_transition', 'time_zone_transition_type', 'user' ) ) ) or ( -- Compressed tables ROW_FORMAT = 'Compressed' ); ``` ## Contas de usuário com privilégios não compatíveis As contas de usuário com privilégios não compatíveis com o Aurora MySQL são importadas sem os privilégios incompatíveis. Para ver a lista de privilégios compatíveis, consulte [Modelo de privilégios baseados em funções](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). É possível executar a consulta SQL a seguir em seu banco de dados de origem para listar as contas de usuário com privilégios incompatíveis. ``` SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'y' OR File_priv = 'y' OR Super_priv = 'y' OR Create_tablespace_priv = 'y'; ``` ## Privilégios dinâmicos no Aurora MySQL versão 3 Os privilégios dinâmicos não são importados. O Aurora MySQL versão 3 comporta os seguintes privilégios dinâmicos. ``` 'APPLICATION_PASSWORD_ADMIN', 'CONNECTION_ADMIN', 'REPLICATION_APPLIER', 'ROLE_ADMIN', 'SESSION_VARIABLES_ADMIN', 'SET_USER_ID', 'XA_RECOVER_ADMIN' ``` O script de exemplo a seguir concede os privilégios dinâmicos compatíveis com as contas de usuário no cluster de banco de dados do Aurora MySQL. ``` -- This script finds the user accounts that have Aurora MySQL supported dynamic privileges -- and grants them to corresponding user accounts in the Aurora MySQL DB cluster. /home/ec2-user/opt/mysql/8.0.26/bin/mysql -uusername -pxxxxx -P8026 -h127.0.0.1 -BNe "SELECT CONCAT('GRANT ', GRANTS, ' ON *.* TO ', GRANTEE ,';') AS grant_statement FROM (select GRANTEE, group_concat(privilege_type) AS GRANTS FROM information_schema.user_privileges WHERE privilege_type IN ( 'APPLICATION_PASSWORD_ADMIN', 'CONNECTION_ADMIN', 'REPLICATION_APPLIER', 'ROLE_ADMIN', 'SESSION_VARIABLES_ADMIN', 'SET_USER_ID', 'XA_RECOVER_ADMIN') AND GRANTEE NOT IN (\"'mysql.session'@'localhost'\",\"'mysql.infoschema'@'localhost'\",\"'mysql.sys'@'localhost'\") GROUP BY GRANTEE) AS PRIVGRANTS; " | /home/ec2-user/opt/mysql/8.0.26/bin/mysql -u master_username -p master_password -h DB_cluster_endpoint ``` ## Objetos armazenados com ‘rdsadmin'@'localhost’ como definidor Funções, procedimentos, visualizações, eventos e acionadores com `'rdsadmin'@'localhost'` como definidor não são importados. Você pode usar o script SQL a seguir, no banco de dados MySQL de origem, a fim de listar os objetos armazenados que têm o definidor incompatível. ``` -- This SQL query lists routines with `rdsadmin`@`localhost` as the definer. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE definer = 'rdsadmin@localhost'; -- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer. SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.triggers WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists events with `rdsadmin`@`localhost` as the definer. SELECT EVENT_SCHEMA, EVENT_NAME FROM information_schema.events WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists views with `rdsadmin`@`localhost` as the definer. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE DEFINER = 'rdsadmin@localhost'; ``` # Migração lógica do MySQL para o Amazon Aurora MySQL usando o mysqldump Como o Amazon Aurora MySQL é um banco de dados compatível com MySQL, você pode usar o utilitário `mysqldump` para copiar dados do banco de dados MySQL ou o utilitário `mariadb-dump` para copar os dados do banco de dados MariaDB em um cluster de banco de dados existente do Aurora MySQL. Para ver uma discussão sobre como fazer isso com bancos de dados MySQL ou MariaDB que são muito grandes, consulte os seguintes tópicos no *Guia do usuário do Amazon Relational Database Service*: + MySQL: [importar dados para um banco de dados Amazon RDS para MySQL com tempo de inatividade reduzido](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html). + MariaDB: [importar dados para um banco de dados Amazon RDS para MariaDB com tempo de inatividade reduzido](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-importing-data-reduced-downtime.html). Em relação a bancos de dados MySQL ou MariaDB que têm volumes menores de dados, consulte os seguintes tópicos no *Guia do usuário do Amazon Relational Database Service*: + MySQL: [importar dados de um banco de dados externo MySQL para uma instância de banco de dados do Amazon RDS para MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-external-database.html). + MariaDB: [importar dados de um banco de dados externo MariaDB para uma instância de banco de dados do Amazon RDS para MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-importing-data-external-database.html). # Migração de dados de um instância de banco de dados RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL. É possível migrar (copiar) dados de um cluster de banco de dados do Amazon Aurora MySQL para uma instância de banco de dados do RDS para MySQL. **Topics** + [Migrar de um snapshot do RDS for MySQL para o Aurora](AuroraMySQL.Migrating.RDSMySQL.Snapshot.md) + [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md) **nota** Como o Amazon Aurora MySQL é compatível com MySQL, você pode migrar dados do seu banco de dados MySQL configurando uma replicação entre o banco de dados MySQL e um cluster de banco de dados do Amazon Aurora MySQL. Para obter mais informações, consulte [Replicação com o Amazon Aurora](Aurora.Replication.md). # Migrar de um snapshot do RDS for MySQL para o Aurora Você pode migrar um snapshot de banco de dados de uma instância de banco de dados RDS for MySQL para criar um cluster de banco de dados Aurora MySQL. O novo cluster de banco de dados do Aurora MySQL é preenchido com os dados da instância de banco de dados RDS for MySQL original. O snapshot de banco de dados precisa ter sido criado de uma instância de banco de dados do Amazon RDS que esteja executando uma versão do MySQL compatível com o Aurora MySQL. É possível migrar um snapshot de banco de dados manual ou automático. Após a criação do cluster de banco de dados, você pode criar réplicas opcionais do Aurora. **nota** Você também pode migrar uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Aurora MySQL criando uma réplica de leitura do Aurora da sua instância de banco de dados do RDS para MySQL de origem. Para obter mais informações, consulte [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md). Não é possível migrar de algumas versões anteriores a 8.0 do MySQL para o Aurora MySQL 3.05, incluindo 8.0.11, 8.0.13 e 8.0.15. Recomendamos que você atualize para a versão 8.0.28 do MySQL antes da migração. Veja as etapas gerais que você deve seguir: 1. Determine a quantidade de espaço para provisionar ao seu cluster de banco de dados Aurora MySQL. Para obter mais informações, consulte [De quanto espaço eu preciso?](#AuroraMySQL.Migrating.RDSMySQL.Space) 1. Use o console para criar o snapshot na região da AWS em que se encontra a instância MySQL do Amazon RDS. Para obter informações sobre a criação de um snapshot de banco de dados, consulte [Criar um snapshot de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html). 1. Se o snapshot do banco de dados não estiver na mesma região da AWS que o cluster de banco de dados, use o console do Amazon RDS para copiar o snapshot do banco de dados para essa região da AWS. Para obter informações sobre a cópia de um snapshot de banco de dados, consulte [Cópia de um snapshot de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html). 1. Use o console para migrar o snapshot de banco de dados e criar um cluster de banco de dados Aurora MySQL com os mesmos bancos de dados que a instância de banco de dados MySQL original. **Atenção** O Amazon RDS limita cada conta da AWS a uma cópia de snapshot para cada região da AWS por vez. ## De quanto espaço eu preciso? Ao migrar um snapshot de uma instância de banco de dados MySQL para um cluster de banco de dados do Aurora MySQL, o Aurora usa um volume do Amazon Elastic Block Store (Amazon EBS) para formatar os dados do snapshot antes de migrá-los. Em alguns casos, um espaço adicional é necessário para formatar os dados para migração. As tabelas que não sejam MyISAM e não estejam compactadas podem ter até 16 TB de tamanho. Se você tiver tabelas MyISAM, o Aurora deverá usar espaço adicional no volume para converter as tabelas e deixá-las compatíveis com o Aurora MySQL. Se você compactar as tabelas, o Aurora deverá usar espaço adicional no volume para expandi-las antes de armazená-las no volume de cluster do Aurora. Devido a esse requisito de espaço adicional, você deve garantir que nenhuma das tabelas MyISAM e das tabelas compactadas sendo migradas da sua instância de banco de dados MySQL exceda 8 TB de tamanho. ## Reduzir a quantidade de espaço necessário para migrar dados para o Amazon Aurora MySQL Talvez você queira modificar o esquema de banco de dados antes de migrá-lo para o Amazon Aurora. Essa modificação pode ser útil nos seguintes casos: + Você deseja agilizar o processo de migração. + Você não sabe quanto espaço deve ser provisionado. + Você tentou migrar os dados e a migração falhou devido à falta de espaço provisionado. É possível fazer as seguintes alterações para melhorar o processo de migração de um banco de dados para o Amazon Aurora. **Importante** Lembre-se de realizar essas atualizações em uma nova instância de banco de dados restaurada do snapshot de um banco de dados de produção, em vez de em uma instância de produção. Em seguida, você poderá migrar os dados do snapshot da sua nova instância de banco de dados para o cluster de banco de dados do Aurora a fim de evitar interrupções no serviço do seu banco de dados de produção. | Tipo de tabela | Limitação ou diretriz | | --- | --- | | Tabelas MyISAM | O Aurora MySQL oferece suporte somente a tabelas InnoDB. Se houver tabelas MyISAM no seu banco de dados, elas deverão ser convertidas antes da migração para o Aurora MySQL. O processo de conversão exige espaço adicional para a conversão de MyISAM para InnoDB durante o procedimento de migração. Para reduzir as chances de ficar sem espaço ou para agilizar o processo de migração, converta todas as tabelas MyISAM para tabelas InnoDB antes de migrá-las. O tamanho da tabela InnoDB resultante é equivalente ao tamanho exigido pelo Aurora MySQL para aquela tabela. Para converter uma tabela MyISAM para InnoDB, execute o seguinte comando: `alter table . engine=innodb, algorithm=copy;` | | Tabelas compactadas | O Aurora MySQL não oferece suporte a tabelas compactadas (ou seja, tabelas criadas com `ROW_FORMAT=COMPRESSED`). Para reduzir as chances de ficar sem espaço ou para agilizar o processo de migração, expanda suas tabelas compactadas definindo `ROW_FORMAT` como `DEFAULT`, `COMPACT`, `DYNAMIC` ou `REDUNDANT`. Para obter mais informações, consulte [Formatos de linha do InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html) na documentação do MySQL. | Use o seguinte script SQL na sua instância de banco de dados MySQL existente para listar as tabelas no seu banco de dados que são MyISAM ou compactadas. ``` -- This script examines a MySQL database for conditions that block -- migrating the database into Amazon Aurora. -- It needs to be run from an account that has read permission for the -- INFORMATION_SCHEMA database. -- Verify that this is a supported version of MySQL. select msg as `==> Checking current version of MySQL.` from ( select 'This script should be run on MySQL version 5.6 or higher. ' + 'Earlier versions are not supported.' as msg, cast(substring_index(version(), '.', 1) as unsigned) * 100 + cast(substring_index(substring_index(version(), '.', 2), '.', -1) as unsigned) as major_minor ) as T where major_minor <> 506; -- List MyISAM and compressed tables. Include the table size. select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`, round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)" from INFORMATION_SCHEMA.TABLES where ENGINE <> 'InnoDB' and ( -- User tables TABLE_SCHEMA not in ('mysql', 'performance_schema', 'information_schema') or -- Non-standard system tables ( TABLE_SCHEMA = 'mysql' and TABLE_NAME not in ( 'columns_priv', 'db', 'event', 'func', 'general_log', 'help_category', 'help_keyword', 'help_relation', 'help_topic', 'host', 'ndb_binlog_index', 'plugin', 'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log', 'tables_priv', 'time_zone', 'time_zone_leap_second', 'time_zone_name', 'time_zone_transition', 'time_zone_transition_type', 'user' ) ) ) or ( -- Compressed tables ROW_FORMAT = 'Compressed' ); ``` O script gera uma saída semelhante à saída do seguinte exemplo. O exemplo mostra duas tabelas que devem ser convertidas de MyISAM para InnoDB. A saída também inclui o tamanho aproximado de cada tabela em megabytes (MB). ``` +---------------------------------+------------------+ | ==> MyISAM or Compressed Tables | Approx size (MB) | +---------------------------------+------------------+ | test.name_table | 2102.25 | | test.my_table | 65.25 | +---------------------------------+------------------+ 2 rows in set (0.01 sec) ``` ## Migrar um snapshot de banco de dados do RDS para MySQL para um cluster de banco de dados do Aurora MySQL Você pode migrar um snapshot de banco de dados de uma instância de banco de dados do RDS para MySQL para criar um cluster de banco de dados do Aurora MySQL usando o Console de gerenciamento da AWS ou a AWS CLI. O novo cluster de banco de dados do Aurora MySQL é preenchido com os dados da instância de banco de dados RDS for MySQL original. Para obter informações sobre a criação de um snapshot de banco de dados, consulte [Criar um snapshot de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html). Se o snapshot do banco de dados não estiver na região da AWS em que você deseja colocar os seus dados, copie o snapshot do banco de dados para essa região da AWS. Para obter informações sobre a cópia de um snapshot de banco de dados, consulte [Cópia de um snapshot de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html). ### Console Quando você migra o snapshot de banco de dados usando o Console de gerenciamento da AWS, o console realiza as ações necessárias para criar somente o cluster de banco de dados. Também é possível determinar que o seu novo cluster de banco de dados do Aurora MySQL seja criptografado em repouso usando uma AWS KMS key. **Para migrar um snapshot de banco de dados MySQL usando o Console de gerenciamento da AWS** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Comece a migração a partir da instância de banco de dados do MySQL ou do snapshot: Para iniciar a migração a partir da instância de banco de dados: 1. No painel de navegação, selecione ** Databases (Bancos de dados)** e selecione a instância de banco de dados MySQL. 1. Em **Actions (Ações)**, escolha **Migrate latest snapshot (Migrar o último snapshot)**. Para iniciar a migração a partir do snapshot: 1. Escolha **Snapshots**. 1. Na página **Snapshots**, escolha o snapshot que você deseja migrar para um cluster de banco de dados do Aurora MySQL. 1. Escolha **Snapshot Actions (Ações do snapshot)** e, em seguida, escolha **Migrate Snapshot (Migrar snapshot)**. A página **Migrate Database (Migrar banco de dados)** é exibida. 1. Defina os seguintes valores na página **Migrate Database**: + **Migrate to DB Engine**: Selecione `aurora`. + **DB Engine Version (Versão do mecanismo de banco de dados)**: selecione a versão do mecanismo de banco de dados para o cluster de banco de dados do Aurora MySQL. + **DB Instance Class** (Classe de instância de banco de dados): selecione uma categoria de instância de banco de dados que tenha o armazenamento e a capacidade necessários para seu banco de dados, por exemplo `db.r3.large`. Os volumes de cluster do Aurora crescem automaticamente à medida em que aumenta a quantidade de dados em seu banco de dados. Um volume de cluster do Aurora pode aumentar até o tamanho máximo de 128 tebibytes (TiB). Assim, só será necessário selecionar uma classe de instância de banco de dados que atenda aos requisitos atuais de armazenamento. Para obter mais informações, consulte [Visão geral do armazenamento do Amazon Aurora](Aurora.Overview.StorageReliability.md#Aurora.Overview.Storage). + **Identificador da instância do banco de dados**: digite um nome para o cluster de banco de dados exclusivo à sua conta na região da AWS selecionada. Esse identificador é usado em endereços de endpoint para as instâncias no cluster de banco de dados. É possível optar por adicionar informações ao nome, como incluir a região da AWS e o mecanismo de banco de dados selecionados, por exemplo, **aurora-cluster1**. O DB instance identifier tem as seguintes restrições: + Deve conter de 1 a 63 caracteres alfanuméricos ou hífens. + O primeiro caractere deve ser uma letra. + Não pode terminar com um hífen ou conter dois hifens consecutivos. + Deve ser exclusivo para todas as instâncias de banco de dados por conta do AWS, por região da AWS. + **Virtual Private Cloud (VPC) (Nuvem privada virtual)**: se você tiver uma VPC existente, poderá usá-la com o seu cluster de banco de dados do Aurora MySQL selecionando o identificador de VPC, por exemplo `vpc-a464d1c1`. Para obter informações sobre como criar uma VPC, consulte [Tutorial: Criar uma VPC para usar com um cluster de banco de dados (somente IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md). De outro modo, é possível optar para que o Aurora crie uma VPC para você selecionando **Create a new VPC (Criar uma VPC)**. + **DB subnet group** (Grupo de sub-redes do banco de dados): se você tiver um grupo de sub-redes existente, poderá usá-lo com o cluster de banco de dados MySQL do Aurora selecionando o identificador do grupo de sub-redes, por exemplo, `gs-subnet-group1`. De outro modo, é possível optar para que o Aurora crie um grupo de sub-redes para você selecionando **Create a new subnet group (Criar um grupo de sub-redes)**. + **Public accessibility**: selecione **No** para especificar que as instâncias no seu cluster de banco de dados só podem ser acessadas por recursos dentro da sua VPC. Selecione **Yes** para especificar que as instâncias no seu cluster de banco de dados podem ser acessadas por recursos na rede pública. O padrão é **Yes (Sim)**. **nota** O cluster de banco de dados de produção talvez não precise estar em uma sub-rede pública, porque apenas os seus servidores de aplicativo precisarão acessá-lo. Se o cluster de banco de dados não precisar estar em uma sub-rede pública, defina **Publicly Accessible** como **No**. + **Availability Zone (Zona de disponibilidade)**: selecione a zona de disponibilidade para hospedar a instância primária do seu cluster de banco de dados Aurora MySQL. Para fazer com que o Aurora selecione uma zona de disponibilidade para você, escolha **No Preference (Sem preferência)**. + **Database Port (Porta de banco de dados)**: digite a porta padrão para ser usada ao se conectar a instâncias no cluster de banco de dados do Aurora MySQL. O padrão é `3306`. **nota** Pode ser que haja um firewall corporativo que impeça o acesso a portas padrão, como a porta padrão do MySQL, 3306. Nesse caso, forneça um valor de porta permitido pelo seu firewall corporativo. Lembre-se desse valor de porta mais tarde ao se conectar ao cluster de banco de dados do Aurora MySQL. + **Encryption (Criptografia)**: selecione **Enable Encryption (Habilitar criptografia)** para que o novo cluster de banco de dados do Aurora MySQL seja criptografado em repouso. Se você selecionar **Enable Encryption** (Habilitar criptografia), deverá escolher uma chave do KMS como o valor de **AWS KMS key**. Se o seu snapshot de banco de dados não for criptografado, especifique uma chave de criptografia para criptografar seu cluster de banco de dados em repouso. Se o seu snapshot de banco de dados for criptografado, especifique uma chave de criptografia para criptografar seu cluster de banco de dados em repouso usando-a. Você pode especificar a chave de criptografia usada pelo snapshot de banco de dados ou por uma chave diferente. Você não pode criar um cluster de banco de dados não criptografado de um snapshot de banco de dados criptografado. + **Auto Minor Version Upgrade (Atualização automática de versão secundária)**: essa configuração não se aplica aos clusters de banco de dados do Aurora MySQL. Para obter mais informações sobre atualizações de mecanismos para o Aurora MySQL, consulte [Atualizações do mecanismo de banco de dados Amazon Aurora MySQLSuporte de longo prazo (LTS) e versões beta do Amazon Aurora MySQL](AuroraMySQL.Updates.md). 1. Selecione **Migrate** para migrar o snapshot de banco de dados. 1. Selecione **Instances** e o ícone de seta para mostrar os detalhes do cluster de banco de dados e monitorar o andamento da migração. Na página de detalhes, você vê o endpoint do cluster usado para se conectar à instância primária do cluster de banco de dados. Para obter mais informações sobre a conexão com um cluster de banco de dados do Aurora MySQL, consulte [Como conectar-se a um cluster de bancos de dados Amazon Aurora](Aurora.Connecting.md). ### AWS CLI Você pode criar um cluster de banco de dados do Aurora a partir de um snapshot de banco de dados de uma instância de banco de dados RDS for MySQL usando o [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html) comando com os seguintes parâmetros: + `--db-cluster-identifier`: o nome do cluster de banco de dados a ser criado. + `--engine aurora-mysql`: para um cluster de banco de dados compatível com o MySQL 5.7 ou 8.0. + `--kms-key-id`: a AWS KMS key para criptografar opcionalmente o cluster de banco de dados, de acordo com a criptografia do seu snapshot de banco de dados. + Se o seu snapshot de banco de dados não for criptografado, especifique uma chave de criptografia para criptografar seu cluster de banco de dados em repouso. Caso contrário, seu cluster de banco de dados não será criptografado. + Se o seu snapshot de banco de dados for criptografado, especifique uma chave de criptografia para criptografar seu cluster de banco de dados em repouso usando-a. Caso contrário, seu cluster de banco de dados será criptografado em repouso usando a chave de criptografia do snapshot de banco de dados. **nota** Você não pode criar um cluster de banco de dados não criptografado de um snapshot de banco de dados criptografado. + `--snapshot-identifier` – O nome do recurso da Amazon (ARN) do snapshot do banco de dados a ser migrado. Para obter mais informações sobre ARNs do Amazon RDS, consulte [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds). Quando você migra o snapshot de banco de dados usando o comando `RestoreDBClusterFromSnapshot`, o comando cria o cluster de banco de dados e a instância primária. Neste exemplo, você cria um cluster de banco de dados compatível com o MySQL 5.7, denominado *mydbcluster*, de um snapshot de banco de dados com um ARN definido como *mydbsnapshotARN*. Para Linux, macOS ou Unix: ``` aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier mydbcluster \ --snapshot-identifier mydbsnapshotARN \ --engine aurora-mysql ``` Para Windows: ``` aws rds restore-db-cluster-from-snapshot ^ --db-cluster-identifier mydbcluster ^ --snapshot-identifier mydbsnapshotARN ^ --engine aurora-mysql ``` Neste exemplo, você cria um cluster de banco de dados compatível com o MySQL 5.7, denominado *mydbcluster*, de um snapshot de banco de dados com um ARN definido como *mydbsnapshotARN*. Para Linux, macOS ou Unix: ``` aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier mydbcluster \ --snapshot-identifier mydbsnapshotARN \ --engine aurora-mysql ``` Para Windows: ``` aws rds restore-db-cluster-from-snapshot ^ --db-cluster-identifier mydbcluster ^ --snapshot-identifier mydbsnapshotARN ^ --engine aurora-mysql ``` # Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora O Aurora usa a funcionalidade de replicação de log binário dos mecanismos de banco de dados MySQL para criar um tipo especial de cluster de banco de dados, chamado réplica de leitura do Aurora, para uma instância de banco de dados do RDS para MySQL. As atualizações feitas na instância de banco de dados do RDS para MySQL de origem são replicadas de forma assíncrona na réplica de leitura do Aurora. Recomendamos usar essa funcionalidade para migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Aurora MySQL criando uma réplica de leitura do Aurora da instância de banco de dados do RDS para MySQL de origem. Quando o atraso da réplica entre a instância de banco de dados do RDS para MySQL e a réplica de leitura do Aurora é 0, você pode direcionar aplicações clientes para a réplica de leitura do Aurora e interromper a replicação, a fim de que a réplica de leitura do Aurora se torne um cluster de banco de dados autônomo do Aurora MySQL. Prepare-se. A migração pode demorar um pouco. Estima-se várias horas por tebibyte (TiB) de dados. Para obter uma lista de regiões onde o Aurora está disponível, consulte [Amazon Aurora](https://docs.aws.amazon.com/general/latest/gr/rande.html#aurora) na *Referência geral da AWS*. Quando você cria uma réplica de leitura do Aurora usando uma instância de banco de dados do RDS para MySQL, o Amazon RDS cria um snapshot de banco de dados da instância de banco de dados do RDS para MySQL de origem (privado para o Amazon RDS sem qualquer custo). Em seguida, o Amazon RDS migra os dados do snapshot do banco de dados para a réplica de leitura do Aurora. Depois que os dados do snapshot de banco de dados são migrados para o novo cluster de banco de dados do Aurora MySQL, o Amazon RDS inicia a replicação entre a instância de banco de dados do RDS para MySQL e o cluster de banco de dados do Aurora MySQL. Caso a instância de banco de dados do RDS para MySQL contenha tabelas que usam mecanismos de armazenamento diferentes do InnoDB ou que usam formato compacto de linha, você pode agilizar o processo de criação de uma réplica de leitura do Aurora. Para isso, basta alterar essas tabelas para que usem o mecanismo de armazenamento InnoDB e o formato dinâmico de linha antes de criar a réplica de leitura do Aurora. Para ter mais informações sobre o processo de cópia de um snapshot de banco de dados MySQL para um cluster de banco de dados do Aurora MySQL, consulte [Migração de dados de um instância de banco de dados RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL.](AuroraMySQL.Migrating.RDSMySQL.md). Você só pode ter uma réplica de leitura do Aurora para uma instância de banco de dados do MySQL. **nota** Podem ocorrer problemas de replicação devido a diferenças de recurso entre o Aurora MySQL e a versão do mecanismo de banco de dados do MySQL da instância de banco de dados do RDS para MySQL, que é a original da replicação. Se você encontrar um erro, tente obter ajuda no [fórum da comunidade do Amazon RDS](https://forums.aws.amazon.com/forum.jspa?forumID=60) ou entre em contato com o AWS Support. Não será possível criar uma réplica de leitura do Aurora se a instância de banco de dados do RDS para MySQL já for a origem de uma réplica de leitura entre regiões. Não é possível migrar de algumas versões anteriores a 8.0 do RDS para MySQL para o Aurora MySQL 3.05, incluindo 8.0.11, 8.0.13 e 8.0.15. Recomendamos que você atualize para a versão 8.0.28 do RDS pra MySQL antes da migração. Para ter mais informações sobre réplicas de leitura do MySQL, consulte [Como trabalhar com réplicas de leitura do MariaDB, do MySQL e de instâncias de banco de dados PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html). ## Criar uma réplica de leitura do Aurora Você pode criar uma réplica de leitura do Aurora para uma instância de banco de dados do RDS para MySQL usando o console, a AWS CLI ou a API do RDS. ### Console **Como criar uma réplica de leitura do Aurora usando uma instância de banco de dados de origem do RDS para MySQL** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha a instância de banco de dados MySQL que você deseja usar como a origem da réplica de leitura do Aurora. 1. Em **Actions (Ações)**, selecione **Create Aurora read replica (Criar réplica de leitura do Aurora)**. 1. Escolha as especificações do cluster de banco de dados que deseja usar para a réplica de leitura do Aurora, como descrito na tabela a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html) 1. Escolha **Create read replica (Criar réplica de leitura)**. ### AWS CLI Para criar uma réplica de leitura do Aurora usando uma instância de banco de dados do MySQL de origem, use os comandos da [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) e [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) da AWS CLI para criar um cluster de banco de dados do Aurora MySQL. Quando você chamar o comando `create-db-cluster`, inclua o parâmetro `--replication-source-identifier` para identificar o Amazon Resource Name (ARN – Nome de recurso da Amazon) da instância do banco de dados MySQL de origem. Para ter mais informações sobre ARNs do Amazon RDS, consulte [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds). Não especifique o nome de usuário principal, a senha principal ou o nome do banco de dados já que a réplica de leitura do Aurora usa o mesmo nome de usuário principal, senha principal e nome de banco de dados que a instância de banco de dados do MySQL de origem. Para Linux, macOS ou Unix: ``` aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora \ --db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:primary-mysql-instance ``` Para Windows: ``` aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora ^ --db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:primary-mysql-instance ``` Se você usar o console para criar uma réplica de leitura do Aurora, o Aurora criará automaticamente a instância primária para a sua réplica de leitura do cluster de banco de dados do Aurora. Se você usar a AWS CLI para criar uma réplica de leitura do Aurora, deverá criar explicitamente a instância primária para o seu cluster de banco de dados. A instância principal é a primeira instância criada em um cluster de banco de dados. Você pode criar uma instância primária para seu cluster de banco de dados usando o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) da AWS CLI com os parâmetros a seguir. + `--db-cluster-identifier` O nome de seu cluster de banco de dados. + `--db-instance-class` O nome da classe da instância de banco de dados a ser usada para sua instância primária. + `--db-instance-identifier` O nome da sua instância primária. + `--engine aurora` Neste exemplo, você cria uma instância primária denominada *myreadreplicainstance* para o cluster de banco de dados denominado *myreadreplicacluster* usando a classe da instância de banco de dados especificada em *myinstanceclass*. **Example** Para Linux, macOS ou Unix: ``` aws rds create-db-instance \ --db-cluster-identifier myreadreplicacluster \ --db-instance-class myinstanceclass \ --db-instance-identifier myreadreplicainstance \ --engine aurora ``` Para Windows: ``` aws rds create-db-instance ^ --db-cluster-identifier myreadreplicacluster ^ --db-instance-class myinstanceclass ^ --db-instance-identifier myreadreplicainstance ^ --engine aurora ``` ### API do RDS Para criar uma réplica de leitura do Aurora de uma instância de banco de dados do RDS para MySQL de origem, use os comandos [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) e [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) da API do Amazon RDS para criar um cluster de banco de dados do Aurora e uma instância primária. Não especifique o nome de usuário principal, a senha principal ou o nome do banco de dados, pois a réplica de leitura do Aurora usa o mesmo nome de usuário principal, senha principal e nome de banco de dados que a instância de banco de dados do RDS para MySQL de origem. Você pode criar um cluster de banco de dados do Aurora para uma réplica de leitura do Aurora com base em uma instância de banco de dados do RDS para MySQL de origem usando o comando [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) da API do Amazon RDS com os seguintes parâmetros: + `DBClusterIdentifier` O nome do cluster de banco de dados a ser criado. + `DBSubnetGroupName` O nome do grupo de sub-redes de banco de dados a ser associado a esse cluster de banco de dados. + `Engine=aurora` + `KmsKeyId` A AWS KMS key a ser usada para criptografar o cluster de banco de dados opcionalmente, de acordo com a criptografia da sua instância de banco de dados do MySQL. + Se a sua instância de banco de dados MySQL não for criptografada, especifique uma chave de criptografia para criptografar seu cluster de banco de dados em repouso. Caso contrário, seu cluster de banco de dados será criptografado em repouso usando a chave de criptografia padrão da sua conta. + Se a sua instância de banco de dados MySQL for criptografada, especifique uma chave de criptografia para criptografar seu cluster de banco de dados em repouso usando-a. Caso contrário, seu cluster de banco de dados será criptografado em repouso usando a chave de criptografia da instância de banco de dados MySQL. **nota** Você não pode criar um cluster de banco de dados não criptografado de uma instância de banco de dados MySQL criptografada. + `ReplicationSourceIdentifier` O Nome de recurso da Amazon (ARN) para a instância de banco de dados MySQL de origem. Para ter mais informações sobre ARNs do Amazon RDS, consulte [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds). + `VpcSecurityGroupIds` A lista de security groups de VPC do EC2 a ser associada a esse cluster de banco de dados. Neste exemplo, você cria um cluster de banco de dados denominado *myreadreplicacluster* de uma instância de banco de dados MySQL de origem com um ARN definido como *mysqlprimaryARN* associado a um grupo do sub-redes de banco de dados denominado *mysubnetgroup*, e um grupo de segurança da VPC denominado *mysecuritygroup*. **Example** ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &DBClusterIdentifier=myreadreplicacluster &DBSubnetGroupName=mysubnetgroup &Engine=aurora &ReplicationSourceIdentifier=mysqlprimaryARN &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &VpcSecurityGroupIds=mysecuritygroup &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20150927/us-east-1/rds/aws4_request &X-Amz-Date=20150927T164851Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=6a8f4bd6a98f649c75ea04a6b3929ecc75ac09739588391cd7250f5280e716db ``` Se você usar o console para criar uma réplica de leitura do Aurora, o Aurora criará automaticamente a instância primária para a sua réplica de leitura do cluster de banco de dados do Aurora. Se você usar a AWS CLI para criar uma réplica de leitura do Aurora, deverá criar explicitamente a instância primária para o seu cluster de banco de dados. A instância principal é a primeira instância criada em um cluster de banco de dados. Você pode criar uma instância primária para seu cluster de banco de dados usando o comando [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) da API do Amazon RDS com os parâmetros a seguir: + `DBClusterIdentifier` O nome de seu cluster de banco de dados. + `DBInstanceClass` O nome da classe da instância de banco de dados a ser usada para sua instância primária. + `DBInstanceIdentifier` O nome da sua instância primária. + `Engine=aurora` Neste exemplo, você cria uma instância primária denominada *myreadreplicainstance* para o cluster de banco de dados denominado *myreadreplicacluster* usando a classe da instância de banco de dados especificada em *myinstanceclass*. **Example** ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=myreadreplicacluster &DBInstanceClass=myinstanceclass &DBInstanceIdentifier=myreadreplicainstance &Engine=aurora &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-09-01 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20140424/us-east-1/rds/aws4_request &X-Amz-Date=20140424T194844Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=bee4aabc750bf7dad0cd9e22b952bd6089d91e2a16592c2293e532eeaab8bc77 ``` ## Visualizar uma réplica de leitura do Aurora Você pode visualizar as relações de replicação do MySQL para o Aurora MySQL de seus clusters de banco de dados do Aurora MySQL usando o Console de gerenciamento da AWS ou a AWS CLI. ### Console **Como visualizar a instância de banco de dados do MySQL para uma réplica de leitura do Aurora** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha o cluster de banco de dados da réplica de leitura do Aurora para exibir seus detalhes. As informações da instância do banco de dados MySQL primária estará no campo **Replication source (Fonte de replicação)**. ![\[Visualizar MySQL primário\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-repl6.png) ### AWS CLI Para visualizar as relações de replicação do MySQL com o Aurora MySQL para clusters de banco de dados do Aurora MySQL utilizando a AWS CLI, use os comandos [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) e [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). Para determinar qual instância de banco de dados MySQL é a primária, use o [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) e especifique o identificador do cluster de réplica de leitura do Aurora para a opção `--db-cluster-identifier`. Consulte o elemento `ReplicationSourceIdentifier` na saída para o ARN da instância de banco de dados que é a primária da replicação. Para determinar qual cluster de banco de dados é a réplica de leitura do Aurora, use o [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) e especifique o identificador da instância de banco de dados MySQL para a opção `--db-instance-identifier`. Consulte o elemento `ReadReplicaDBClusterIdentifiers` na saída para o identificador de cluster de banco de dados da réplica de leitura do Aurora. **Example** Para Linux, macOS ou Unix: ``` aws rds describe-db-clusters \ --db-cluster-identifier myreadreplicacluster ``` ``` aws rds describe-db-instances \ --db-instance-identifier mysqlprimary ``` Para Windows: ``` aws rds describe-db-clusters ^ --db-cluster-identifier myreadreplicacluster ``` ``` aws rds describe-db-instances ^ --db-instance-identifier mysqlprimary ``` ## Promover uma réplica de leitura do Aurora Depois que a migração for concluída, você poderá promover a réplica de leitura do Aurora para um cluster de banco de dados autônomo usando o Console de gerenciamento da AWS ou a AWS CLI. Depois, você poderá direcionar suas aplicações cliente ao endpoint para a réplica de leitura do Aurora. Para ter mais informações sobre os endpoints do Aurora, consulte [Conexões de endpoints do Amazon Aurora](Aurora.Overview.Endpoints.md). A promoção deve ser bem rápida. É possível fazer operações de leitura e gravação na réplica de leitura do Aurora durante a promoção. No entanto, você não pode excluir a instância primária do banco de dados MySQL ou desvincular a instância de banco de dados e a réplica de leitura do Aurora neste momento. Antes de promover a sua réplica de leitura do Aurora interrompa quaisquer transações de gravação na instância do banco de dados MySQL de origem. Em seguida, aguarde que o atraso da réplica de leitura do Aurora chegue a 0. É possível visualizar o atraso da réplica para uma réplica de leitura do Aurora chamando o comando `SHOW SLAVE STATUS` (Aurora MySQL versão 2) ou `SHOW REPLICA STATUS` (Aurora MySQL versão 3) na sua réplica de leitura do Aurora. Verifique o valor **Seconds behind master** (Segundos atrás do mestre). Você pode iniciar a gravação na réplica de leitura do Aurora depois que as transações de gravação para o primário tiverem parado e o atraso da réplica for 0. Se você gravar na réplica de leitura do Aurora antes disso e alterar as tabelas que também estão sendo modificadas no MySQL primário, você se arriscará a interromper a replicação para o Aurora. Se isso acontecer, você deve excluir e recriar sua réplica de leitura do Aurora. ### Console **Como promover uma réplica de leitura do Aurora a um cluster de bancos de dados Aurora** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha o cluster de banco de dados para a réplica de leitura do Aurora. 1. Em **Actions (Ações)**, selecione **Promote (Promover)**. 1. Escolha **Promote read replica (Promover réplica de leitura)**. Depois de promover, confirme se a promoção foi concluída usando o procedimento a seguir. **Para confirmar que a réplica de leitura do Aurora foi promovida** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, selecione **Events**. 1. Na página **Eventos**, verifique se há um evento do `Promoted Read Replica cluster to a stand-alone database cluster` para o cluster que você promoveu. Depois que promoção estiver concluída, a instância do banco de dados MySQL primária e a réplica de leitura do Aurora serão desvinculados e, se desejar, você poderá excluir a instância de banco de dados com segurança. ### AWS CLI Para promover uma réplica de leitura do Aurora a um cluster de banco de dados autônomo, use o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) da AWS CLI. **Example** Para Linux, macOS ou Unix: ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier myreadreplicacluster ``` Para Windows: ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier myreadreplicacluster ```