Réplicas de leitura no Banco de Dados do Azure para MariaDB

Importante

O Banco de Dados do Azure para MariaDB está a caminho da desativação. É altamente recomendável que você migre para o Banco de Dados do Azure para MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para MariaDB?.

O recurso de réplica de leitura permite replicar dados de um servidor de Banco de Dados do Azure para MariaDB para um servidor somente leitura. Você pode replicar do servidor de origem para até cinco réplicas. As réplicas são atualizadas de forma assíncrona usando a tecnologia de replicação baseada em posição do arquivo binário (log binário) do mecanismo MariaDB com ID de transação global (GTID). Para saber mais sobre a replicação do binlog, confira a visão geral da replicação do binlog.

As réplicas são novos servidores que você gerencia de modo semelhante aos servidores normais do Banco de Dados do Azure para MariaDB. Para cada réplica de leitura, você será cobrado pela computação provisionada em vCores e pelo armazenamento em GB/mês.

Para saber mais sobre replicação com GTID, acesse a documentação de replicação do MariaDB.

Observação

Este artigo contém referências ao termo servidor subordinado, um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Quando usar uma réplica de leitura

O recurso de réplica de leitura ajuda a melhorar o desempenho e o dimensionamento de cargas de trabalho com uso intenso de leitura. As cargas de trabalho de leitura podem ser isoladas para as réplicas, enquanto as cargas de trabalho de gravação podem ser direcionadas para o primário.

Um cenário comum é ter cargas de trabalho analíticas e de BI usando a réplica de leitura como a fonte de dados para relatório.

Como réplicas são somente leitura, elas não reduzem diretamente os encargos de capacidade de gravação no primário. Esse recurso não se destina a cargas de trabalho com uso intenso de gravação.

O recurso de réplica de leitura usa replicação assíncrona. O recurso não se destina a cenários de replicação síncrona. Haverá um atraso mensurável entre a origem e a réplica. Os dados na réplica acabarão se tornando consistentes com os dados no primário. Use este recurso para cargas de trabalho que podem acomodar esse atraso.

Replicação entre regiões

Você pode criar uma réplica de leitura em uma região diferente da do servidor de origem. A replicação entre regiões pode ser útil para cenários como o planejamento de recuperação de desastres ou para trazer dados mais próximos dos seus usuários.

Você pode ter um servidor de origem em qualquer região do Banco de Dados do Azure para MariaDB. Um servidor de origem pode ter uma réplica na região emparelhada ou nas regiões de réplica universal. A figura abaixo mostra quais regiões de réplica estão disponíveis dependendo da sua região de origem.

Read replica regions

Regiões de réplica universal

Você pode criar uma réplica de leitura em qualquer uma das seguintes regiões, independentemente de onde o servidor de origem estiver localizado. As regiões de réplica universal compatíveis incluem:

Leste da Austrália, Sudeste da Austrália, Sul do Brasil, Canadá Central, Leste do Canadá, EUA Central, Leste da Ásia, Leste dos EUA, Leste dos EUA 2, Leste do Japão, Oeste do Japão, Coreia Central, Sul da Coreia, Centro-Norte dos EUA, Norte da Europa, Centro-Sul dos EUA, Sudeste da Ásia, Sul do Reino Unido, Oeste do Reino Unido, Oeste da Europa, Oeste dos EUA, Oeste dos EUA 2, Centro-Oeste dos EUA.

Regiões emparelhadas

Você pode criar uma réplica de leitura na região emparelhada do Azure do seu servidor de origem além das regiões de réplica universal. Se não souber o par da sua região, você pode encontrar essa informação no artigo Regiões emparelhadas do Azure.

Se você estiver usando réplicas entre regiões para o planejamento de recuperação de desastres, recomendamos criar a réplica na região emparelhada, e não em uma das outras regiões. Regiões emparelhadas evitam atualizações simultâneas e priorizam isolamento físico e residência de dados.

