Solução de problemas para o Amazon RDS - Amazon Relational Database Service

Solução de problemas para o Amazon RDS

Use as seções a seguir para solucionar problemas que possam surgir com instâncias de bancos de dados do Amazon RDS e do Aurora.

Para obter informações sobre como depurar problemas usando a API do Amazon RDS, consulte Solução de problemas de aplicações no Amazon RDS.

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 obter mais informações sobre como configurar um grupo de segurança, consulte Fornecer acesso à instância de banco de dados na VPC criando um grupo de segurança.

    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 um aplicativo 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 uma instância de banco de dados em uma VPC da Internet.

  • 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 AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

    2. No painel de navegação, escolha Databases (Bancos de dados) e escolha o nome da instância de banco de dados.

    3. 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).

    4. Abra o console da Amazon VPC em https://console.aws.amazon.com/vpc/.

    5. 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.

    6. No painel de navegação, selecione Sub-redes e selecione sua sub-rede.

    7. 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.

      1. Escolha o ID da tabela de rotas (rtb-xxxxxxxx) para navegar para a tabela de rotas.

      2. 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.

      3. Escolha Save routes (Salvar rotas).

    Para obter mais informações, consulte Trabalhar com uma instância de banco de dados em uma VPC.

Para problemas de conexão específicos do mecanismo, consulte os seguintes tópicos:

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 da 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

Se você puder se conectar à sua instância de banco de dados, mas receber erros de autenticação, convém redefinir a senha do usuário mestre para a instância de banco de dados. Isso pode ser feito ao modificar a instância do RDS.

Para obter mais informações sobre a modificação de uma instância de banco de dados , consulte Modificar uma instância de banco de dados do Amazon RDS.

Problemas de segurança do Amazon RDS

Para evitar problemas de segurança, nunca use o nome do usuário e a senha mestre da AWS para uma conta de usuário. A prática recomendada é usar sua conta mestre da AWS para criar usuários do AWS Identity and Access Management IAM e atribuí-los a contas de usuário de banco de dados. Você também pode usar sua conta mestre para criar outras contas de usuário, se necessário.

Para obter mais informações sobre como criar usuários do IAM, consulte Criar um usuário do IAM.

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 do IAM precisa fornecer as funções necessárias para a sua conta. Para obter mais informações, consulte a documentação do IAM.

Redefinir a senha de proprietário da instância de banco de dados

Se não conseguir acessar sua instância 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.

É 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 ou a operação de API ModifyDBInstance. Para obter mais informações sobre a modificação de uma instância de banco de dados , consulte Modificar uma instância de banco de dados do Amazon RDS.

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 quando você reinicia manualmente sua instância de banco de dados ou altera uma configuração da instância de banco de dados que requer uma reinicialização para poder entrar em vigor.

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 a alteração tenha efeito imediato ou 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 e define 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.

  • Você altera o tipo de armazenamento de Magnetic (Standard) (Magnético (padrão)) para General Purpose (SSD) (Finalidade geral (SSD)) ou Provisioned IOPS (SSD) (IOPS provisionadas (SSD)) ou de Provisioned IOPS (SSD) (IOPS provisionadas (SSD)) ou General Purpose (SSD) (Finalidade geral (SSD)) para Magnetic (Standard) (Magnético (padrão)).

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.

Para ver uma tabela que mostra as ações das instâncias de bancos de dados e o efeito de configurar o valor Apply Immediately, consulte Modificar uma instância de banco de dados do Amazon RDS.

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.

