Trabalhar com réplicas de leitura do MariaDB - Amazon Relational Database Service

Trabalhar com réplicas de leitura do MariaDB

Encontre a seguir informações específicas sobre como trabalhar com réplicas de leitura no Amazon RDS para MariaDB. Para obter informações gerais sobre as réplicas de leitura e as instruções de como usá-las, consulte Trabalhar com réplicas de leitura de instância de banco de dados.

Configurar réplicas de leitura com o MariaDB

Para que uma instância de banco de dados do MariaDB possa servir como uma fonte de replicação, você deve ativar os backups automáticos na instância de banco de dados de origem definindo o período de retenção do backup como um valor diferente de 0. Esse requisito também se aplica a uma réplica de leitura que seja a instância de banco de dados de origem de outra réplica de leitura.

Você pode criar até quinze réplicas de leitura de uma instância de banco de dados na mesma região. Para que a replicação funcione efetivamente, cada réplica de leitura deve ter a mesma quantidade de recursos de computação e armazenamento que a instância de banco de dados de origem. Se você dimensionar a instância de banco de dados de origem, dimensione as réplicas de leitura também.

O RDS para MariaDB é compatível com réplicas de leitura em cascata. Para saber mais sobre como configurar réplicas de leitura em cascata, consulte Usar réplicas de leitura em cascata com o RDS para MariaDB.

É possível executar várias ações simultâneas de criação ou exclusão de réplicas de leitura que fazem referência à mesma instância de banco de dados de origem. Ao realizar essas ações, permaneça dentro do limite de quinze réplicas de leitura para cada instância de origem.

Configurar filtros de replicação com o MariaDB

Você pode usar filtros de replicação para especificar quais bancos de dados e tabelas são replicados com uma réplica de leitura. Os filtros de replicação podem incluir bancos de dados e tabelas na replicação ou excluí-los da replicação.

Veja a seguir alguns casos de uso para filtros de replicação:

  • Para reduzir o tamanho de uma réplica de leitura. Com a filtragem de replicação, você pode excluir os bancos de dados e tabelas que não são necessários na réplica de leitura.

  • Para excluir bancos de dados e tabelas de réplicas de leitura por motivos de segurança.

  • Para replicar diferentes bancos de dados e tabelas para casos de uso específicos em diferentes réplicas de leitura. Por exemplo, você pode usar réplicas de leitura específicas para análise ou fragmentação.

  • Para uma instância de banco de dados que tenha réplicas de leitura em diferentes Regiões da AWS, para replicar diferentes bancos de dados ou tabelas em diferentes Regiões da AWS.

nota

É possível usar filtros de replicação para especificar quais bancos de dados e tabelas serão replicados com uma instância de banco de dados primária do MariaDB configurada como uma réplica em uma topologia de replicação de entrada. Para obter mais informações sobre essa configuração, consulte Configurar a replicação da posição do arquivo de log binário com uma instância de origem externa.

Definir parâmetros de filtragem de replicação do RDS para MariaDB

Para configurar filtros de replicação, defina os seguintes parâmetros de filtragem de replicação na réplica de leitura:

  • replicate-do-db – Replicar alterações nos bancos de dados especificados. Quando você define esse parâmetro para uma réplica de leitura, somente os bancos de dados especificados no parâmetro são replicados.

  • replicate-ignore-db – Não replique as alterações nos bancos de dados especificados. Quando o parâmetro replicate-do-db é definido para uma réplica de leitura, esse parâmetro não é avaliado.

  • replicate-do-table – Replicar alterações nas tabelas especificadas. Quando você define esse parâmetro para uma réplica de leitura, somente as tabelas especificadas no parâmetro são replicadas. Além disso, quando o parâmetro replicate-do-db ou replicate-ignore-db é definido, o banco de dados que inclui as tabelas especificadas deve ser incluído na replicação com a réplica de leitura.

  • replicate-ignore-table – Não replique as alterações nas tabelas especificadas. Quando o parâmetro replicate-do-table é definido para uma réplica de leitura, esse parâmetro não é avaliado.

  • replicate-wild-do-table – Replicar tabelas com base nos padrões de nome de banco de dados e tabela especificados. Os caracteres curinga % e _ são compatíveis. Quando o parâmetro replicate-do-db ou replicate-ignore-db estiver definido, certifique-se de incluir o banco de dados que inclui as tabelas especificadas na replicação com a réplica de leitura.

  • replicate-wild-ignore-table – Não replique tabelas com base nos padrões de nome de banco de dados e tabela especificados. Os caracteres curinga % e _ são compatíveis. Quando o parâmetro replicate-do-table ou replicate-wild-do-table é definido para uma réplica de leitura, esse parâmetro não é avaliado.