No entanto, há certas limitações a serem consideradas:

  • Disponibilidade regional: O Banco de Dados do Azure para MariaDB está disponível na França Central, Norte dos EAU e Alemanha Central. Entretanto, suas regiões emparelhadas não estão disponíveis.

  • Pares unidirecionais: Algumas regiões do Azure são emparelhadas em uma direção apenas. Essas regiões incluem Oeste da Índia, Sul do Brasil e US Gov - Virgínia. Isso significa que um servidor de origem no Oeste da Índia pode criar uma réplica no Sul da Índia. Entretanto, um servidor de origem no Sul da Índia não pode criar uma réplica no Oeste da Índia. Isso ocorre porque a região secundária do Oeste da Índia é o Sul da Índia, mas a região secundária do Sul da Índia não é o Oeste da Índia.

Criar uma réplica

Importante

O recurso de réplica de leitura está disponível apenas para servidores do Banco de Dados do Azure para MariaDB nos tipos de preços de Uso Geral ou Otimizado para Memória. Verifique se o servidor de origem está em um desses tipos de preços.

Se um servidor de origem não tiver servidores de réplica, a origem será reiniciada primeiro para se preparar para a replicação.

Quando você inicia o fluxo de trabalho de criação de réplica, um servidor do Banco de Dados do Azure para MariaDB é criado. O novo servidor é preenchido com os dados que estavam no servidor de origem. A hora de criação depende da quantidade de dados na origem e do tempo decorrido desde o último backup completo semanal. O tempo pode variar de alguns minutos a várias horas.

Observação

Se você não tem alerta de armazenamento configurado em seus servidores, recomendamos que você faça isso. O alerta informa quando um servidor está se aproximando de seu limite de armazenamento, o que afetará a replicação.

Saiba como criar uma réplica de leitura no portal do Azure.

Conectar-se a uma réplica

Uma réplica herda as regras de firewall do servidor de origem na criação. Essas regras são independentes do servidor de origem posteriormente.

A réplica herda a conta do administrador do servidor de origem. Todas as contas de usuário no servidor de origem são replicadas para as réplicas de leitura. Você só pode se conectar a uma réplica de leitura usando as contas de usuário disponíveis no servidor de origem.

Você pode se conectar à réplica usando seu nome de host e uma conta de usuário válida, assim como faria em um servidor regular do Banco de Dados do Azure para MariaDB. Para um servidor chamado myreplica com o nome de usuário admin myadmin, você pode se conectar à réplica usando a CLI do mysql:

mysql -h myreplica.mariadb.database.azure.com -u myadmin@myreplica -p

No prompt, insira a senha da conta de usuário.

Monitorar a replicação

O Banco de Dados do Azure para MariaDB fornece a métrica Atraso da replicação em segundos no Azure Monitor. Essa métrica está disponível apenas para réplicas.

Essa métrica é calculada com o uso da métrica seconds_behind_master disponível no comando SHOW SLAVE STATUS do MariaDB.

Defina um alerta para informá-lo quando o retardo da replicação atinge um valor que não é aceitável para sua carga de trabalho.

Parar replicação

Você pode interromper a replicação entre uma origem e uma réplica. Após a replicação ser interrompida entre um servidor de origem e uma réplica de leitura, a réplica se torna um servidor autônomo. Os dados no servidor autônomo são os dados que estavam disponíveis na réplica no momento em que o comando de parar a replicação foi iniciado. O servidor autônomo não alcança o servidor de origem.

Quando você escolhe interromper a replicação em uma réplica, ela perde todos os links para a origem anterior e outras réplicas. Não há failover automatizado entre uma origem e sua réplica.

Importante

O servidor autônomo não pode se tornar uma réplica novamente. Antes de interromper a replicação em uma réplica de leitura, verifique se a réplica tem todos os dados de que você precisa.

Saiba como interromper a replicação para uma réplica.

Failover

Não há failover automatizado entre uma origem e seus servidores de réplica.

Como a replicação é assíncrona, há um atraso entre a origem e a réplica. A duração da latência pode ser influenciada por uma variedade de fatores, como a intensidade da carga de trabalho em execução no servidor de origem e a latência entre os data centers. Na maioria dos casos, o atraso da réplica varia entre alguns segundos e alguns minutos. Você pode acompanhar o retardo de replicação real usando a métrica Retardo de réplica, que está disponível para cada réplica. A métrica Retardo da Réplica mostra o tempo decorrido desde a última transação reproduzida. É recomendável que você identifique o retardo médio, observando o retardo de réplica em um período de tempo. Você pode definir um alerta para o retardo de réplica, de modo que, se ele ficar fora do intervalo esperado, você poderá executar uma ação.

