Compartilhar via

Ler réplicas no Banco de Dados do Azure para MySQL

O MySQL é um dos mecanismos de banco de dados populares para a execução de aplicativos Web e móveis de escala da Internet. Muitos clientes usam o Banco de Dados do Azure para MySQL para uma ampla gama de aplicativos, incluindo educação online, streaming de vídeo, pagamentos digitais, comércio eletrônico, jogos, portais de notícias, governo e sites de saúde. Esses serviços devem ser capazes de atender e dimensionar à medida que o tráfego na Web ou aplicativo móvel aumenta.

No lado dos aplicativos, os desenvolvedores normalmente usam Java ou PHP. Eles migram o aplicativo para ser executado nos Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, nos Serviços de Aplicativo do Azure ou em contêineres para serem executados no AKS (Serviço de Kubernetes do Azure). Com o Conjunto de Dimensionamento de Máquinas Virtuais, o Serviço de Aplicativo ou o AKS como a infraestrutura subjacente, o dimensionamento de aplicativos é simplificado provisionando instantaneamente novas VMs e replicando os componentes sem estado dos aplicativos para atender às solicitações. No entanto, o banco de dados geralmente se torna um gargalo como um 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 usando a tecnologia de replicação baseada em posição de arquivo de log binário nativo (binlog) do mecanismo MySQL. Para saber mais sobre a replicação do binlog, confira a visão geral da replicação do binlog do MySQL.

Você gerencia réplicas como novos servidores, assim como as instâncias de servidor flexível do Banco de Dados do Azure para MySQL de origem. Você incorre em encargos de cobrança para cada réplica de leitura com base na computação provisionada em vCores e armazenamento em GB por mês. Para saber mais, confira os preços.

O recurso de réplica de leitura está disponível apenas para as instâncias de Servidor Flexível do Banco de Dados do Azure para MySQL nas camadas de preços de Uso Geral ou Comercialmente Crítico. Verifique se o servidor de origem está em um desses tipos de preços.

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

Observação

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

Casos de uso comuns para réplica de leitura

O recurso de réplica de leitura ajuda você a melhorar o desempenho e a escala de cargas de trabalho com uso intensivo de leitura. Você pode isolar cargas de trabalho de leitura para as réplicas, enquanto direciona cargas de trabalho de gravação para a origem.

Cenários comuns incluem:

  • Dimensionamento de cargas de trabalho de leitura provenientes do aplicativo usando um proxy de conexão leve como ProxySQL ou usando um padrão baseado em microsserviços para expandir suas consultas de leitura provenientes do aplicativo para ler réplicas
  • Usando réplicas de leitura como uma fonte de dados para cargas de trabalho de BI ou relatórios analíticos
  • Ingerir informações de telemetria no mecanismo de banco de dados MySQL ao usar várias réplicas de leitura para relatórios de dados em cenários de IoT ou De fabricação

Como réplicas são somente leitura, elas não reduzem diretamente os encargos de capacidade de gravação na origem. 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 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 acabarão se tornando consistentes com os dados na origem. 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. O Servidor Flexível do Banco de Dados do Azure para MySQL permite provisionar uma réplica de leitura em qualquer região com suporte do Azure em que o Servidor Flexível do Banco de Dados do Azure para 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. Veja aqui para encontrar a lista de regiões do Azure em que o Servidor Flexível do Banco de Dados do Azure para MySQL está disponível hoje.

Criar uma réplica

Ao iniciar o fluxo de trabalho de criação de réplica, você cria uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL em branco. O novo servidor contém 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

Você cria réplicas de leitura com a mesma configuração de servidor que a origem. Você pode alterar a configuração do servidor de réplica após a criação. Você sempre cria o servidor de réplica no mesmo grupo de recursos e assinatura que o servidor de origem. Se você quiser criar um servidor de réplica em um grupo de recursos diferente ou em uma assinatura diferente, poderá mover o servidor de réplica após a criação. Mantenha a configuração do servidor de réplica em valores iguais ou maiores que a origem para garantir que a réplica possa acompanhar a origem.

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

Conectar-se a uma réplica

Quando você cria uma réplica, ela 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 usar o acesso privado (Integração VNet), a réplica não poderá usar o acesso público (endereços IP permitidos).

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 uma instância do Servidor Flexível regular do Banco de Dados do Azure para MySQL. Para um servidor chamado myreplica com o nome de usuário administrador myadmin, você pode se conectar à réplica usando a CLI do MySQL:

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

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

