# Configurar a replicação de várias origens do Amazon Aurora MySQL Com a replicação de várias origens, é possível configurar um cluster de banco de dados do Amazon Aurora MySQL como uma réplica que recebe eventos de log binário de mais de um banco de dados MySQL de origem. Cada origem pode ser uma instância de banco de dados do RDS para MySQL, outro cluster de banco de dados do Aurora MySQL ou um banco de dados MySQL executado externamente em relação ao Amazon RDS. A replicação de várias origens é compatível com clusters de banco de dados do Aurora MySQL que executam as seguintes versões de mecanismo: + Aurora MySQL 8.4.8 e posterior Para obter mais informações sobre a replicação de várias origens do MySQL, consulte [Replicação de várias origens do MySQL](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html) na documentação do MySQL. **nota** A replicação de várias origens no Aurora MySQL usa a instância de gravação (primária) do cluster de banco de dados Aurora como destino de replicação. Todos os procedimentos armazenados de replicação devem ser chamados enquanto houver conexão à instância de gravação do cluster. ## Casos de uso da replicação de várias fontes Considere usar a replicação de várias origens no Aurora MySQL nos seguintes casos: + **Consolidação de fragmentos**: aplicativos que precisam mesclar ou combinar dados de vários fragmentos hospedados em instâncias de banco de dados separadas em um único cluster de banco de dados do Aurora MySQL. + **Relatórios consolidados**: aplicativos que precisam gerar relatórios a partir de dados consolidados de várias origens, aproveitando os recursos de dimensionamento de leitura do Aurora. + **Backups de longo prazo**: requisitos para criar backups consolidados de longo prazo de dados distribuídos entre várias instâncias de banco de dados compatíveis com MySQL. + **Migração entre mecanismos**: consolidação de dados de várias instâncias do RDS para MySQL ou servidores MySQL externos em um único cluster Aurora MySQL durante a migração. + **Agregação multilocatária**: consolidação de vários bancos de dados de locatário único em um cluster Aurora multilocatário para otimização de custos e gerenciamento simplificado. ## Pré-requisitos para replicação de várias fontes Antes de configurar a replicação de várias origens em seu cluster de banco de dados Aurora MySQL, preencha os pré-requisitos padrão para replicação de log binário, conforme descrito em [Configurar a replicação de logs binários para o Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md). Isso inclui habilitar o registro em log binário em cada origem, reter logs binários, criar um usuário de replicação e criar uma cópia ou dump de cada origem. Para a replicação de várias origens, repita essas etapas para cada instância de banco de dados de origem. Além dos pré-requisitos padrão, satisfaça os seguintes requisitos específicos para a replicação de várias origens. + Verificar a versão e a configuração do cluster de destino do Aurora MySQL + O cluster de banco de dados Aurora MySQL deve estar executando uma versão de mecanismo compatível (Aurora MySQL 8.4.8 e superior). + Habilite a confirmação automática na instância do gravador do Aurora MySQL. Defina o parâmetro `autocommit` como `1` no grupo de parâmetros do cluster do banco de dados. + Configurar a conectividade de rede para cada origem Para cada instância de banco de dados de origem, a instância do gravador do Aurora MySQL deve se conectar à origem na porta especificada. Entre as opções estão: + Se a origem e o destino estiverem na mesma VPC, configure o grupo de segurança na instância de banco de dados de origem para permitir conexões de entrada na porta 3306 (ou na sua porta personalizada) do grupo de segurança do cluster do Aurora MySQL. + Se estiverem em VPCs diferentes, configure o emparelhamento de VPC ou use um gateway de trânsito. Para obter mais informações, consulte [Um cluster de banco de dados em uma VPC acessada por uma instância do EC2 em uma VPC diferente](USER_VPC.Scenarios.md#USER_VPC.Scenario3). + Se a origem for externa à AWS, verifique se as rotas de rede estão disponíveis (por exemplo, por meio de uma conexão VPN). **nota** Como a replicação de várias origens envolve várias origens, você deve verificar a conectividade com cada origem de forma independente. Garanta que os grupos de segurança e o roteamento acomodem todos os endpoints de origem simultaneamente. ## Configurar canais de replicação de várias origens em clusters de banco de dados do Aurora MySQL A configuração de canais de replicação de várias origens no Aurora MySQL é semelhante à configuração da replicação de uma única origem. Para replicação de várias origens, primeiro você ativa o registro em log binário nas instâncias de origem, importa os dados das origens para o cluster do Aurora MySQL e, em seguida, inicia a replicação de cada origem usando as coordenadas do log binário ou o posicionamento automático do GTID. **Importante** Todos os procedimentos armazenados de replicação de várias origens devem ser chamados enquanto estiverem conectados à **instância de gravação** do cluster de banco de dados do Aurora MySQL. Se ocorrer um failover, você deverá se reconectar à nova instância do gravador. ### Etapa 1: importar dados das instâncias de banco de dados de origem para o cluster do Aurora MySQL Realize as etapas a seguir em cada instância de banco de dados de origem. 1. Determine o arquivo de log binário atual e a posição na instância de banco de dados de origem. ``` SHOW BINARY LOG STATUS; ``` ``` SHOW MASTER STATUS; ``` Resultado do exemplo: ``` +----------------------------+----------+ | File | Position | +----------------------------+----------+ | mysql-bin-changelog.000031 | 107 | +----------------------------+----------+ ``` Registre os valores de `File` e `Position`. Você precisará deles em uma etapa posterior. 1. Copie o banco de dados da instância de banco de dados de origem para o cluster do Aurora MySQL usando `mysqldump`. ``` mysqldump --databases {{database_name}} \ --single-transaction \ --compress \ --order-by-primary \ -u {{RDS_user_name}} \ -p'{{RDS_password}}' \ --host={{source-endpoint.region.rds.amazonaws.com}} | mysql \ --host={{aurora-cluster-endpoint.cluster-xxxxxx.region.rds.amazonaws.com}} \ --port=3306 \ -u {{aurora_user_name}} \ -p'{{aurora_password}}' ``` **dica** Para bancos de dados grandes, tente usar o AWS DMS ou criar um instantâneo e restaurá-lo para reduzir o tempo de transferência de dados. 1. Depois que a importação de dados for concluída, você poderá reativar as gravações na instância de banco de dados de origem se a tiver configurado anteriormente como somente leitura. ### Etapa 2: iniciar a replicação das instâncias de banco de dados de origem para o cluster do Aurora MySQL Para cada instância de banco de dados de origem, conecte-se à **instância de gravação** do cluster de banco de dados do Aurora MySQL e execute os procedimentos armazenados para configurar e iniciar a replicação em um canal. ``` CALL mysql.rds_set_external_source_for_channel( '{{source-endpoint.region.rds.amazonaws.com}}', 3306, '{{repl_user}}', '{{password}}', '{{mysql-bin-changelog.000031}}', 107, 0, '{{channel_1}}' ); CALL mysql.rds_start_replication_for_channel('{{channel_1}}'); ``` Se as instâncias de banco de dados de origem usarem replicação baseada em GTID, você poderá usar o posicionamento automático em vez de especificar coordenadas de log binário: ``` CALL mysql.rds_set_external_source_with_auto_position_for_channel( '{{source-endpoint.region.rds.amazonaws.com}}', 3306, '{{repl_user}}', '{{password}}', 0, 0, '{{channel_1}}' ); CALL mysql.rds_start_replication_for_channel('{{channel_1}}'); ``` **nota** Ao usar o posicionamento automático do GTID, os parâmetros `gtid_mode` e `enforce_gtid_consistency` devem estar configurados de forma consistente em todas as instâncias de origem e no cluster do Aurora MySQL. Repita essas etapas para cada instância de banco de dados de origem, especificando um nome de canal exclusivo para cada uma (por exemplo, `channel_1`, `channel_2`, `channel_3`). ## Usar filtros com replicação de várias origens É possível usar filtros de replicação para especificar quais bancos de dados e tabelas são replicados na réplica de várias origens do Aurora MySQL. Para obter mais informações sobre filtros de replicação, consulte [Configurar filtros de replicação com o Aurora MySQL](AuroraMySQL.Replication.Filters.md). A seguir, descrevemos os recursos adicionais de filtro no nível do canal disponíveis com a replicação de várias origens. Com a replicação de várias origens, é possível configurar filtros de replicação em dois níveis: + **Filtros globais**: aplicam-se a todos os canais. Definido usando o grupo de parâmetros do cluster de banco de dados do Aurora MySQL (por exemplo, `replicate-do-db`, `replicate-ignore-db`). + **Filtros no nível do canal**: aplicam-se somente a canais específicos, substituindo os filtros globais desse canal. + Você deve reiniciar a replicação depois de alterar os filtros no nível do canal. + Se nenhum filtro específico do canal estiver configurado, o Aurora MySQL aplicará os filtros globais para esse canal. + Se um filtro for aplicado globalmente e no nível do canal, somente o filtro no nível do canal será aplicado para esse canal. ## Monitorar canais de replicação de várias origens É possível monitorar canais individuais em uma réplica de várias origens do Aurora MySQL usando os seguintes métodos. ### Usar SHOW REPLICA STATUS Conecte-se à instância de gravação do cluster de banco de dados do Aurora MySQL e execute: ``` -- View status for all channels SHOW REPLICA STATUS\G -- View status for a specific channel SHOW REPLICA STATUS FOR CHANNEL '{{channel_1}}'\G ``` Campos principais a serem monitorados: | Campo | Descrição | | --- | --- | | Replica\_IO\_Running | Se o thread de E/S do canal está em execução | | Replica\_SQL\_Running | Se o thread SQL do canal está em execução | | Seconds\_Behind\_Source | Atraso de replicação em segundos do canal | | Last\_IO\_Error | Último erro de E/S encontrado no canal | | Last\_SQL\_Error | Último erro SQL encontrado no canal | | Source\_Log\_File | O arquivo de log binário atual que está sendo lido na origem | | Exec\_Source\_Log\_Pos | A posição no log binário que o thread SQL aplicou | ### Usar métricas do CloudWatch Monitore a métrica `ReplicationChannelLag` do CloudWatch para cada canal de replicação. Essa métrica fornece dados de atraso de replicação por canal com um período de 60 segundos e está disponível por 15 dias. Para localizar o atraso do canal de replicação, use o identificador da instância do cluster de banco de dados do Aurora e o nome do canal de replicação como dimensões. Você pode configurar os alarmes do CloudWatch para receber notificações quando o atraso exceder um limite específico. Para obter mais informações, consulte [Monitorar métricas em um cluster do Amazon Aurora](MonitoringAurora.md). ## Gerenciar procedimentos armazenados de replicação de várias origens Para obter mais informações sobre como usar procedimentos armazenados para configurar e gerenciar os canais de replicação de várias origens, consulte [Gerenciar a replicação de várias fontes](mysql-stored-proc-multi-source-replication.md). ## Considerações e práticas recomendadas Para obter recomendações gerais de otimização de replicação, incluindo formato de log binário, operadores paralelos e log binário aprimorado, consulte [Otimizar a replicação de logs binários para Aurora MySQL](binlog-optimization.md). As considerações a seguir são específicas para replicação de várias origens. ### Planejamento de recursos Ao executar vários canais de replicação, o número total de threads de replicação alocados na réplica é: (`replica_parallel_workers` \+ 1 thread coordenador) × número de canais. Por exemplo, com o valor padrão de `replica_parallel_workers` igual a 4 e 10 canais, o Aurora MySQL aloca 50 threads de replicação. Use uma classe de instância de banco de dados maior (como db.r6g.2xlarge ou maior) com base no throughput total da origem e na contagem de canais. Cada canal recebe o mesmo número de operadores paralelos. O MySQL não oferece suporte à configuração de diferentes contagens de operadores paralelos por canal. ### Como evitar conflitos A replicação de várias origens do MySQL não fornece detecção ou resolução de conflitos. Você deve garantir que as alterações de diferentes origens não sejam conflitantes. As estratégias comuns incluem: + Cada origem grava em um banco de dados ou conjunto de tabelas diferente. + Use filtros de replicação (`replicate-do-db`) para garantir que cada canal replique somente os bancos de dados pelos quais é responsável. + Use a opção `replicate-rewrite-db` para remapear um nome de esquema da origem para um nome diferente na réplica, se necessário. Para evitar gravações conflitantes de aplicativos conectados diretamente à réplica de várias origens, ative o modo somente leitura no cluster do Aurora MySQL: `CALL mysql.rds_set_read_only(1);` ### Melhores práticas operacionais + **Um canal por vez**: execute operações de gerenciamento (como alterações de configuração, ignorar erros ou iniciar/parar a replicação) em um canal por vez. Evite alterações simultâneas em vários canais de conexões diferentes. + **Monitore o atraso por canal**: monitore o atraso na replicação de cada canal usando a métrica `ReplicationChannelLag` do CloudWatch. + **Tratamento do failover na origem**: se uma instância de banco de dados de origem fizer o failover (por exemplo, um failover Multi-AZ do Amazon RDS), o canal de replicação poderá parar com um erro de E/S. Depois que a origem estiver disponível novamente: + Chame `mysql.rds_start_replication_for_channel` para retomar a replicação. + Se ocorrer o erro 1236 (arquivo de log não encontrado), chame `mysql.rds_next_source_log_for_channel` para avançar para o próximo arquivo de log binário. + **Failover do gravador do Aurora**: se a instância do gravador do Aurora MySQL passar para um leitor, as configurações do canal de replicação serão preservadas no armazenamento compartilhado do cluster. Após a conclusão do failover, os threads de replicação são reiniciados automaticamente na nova instância do gravador. ## Limitações As limitações a seguir são específicas da replicação de várias origens do Aurora MySQL. Para limitações gerais de replicação de várias origens do MySQL (como configuração de operador paralelo por canal), consulte [Replicação de várias origens do MySQL](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html) na documentação do MySQL. + A replicação de várias origens é compatível somente com o Aurora MySQL versão 8.4.8 e superior. + O Aurora MySQL suporta a configuração de no máximo **15 canais** para uma réplica de várias origens. ## Solução de problemas Para solução de problemas gerais de replicação, consulte [ Problemas de replicação no Amazon Aurora MySQL](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL). Confira a seguir as notas de solução de problemas específicas da replicação de várias origens. ### A configuração do canal não foi restaurada após a restauração do instantâneo Os instantâneos de cluster de banco de dados não incluem configurações de canal de várias origens. Depois de restaurar a partir de um instantâneo: + Reconfigure cada canal usando `mysql.rds_set_external_source_for_channel` ou `mysql.rds_set_external_source_with_auto_position_for_channel`. + Se estiver usando o posicionamento automático do GTID, a réplica pode ser retomada automaticamente de onde parou. + Se estiver usando as posições do arquivo de log binário, determine a posição atual comparando o log binário da origem com a última transação aplicada no cluster restaurado. ### Aumento do atraso na replicação em um ou mais canais + Verifique as métricas de CPU e E/S da instância do gravador. Se a utilização de recursos for alta, aumente a classe da instância na vertical. + Aumente `replica_parallel_workers` para melhorar o throughput do thread SQL. + Verifique se não há transações de longa duração ou operações DDL no canal que possam estar bloqueando o thread SQL. + Verifique se há configurações de filtro conflitantes que possam fazer com que a replicação processe e, em seguida, descarte um grande número de eventos. ## Exemplo: configuração completa de várias origens com três origens O exemplo a seguir demonstra a configuração de um cluster de banco de dados do Aurora MySQL como uma réplica de várias origens de três instâncias de origem do RDS para MySQL. ### Etapa 1: registrar as posições do log binário em cada origem Conecte-se a cada origem e registre as coordenadas do log binário: ``` -- On source 1 (orders-db.xxxxx.us-east-1.rds.amazonaws.com) SHOW BINARY LOG STATUS; -- Result: mysql-bin-changelog.000045, Position: 3892 -- On source 2 (inventory-db.xxxxx.us-east-1.rds.amazonaws.com) SHOW BINARY LOG STATUS; -- Result: mysql-bin-changelog.000012, Position: 1567 -- On source 3 (analytics-db.xxxxx.us-east-1.rds.amazonaws.com) SHOW BINARY LOG STATUS; -- Result: mysql-bin-changelog.000078, Position: 9421 ``` ### Etapa 2: importar dados de cada origem ``` # Import from source 1 mysqldump --databases orders_db --single-transaction --compress \ -u admin -p --host=orders-db.xxxxx.us-east-1.rds.amazonaws.com | \ mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p # Import from source 2 mysqldump --databases inventory_db --single-transaction --compress \ -u admin -p --host=inventory-db.xxxxx.us-east-1.rds.amazonaws.com | \ mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p # Import from source 3 mysqldump --databases analytics_db --single-transaction --compress \ -u admin -p --host=analytics-db.xxxxx.us-east-1.rds.amazonaws.com | \ mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p ``` ### Etapa 3: configurar e iniciar canais de replicação Conecte-se à instância de gravação do Aurora MySQL: ``` -- Configure channel for source 1 (orders) CALL mysql.rds_set_external_source_for_channel( 'orders-db.xxxxx.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000045', 3892, 0, 'orders_channel' ); -- Configure channel for source 2 (inventory) CALL mysql.rds_set_external_source_for_channel( 'inventory-db.xxxxx.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000012', 1567, 0, 'inventory_channel' ); -- Configure channel for source 3 (analytics) CALL mysql.rds_set_external_source_for_channel( 'analytics-db.xxxxx.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000078', 9421, 0, 'analytics_channel' ); -- Start all channels CALL mysql.rds_start_replication_for_channel('orders_channel'); CALL mysql.rds_start_replication_for_channel('inventory_channel'); CALL mysql.rds_start_replication_for_channel('analytics_channel'); ``` ### Etapa 4: verificar o status da replicação ``` SHOW REPLICA STATUS\G ``` Confirme se, para cada canal: + `Replica_IO_Running: Yes` + `Replica_SQL_Running: Yes` + `Seconds_Behind_Source: 0` (ou um valor baixo) ## Recursos relacionados + [Replicação de várias origens do MySQL](https://dev.mysql.com/doc/refman/8.4/en/replication-multi-source.html): documentação do MySQL + [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md): Guia do usuário do Aurora + [Otimizar a replicação de logs binários para Aurora MySQL](binlog-optimization.md): Guia do usuário do Aurora + [Configurar filtros de replicação com o Aurora MySQL](AuroraMySQL.Replication.Filters.md): Guia do usuário do Aurora + [Usar a replicação baseada em GTID](mysql-replication-gtid.md): Guia do usuário do Aurora