É possível reinicializar uma instância de banco de dados usando o console do RDS ou chamando explicitamente a operação de API RebootDBInstance (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 pode ser chamar ModifyDBInstance para alterar a classe da instância de banco de dados. Para obter mais informações, consulte Modificar parâmetros em um grupo de parâmetros de banco de dados.

Instância de banco de dados do Amazon RDS ficando sem espaço de armazenamento

Se a sua instância de banco de dados ficar sem espaço de armazenamento, talvez ela se torne indisponível. Recomendamos que você monitore constantemente a métrica FreeStorageSpace publicada no CloudWatch para garantir que a sua instância de banco de dados tenha espaço de armazenamento livre suficiente.

Se a instância de banco de dados ficar sem armazenamento, seu status será alterado para storage-full. Por exemplo, uma chamada para a operação de API DescribeDBInstances para uma instância de banco de dados que esgotou seu armazenamento emitirá o seguinte:

aws rds describe-db-instances --db-instance-identifier mydbinstance DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Para solucionar esse cenário, adicione mais espaço de armazenamento à instância usando a operação de API ModifyDBInstance ou o comando da AWS CLI a seguir.

Para Linux, macOS ou Unix:

aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --allocated-storage 60 \ --apply-immediately

Para Windows:

aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --allocated-storage 60 ^ --apply-immediately
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Agora, quando descrever sua instância de banco de dados, você verá que ela terá o status modifying, o que indica que o armazenamento está sendo dimensionado.

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa modifying mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Após a conclusão do dimensionamento do armazenamento, o status da instância de banco de dados mudará para available.

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 60 sa available mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Ao usar a operação DescribeEvents, é possível que você receba notificações quando seu espaço estiver esgotado. Por exemplo, nesse cenário, se fizer uma chamada DescribeEvents depois dessas operações, você verá a seguinte saída:

aws rds describe-events --source-type db-instance --source-identifier mydbinstance
2009-12-22T23:44:14.374Z mydbinstance Allocated storage has been exhausted db-instance 2009-12-23T00:14:02.737Z mydbinstance Applying modification to allocated storage db-instance 2009-12-23T00:31:54.764Z mydbinstance Finished applying modification to allocated storage

Capacidade insuficiente da instância de banco de dados do Amazon RDS

O erro InsufficientDBInstanceCapacity pode ser retornado ao tentar criar, iniciar ou modificar uma instância de banco de dados ou ao tentar restaurar uma instância de banco de dados de um snapshot de banco de dados. Quando esse erro é retornado, estas são as causas comuns:

  • A classe de instância de banco de dados específica não está disponível na zona de disponibilidade solicitada. É possível tentar uma das seguinte opções para resolver o problema:

    • Repita a solicitação com uma classe de instância de banco de dados diferente.

    • Repita a solicitação com uma zona de disponibilidade diferente.

    • Repita a solicitação sem especificar uma zona de disponibilidade explícita.

    Para obter informações sobre como solucionar problemas de capacidade de instância para o Amazon EC2, consulte Capacidade da instância insuficiente no Guia do usuário do Amazon Elastic Compute Cloud.

  • A instância de banco de dados está na plataforma EC2-Classic e, portanto, não está em uma VPC. Algumas classes de instância de banco de dados requerem uma VPC. Por exemplo, se você estiver na plataforma EC2-Classic e tentar aumentar a capacidade mudando para uma classe de instância de banco de dados que exija uma VPC, receberá esse erro. Para obter informações sobre os tipos de instância do Amazon EC2 que estão disponíveis em uma VPC, consulte Tipos de instância disponíveis no EC2-Classic no Guia do usuário do Amazon Elastic Compute Cloud. Para corrigir o problema, você pode mover a instância de banco de dados para uma VPC. Para obter mais informações, consulte Mover uma instância de banco de dados fora de uma VPC para uma VPC.

Para mais informações sobre a modificação de uma instância de banco de dados , consulte Modificar uma instância de banco de dados do Amazon RDS.

Problemas no MySQL e MariaDB

É possível diagnosticar e corrigir problemas em instâncias de banco de dados MySQL e MariaDB.

Máximo de conexões MySQL e MariaDB

O número máximo de conexões permitidas para uma instância de banco de dados RDS for MySQL ou RDS for MariaDB baseia-se na quantidade de memória disponível para a classe de instância de banco de dados. Uma classe de instância de banco de dados com mais memória disponível resulta em um número maior de conexões disponíveis. Para mais informações sobre classes de instância de banco de dados, consulte Classes de instância de banco de dados .

O limite de conexão para uma instância de banco de dados é definido por padrão como o máximo para a classe de instância de banco de dados. É possível limitar o número de conexões simultâneas a qualquer valor até o número máximo de conexões permitidas. Use o parâmetro max_connections no grupo de parâmetros para a instância de banco de dados. Para obter mais informações, consulte Número máximo de conexões de banco de dados e Como trabalhar com grupos de parâmetros de banco de dados.

É possível recuperar o número máximo de conexões permitidas para uma instância de banco de dados MySQL ou MariaDB executando a consulta a seguir.

SELECT @@max_connections;

É possível recuperar o número de conexões ativas para uma instância de banco de dados MySQL ou MariaDB executando a consulta a seguir.

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

Diagnosticar e resolver o status de parâmetros incompatíveis para um limite de memória

Uma instância de banco de dados MariaDB ou MySQL pode ser colocada no status incompatible parameters (parâmetros incompatíveis) para limitar a memória quando as duas seguintes condições forem atendidas:

  • A instância de banco de dados foi reiniciada pelo menos três vezes em uma hora ou pelo menos cinco vezes em um dia, ou houve uma tentativa de reiniciar a instância que falhou.

  • O uso de memória potencial da instância de banco de daos excedeu 1,2 vezes a memória alocada para a respectiva classe de instância de banco de dados.

Quando uma instância de banco de dados é reiniciada pela terceira vez em uma hora ou pela quinta vez em um dia, o Amazon RDS for MySQL executará uma verificação de uso de memória. A verificação faz com que o cálculo do potencial uso de memória da instância de banco de dados. O valor retornado pelo cálculo é a soma dos seguintes valores:

  • Valor 1 – a soma dos seguintes parâmetros:

    • innodb_additional_mem_pool_size

    • innodb_buffer_pool_size

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size (MySQL versão 5.6 e 5.7 somente)

    • tmp_table_size

  • Valor 2 – o max_connections parâmetro multiplicado pela soma dos seguintes parâmetros:

    • binlog_cache_size

    • join_buffer_size

    • read_buffer_size

    • read_rnd_buffer_size

    • sort_buffer_size

    • thread_stack

  • Valor 3 – se o parâmetro performance_schema estiver habilitado, multiplique o parâmetro max_connections por 257700.

    Se o parâmetro performance_schema estiver desabilitado, esse valor será zero.

Então, o valor retornado pelo cálculo é o seguinte:

Value 1 + Value 2 + Value 3

Quando esse valor excede 1,2 vezes a memória alocada para a classe da instância de banco de dados, essa instância é colocada no status incompatible-parameters (parâmetros incompatíveis). Para obter mais informações sobre a memória alocada para as classes de instâncias de banco de dados , consulte Especificações de hardware para classes de instância de banco de dados .

O cálculo multiplica o valor do parâmetro max_connections pela soma de vários parâmetros. Se o parâmetro max_connections for definido para um valor grane, é possível que a verificação retorne um valoro elevado para o uso potencial de memória da instância de banco de dados. Nesse caso, avalie a possibilidade de reduzir o valor do parâmetro max_connections.

Para resolver o problema, conclua as seguintes etapas:

  1. Ajuste os parâmetros de memória no grupo de parâmetros de banco de dados associado à instância de banco de dados para que o uso potencial de memória seja menor que 1,2 vezes a memória alocada para sua classe de instância de banco de dados.

    Para obter informações sobre como configurar parâmetros, consulte Modificar parâmetros em um grupo de parâmetros de banco de dados.

  2. Reinicie a instância de banco de dados.

    Para obter informações sobre como configurar parâmetros, consulte Iniciar uma instância de banco de dados do Amazon RDS que foi anteriormente interrompida.

Diagnosticar e resolver atrasos entre réplicas de leitura

Depois de criar uma réplica de leitura MySQL ou MariaDB 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 ReplicaLag do Amazon RDS.

A métrica ReplicaLag informa o valor do campo Seconds_Behind_Master do comando SHOW REPLICA STATUS do MariaDB ou MySQL. Para obter mais informações, consulte SHOW REPLICA STATUS (Exibir status da réplica). Quando a métrica ReplicaLag chega a 0, isso mostra que a réplica alcançou a instância do banco de dados de origem. Se a métrica ReplicaLag 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 ou MariaDB. Um ReplicaLag 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 MariaDB e MySQL usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver usando uma versão do MariaDB anterior à 10.5 ou uma versão do MySQL anterior à 8.0.23, use SHOW SLAVE STATUS.

A métrica ReplicaLag 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 ReplicaLag.

A tecnologia de replicação de leitura do MySQL e do MariaDB é assíncrona. Portanto, você pode esperar aumentos ocasionais da métrica BinLogDiskUsage na instância de banco de dados de origem e da métrica ReplicaLag 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 obter mais informações sobre réplicas de leitura e o MySQL, consulte Detalhes da implementação da replicação na documentação do MySQL. Para obter mais informações sobre réplicas de leitura e o MariaDB, consulte Visão geral sobre a replicação na documentação do MariaDB.

É 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 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 parameter group de banco de dados da instância de banco de dados. Para obter mais informações sobre o cache de consulta, consulte Configuração do cache de consulta.

  • Aqueça o grupo de buffers na réplica de leitura do InnoDB para MySQL ou MariaDB. 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 <endpoint> \ --port=<port> \ -u=<username> \ -p <password> \ database_name table1 table2 > /dev/null

    Para Windows:

    PROMPT> mysqldump ^ -h <endpoint> ^ --port=<port> ^ -u=<username> ^ -p <password> ^ database_name table1 table2 > /dev/null

Diagnosticar e resolver uma falha de replicação de leitura do MySQL ou MariaDB

O Amazon RDS monitora o status de replicação de suas réplicas de leitura e 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 ou MariaDB 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, RDS-EVENT-0046 e RDS-EVENT-0047. Para mais informações sobre eventos e como se inscrever neles, consulte Usar a notificação de evento do Amazon RDS. Se for retornada uma mensagem de erro do MySQL, verifique o erro na documentação de mensagens de erro do MySQL. Se for retornada uma mensagem de erro do MariaDB, verifique o erro na documentação de mensagens de erro do MariaDB.

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. Se o valor de max_allowed_packet para a instância de banco de dados de origem for maior que o valor de max_allowed_packet para a réplica de leitura, 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 <schema>.<table_name> engine=innodb;

  • Usando consultas não deterministas inseguras, como SYSDATE(). Para obter mais informações, consulte Determinar instruções seguras e não seguras em registros em logs binários 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. Sua instância de banco de dados MySQL ou MariaDB deve estar executando uma versão que inclua o procedimento mysql_rds_skip_repl_error. Para obter mais informações, consulte mysql.rds_skip_repl_error.

  • Se encontrar um problema de posição de log binários, você poderá alterar a posição de reprodução da réplica com o comando mysql_rds_next_master_log. Sua instância de banco de dados MySQL ou MariaDB deve estar executando uma versão que ofereça suporte ao comando mysql_rds_next_master_log para alterar a posição de reprodução da réplica. Para obter informações sobre versões, consulte mysql.rds_next_master_log.

  • Se encontrar um problema de desempenho 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. Se você fizer isso, 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 obter mais informações, consulte Solucionar problemas de uma réplica de leitura do MySQL.

Criar triggers com o registro de logs binários habilitado requer o privilégio SUPER

Ao tentar criar triggers em uma instância de banco de dados RDS for MySQL ou RDS for MariaDB, você pode receber o seguinte erro:

"You do not have the SUPER privilege and binary logging is enabled"

Para usar triggers quando o registro em logs binários está habilitado, é necessário ter o privilégio SUPER, que é restrito para as instâncias de bancos de dados RDS for MySQL e RDS for MariaDB. Você pode criar triggers quando o registro em logs binários está habilitado sem o privilégio SUPER, definindo o parâmetro log_bin_trust_function_creators como true. Para definir log_bin_trust_function_creators como true., crie um novo parameter group de banco de dados ou modifique um parameter group de banco de dados existente.

Para criar um novo grupo de parâmetros de banco de dados que permita criar triggers na sua instância de banco de dados RDS for MySQL e RDS for MariaDB com registro em logs binários habilitado, use os seguintes comandos da CLI. Para modificar um parameter group existente, comece com a etapa 2.

Para criar um novo parameter group de forma a permitir triggers com o registro em logs binários habilitado usando a CLI

  1. Crie um novo parameter group.

    Para Linux, macOS ou Unix:

    aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql8.0 \ --description "parameter group allowing triggers"

    Para Windows:

    aws rds create-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --db-parameter-group-family mysql8.0 ^ --description "parameter group allowing triggers"
  2. Modifique o parameter group de banco de dados para permitir triggers.

    Para Linux, macOS ou Unix:

    aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

    Para Windows:

    aws rds modify-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"
  3. Modifique sua instância de banco de dados para usar o novo parameter group de banco de dados.

    Para Linux, macOS ou Unix:

    aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --db-parameter-group-name allow-triggers \ --apply-immediately

    Para Windows:

    aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --db-parameter-group-name allow-triggers ^ --apply-immediately
  4. Para que as alterações entrem em vigor, reinicialize manualmente a instância de banco de dados.

    aws rds reboot-db-instance --db-instance-identifier mydbinstance

Diagnosticar e resolver falhas de restauração pontual

Restauração de uma instância de banco de dados que inclui tabelas temporárias

Ao tentar uma restauração para um ponto específico (PITR) da sua instância de banco de dados MySQL ou MariaDB, você pode encontrar o seguinte erro:

Database instance could not be restored because there has been incompatible database activity for restore functionality. Common examples of incompatible activity include using temporary tables, in-memory tables, or using MyISAM tables. In this case, use of Temporary table was detected.

A PITR depende do snapshot do backup e dos logs binários (binlogs) do MySQL ou do MariaDB para restaurar sua instância de banco de dados para um momento específico. As informações de tabelas temporárias podem ser pouco confiáveis nos logs binários e podem causar uma falha na PITR. Se você usar tabelas temporárias na sua instância de banco de dados MySQL ou MariaDB, poderá minimizar a possibilidade de uma falha de PITR realizando backups mais frequentes. Uma falha de PITR é mais provável no momento entre a criação de uma tabela temporária e o próximo snapshot de backup.

Restauração de uma instância de banco de dados que inclui tabelas na memória

Você pode encontrar um problema ao restaurar um banco de dados que possua tabelas na memória. As tabelas na memória são limpas durante uma reinicialização. Como resultado, suas tabelas na memória podem ficar vazias após uma reinicialização. Recomendamos que, ao usar tabelas na memória, você arquitete sua solução para lidar com tabelas vazias em caso de uma reinicialização. Se você estiver usando tabelas na memória com instâncias de banco de dados replicadas, talvez seja necessário recriar as réplicas de leitura após uma reinicialização. Isso pode ser necessário se uma réplica de leitura for reinicializada e não conseguir restaurar dados de uma tabela vazia na memória.

Para obter mais informações sobre backups e PITR, consulte Trabalhar com backups e Restauração de uma instance de banco de dados para um tempo especificado.

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 devido a arquivos de log binário sendo removidos antes de terem sido reproduzidos 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. 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é 720 (30 dias). 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);