Monitorar a replicação

O Azure Database para Servidor Flexível do MySQL fornece a métrica Atraso da replicação em segundos no Azure Monitor. Essa métrica está disponível apenas para réplicas. O Azure Monitor calcula essa métrica usando a seconds_behind_master métrica no comando do SHOW SLAVE STATUS MySQL. Defina um alerta para notificá-lo quando o atraso de replicação exceder um limite inaceitável para sua carga de trabalho.

Se você vir maior atraso de replicação, confira Solucionar 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 SLAVE_IO_RUNNING/REPLICA_IO_RUNNING métrica disponível no comando do SHOW SLAVESTATUS'/'SHOWREPLICA STATUS MySQL. Esse valor é sempre exibido como "Não" e não é um indicativo do status de replicação. Para saber o status correto da replicação, consulte as métricas de replicação – Status da Réplica IO e Status do SQL da Réplica na página Monitoramento.

Parar replicação

Você pode interromper a replicação entre um servidor de origem e um servidor de réplica. Quando você interrompe a replicação entre um servidor de origem e uma réplica de leitura, o servidor de réplica se torna um servidor autônomo. O servidor autônomo contém os dados que estavam disponíveis no servidor de réplica quando você iniciou o comando parar replicação. O servidor autônomo não sincroniza nenhum dado ausente do servidor de origem.

Quando você interrompe a replicação em um servidor de réplica, o servidor de réplica perde todos os links para o servidor de origem anterior e para outros servidores de réplica. Não há failover automatizado entre um servidor de origem e seus servidores de réplica.

Importante

Você não pode converter o servidor autônomo de volta em um servidor de réplica. Antes de interromper a replicação em uma réplica de leitura, verifique se o servidor de réplica tem todos os dados necessários.

Para obter mais informações, consulte parar a replicação em uma réplica.

Failover

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

As réplicas de leitura dimensionam cargas de trabalho com uso intensivo de leitura e não fornecem alta disponibilidade para um servidor. Você executa o failover manual interrompendo a replicação em uma réplica de leitura, colocando-a online no modo de leitura-gravação.

Como a replicação é assíncrona, há um atraso entre a origem e a réplica. Muitos fatores influenciam a quantidade de retardo, como a carga de trabalho no servidor de origem e a latência entre data centers. Na maioria dos casos, o atraso de réplica varia entre alguns segundos e alguns minutos. Você pode acompanhar o retardo de replicação real usando a métrica Defasagem 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. Recomendamos que você identifique o atraso médio observando o atraso de réplica ao longo do 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ê fizer failover para a réplica, o atraso no momento em que você desvincular a réplica da fonte indicará a quantidade de dados perdida.

Depois de decidir fazer failover para uma réplica:

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

    Você precisa interromper a replicação para tornar o servidor de réplica capaz de aceitar gravações. Esse processo desvincula o servidor de réplica da origem. Depois de iniciar a replicação de parada, o processo de back-end normalmente leva cerca de dois minutos para ser concluído. 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 da origem.

Quando o aplicativo processa leituras e gravações com êxito, você conclui o failover. A quantidade de tempo de inatividade que seu aplicativo experimenta depende de quando você detecta um problema e conclui as etapas 1 e 2.

GTID (identificador de transação global)

Um GTID (identificador de transação global) é um identificador exclusivo que o servidor de origem cria com cada transação confirmada. O Servidor Flexível do Banco de Dados do Azure para MySQL desativa o GTID por padrão. As versões 5.7 e 8.0 dão suporte a GTID. Para obter mais informações sobre GTID e como a replicação a usa, consulte a replicação do MySQL com a documentação gtid .

Use os seguintes parâmetros de servidor 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 os modos só podem ser feitas uma etapa de cada vez em ordem crescente (por exemplo, OFF -OFF_PERMISSIVE> ->ON_PERMISSIVE ->ON) OFF* OFF: as transações novas e de replicação devem ser anônimas
OFF_PERMISSIVE: novas transações são anônimas. As transações replicadas podem ser transações anônimas ou GTID.
ON_PERMISSIVE: novas transações são transações GTID. As transações replicadas podem ser transações anônimas ou GTID.
ON: as transações novas e replicadas devem ser transações GTID.
enforce_gtid_consistency Impõe a consistência do GTID permitindo a execução apenas das instruções que podem ser registradas de maneira transacional segura. Defina o valor ON antes de habilitar a replicação GTID. OFF* OFF: todas as transações têm permissão para violar a consistência de GTID.
ON: nenhuma transação tem permissão para violar a consistência de GTID.
WARN: todas as transações têm permissão para violar a consistência de GTID, mas um aviso é gerado.