Os parâmetros são avaliados na ordem em que estão listados. Para obter mais informações sobre como esses parâmetros funcionam, consulte a documentação do MariaDB.

Por padrão, cada um desses parâmetros tem um valor vazio. Em cada réplica de leitura, você pode usar esses parâmetros para definir, alterar e excluir filtros de replicação. Quando você define um desses parâmetros, separe cada filtro dos outros com uma vírgula.

Você pode usar % os caracteres curinga _ e nos parâmetros replicate-wild-do-table e replicate-wild-ignore-table. O curinga % corresponde a qualquer número de caracteres e o caractere curinga _ corresponde apenas a um caractere.

O formato de log binário da instância de banco de dados de origem é importante para replicação porque determina o registro de alterações de dados. A configuração do parâmetro binlog_format determina se a replicação é baseada em linha ou baseada em declaração. Para obter mais informações, consulte Formato de registro em log binário.

nota

Todas as instruções DDL (Data Definition Language, linguagem de definição de dados) são replicadas como instruções, independentemente da binlog_format configuração na instância de banco de dados de origem.

banco de dados primário filtragem de replicação do RDS para MariaDB

As seguintes limitações se aplicam à filtragem de replicação do RDS para MariaDB:

  • Cada parâmetro de filtragem de replicação tem um limite de 2.000 caracteres.

  • As vírgulas não são compatíveis em filtros de replicação.

  • As opções binlog_do_db e binlog_ignore_db do MariaDB para filtragem de log binário não são compatíveis.

  • A filtragem de replicação não suporta transações XA.

    Para obter mais informações, consulte Restrictions on XA Transactions na documentação do MySQL.

  • A filtragem de replicação não é compatível com o RDS para MariaDB versão 10.2.

Exemplos de filtragem de replicação no RDS para MariaDB

Para configurar a filtragem de replicação para uma réplica de leitura, modifique os parâmetros de filtragem de replicação no grupo de parâmetros associado à réplica de leitura.

nota

Não é possível modificar um grupo de parâmetros padrão. Se a réplica de leitura estiver usando um grupo de parâmetros padrão, crie um novo grupo de parâmetros e o associe à instância de banco de dados. Para obter mais informações sobre grupos de parâmetros de banco de dados, consulte Grupos de parâmetros para Amazon RDS.

Você pode definir parâmetros em um grupo de parâmetros usando a AWS Management Console, a AWS CLI ou a API do RDS. Para obter informações sobre como configurar parâmetros, consulte Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS. Quando você define parâmetros em um grupo de parâmetros, todas as instâncias de banco de dados associadas ao grupo de parâmetros usam as configurações de parâmetro. Se você definir os parâmetros de filtragem de replicação em um grupo de parâmetros, verifique se o grupo de parâmetros está associado apenas a réplicas de leitura. Deixe os parâmetros de filtragem de replicação vazios para instâncias de banco de dados de origem.

Os exemplos a seguir definem os parâmetros usando o AWS CLI. Estes exemplos definem ApplyMethod para immediate de modo que as mudanças do parâmetro ocorram imediatamente depois que o comando CLI termina. Se você quiser que uma alteração pendente seja aplicada depois que a réplica de leitura for reinicializada, defina como ApplyMethod pending-reboot.

Os exemplos a seguir definem filtros de replicação:

exemplo Incluir bancos de dados em replicação

O exemplo a seguir inclui os bancos de dados mydb1 e mydb2 na replicação. Quando você define replicate-do-db para uma réplica de leitura, somente os bancos de dados especificados no parâmetro são replicados.

Para Linux, macOS ou Unix:

aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"

Para Windows:

aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
exemplo Incluir tabelas na replicação

O exemplo a seguir inclui as tabelas table1 e table2 no banco de dados mydb1 na replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"

