Partilhar via

Ler réplicas no Banco de Dados do Azure para MySQL - Servidor flexível

  • Artigo

O MySQL é um dos mecanismos de banco de dados populares para executar aplicativos web e móveis em escala de internet. Muitos de nossos clientes o usam para seus serviços de educação on-line, serviços de streaming de vídeo, soluções de pagamento digital, plataformas de comércio eletrônico, serviços de jogos, portais de notícias, sites governamentais e de saúde. Esses serviços são necessários para servir e escalar à medida que o tráfego na web ou aplicativo móvel aumenta.

No lado dos aplicativos, o aplicativo normalmente é desenvolvido em Java ou PHP e migrado para ser executado em Conjuntos de Escala de Máquina Virtual do Azure ou Serviços de Aplicativo do Azure ou são conteinerizados para serem executados no Serviço Kubernetes do Azure (AKS). Com o Conjunto de Dimensionamento de Máquina Virtual, Serviço de Aplicativo ou AKS como infraestrutura subjacente, o dimensionamento de aplicativos é simplificado pelo provisionamento instantâneo de novas VMs e pela replicação dos componentes sem estado dos aplicativos para atender às solicitações, mas, muitas vezes, o banco de dados acaba sendo um gargalo como componente com estado centralizado.

O recurso de réplica de leitura permite replicar dados de uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL para um servidor somente leitura. Você pode replicar do servidor de origem para até 10 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 de origem para instâncias do Servidor Flexível MySQL. Você incorre em cobranças para cada réplica de leitura com base na computação provisionada em vCores e armazenamento em GB/mês. Para obter mais informações, veja os preços.

Nota

O recurso de réplica de leitura só está disponível para instâncias do Servidor Flexível do Banco de Dados do Azure para MySQL nas camadas de preços Uso Geral ou Crítica para os Negócios. Verifique se o servidor de origem está em uma dessas camadas de preço.

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.

Casos de uso comuns para 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.

Os cenários comuns são:

  • Dimensionamento de cargas de trabalho de leitura provenientes do aplicativo usando proxy de conexão leve como ProxySQL ou usando padrão baseado em microsserviços para dimensionar suas consultas de leitura provenientes do aplicativo para ler réplicas
  • Cargas de trabalho de relatórios analíticos ou de BI podem usar réplicas de leitura como fonte de dados para geração de relatórios
  • Para cenários de IoT ou Manufatura em que as informações de telemetria são ingeridas no mecanismo de banco de dados MySQL enquanto várias réplicas de leitura são usadas para relatórios de dados

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. Há 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. O Banco de Dados do Azure para Servidor Flexível MySQL permite provisionar réplica de leitura em qualquer região com suporte do Azure onde o Banco de Dados do Azure para Servidor Flexível MySQL esteja disponível. Usando esse recurso, um servidor de origem pode ter uma réplica em sua região emparelhada ou nas regiões de réplica universal. Consulte aqui para encontrar a lista de regiões do Azure onde o Banco de Dados do Azure para MySQL Flexible Server está disponível hoje.

Criar uma réplica

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

Quando você inicia o fluxo de trabalho de criação de réplica, uma instância em branco do Banco de Dados do Azure para Servidor Flexível MySQL é criada. 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

As réplicas de leitura são criadas com a mesma configuração de servidor da origem. A configuração do servidor de réplica pode ser alterada após a sua criação. 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. É recomendável que a configuração do servidor de réplica seja mantida em valores iguais ou maiores do que a origem para garantir que a réplica seja capaz de acompanhar a origem.

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

Ligar a uma réplica

Na criação, uma réplica herda o método de conectividade do servidor de origem. Não é possível alterar o método de conectividade da réplica. Por exemplo, se o servidor de origem tiver acesso privado (integração VNet), a réplica não poderá estar em Acesso público (endereços IP permitidos).

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 uma instância normal do Banco de Dados do Azure para o Servidor Flexível 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 -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 Servidor Flexível MySQL fornece a métrica de 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 aumento do atraso de replicação, consulte Solução de problemas de latência de replicação para solucionar problemas e entender possíveis causas.

