Réplicas de leitura no Azure Database for MariaDB

Importante

O Banco de Dados do Azure para MariaDB está no caminho da aposentadoria. É altamente recomendável migrar 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?.

A funcionalidade de réplica de leitura permite replicar dados de um servidor do Azure Database for MariaDB para um servidor só de leitura. 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 de arquivo de log binário (binlog) do mecanismo MariaDB com ID de transação global (GTID). Para saber mais sobre a replicação binlog, consulte a visão geral da replicação binlog.

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

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

Nota

Este artigo poderá conter referências ao termo slave (secundário), um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo deste artigo.

Quando utilizar uma réplica de leitura

A funcionalidade de réplica de leitura ajuda a melhorar o desempenho e o dimensionamento de cargas de trabalho de leitura intensiva. As cargas de trabalho de leitura podem ser isoladas das réplicas e as cargas de trabalho de escrita podem ser encaminhadas para o servidor principal.

Um cenário comum é fazer com que as cargas de trabalho analíticas e de BI utilizem a réplica de leitura como a origem de dados de relatórios.

Como as réplicas são só de leitura, não reduzem diretamente as cargas de capacidade de escrita no servidor principal. Esta funcionalidade não está direcionada para cargas de trabalho de escrita intensa.

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 podem tornar-se consistentes com os dados no cluster principal. Utilize esta funcionalidade para cargas de trabalho que podem acomodar este atraso.

Replicação entre regiões

Você pode criar uma réplica de leitura em uma região diferente do servidor de origem. A replicação entre regiões pode ser útil em cenários como o planeamento de recuperação após desastre ou para que os dados fiquem mais próximos dos utilizadores.

Você pode ter um servidor de origem em qualquer Banco de Dados do Azure para a região MariaDB. Um servidor de origem pode ter uma réplica em sua região emparelhada ou nas regiões de réplica universal. A imagem 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 está localizado. As regiões de réplica universal suportadas incluem:

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

Regiões emparelhadas

Além das regiões de réplica universal, você pode criar uma réplica de leitura na região emparelhada do Azure do seu servidor de origem. Se não souber o par da sua região, pode saber mais no artigo Regiões Emparelhadas do Azure.

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

No entanto, há limitações a considerar:

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

  • Pares unidirecionais: algumas regiões do Azure são emparelhadas em apenas uma direção. Essas regiões incluem a Índia Ocidental, o Sul do Brasil e o governo dos EUA da Virgínia. Isso significa que um servidor de origem na Índia Ocidental pode criar uma réplica no sul da Índia. No entanto, um servidor de origem no sul da Índia não pode criar uma réplica na Índia Ocidental. Isso ocorre porque a região secundária da Índia Ocidental é o Sul da Índia, mas a região secundária do Sul da Índia não é a Índia Ocidental.

Criar uma réplica

Importante

O recurso de réplica de leitura só está disponível para servidores do Banco de Dados do Azure para MariaDB nas camadas de preços de Uso Geral ou Memória Otimizada. Verifique se o servidor de origem está em uma dessas camadas de preço.

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

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

Nota

Se não tiver um alerta de armazenamento configurado nos seus servidores, recomendamos que o faça. 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.

Ligar a uma réplica

Na criação, uma réplica herda as regras de firewall do servidor de origem. Depois, essas regras são independentes do servidor de origem.

A réplica herda a conta de 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, como faria em um Banco de Dados do Azure regular para o servidor MariaDB. Para um servidor chamado myreplica com o nome de usuário admin myadmin, você pode se conectar à réplica usando a CLI mysql:

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

Quando lhe for pedido, introduza a palavra-passe para a conta de utilizador.

Monitorizar a replicação

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

Essa métrica é calculada usando a seconds_behind_master métrica disponível no comando do SHOW SLAVE STATUS MariaDB.

Defina um alerta para informá-lo quando o atraso de replicação atingir um valor que não seja aceitável para sua carga de trabalho.

Parar replicação

Você pode interromper a replicação entre uma origem e uma réplica. Depois que a replicação é 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 stop replication foi iniciado. O servidor autônomo não alcança o servidor de origem.

Quando você opta por interromper a replicação para uma réplica, ela perde todos os links para sua 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 ser transformado em 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 necessários.

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

Ativação pós-falha

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

Como a replicação é assíncrona, há um atraso entre a origem e a réplica. A quantidade de atraso pode ser influenciada por vários fatores, como o peso 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 controlar o atraso real da replicação usando a métrica Atraso da réplica, que está disponível para cada réplica. Esta métrica mostra o tempo desde a última transação repetida. Recomendamos que você identifique qual é o atraso médio observando o atraso da réplica durante um período de tempo. Você pode definir um alerta sobre o atraso da réplica, para que, se ele sair do intervalo esperado, você possa agir.

Gorjeta

Se você fizer failover para a réplica, o atraso no momento em que você desvincular a réplica da origem indicará quantos dados foram perdidos.

Depois de decidir que deseja fazer failover para uma réplica,

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

    Esta 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 principal. Depois de iniciar a interrupção da replicação, o processo de back-end normalmente leva cerca de 2 minutos para ser concluído. Consulte a seção Parar replicação deste artigo para entender as implicações dessa ação.

  2. Aponte seu aplicativo para a réplica (anterior).

    Cada servidor tem uma cadeia de conexão exclusiva. Atualize seu aplicativo para apontar para a réplica (anterior) em vez da principal.

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

Considerações e limitações

Escalões de preço

Atualmente, as réplicas de leitura só estão disponíveis nos níveis de preços de uso geral e memória otimizada.

Nota

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

Reinicialização do servidor de origem

Quando você cria uma réplica para uma fonte que não tem réplicas existentes, a origem será reiniciada primeiro para se preparar para a replicação. Leve isso em consideração e execute essas operações durante um período fora de pico.

Novas réplicas

Uma réplica de leitura é criada como um novo Banco de Dados do Azure para o servidor MariaDB. Um servidor existente não pode ser transformado em uma réplica. Não é possível 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 a principal. 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 MariaDB. O nível de preços também pode ser alterado de forma independente, exceto para ou a partir do nível Básico.

Importante

Antes de atualizar uma configuração do servidor de origem para os novos valores, atualize a configuração da réplica para valores iguais ou superiores. Essa ação garante que a réplica possa acompanhar todas as alterações feitas no primário.

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

Réplicas interrompidas

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 ser transformado em uma réplica novamente.

Servidores de origem e autônomos 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 automaticamente servidores autônomos e podem aceitar leituras e gravações. O próprio servidor de origem é excluído.

Contas de utilizador

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 dessincronizados e evitar potenciais perdas de dados ou corrupção, a atualização de alguns parâmetros de servidor é bloqueada ao utilizar réplicas de leitura.

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

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

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

Outro

  • Não há suporte para a criação de uma réplica de uma réplica.
  • As 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 do servidor de origem tê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óximos passos