Para Windows:

aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
exemplo Incluir tabelas na replicação usando caracteres curinga

O exemplo a seguir inclui tabelas com nomes que começam com orders e returns no banco de dados mydb na replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"

Para Windows:

aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
exemplo Caracteres de escape curinga em nomes

O exemplo a seguir mostra como usar o caractere de escape \ para liberar um caractere curinga que faz parte de um nome.

Suponha que você tenha vários nomes de tabela no banco de dados mydb1 que começam com my_table, e você deseja incluir essas tabelas na replicação. Os nomes das tabelas incluem um sublinhado, que também é um caractere curinga, portanto, o exemplo escapa ao sublinhado nos nomes das tabelas.

Para Linux, macOS ou Unix:

aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"

Para Windows:

aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
exemplo Excluir bancos de dados da replicação

O exemplo a seguir exclui os bancos de dados mydb1 e mydb2 da replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"

Para Windows:

aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
exemplo Excluir tabelas da replicação

O exemplo a seguir exclui tabelas table1 e table2 no banco de dados mydb1 da replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"

Para Windows:

aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
exemplo Excluir tabelas da replicação usando caracteres curinga

O exemplo a seguir exclui tabelas com nomes que começam com orders e returns no banco de dados mydb da replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"

Para Windows:

aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"

Visualizar os filtros de replicação para uma réplica de leitura

Você pode visualizar os filtros de replicação de uma réplica de leitura das seguintes maneiras:

  • Verifique as configurações dos parâmetros de filtragem de replicação no grupo de parâmetros associado à réplica de leitura.

    Para obter instruções, consulte Visualizar valores de parâmetros para um grupo de parâmetros de banco de dados no Amazon RDS.

  • Em um cliente MariaDB, conecte-se à réplica de leitura e execute a instrução SHOW REPLICA STATUS.

    Na saída, os campos a seguir mostram os filtros de replicação para a réplica de leitura:

    • Replicate_Do_DB

    • Replicate_Ignore_DB

    • Replicate_Do_Table

    • Replicate_Ignore_Table

    • Replicate_Wild_Do_Table

    • Replicate_Wild_Ignore_Table

    Para obter mais informações sobre esses campos, consulte Verificar o status da replicação na documentação do MySQL.

    nota

    Versões anteriores do MariaDB usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver usando uma versão do MariaDB anterior à 10.5, use SHOW SLAVE STATUS.

Configurar a replicação atrasada com o MariaDB

Você pode usar a replicação atrasada como uma estratégia para a recuperação de desastres. Com a replicação atrasada, você especifica o tempo mínimo, em segundos, para atrasar a replicação da origem para a réplica de leitura. Em caso de um desastre, como uma tabela excluída acidentalmente, você executa as seguintes etapas para recuperar-se rapidamente do desastre:

nota
  • A replicação atrasada é compatível com o MariaDB 10.6 e posteriores.

  • Use procedimentos armazenados para configurar a replicação atrasada. Você não pode configurar a replicação atrasada com o AWS Management Console, a AWS CLI ou a API do Amazon RDS.

  • Você pode usar a replicação com base em identificadores de transação global (GTIDs) em uma configuração de replicação atrasada.

Configurar replicação atrasada durante a criação da réplica de leitura

Para configurar a replicação atrasada para qualquer réplica de leitura futura criada a partir de uma instância de banco de dados, execute o procedimento armazenado mysql.rds_set_configuration com o parâmetro target delay.

Para configurar a replicação atrasada durante a criação da réplica de leitura
  1. Usando um cliente MariaDB, conecte-se à instância de banco de dados MariaDB que será a origem para réplicas de leitura como o usuário primário.

  2. Execute o procedimento armazenado mysql.rds_set_configuration com o parâmetro target delay.

    Por exemplo, execute o procedimento armazenado a seguir para especificar que a replicação é atrasada em pelo menos uma hora (3,600 segundos) para qualquer réplica de leitura criada a partir da instância de banco de dados atual.

    call mysql.rds_set_configuration('target delay', 3600);
    nota

    Após executar esse procedimento armazenado, qualquer réplica de leitura que você criar usando a AWS CLI ou a API do Amazon RDS será configurada com a replicação atrasada pelo número de segundos especificado.