Falha na criação da réplica de leitura ou interrupção da replicação com o erro fatal 1236

Depois de alterar os valores de parâmetro padrão para uma instância de banco de dados MySQL ou MariaDB, você pode encontrar um dos seguintes problemas:

  • É possível criar uma réplica de leitura para a instância de banco de dados.

  • A replicação falha com fatal error 1236.

Alguns valores de parâmetro padrão para instâncias de banco de dados MySQL e MariaDB ajudam a garantir que o banco de dados seja compatível com ACID e que as réplicas de leitura estejam protegidas contra falhas. Eles fazem isso garantindo que cada confirmação seja totalmente sincronizada gravando a transação no log binário antes de ser confirmada. Alterar esses parâmetros de seus valores padrão para melhorar o desempenho pode fazer com que haja falha na replicação quando uma transação não for gravada no log binário.

Para resolver esse problema, defina os seguintes valores de parâmetros:

  • sync_binlog = 1

  • innodb_support_xa = 1

  • innodb_flush_log_at_trx_commit = 1

Não é possível definir o período de retenção de backup como 0

Há várias razões pelas quais pode ser necessário definir o período de retenção de backup como 0. Por exemplo, você pode desativar os backups automáticos imediatamente ao configurar o período de retenção como 0.

Em alguns casos, é possível definir o valor como 0 e receber uma mensagem dizendo que o período de retenção deve estar entre 1 e 35. Nesses casos, verifique se você não configurou uma réplica de leitura para a instância. As réplicas de leitura exigem backups para o gerenciamento dos logs de réplica de leitura, portanto, não será possível definir o período de retenção como 0.