Observação

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

Depois de habilitar o GTID, você não poderá desativá-lo. Se você precisar desativar o GTID, entre em contato com o suporte.

Você pode alterar GTIDs de um valor para outro somente em uma etapa por vez em ordem crescente de modos. Por exemplo, se gtid_mode estiver definido OFF_PERMISSIVEno momento, você poderá alterá-lo para ON_PERMISSIVE , mas não para ON.

Para manter a replicação consistente, você não pode atualizá-la para um servidor primário ou de réplica.

Definir enforce_gtid_consistency como ON antes de definir gtid_mode como ON.

Para habilitar o GTID e configurar o comportamento de consistência, atualize os parâmetros e enforce_gtid_consistency os parâmetros do gtid_mode servidor. Use 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 Azure.

Se um servidor de origem habilitar GTID (gtid_mode = ON), as réplicas recém-criadas também habilitarão o GTID e usarão a replicação GTID. Para garantir a consistência da replicação, você não pode alterar gtid_mode depois de criar servidores primários ou de réplica com GTID habilitado.

Considerações e limitações

Cenário Limitação/Consideração
Réplica no servidor no nível de preço com capacidade de intermitência Sem suporte
Preços O custo de execução do servidor de réplica depende da região em que o servidor de réplica é executado.
Tempo de inatividade/reinicialização do servidor de origem Nenhuma reinicialização ou tempo de inatividade é necessário ao criar uma réplica de leitura. Esta operação é uma operação online.
Novas réplicas Crie uma réplica de leitura como uma nova instância do Servidor Flexível do Banco de Dados do Azure para MySQL. Você não pode transformar um servidor existente em uma réplica. Você não pode criar uma réplica de outra réplica de leitura.
Configuração da réplica Você cria uma réplica usando a mesma configuração de servidor que a origem. Depois de criar uma réplica, você pode alterar várias configurações independentemente do servidor de origem: geração de computação, vCores, armazenamento e período de retenção de backup. Você também pode alterar a camada de computação de forma independente.

IMPORTANTE - Antes de atualizar uma configuração do servidor de origem para novos valores, atualize a configuração da réplica para valores iguais ou maiores. Esta ação garante que a réplica possa acompanhar as alterações realizadas na origem.
O método de conectividade e as configurações de parâmetro são herdados do servidor de origem para a réplica quando você cria a réplica. 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. Você não pode transformar o servidor autônomo em uma réplica novamente.
Servidores de origem excluídos Quando você exclui um servidor de origem, 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:
- innodb_file_per_table
- log_bin_trust_function_creators
O parâmetro event_scheduler está bloqueado nos servidores de réplica.
Para atualizar um dos parâmetros anteriores no servidor de origem, exclua servidores de réplica, atualize o valor do parâmetro na origem e recrie as 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, verifique se os valores de parâmetro que você está definindo na réplica de leitura são consistentes com os do servidor de origem.
Adicionando uma coluna AUTO_INCREMENT Chave Primária à tabela existente no servidor de origem Não recomendamos alterar a tabela depois AUTO_INCREMENT de criar uma réplica de leitura, pois essa ação interrompe a replicação. Se você quiser adicionar uma coluna de incremento automático depois de criar um servidor de réplica, considere estas abordagens:
- Crie uma nova tabela com o mesmo esquema que a tabela que você deseja modificar. Na nova tabela, altere a coluna com AUTO_INCREMENTe restaure os dados da tabela original. Solte a tabela antiga e renomeie-a na origem; essa abordagem não requer a exclusão do servidor de réplica, mas pode incorrer em um grande custo de inserção para criar uma tabela de backup.
- Recrie a réplica depois de adicionar todas as colunas de incremento automático.
Outros – Não há suporte para a criação de uma réplica de uma réplica.
- Tabelas na memória podem fazer com que as réplicas fiquem fora de sincronia. Essa limitação ocorre devido à tecnologia de replicação MySQL. Para obter mais informações, consulte a documentação de referência do MySQL.
* 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.
- Examine a lista completa das limitações de replicação do MySQL na documentação do MySQL.

Conteúdo relacionado

  • Last updated on