Modificar replicação atrasada de uma réplica de leitura existente

Para modificar a replicação atrasada para uma réplica de leitura existente, execute o procedimento armazenado mysql.rds_set_source_delay.

Para modificar a replicação atrasada para uma réplica de leitura existente
  1. Usando um cliente do MariaDB, conecte-se à réplica de leitura como o usuário primário.

  2. Use o procedimento armazenado mysql.rds_stop_replication para interromper a replicação.

  3. Execute o procedimento armazenado mysql.rds_set_source_delay.

    Por exemplo, execute o procedimento armazenado a seguir para especificar que a replicação para a réplica de leitura é atrasada em pelo menos uma hora (3.600 segundos) para qualquer réplica de leitura criada a partir da instância de banco de dados atual.

    call mysql.rds_set_source_delay(3600);
  4. Use o procedimento armazenado mysql.rds_start_replication para iniciar a replicação.

Promover uma réplica de leitura

Após a replicação ser interrompida, em um cenário de recuperação de desastres, você pode promover uma réplica de leitura para ser a nova instância de banco de dados de origem. Para obter informações sobre como promover uma réplica de leitura, consulte Promoção de uma réplica de leitura a uma instância de banco de dados autônoma.

Atualizar réplicas de leitura com o MariaDB

As réplicas de leitura foram projetadas para oferecer suporte a consultas de leitura, mas você pode precisar fazer atualizações ocasionais. Por exemplo, talvez seja necessário adicionar um índice para acelerar tipos específicos de consultas que acessam a réplica. Você pode habilitar as atualizações configurando o parâmetro read_only como 0 no grupo de parâmetros de banco de dados da réplica de leitura.

Trabalhar com implantações de réplicas de leitura multi-AZ com o MariaDB

É possível criar uma réplica de leitura a partir de implantações de instâncias de banco de dados single-AZ ou multi-AZ. Você pode usar implantações multi-AZ para melhorar a durabilidade e a disponibilidade de dados essenciais. No entanto, não é possível usar o multi-AZ secundário para atender a consultas somente leitura. Em vez disso, crie réplicas de leitura de instâncias de banco de dados multi-AZ de alto tráfego para descarregar consultas somente leitura. Se a instância de origem de uma implantação multi-AZ falhar na secundária, todas as réplicas de leitura associadas serão automaticamente alteradas para usar a secundária (não a primária) como a origem de replicação. Para obter mais informações, consulte Configurar e gerenciar uma implantação multi-AZ.

É possível criar uma réplica de leitura como uma instância de banco de dados multi-AZ. O Amazon RDS cria um em modo de espera de sua réplica em outra zona de disponibilidade para suporte a failover da réplica. Você pode criar a réplica de leitura como uma instância de banco de dados multi-AZ independentemente de o banco de dados de origem ser ou não uma instância de banco de dados multi-AZ.

Usar réplicas de leitura em cascata com o RDS para MariaDB

O RDS para MariaDB é compatível com réplicas de leitura em cascata. Com réplicas de leitura em cascata, é possível escalar leituras sem adicionar sobrecarga à instância de banco de dados do RDS para MariaDB de origem.

Com réplicas de leitura em cascata, sua instância de banco de dados do RDS para MariaDB envia dados para a primeira réplica de leitura da cadeia. Essa réplica de leitura envia dados para a segunda réplica na cadeia e assim por diante. O resultado final é que todas as réplicas de leitura na cadeia têm as alterações da instância de banco de dados do RDS para MariaDB, mas sem a sobrecarga apenas na instância de banco de dados de origem.

É possível criar uma série de até três réplicas de leitura em uma cadeia de uma instância de banco de dados de origem do RDS para MariaDB. Por exemplo, suponha que você tenha uma instância de banco de dados do RDS para MariaDB, mariadb-main. Você pode fazer o seguinte:

  • Começando com mariadb-main, crie a primeira réplica de leitura na cadeia, read-replica-1.

  • Na read-replica-1, crie a próxima réplica de leitura na cadeia, read-replica-2.

  • Finalmente, na read-replica-2, crie a terceira réplica de leitura na cadeia, read-replica-3.