Dica

Se você realizar o failover para a réplica, o retardo no momento em que você desvincular a réplica da fonte indicará a quantidade de dados perdida.

Depois que você decidir que deseja realizar o failover para uma réplica,

  1. Pare a replicação para a réplica.

    Essa etapa é necessária para tornar o servidor de réplica capaz de aceitar gravações. Como parte desse processo, o servidor de réplica será desvinculado do servidor de origem. Depois de iniciar a interrupção da replicação, o processo de back-end normalmente leva dois minutos para terminar. Consulte a seção Parar replicação deste artigo para entender as implicações dessa ação.

  2. Direcione seu aplicativo para a réplica (antiga).

    Cada servidor tem uma cadeia de conexão única. Atualize seu aplicativo para direcionar para a réplica (antiga) em vez do primário.

Depois que o aplicativo processar leituras e gravações com êxito, você terá concluído o failover. A quantidade de tempo de inatividade do seu aplicativo dependerá de quando você detectar um problema e concluir as etapas 1 e 2 acima.

Considerações e limitações

Tipos de preço

No momento, as réplicas de leitura estão disponíveis apenas nas camadas de preços de uso geral e de otimização de memória.

Observação

O custo da execução do servidor de réplica é baseado na região em que o servidor de réplica está em execução.

Reinicialização do servidor de origem

Quando você criar uma réplica para uma origem que não tenha réplicas existentes, primeiro, a origem será reiniciada para se preparar para a replicação. Leve isso em consideração e realize essas operações durante um período de pouca atividade.

Novas réplicas

Uma réplica de leitura é criada como um novo servidor de Banco de Dados do Azure para MariaDB. Um servidor existente não pode se tornar uma réplica. Você não pode criar uma réplica de outra réplica de leitura.

Configuração da réplica

Uma réplica é criada usando a mesma configuração de servidor que o primário. Depois que uma réplica é criada, várias configurações podem ser alteradas independentemente do servidor de origem: geração de computação, vCores, armazenamento, período de retenção de backup e versão do mecanismo do MariaDB. O tipo de preço também pode ser alterado de forma independente, exceto de ou para a camada básica.

Importante

Antes de uma configuração de servidor de origem ser atualizada com novos valores, atualize a configuração de réplica para valores iguais ou maiores. Esta ação garante que a réplica possa acompanhar as alterações realizadas no servidor primário.

Regras de firewall e configurações de parâmetros são herdadas do servidor de origem para a réplica quando a réplica é criada. As regras da réplica são independentes posteriormente.

Réplicas paradas

Se você interromper a replicação entre um servidor de origem e uma réplica de leitura, a réplica interrompida se tornará um servidor autônomo que aceita leituras e gravações. O servidor autônomo não pode se tornar uma réplica novamente.

Servidores de origem e autônomo excluídos

Quando um servidor de origem é excluído, a replicação é interrompida para todas as réplicas de leitura. Essas réplicas se tornam servidores autônomos automaticamente e podem aceitar leituras e gravações. O próprio servidor de origem é excluído.

Contas de usuário

Os usuários no servidor de origem são replicados para as réplicas de leitura. Você só pode se conectar a uma réplica de leitura usando as contas de usuário disponíveis no servidor de origem.

Parâmetros do Servidor

Para impedir que os dados fiquem fora de sincronia e evitar possíveis perdas de dados ou danos, alguns parâmetros de servidor estão bloqueados para serem atualizados ao usar réplicas de leitura.

Os seguintes parâmetros do servidor estão bloqueados nos servidores e origem e de réplica:

O parâmetro event_scheduler está bloqueado nos servidores de réplica.

Para atualizar um dos parâmetros acima no servidor de origem, exclua os servidores de origem, atualize o valor do parâmetro no servidor primário e recrie as réplicas.

Outro

  • A criação de uma réplica de uma réplica não é suportada.
  • * Tabelas na memória podem fazer com que as réplicas fiquem fora de sincronia. Esta é uma limitação da tecnologia de replicação do MariaDB.
  • Verifique se as tabelas de servidor de origem contêm chaves primárias. A falta de chaves primárias pode resultar em latência de replicação entre a origem e as réplicas.

Próximas etapas