Réplicas de leitura na Base de Dados do Azure para MySQL

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

A funcionalidade de réplica de leitura permite replicar dados de um servidor de Base de Dados do Azure para MySQL 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 com a tecnologia de replicação baseada na posição dos ficheiros de registo binário nativo (binlog) do motor MySQL. Para saber mais sobre a replicação binlog, consulte a visão geral da replicação binlog do MySQL.

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

Para saber mais sobre os recursos e problemas de replicação do MySQL, consulte a documentação de replicação do MySQL.

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 nas réplicas, enquanto as cargas de trabalho de gravação podem ser direcionadas para a origem.

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 somente leitura, elas não reduzem diretamente os encargos de capacidade de gravação na origem. Esta funcionalidade não está direcionada para cargas de trabalho de escrita intensa.

O recurso de réplica de leitura usa a replicação assíncrona do MySQL. 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 eventualmente se tornam consistentes com os dados na fonte. 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 região MySQL. Um servidor de origem pode ter uma réplica em sua região emparelhada ou nas regiões de réplica universal. A imagem a seguir mostra quais regiões de réplica estão disponíveis, dependendo da sua região de origem.

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:

País/Região Disponibilidade da réplica
Leste da Austrália ✔️
Sudeste da Austrália ✔️
Sul do Brasil ✔️
Canadá Central ✔️
Leste do Canadá ✔️
E.U.A. Central ✔️
E.U.A. Leste ✔️
E.U.A. Leste 2 ✔️
Ásia Leste ✔️
Leste do Japão ✔️
Oeste do Japão ✔️
Coreia do Sul Central ✔️
Sul da Coreia do Sul ✔️
Europa do Norte ✔️
E.U.A. Centro-Norte ✔️
E.U.A. Centro-Sul ✔️
Sudeste Asiático ✔️
Norte da Suíça ✔️
Sul do Reino Unido ✔️
Oeste do Reino Unido ✔️
E.U.A. Centro-Oeste ✔️
E.U.A. Oeste ✔️
E.U.A. Oeste 2 ✔️
Europa Ocidental ✔️
Índia Central* ✔️
França Central* ✔️
Norte dos Emirados Árabes Unidos* ✔️
África do Sul Norte* ✔️

Nota

*Regiões onde o Banco de Dados do Azure para MySQL tem armazenamento de uso geral v2 na visualização pública
*Para essas regiões do Azure, você terá uma opção para criar servidor no armazenamento de uso geral v1 e v2. Para os servidores criados com o armazenamento de finalidade geral v2 na visualização pública, você está limitado a criar servidor de réplica somente nas regiões do Azure que oferecem suporte ao armazenamento de finalidade geral v2.

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 o 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 MySQL 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 o Banco de Dados do Azure para servidores MySQL 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 o servidor de origem não tiver servidores de réplica existentes, o servidor de origem pode precisar de uma reinicialização para se preparar para a replicação, dependendo do armazenamento usado (v1/v2). Considere reiniciar o servidor e execute esta operação fora do horário de pico. Consulte Reinicialização do servidor de origem para obter mais detalhes.

Quando você inicia o fluxo de trabalho de criação de réplica, um Banco de Dados do Azure em branco para o servidor MySQL é 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. O servidor de réplica é sempre criado no mesmo grupo de recursos e na mesma assinatura que o servidor de origem. Se desejar criar um servidor de réplica para um grupo de recursos diferente ou uma assinatura diferente, você poderá mover o servidor de réplica após a criação.

Todas as réplicas estão habilitadas para crescimento automático de armazenamento. O recurso de crescimento automático permite que a réplica acompanhe os dados replicados para ela e evite uma interrupção na replicação causada por erros de falta de armazenamento.

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 normal para o servidor MySQL. 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.mysql.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 MySQL fornece a métrica Atraso de replicação em segundos no Azure Monitor. Essa métrica está disponível apenas para réplicas. Esta métrica é calculada usando a seconds_behind_master métrica disponível no comando do SHOW SLAVE STATUS MySQL. 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.

Se você observar um maior atraso de replicação, consulte Solução de problemas de latência de replicação para solucionar problemas e entender possíveis causas.

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 muitos 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á a quantidade de dados perdidos.

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

  1. Interromper 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 da origem. 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 fonte.

Depois que seu aplicativo estiver processando leituras e gravações com êxito, 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 listadas anteriormente.

Identificador global de transação (GTID)