Não é possível criar outra réplica de leitura além dessa terceira réplica de leitura em cascata na série de mariadb-main. Uma série completa de instâncias de uma instância de banco de dados de origem do RDS para MariaDB até o final de uma série de réplicas de leitura em cascata pode consistir em, no máximo, quatro instâncias de banco de dados.

Para que as réplicas de leitura em cascata funcionem, cada instância de banco de dados do RDS para MariaDB de origem deve ter os backups automatizados ativados. Para ativar backups automáticos em uma réplica de leitura, primeiro crie a réplica de leitura e a modifique para ativar backups automáticos. Para obter mais informações, consulte Como criar uma réplica de leitura.

Como em qualquer réplica de leitura, é possível promover uma réplica de leitura que faz parte de uma cascata. A promoção de uma réplica de leitura de uma cadeia de réplicas de leitura remove essa réplica da cadeia. Por exemplo, suponha que você queira mover parte da workload da instância de banco de dados mariadb-main para uma nova instância para uso somente pelo departamento de contabilidade. Pressupondo a cadeia com três réplicas de leitura do exemplo, você decide promover read-replica-2. A cadeia é afetada da seguinte forma:

  • A promoção de read-replica-2 a remove da cadeia de replicação.

    • Ela agora é uma instância de banco de dados de leitura/gravação completa.

    • Ela continua replicando para read-replica-3, da mesma forma como estava fazendo antes da promoção.

  • A mariadb-main continua a replicar para a read-replica-1.

Para obter mais informações sobre como promover réplicas de leitura, consulte Promoção de uma réplica de leitura a uma instância de banco de dados autônoma.

Monitoramento de réplicas de leitura do MariaDB

Para as réplicas de leitura do MariaDB, você pode monitorar o atraso da replicação no Amazon CloudWatch visualizando a métrica ReplicaLag do Amazon RDS. A métrica ReplicaLag relata o valor do campo Seconds_Behind_Master do comando SHOW REPLICA STATUS.

nota

Versões anteriores do MariaDB usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver usando uma versão do MariaDB anterior à 10.5, use SHOW SLAVE STATUS.

As causas comuns para o atraso da replicação do MariaDB são as seguintes:

  • Uma queda de rede.

  • Gravar em tabelas com índices em uma réplica de leitura. Se o parâmetro read_only não estiver definido como 0 na réplica de leitura, isso poderá interromper a replicação.

  • Uso de um mecanismo de armazenamento não transacional, como o MyISAM. A replicação só é compatível com o mecanismo de armazenamento InnoDB no MariaDB.

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, então a replicação não está ativa no momento. ReplicaLag = -1 é equivalente a Seconds_Behind_Master = NULL.

Início e interrupção de replicação com réplicas de leitura do MariaDB

Você pode interromper e reiniciar o processo de replicação em uma instância de banco de dados do Amazon RDS ao chamar os procedimentos armazenados do sistema mysql.rds_stop_replication e mysql.rds_start_replication. Você pode fazer isso ao replicar entre duas instâncias do Amazon RDS para operações de longa duração, como a criação de índices grandes. Você também precisa interromper e iniciar a replicação ao importar ou exportar bancos de dados. Para obter mais informações, consulte Importar dados para um banco de dados MariaDB ou MySQL do Amazon RDS com tempo de inatividade reduzido e Exportar dados de uma instância de banco de dados MySQL usando replicação.

Se a replicação for interrompida por mais de 30 dias consecutivos, seja manualmente ou devido a um erro de replicação, o Amazon RDS a encerrará entre a instância de banco de dados de origem e todas as réplicas de leitura. Isso acontece para evitar um aumento nos requisitos de armazenamento da instância de banco de dados de origem e nos tempos de failover prolongado. A instância de banco de dados da réplica de leitura ainda está disponível. No entanto, a replicação não pode ser retomada porque os logs binários exigidos pela réplica de leitura são excluídos da instância de banco de dados de origem após o encerramento da replicação. Você pode criar uma nova réplica de leitura para a instância de banco de dados de origem a fim de restabelecer a replicação.

Solução de problemas da réplica de leitura do MariaDB

