# Solução de problemas do Amazon Aurora Use as seções a seguir para solucionar problemas que possam surgir com instâncias de bancos de dados do Amazon RDS e do Amazon Aurora. **Topics** + [Não é possível conectar-se à instância de banco de dados do Amazon RDS](#CHAP_Troubleshooting.Connecting) + [Problemas de segurança do Amazon RDS](#CHAP_Troubleshooting.Security) + [Redefinir a senha de proprietário da instância de banco de dados](#CHAP_Troubleshooting.ResetPassword) + [Interrupção ou reinicialização da instância de banco de dados do Amazon RDS](#CHAP_Troubleshooting.Reboots) + [Alterações de parâmetros de banco de dados do Amazon RDS que não entram em vigor](#CHAP_Troubleshooting.Parameters) + [Problemas de memória liberável no Amazon Aurora](#Troubleshooting.FreeableMemory) + [Problemas de replicação no Amazon Aurora MySQL](#CHAP_Troubleshooting.MySQL) Para obter informações sobre como depurar problemas usando a API do Amazon RDS, consulte [Solução de problemas de aplicações no Aurora](APITroubleshooting.md). ## Não é possível conectar-se à instância de banco de dados do Amazon RDS Quando você não consegue se conectar a uma instância de banco de dados, as causas a seguir são motivos comuns: + **Regras de entrada** – as regras de acesso impostas pelo firewall local e os endereços IP autorizados a acessar a instância de banco de dados podem não corresponder. O problema está provavelmente nas regras de entrada do seu grupo de segurança. Por padrão, as instâncias de banco de dados não permitem acesso. O acesso é concedido por meio de um grupo de segurança associado à VPC que permite o tráfego de entrada e saída da instância de banco de dados. Se necessário, adicione regras de entrada e saída para sua situação específica ao grupo de segurança. Você pode especificar um endereço IP, um intervalo de endereços IP ou outro grupo de segurança da VPC. **nota** Ao adicionar uma nova regra de entrada, escolha **My IP (Meu IP)** para a **Source (Origem)** a fim de permitir o acesso à instância de banco de dados do endereço IP detectado em seu navegador. Para ter mais informações sobre como configurar um grupo de segurança, consulte [Fornecer acesso ao cluster de banco de dados na VPC criando um grupo de segurança](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup). **nota** Conexões de cliente de endereços IP dentro do intervalo 169.254.0.0/16 não são permitidas. Esse é o APIPA (Automatic Private IP Addressing Range, Intervalo de endereçamento IP privado automático), usado para o endereçamento de link local. + **Acessibilidade pública** – para se conectar à sua instância de banco de dados de fora da VPC, como por exemplo, usando uma aplicação cliente, a instância deve ter um endereço IP público atribuído a ela. Para tornar a instância acessível publicamente, modifique-a e escolha **Yes (Sim)** em **Public accessibility (Acessibilidade pública)**. Para obter mais informações, consulte [Ocultar um cluster de banco de dados em uma VPC da Internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding). + **Porta**: a porta que você especificou quando criou a instância de banco de dados não pode ser usada para enviar ou receber comunicações devido às restrições de firewall locais. Verifique com seu administrador de rede para determinar se a rede permite que a porta especificada seja usada para a comunicação de entrada e saída. + **Disponibilidade** – a instância de banco de dados recém-criada fica com o status `creating` até que esteja pronta para uso. Quando o estado for alterado para `available`, será possível se conectar à instância de banco de dados. Dependendo do tamanho da sua instância de banco de dados, pode demorar até 20 minutos para que uma instância esteja disponível. + **Gateway da Internet** – para que uma instância de banco de dados seja acessível publicamente, as sub-redes no grupo de sub-redes de banco de dados devem ter um gateway da Internet. **Como configurar um gateway da Internet para uma sub-rede** 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)** e escolha o nome da instância de banco de dados. 1. Na guia **Connectivity & security (Conectividade e segurança)** anote os valores do ID da VPC em **VPC** e o ID da sub-rede em **Subnets (Sub-redes)**. 1. Abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. No painel de navegação, escolha **Gateways da Internet**. Verifique se há um gateway de internet associado à sua VPC. Caso contrário, escolha **Criar gateway da internet** para criar um gateway da Internet. Selecione o gateway de internet e escolha **Associar à VPC** e siga as instruções para associá-la à sua VPC. 1. No painel de navegação, escolha **Sub-redes** e selecione sua sub-rede. 1. Na guia **Tabela de rotas**, verifique que há uma rota com `0.0.0.0/0` como o destino e o gateway de Internet para sua VPC como destino. Se você estiver se conectando à sua instância usando o endereço IPv6, verifique se há uma rota para todo o tráfego IPv6 (`::/0`) que aponta para o gateway de Internet. Caso contrário, faça o seguinte: 1. Escolha o ID da tabela de rotas (rtb-*xxxxxxxx*) para navegar para a tabela de rotas. 1. Na guia **Routes (Rotas)**, escolha **Edit routes (Editar rotas)**. Escolha **Add route (Adicionar rota)**, use `0.0.0.0/0` como o destino, e o gateway da Internet como o destino. Para IPv6, escolha **Add route (Adicionar rota)**, use `::/0` como o destino, e o gateway da Internet como o destino. 1. Escolha **Save routes (Salvar rotas)**. Além disso, se você estiver tentando se conectar ao endpoint IPv6, verifique se o intervalo de endereços IPv6 do cliente está autorizado a se conectar à instância de banco de dados. Para ter mais informações, consulte [Trabalhar com um cluster de banco de dados em uma VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md). ### Testar uma conexão a uma instância de banco de dados É possível testar sua conexão a uma instância de banco de dados usando ferramentas comuns do Linux ou do Microsoft Windows. Em um terminal Linux ou Unix, teste a conexão inserindo o seguinte. Substitua `{{DB-instance-endpoint}}` pelo endpoint e `{{port}}` pela porta de sua instância de banco de dados. ``` nc -zv {{DB-instance-endpoint}} {{port}} ``` Veja a seguir um exemplo de comando e o valor de retorno. ``` nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded! ``` Os usuários do Windows podem usar o Telnet para testar a conexão com uma instância de banco de dados. As ações do Telnet não têm suporte além do teste da conexão. Se uma conexão for bem-sucedida, a ação não retorna uma mensagem. Se uma conexão não for bem-sucedida, você receberá uma mensagem de erro, como a seguinte: ``` C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819 Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open connection to the host, on port 819: Connect failed ``` Se as ações do Telnet retornarem êxito, seu grupo de segurança está corretamente configurado. **nota** O Amazon RDS não aceita o tráfego pelo protocolo ICMP (protocolo de mensagens de controle da Internet), incluindo ping. ### Solução de problemas de autenticação da conexão Em alguns casos, você pode se conectar à sua instância de banco de dados, mas recebe erros de autenticação. Nesses casos, convém redefinir a senha do usuário principal para a instância de banco de dados. Isso pode ser feito ao modificar a instância do RDS. ## Problemas de segurança do Amazon RDS Para evitar problemas de segurança, nunca use o nome do usuário-raiz e a senha da Conta da AWS para uma conta de usuário. A prática recomendada é usar o usuário-raiz para criar usuários e atribuí-los a contas de usuário de banco de dados. Também é possível usar o usuário-raiz para criar outras contas de usuário, se necessário. Para obter informações sobre a criação de usuários, consulte [Criar um usuário do IAM na sua Conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). Para obter informações sobre como criar usuários no Centro de Identidade do AWS IAM, consulte [Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) (Gerenciar identidades no IAM Identity Center). ### Mensagem de erro "Falha ao recuperar atributos da conta, certas funções do console podem ser prejudicadas." Esse erro pode ser exibido por vários motivos. Pode ser porque sua conta não tem as permissões ou não tenha sido configurada corretamente. Se a sua conta for nova, talvez você não tenha esperado que ela ficasse pronta. Se for uma conta existente, talvez você não tenha permissões nas suas políticas de acesso para realizar determinadas ações, como criar uma instância de banco de dados. Para corrigir o problema, o administrador precisa fornecer os perfis necessários para a sua conta. Para ter mais informações, consulte a [documentação do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ## Redefinir a senha de proprietário da instância de banco de dados Se não conseguir acessar seu cluster de banco de dados, você poderá fazer login como o usuário mestre. Depois, você poderá redefinir as credenciais de outros usuários administrativos ou funções. Se não conseguir fazer login como usuário mestre, o proprietário da conta da AWS poderá redefinir a senha do usuário mestre. Para obter detalhes sobre quais contas administrativas ou funções deverão ser redefinidas, consulte [Privilégios da conta de usuário mestre](UsingWithRDS.MasterAccounts.md). É possível alterar a senha da instância de banco de dados usando o console do Amazon RDS, o comando da AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) ou a operação de API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html). Para ter mais informações sobre como modificar uma instância de banco de dados em um cluster de banco de dados, consulte [Modificar uma instância de banco de dados em um cluster de banco de dados](Aurora.Modifying.md#Aurora.Modifying.Instance). ## Interrupção ou reinicialização da instância de banco de dados do Amazon RDS Uma interrupção da instância de banco de dados pode ocorrer quando a instância de banco de dados é reinicializada. A interrupção também pode ocorrer quando a instância de banco de dados é colocada em um estado que impede o acesso a ela e quando o banco de dados é reiniciado. Uma reinicialização pode ocorrer ao reinicializar manualmente a instância de banco de dados. Uma reinicialização também pode ocorrer quando você altera uma configuração da instância de banco de dados que exija uma reinicialização para que tenha efeito. A reinicialização de uma instância de banco de dados só ocorre quando você altera uma configuração que exija uma reinicialização ou quando você faz uma reinicialização manualmente. Uma reinicialização poderá ocorrer imediatamente se você alterar uma configuração e solicitar que ela tenha efeito imediato. Ou isso pode ocorrer durante a janela de manutenção da instância de banco de dados. Uma reinicialização de instância de banco de dados ocorre imediatamente quando ocorre um dos seguintes eventos: + Você altera o período de retenção de backup para uma instância de banco de dados de 0 para um valor diferente de zero ou vice-versa. Depois, defina **Apply Immediately** (Aplicar imediatamente) como `true`. + Você altera a classe de instância de banco de dados, e **Apply Immediately (Aplicar imediatamente)** é definido como `true`. A reinicialização de uma instância de banco de dados ocorre durante a janela de manutenção quando ocorre um dos seguintes: + Você altera o período de retenção de backup para uma instância de banco de dados de 0 para um valor diferente de zero ou vice-versa e define **Apply Immediately (Aplicar imediatamente)** como `false`. + Você altera a classe de instância de banco de dados, e **Apply Immediately (Aplicar imediatamente)** é definido como `false`. Quando você altera um parâmetro estático em um grupo de parâmetros de banco de dados, a alteração não terá efeito até que a instância de banco de dados associada ao grupo de parâmetros seja reinicializada. A alteração requer uma reinicialização manual. A instância de banco de dados não é reinicializada automaticamente durante a janela de manutenção. ## Alterações de parâmetros de banco de dados do Amazon RDS que não entram em vigor Em alguns casos, talvez você altere um parâmetro em um grupo de parâmetros do banco de dados, mas não veja as alterações entrarem em vigor. Nesse caso, provavelmente será necessário reinicializar a instância de banco de dados associada ao grupo de parâmetros do banco de dados. Quando você altera um parâmetro dinâmico, a alteração entra em vigor imediatamente. Quando você altera um parâmetro estático, a alteração não entrará em vigor até que você reinicie a instância de banco de dados associada ao grupo de parâmetros. Você pode reinicializar uma instância de banco de dados usando o console do RDS. Ou você pode chamar explicitamente a operação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html) da API. Você poderá reinicializar sem failover se a instância de banco de dados estiver em uma implantação multi-AZ. A exigência de reinicializar a instância de banco de dados associada após uma alteração de parâmetro estático ajuda a atenuar o risco de que uma configuração incorreta de parâmetro afete uma chamada de API. Um exemplo disso é chamar `ModifyDBInstance` para alterar a classe de instância de banco de dados. Para ter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ## Problemas de memória liberável no Amazon Aurora *Memória liberável*é a memória total de acesso aleatório (RAM) em uma instância de banco de dados que pode ser disponibilizada para o mecanismo de banco de dados. É a soma da memória livre do sistema operacional (SO) e o buffer e a memória cache de página disponíveis. O mecanismo de banco de dados usa a maior parte da memória no host, mas os processos do sistema operacional também usam RAM. A memória atualmente alocada ao mecanismo de banco de dados ou usada pelos processos do sistema operacional não está incluída na memória liberável. Quando o mecanismo de banco de dados está ficando sem memória, a instância de banco de dados pode usar o espaço temporário normalmente usado para buffer e armazenamento em cache. Como mencionado anteriormente, esse espaço temporário está incluído na memória liberável. Você usa a métrica `FreeableMemory` no Amazon CloudWatch para monitorar a memória liberável. Para ter mais informações, consulte [Ferramentas de monitoramento do Amazon Aurora](MonitoringOverview.md). Se a instância de banco de dados for executada consistentemente com memória liberável ou usar espaço de troca, pense em aumentar a escala verticalmente para uma classe de instância de banco de dados maior. Para ter mais informações, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md). Também é possível alterar as configurações de memória. Por exemplo, no Aurora MySQL , você pode ajustar o tamanho do parâmetro `innodb_buffer_pool_size`. Esse parâmetro é definido por padrão como 75% da memória física. Para obter mais dicas sobre solução de problemas do MySQL, consulte [How can I troubleshoot low freeable memory in an Amazon RDS para MySQL database?](https://aws.amazon.com/premiumsupport/knowledge-center/low-freeable-memory-rds-mysql-mariadb/) (Como posso solucionar problemas de pouca memória liberável em um banco de dados do Amazon RDS para MySQL?) No caso do Aurora Serverless v2, `FreeableMemory` representa a quantidade de memória não utilizada que está disponível quando a instância de banco de dados do Aurora Serverless v2 é dimensionada para sua capacidade máxima. Você pode reduzir a escala da instância verticalmente para capacidade relativamente baixa, mas ela ainda relata um valor alto para `FreeableMemory`, porque é possível aumentar a escala da instância verticalmente. Essa memória não está disponível no momento, mas você poderá obtê-la se for necessário. Para cada unidade de capacidade do Aurora (ACU) em que a capacidade atual está abaixo da capacidade máxima, a `FreeableMemory` aumenta em cerca de 2 GiB. Assim, essa métrica não se aproxima de zero até que a escala da instância de banco de dados seja aumentada na vertical ao nível mais alto possível. Se essa métrica se aproximar de um valor de `0`, a escala da instância de banco de dados foi aumentada verticalmente o máximo possível. Está se aproximando do limite de sua memória disponível. Considere aumentar a configuração máxima de ACU para o cluster. Se essa métrica se aproximar de um valor de `0` em uma instância de banco de dados do leitor, considere adicionar mais instâncias de banco de dados do leitor ao cluster. Dessa forma, é possível distribuir a parte somente leitura da workload por mais instâncias de banco de dados, reduzindo o uso de memória em cada instância de banco de dados do leitor. Para obter mais informações, consulte [Métricas importantes do Amazon CloudWatch para o Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring). ## Problemas de replicação no Amazon Aurora MySQL Alguns problemas de replicação do MySQL também se aplicam ao Aurora MySQL. É possível diagnosticar e corrigir esses problemas. **Topics** + [Diagnosticar e resolver atrasos entre réplicas de leitura](#CHAP_Troubleshooting.MySQL.ReplicaLag) + [Diagnosticar e resolver uma falha de replicação de leitura do MySQL](#CHAP_Troubleshooting.MySQL.RR) + [Erro de replicação interrompida](#CHAP_Troubleshooting.MySQL.ReplicationStopped) + [A replicação da réplica de leitura falha ao inicializar a estrutura de metadados](#CHAP_Troubleshooting.MySQL.ReadReplicas.ReplicationErrorMetadata) ### Diagnosticar e resolver atrasos entre réplicas de leitura Depois de criar uma réplica de leitura MySQL e quando ela estiver disponível, o Amazon RDS primeiro replicará as alterações feitas na instância de banco de dados de origem a partir do momento em que a operação de criação da réplica de leitura foi iniciada. Durante essa fase, o tempo de atraso da replicação para a réplica de leitura será maior que 0. Você pode monitorar esse tempo de atraso no Amazon CloudWatch visualizando a métrica `AuroraBinlogReplicaLag` do Amazon RDS. A métrica `AuroraBinlogReplicaLag` informa o valor do campo `Seconds_Behind_Master` do comando `SHOW REPLICA STATUS` do MySQL. Para ter mais informações, consulte [Instrução SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) na documentação do MySQL. Quando a métrica `AuroraBinlogReplicaLag` chega a 0, isso mostra que a réplica alcançou a instância do banco de dados de origem. Se a métrica `AuroraBinlogReplicaLag` retornar -1, a replicação pode não estar ativa. Para solucionar um erro de replicação, consulte [Diagnosticar e resolver uma falha de replicação de leitura do MySQL ](#CHAP_Troubleshooting.MySQL.RR). Um `AuroraBinlogReplicaLag` com um valor de -1 também pode significar que o valor de `Seconds_Behind_Master` não pode ser determinado ou é `NULL`. **nota** As versões anteriores do Aurora MySQL usavam `SHOW SLAVE STATUS` em vez de `SHOW REPLICA STATUS`. Se você estiver utilizando o Aurora MySQL versão 1 ou 2, utilize `SHOW SLAVE STATUS`. Use `SHOW REPLICA STATUS` para o Aurora MySQL versão 3 e posteriores. A métrica `AuroraBinlogReplicaLag` retorna -1 durante uma interrupção da rede ou quando um patch é aplicado durante a janela de manutenção. Nesse caso, aguarde até que a conectividade de rede seja restaurada ou a janela de manutenção seja finalizada antes de verificar novamente a métrica `AuroraBinlogReplicaLag`. A tecnologia de replicação de leitura do MySQL é assíncrona. Portanto, é possível esperar aumentos ocasionais da métrica `BinLogDiskUsage` na instância de banco de dados de origem e da métrica `AuroraBinlogReplicaLag` na réplica de leitura. Por exemplo, considere uma situação em que um alto volume de operações de gravação para a instância de banco de dados de origem ocorra em paralelo. Ao mesmo tempo, as operações de gravação na réplica de leitura são serializadas usando um único thread de E/S. Tal situação pode levar a um atraso entre a instância de origem e a réplica de leitura. Para ter mais informações sobre réplicas de leitura e o MySQL, consulte [Detalhes da implementação da replicação](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html) na documentação do MySQL. . É possível reduzir o atraso entre as atualizações em uma instância de banco de dados de origem e as atualizações subsequentes da réplica de leitura fazendo o seguinte: + Defina a classe da instância de banco de dados da réplica de leitura para que ela tenha um tamanho de armazenamento comparável ao da instância de banco de dados de origem. + Certifique-se de que as configurações de parâmetros nos grupos de parâmetros do banco de dados utilizados pela instância de banco de dados de origem e pela réplica de leitura sejam compatíveis. Para ter mais informações e um exemplo, consulte a discussão sobre o parâmetro `max_allowed_packet` na próxima seção. + Desabilite o cache de consulta. Para tabelas que são modificadas com frequência, o uso do cache de consulta pode aumentar o atraso das réplicas, pois o cache é bloqueado e atualizado com frequência. Se esse for o caso, talvez você veja um atraso menor de réplicas se desabilitar o cache de consulta. É possível desabilitar o cache de consultas definindo `query_cache_type parameter` como 0 no grupo de parâmetros de banco de dados da instância de banco de dados. Para ter mais informações sobre o cache de consulta, consulte [Configuração do cache de consulta](https://dev.mysql.com/doc/refman/5.7/en/query-cache-configuration.html). + Aqueça o grupo de buffers na réplica de leitura do InnoDB para MySQL. Por exemplo, suponha que você tenha um pequeno conjunto de tabelas sendo atualizadas com frequência e esteja usando o esquema de tabela InnoDB ou XtraDB. Nesse caso, despeje essas tabelas na réplica de leitura. Isso faz com que o mecanismo de banco de dados explore as linhas dessas tabelas no disco e armazene-as em cache no grupo de buffers, o que pode reduzir o atraso das réplicas. Essa abordagem pode reduzir o atraso da réplica. Por exemplo: Para Linux, macOS ou Unix: ``` PROMPT> mysqldump \ -h {{}} \ --port={{}} \ -u={{}} \ -p {{}} \ database_name {{table1 table2}} > /dev/null ``` Para Windows: ``` PROMPT> mysqldump ^ -h {{}} ^ --port={{}} ^ -u={{}} ^ -p {{}} ^ database_name {{table1 table2}} > /dev/null ``` ### Diagnosticar e resolver uma falha de replicação de leitura do MySQL O Amazon RDS monitora o status de replicação de suas réplicas de leitura. O RDS atualiza o campo **Replication State** (Estado de replicação) da instância da réplica de leitura para `Error` caso a replicação seja interrompida por qualquer motivo. É possível analisar os detalhes do erro associado lançado pelos mecanismos do MySQL visualizando o campo **Replication Error (Erro de replicação)**. Os eventos que indicam o status da réplica de leitura também são gerados, incluindo [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) e [RDS-EVENT-0057](USER_Events.Messages.md#RDS-EVENT-0057). Para ter mais informações sobre eventos e como se inscrever neles, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md). Se for retornada uma mensagem de erro do MySQL, verifique o erro na [documentação de mensagens de erro do MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html). . Situações comuns que podem causar erros de replicação incluem o seguinte: + O valor do parâmetro `max_allowed_packet` para uma réplica de leitura é menor que o parâmetro `max_allowed_packet` para a instância do banco de dados de origem. O parâmetro `max_allowed_packet` é um parâmetro personalizado que você pode definir em um grupo de parâmetros de banco de dados. O parâmetro `max_allowed_packet` é usado para especificar o tamanho máximo de linguagem de manipulação de dados (DML) que pode ser executado no banco de dados. Em alguns casos, o valor `max_allowed_packet` para a instância de banco de dados de origem pode ser maior do que o valor `max_allowed_packet` para a réplica de leitura. Se sim, o processo de replicação poderá lançar um erro e interromper a replicação. O erro mais comum é `packet bigger than 'max_allowed_packet' bytes`. É possível corrigir o erro fazendo com que a origem e a réplica de leitura usem grupos de parâmetros de banco de dados com os mesmos valores do parâmetro `max_allowed_packet`. + A gravação em tabelas em uma réplica de leitura. Se você estiver criando índices em uma réplica de leitura, será necessário que o parâmetro `read_only` seja definido como *0* para criar os índices. Se você estiver gravando em tabelas na réplica de leitura, isso poderá interromper a replicação. + Uso de um mecanismo de armazenamento não transacional, como o MyISAM. As réplicas de leitura exigem um mecanismo de armazenamento transacional. A replicação só é compatível com os seguintes mecanismos de armazenamento: InnoDB para MySQL ou MariaDB. Você pode converter uma tabela MyISAM para o InnoDB com o seguinte comando: `alter table . engine=innodb;` + Usando consultas não deterministas inseguras, como `SYSDATE()`. Para ter mais informações, consulte [Determinar instruções seguras e não seguras em registros em logs binários](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) na documentação do MySQL. As seguintes etapas podem ajudar a resolver seu erro de replicação: + Se você encontrar um erro lógico e puder ignorar o erro com segurança, siga as etapas descritas em [Ignorar o erro de replicação atual](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.SkipError.html). Sua instância de banco de dados do Aurora MySQL deve estar executando uma versão que inclua o procedimento `mysql_rds_skip_repl_error`. Para ter mais informações, consulte [mysql\_rds\_skip\_repl\_error](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_skip_repl_error.html). + Se encontrar um problema de posição de log binário, você poderá alterar a posição de reprodução da réplica. Você faz isso com o comando `mysql.rds_next_master_log` do Aurora MySQL versões 1 e 2. Você faz isso com o comando `mysql.rds_next_source_log` do Aurora MySQL versões 3 e posteriores. Sua instância de banco de dados do Aurora MySQL deve estar executando uma versão com suporte a esse comando para alterar a posição de reprodução da réplica. Para obter informações sobre a versão, consulte [mysql\_rds\_next\_master\_log](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_next_master_log.html). + Se encontrar um problema de performance temporário devido à alta carga DML, você poderá definir o parâmetro `innodb_flush_log_at_trx_commit` como 2 no grupo de parâmetros do banco de dados da réplica de leitura. Fazer isso pode ajudar na recuperação da réplica de leitura, embora isso reduza temporariamente a atomicidade, a consistência, o isolamento e a durabilidade (ACID). + É possível excluir a réplica de leitura e criar uma instância usando o mesmo identificador de instância de banco de dados. Dessa forma, o endpoint permanecerá igual ao da réplica de leitura antiga. Se um erro de replicação for corrigido, o valor de **Replication State (Estado de replicação)** mudará para **replicating (replicando)**. Para ter mais informações, consulte [Solução de problemas da réplica de leitura do MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Troubleshooting.html). ### Erro de replicação interrompida Quando você chama o comando `mysql.rds_skip_repl_error`, você pode receber uma mensagem de erro informando que a replicação está inativa ou desabilitada. Esta mensagem de erro é exibida porque a replicação parou e não foi possível reiniciá-la. Se você precisar ignorar um grande número de erros, o atraso de replicação pode aumentar além do período de retenção padrão para arquivos de log binário. Nesse caso, você poderá encontrar um erro fatal, com os arquivos do log binário sendo limpos antes de sua reprodução na réplica. Essa remoção faz com que a replicação pare, e você não consegue chamar o comando `mysql.rds_skip_repl_error` para ignorar erros de replicação. Você pode mitigar esse problema aumentando o número de horas em que os arquivos de log binário são retidos na origem da replicação. Após aumentar o período de retenção de log binário, você pode reiniciar a replicação e chamar o comando `mysql.rds_skip_repl_error` conforme necessário. Para definir o tempo de retenção do log binário, use o procedimento [mysql\_rds\_set\_configuration](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Troubleshooting.html) . Especifique um parâmetro de configuração de "horas de retenção do log binário" juntamente com o número de horas para reter arquivos de log binário no cluster de banco de dados, até 2160 (90 dias). O padrão para Aurora MySQL é 24 (1 dia). O exemplo a seguir define o período de retenção para arquivos de log binário em 48 horas. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ### A replicação da réplica de leitura falha ao inicializar a estrutura de metadados Ao tentar iniciar a replicação, você recebeu a seguinte mensagem de erro: ``` Read Replica Replication Error - SQLError: 13124, reason: Replica failed to initialize applier metadata structure from the repository ``` Esse erro ocorre quando há um problema com a estrutura de metadados da réplica. Para corrigir a estrutura de metadados, você deve criar outra réplica. Para evitar que isso aconteça no futuro, execute uma das seguintes ações: + Se possível, desabilite o multithreading nas réplicas. A partir do MySQL 8.0.27, o multithreading é habilitado por padrão. + Se você precisar usar multithreading nas réplicas, recomendamos que use a replicação baseada em GTID. Para obter mais informações, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md).