Importante

A réplica de leitura usa a tecnologia de replicação baseada em armazenamento, que não usa mais a métrica 'SLAVE_IO_RUNNING'/'REPLICA_IO_RUNNING' disponível no comando 'SHOW SLAVE STATUS'/'SHOW REPLICA STATUS' do MySQL. Esse valor é sempre exibido como "Não" e não é indicativo do status de replicação. Para saber o status correto da replicação, consulte as métricas de replicação - Status de E/S da réplica e Status SQL da réplica na folha Monitoramento.

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.

As réplicas de leitura destinam-se ao dimensionamento de cargas de trabalho de leitura intensiva e não foram projetadas para atender às necessidades de alta disponibilidade de um servidor. Interromper a replicação na réplica de leitura para colocá-la online no modo de gravação de leitura é o meio pelo qual esse failover manual é executado.

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á quantos dados serão 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 é 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 depende de quando você deteta um problema e conclui as etapas 1 e 2 acima.

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 Servidor Flexível MySQL. O GTID é suportado nas versões 5.7 e 8.0. Para saber mais sobre o GTID e como ele é usado na replicação, consulte a documentação de replicação com GTID do MySQL.

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 ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) 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.

**Para instâncias do Banco de Dados do Azure para Servidor Flexível MySQL que têm o recurso de Alta Disponibilidade habilitado, o valor padrão é definido como ON.

Nota

  • Após a ativação do GTID, não o poderá desativar. Se você precisar desativar o GTID OFF, entre em contato com o suporte.
  • Você pode alterar GTIDs de um valor para outro apenas uma etapa de cada vez em ordem crescente de modos. Por exemplo, se gtid_mode estiver atualmente definido como OFF_PERMISSIVE, é possível mudar 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.
  • Recomenda-se DEFINIR enforce_gtid_consistency para ON antes de poder definir gtid_mode=ON.

Para habilitar o GTID e configurar o comportamento de consistência, atualize os parâmetros e do gtid_mode servidor usando Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando o portal do Azure ou Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando a CLI do enforce_gtid_consistency Azure.

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 pode ser alterada 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

Cenário Limitação/Consideração
Réplica no servidor no nível de preços Burstable Não suportado
Preços 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 uma nova instância do Banco de Dados do Azure para o Servidor Flexível 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. A camada de computação também pode ser alterada independentemente.

IMPORTANTE - Antes que uma configuração do servidor de origem seja atualizada para novos valores, atualize a configuração da réplica para valores iguais ou maiores. Esta ação garante que a réplica pode acompanhar quaisquer alterações feitas na origem.
O método de conectividade e as configurações de parâmetros são herdados 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:
- innodb_file_per_table
- log_bin_trust_function_creators
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.
Parâmetros de nível de sessão Ao configurar parâmetros de nível de sessão, como 'foreign_keys_checks' na réplica de leitura, certifique-se de que os valores de parâmetro que estão sendo definidos na réplica de leitura sejam consistentes com os do servidor de origem.
Adicionar AUTO_INCREMENT coluna Chave Primária à tabela existente no servidor de origem. Não recomendamos alterar a tabela com AUTO_INCREMENT criação de réplica pós-leitura, pois isso quebra a replicação. Mas caso você queira adicionar a coluna de incremento automático após a criação de um servidor de réplica, recomendamos estas duas abordagens:
- Crie uma nova tabela com o mesmo esquema de tabela que você deseja modificar. Na nova tabela, altere a coluna com AUTO_INCREMENT e, em seguida, a partir da tabela original, restaure os dados. Solte a tabela antiga e renomeie-a na origem, isso não precisa que excluamos o servidor de réplica, mas pode precisar de um grande custo de inserção para criar a tabela de backup.
- O outro método mais rápido é recriar a réplica depois de adicionar todas as colunas de incremento automático.
Outro - A criação de uma réplica de uma réplica não é suportada.
- 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.
- Revise a lista completa de limitações de replicação do MySQL na documentação do MySQL

Conteúdos relacionados