As tecnologias de replicação do MariaDB são assíncronas. Como são assíncronas, são esperados ocasionais aumentos de BinLogDiskUsage na instância de banco de dados de origem e ReplicaLag na réplica de leitura. Por exemplo, um volume elevado de operações de gravação para a instância de banco de dados de origem pode ocorrer em paralelo. Por outro lado, as operações de gravação na réplica de leitura são serializadas usando um único thread de E/S, o que pode ocasionar um atraso entre a instância de origem e a réplica de leitura. Para obter mais informações sobre réplicas somente leitura na documentação do MariaDB, acesse Visão geral da replicação.

Você pode fazer várias coisas para reduzir o atraso entre as atualizações de uma instância de banco de dados de origem e as atualizações subsequentes da réplica de leitura, como o seguinte:

  • Dimensionar uma réplica de leitura para ter um tamanho de armazenamento e uma categoria de instância de banco de dados comparáveis à da instância de banco de dados de origem.

  • Assegurar-se de que as configurações de parâmetros nos grupos de parâmetros de banco de dados utilizados pela instância de banco de dados de origem e pela réplica de leitura são compatíveis. Para mais informações e um exemplo, consulte a discussão sobre o parâmetro max_allowed_packet posteriormente nesta seção.

O Amazon RDS monitora o status de replicação de suas réplicas de leitura e atualiza o campo Replication State da instância da réplica de leitura para Error caso a replicação seja interrompida por qualquer motivo. Um exemplo pode ser se as consultas DML forem executadas no seu conflito de réplica de leitura com as atualizações feitas na instância de banco de dados de origem.

Você pode analisar os detalhes do erro associado gerado pelo mecanismo do MariaDB visualizando o campo Replication Error. 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 Trabalhar com a notificação de eventos do Amazon RDS. Se for retornada uma mensagem de erro do MariaDB, analise o erro na documentação de mensagens de erro do MariaDB.

Um problema comum que pode causar erros de replicação é quando o valor do parâmetro max_allowed_packet para uma réplica de leitura é menor que o do parâmetro max_allowed_packet para a instância de banco de dados de origem. O parâmetro max_allowed_packet é um parâmetro personalizado que pode ser definido em um grupo de parâmetros de banco de dados usado para especificar o código de DML que pode ser executado no banco de dados. Em alguns casos, o valor do parâmetro max_allowed_packet no grupo de parâmetros de banco de dados associado a uma instância de banco de dados de origem é menor do que o valor do parâmetro max_allowed_packet no grupo de parâmetros de banco de dados associado à réplica de leitura da origem. Nesses casos, o processo de replicação pode exibir um erro (Packet bigger than 'max_allowed_packet' bytes [Pacote maior que a quantidade máxima de bytes]) e interromper a replicação. É 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.

Outras situações comuns que podem causar erros de replicação incluem o seguinte:

  • A gravação em tabelas em uma réplica de leitura. Se estiver criando índices em uma réplica de leitura, você precisará ter o parâmetro read_only definido como 0 para criar os índices. Se você estiver gravando em tabelas na réplica de leitura, isso poderá interromper a replicação.

  • O uso de um mecanismo de armazenamento não transacional, como MyISAM. As réplicas de leitura exigem um mecanismo de armazenamento transacional. A replicação só é compatível com o mecanismo de armazenamento InnoDB no MariaDB.

  • Usando consultas não deterministas inseguras, como SYSDATE(). Para obter mais informações, consulte Determinação de instruções seguras e inseguras no registro de logs binários.

Se você acreditar que pode ignorar um erro com segurança, siga as etapas descritas em Ignorar o erro de replicação atual. Caso contrário, você pode excluir a réplica de leitura e criar uma instância usando o mesmo identificador de instância de banco de dados para que o endpoint permaneça o mesmo que o da sua antiga réplica de leitura. Se um erro de replicação for corrigido, o Replication State mudará para replicating.

Para as instâncias de banco de dados do MariaDB, em alguns casos, as réplicas de leitura não poderão ser alternadas para a secundária se alguns eventos de log binário (binlog) não forem liberados durante a falha. Nesses casos, exclua e recrie manualmente as réplicas de leitura. Você pode reduzir a chance disso acontecer definindo os seguintes valores de parâmetro: sync_binlog=1 e innodb_flush_log_at_trx_commit=1. Essas configurações podem reduzir a performance, portanto, teste o impacto delas antes de implantar as alterações em um ambiente de produção.