O identificador de transação global (GTID) é um identificador exclusivo criado com cada transação confirmada em um servidor de origem e está DESATIVADO por padrão no Banco de Dados do Azure para MySQL. O GTID é suportado nas versões 5.7 e 8.0 e apenas em servidores que suportam armazenamento de até 16 TB (armazenamento de uso geral v2). Para saber mais sobre o GTID e como ele é usado na replicação, consulte a documentação de replicação com GTID do MySQL.

O MySQL suporta dois tipos de transações: transações GTID (identificadas com GTID) e transações anônimas (não têm um GTID alocado)

Os seguintes parâmetros de servidor estão disponíveis para configurar o GTID:

Parâmetro do servidor Descrição Valor padrão Valores
gtid_mode Indica se os GTIDs são usados para identificar transações. As alterações entre modos só podem ser feitas um passo de cada vez em ordem crescente (ex. OFF - - ->>ON>OFF_PERMISSIVEON_PERMISSIVE) OFF OFF: As transações novas e de replicação devem ser anônimas
OFF_PERMISSIVE: As novas transações são anónimas. As transações replicadas podem ser anônimas ou transações GTID.
ON_PERMISSIVE: Novas transações são transações GTID. As transações replicadas podem ser anônimas ou transações GTID.
ON: As transações novas e replicadas devem ser transações GTID.
enforce_gtid_consistency Reforça a consistência do GTID, permitindo a execução apenas das instruções que podem ser registradas de forma transacionalmente segura. Esse valor deve ser definido como antes de habilitar a ON replicação GTID. OFF OFF: Todas as transações podem violar a consistência do GTID.
ON: Nenhuma transação pode violar a consistência do GTID.
WARN: Todas as transações podem violar a consistência do GTID, mas um aviso é gerado.

Nota

  • Depois que o GTID estiver ativado, você não poderá desativá-lo novamente. Se você precisar desativar o GTID OFF, entre em contato com o suporte.

  • Alterar GTID's de um valor para outro só pode ser um passo de cada vez em ordem crescente de modos. Por exemplo, se gtid_mode estiver atualmente definido como OFF_PERMISSIVE, é possível alterar para ON_PERMISSIVE, mas não para ON.

  • Para manter a replicação consistente, não é possível atualizá-la para um servidor mestre/réplica.

  • Recomendado para DEFINIR enforce_gtid_consistency como ON antes de poder definir gtid_mode=ON

Para habilitar o GTID e configurar o comportamento de consistência, atualize os parâmetros e enforce_gtid_consistency do servidor usando o portal do Azure, a CLI do gtid_modeAzure ou o PowerShell.

Se o GTID estiver habilitado em um servidor de origem (gtid_mode = ON), as réplicas recém-criadas também terão o GTID habilitado e usarão a replicação GTID. Para garantir que a replicação seja consistente, gtid_mode não é possível alterar depois que o(s) servidor(es) mestre(s) ou de réplica for(em) criado(s) com o GTID habilitado.

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

Servidor que tem armazenamento de uso geral v1, o log_bin parâmetro será OFF por padrão. O valor será ativado quando você criar a primeira réplica de leitura. Se um servidor de origem não tiver réplicas de leitura existentes, o servidor de origem será reiniciado primeiro para se preparar para a replicação. Considere reiniciar o servidor e execute esta operação fora do horário de pico.

Servidor de origem que tem armazenamento de uso geral v2, o parâmetro estará ATIVADO log_bin por padrão e não requer uma reinicialização quando você adiciona uma réplica de leitura.

Novas réplicas

Uma réplica de leitura é criada como um novo Banco de Dados do Azure para o servidor MySQL. 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 origem. 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 e período de retenção de backup. 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. Esta ação garante que a réplica pode acompanhar quaisquer alterações feitas na origem.

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 na origem e recrie réplicas.

GTID

O GTID é suportado em:

  • MySQL versões 5.7 e 8.0.
  • Servidores que suportam armazenamento de até 16 TB. Veja o artigo Escalão de preço para obter a lista completa das regiões que suportam o armazenamento de 16 TB.

O GTID está DESATIVADO por padrão. Após a ativação do GTID, não o poderá desativar. Se precisar de desativar o GTID, contacte o suporte.

Se o GTID estiver ativado num servidor de origem, as réplicas recém-criadas também terão o GTID ativado e utilizarão a replicação do GTID. Para manter a replicação consistente, não é possível atualizar gtid_mode no(s) servidor(es) de origem ou de réplica.

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 MySQL. Leia mais na documentação de referência do MySQL para obter mais informações.
  • 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.
  • Consulte a lista completa de limitações de replicação do MySQL na documentação do MySQL

Próximos passos