Confiabilidade no Banco de Dados do Azure para MySQL

Banco de Dados do Azure para MySQL é um serviço de banco de dados totalmente gerenciado que oferece controle granular e flexibilidade sobre as funções de gerenciamento de banco de dados e as configurações. O serviço fornece recursos de alta disponibilidade (HA) e recuperação de desastre (DR) com base em seus requisitos.

Quando você usa o Azure, reliability é uma responsabilidade compartilhada. Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar os Banco de Dados do Azure para MySQL resilientes a várias possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções na região e manutenção do serviço. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) Banco de Dados do Azure para MySQL.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, segurança, custo, operações e desempenho. Para entender como essas áreas influenciam umas às outras e contribuem para uma solução de Banco de Dados do Azure para MySQL confiável, consulte as práticas recomendadas de arquitetura para Banco de Dados do Azure para MySQL.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

Ao trabalhar com Banco de Dados do Azure para MySQL, você implanta um server, que representa os recursos de computação e armazenamento necessários para dar suporte ao servidor de banco de dados. Você implanta um ou mais bancos de dados no servidor.

Você pode implantar servidores nas camadas de computação Burstable, General Purpose e Memory Optimized. Cada camada de computação é otimizada para diferentes tipos de cargas de trabalho.

Para obter mais informações sobre a arquitetura de serviço geral e os modelos de implantação, consulte Banco de Dados do Azure para MySQL visão geral.

Arquitetura física

• Separação de computação e armazenamento: Banco de Dados do Azure para MySQL usa uma arquitetura de separação de armazenamento e computação para dar suporte à HA. O mecanismo de banco de dados é executado em uma VM (máquina virtual). Os arquivos de dados são armazenados em Armazenamento do Azure, que mantém de forma síncrona três cópias dos dados para proteger contra falhas de hardware de armazenamento. Dependendo da configuração de HA do servidor, os arquivos de dados podem ser armazenados no ZRS (armazenamento com redundância de zona) ou no LRS (armazenamento com redundância local).

• HA: Opcionalmente, você pode habilitar uma configuração de HA em seu servidor. Quando você ativa a configuração de HA, o serviço provisiona e mantém um servidor de réplica de prontidão. As alterações de dados no servidor primário são replicadas de forma síncrona para o servidor de réplica em espera para garantir a perda de dados zero durante uma falha do servidor primário.

  A arquitetura separa a camada de computação da camada de armazenamento, o que permite que o serviço lide com diferentes tipos de falhas adequadamente. Para maior resiliência, você pode espalhar os servidores entre zonas de disponibilidade.

  Um servidor de réplica em espera é implantado na mesma configuração de VM que o servidor primário, incluindo vCores, armazenamento e configurações de rede.

  Você pode alternar entre servidores executando um failover. Use failovers não planejados quando o servidor primário falhar e use failovers planejados quando precisar minimizar o tempo de inatividade do aplicativo durante um failover.

  Para obter mais informações, consulte HA no Banco de Dados do Azure para MySQL.

• Backups: Banco de Dados do Azure para MySQL cria automaticamente backups de servidor. Para obter mais informações, consulte Cópia de Segurança e Restauração.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas Azure quando se comunicam com apis, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Seus aplicativos devem lidar com erros transitórios de conectividade que podem ocorrer durante a manutenção, operações de dimensionamento ou interrupções de rede. Siga estas recomendações:

Resiliência a falhas de zona de disponibilidade

as zonas Availability são grupos fisicamente separados de datacenters em uma região Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Selecione seu tipo de suporte de zona de disponibilidade por meio da configuração de HA. Quando você habilita a HA, Banco de Dados do Azure para MySQL implanta um servidor de réplica em espera ao lado do servidor primário. Esse modelo de HA ajuda a garantir que os dados confirmados nunca sejam perdidos durante falhas. Seja qual for o modelo de implantação de HA escolhido, o serviço confirma dados de forma síncrona para os servidores de réplica primários e em espera. Se o servidor primário for interrompido, o servidor fará failover automaticamente para o servidor de réplica em espera.

O serviço armazena dados no armazenamento premium Arquivos do Azure. Dependendo da configuração de HA do servidor, ele usa ZRS ou LRS, que armazena três cópias de dados dentro ou entre zonas de disponibilidade.

Banco de Dados do Azure para MySQL dá suporte a dois tipos de configuração de zona de disponibilidade quando você usa HA:

• HA com redundância de zona: A redundância de zona fornece o nível mais alto de resiliência de zona implantando um servidor primário em uma zona de disponibilidade e um servidor de réplica em espera em uma zona de disponibilidade diferente. O servidor de réplica em espera usa computação, armazenamento e configuração de rede semelhantes ao servidor primário. A configuração com redundância de zona fornece isolamento físico de toda a pilha entre servidores primários e em espera.

  Selecione as zonas de disponibilidade para os servidores primários e em espera.

  Use implantações com redundância de zona para servidores de produção.

  

  O diagrama consiste em três seções. A primeira seção lista aplicativos cliente como Azure VMs, AKS (Serviço de Kubernetes do Azure) e Serviço de Aplicativo do Azure. A próxima seção é rotulada zona de disponibilidade 1. Ele contém o servidor primário e duas subseções, computação e armazenamento, separadas por uma linha pontilhada. A terceira seção é rotulada zona de disponibilidade 2. Ele espelha a zona de disponibilidade 1, mas contém o servidor em espera. As setas apontam dos aplicativos cliente para um balanceador de carga padrão. Uma seta aponta do balanceador de carga para uma VM no servidor primário na zona de disponibilidade 1. As setas bidirecionais conectam a VM ao compartilhamento de arquivos Premium e à unidade de estado sólido (SSD). Outra seta aponta do compartilhamento de arquivos premium para o armazenamento de blobs de backup. Uma seta rotulada como replicação assíncrona baseada em armazenamento aponta da zona de disponibilidade 1 para a zona de disponibilidade 2.

  As operações de gravação podem experimentar um pequeno aumento na latência de confirmação porque o serviço replica dados de forma síncrona para o servidor em espera. Em média, você pode esperar um aumento de 5% a 10% na latência das operações de gravação e commit do aplicativo. O impacto varia de acordo com a carga de trabalho, a SKU selecionada e a região.

• HA com redundância local: Os servidores primários e em espera usam a mesma zona de disponibilidade. Se ocorrer uma interrupção no servidor primário, mas a zona ainda estiver íntegra, o servidor fará failover automaticamente para o servidor em espera.

  Uma implantação localmente redundante fornece HA dentro de uma única zona de disponibilidade. Ele protege você contra falhas em nível de nó e também ajuda a reduzir a indisponibilidade da aplicação durante paradas planejadas e não planejadas. No entanto, ele não protege contra uma interrupção nessa zona. Em regiões que têm zonas de disponibilidade, esse tipo de configuração também às vezes é chamado de zonal ou de zona única.

  

  O diagrama consiste em três seções. A primeira seção lista aplicativos cliente como Azure VMs, AKS e Serviço de Aplicativo. A próxima seção é rotulada zona de disponibilidade 1. Ele contém duas seções separadas para o servidor primário e o servidor em espera. Uma linha pontilhada divide a seção de cada servidor em duas subseções, computação e armazenamento. As setas apontam dos aplicativos cliente para um balanceador de carga padrão. Uma seta aponta do balanceador de carga para uma VM no servidor primário na zona de disponibilidade 1. As setas bidirecionais ligam a VM ao compartilhamento de arquivos Premium e à unidade de estado sólido (SSD). Outra seta aponta do compartilhamento de arquivos premium para o armazenamento de blobs de backup. Uma seta rotulada como "replicação assíncrona baseada em armazenamento" aponta do servidor primário para o servidor de espera. A terceira seção, chamada zona de disponibilidade 2, está vazia.

  Use a HA com redundância local apenas nos seguintes cenários:

  • Quando você tem aplicativos extraordinariamente sensíveis à latência, você valida a necessidade de minimizar a latência entre sua réplica primária e secundária e planeja a resiliência de zona usando outras abordagens arquitetônicas.

  • Quando você implanta em uma região que não dá suporte a zonas de disponibilidade. Nesse cenário, a região funciona como uma única zona, o que torna a HA com redundância local a única opção de HA.

  Os servidores estão na mesma zona, o que pode reduzir a latência de gravação para aplicativos que você implanta dentro dessa zona.

Se você configurar o servidor sem HA, ele será executado em um único servidor. Se esse servidor ou sua zona falhar, o servidor não estará disponível.

Requisitos

• Suporte à região: Banco de Dados do Azure para MySQL dá suporte a diferentes configurações de zona de disponibilidade, dependendo de sua região de Azure. Para obter uma lista completa de regiões, incluindo tipos de suporte de zona de disponibilidade e considerações específicas para cada região, consulte Azure regiões.

• Camada de serviço: A HA requer camadas de Uso Geral ou Otimizada para Memória. A categoria Burstable não oferece suporte a HA (com redundância de zona ou local).

Custo

Ao habilitar a HA, você cria e paga pelo servidor em espera na mesma taxa que o servidor primário. A configuração da zona de disponibilidade não afeta o custo. A replicação de dados não incorre em encargos dentro ou entre zonas de disponibilidade. Dependendo do volume de armazenamento de backup, você também pode receber uma cobrança pelo armazenamento de backup. Para obter informações detalhadas sobre preços, consulte preços do Banco de Dados do Azure para MySQL.

Considerações

• Chaves primárias: Use chaves primárias em todas as tabelas porque essa abordagem reduz o tempo de replicação e failover.

• Limitações e problemas conhecidos: Examine a lista de limitações e problemas conhecidos.

Configurar o suporte à zona de disponibilidade

Para configurar o suporte à zona de disponibilidade para um servidor, defina as configurações de HA.

• Crie um servidor com redundância de zona. Para saber como criar um servidor com HA e redundância de zona habilitada, consulte os seguintes artigos:

  • Azure portal: Gerenciar a alta disponibilidade (HA) com redundância entre zonas no Banco de Dados do Azure para MySQL usando o portal do Azure.

  • CLI do Azure: gerenciar a HA com redundância de zona em Banco de Dados do Azure para MySQL usando o CLI do Azure.

• Crie um servidor com redundância local. Para criar um servidor com HA com redundância local em uma única zona de disponibilidade, você deve usar o CLI do Azure ou outro método de implantação programática. Para obter as instruções de CLI do Azure, consulte Habilitar HA durante a criação do servidor.

• Altere a configuração da zona de disponibilidade para servidores existentes. Se você tiver um servidor existente, a abordagem que você segue para habilitar o suporte à zona de disponibilidade dependerá da configuração inicial do servidor.

  • Para alterar um servidor existente para ha com redundância de zona, você precisa migrar para um novo servidor. Para obter mais informações, consulte Migrar de um servidor existente para um servidor com redundância de zona.

  • Para alterar um servidor existente para HA com redundância local:

    1. Desabilite a HA, se ela estiver habilitada.

    2. Ative a HA com redundância local. Você deve usar o CLI do Azure ou outro método de implantação programática. Para obter instruções sobre a CLI do Azure, consulte Gerenciar a alta disponibilidade com redundância de zona no Banco de Dados do Azure para MySQL usando a CLI do Azure.

• Desabilite a HA. Desabilitar a HA remove o servidor de réplica em espera, de modo que o servidor não seja resiliente a interrupções no nível da zona. No entanto, se os backups com redundância geográfica estiverem habilitados, você ainda poderá recuperar o servidor em uma região diferente usando esses backups. Para obter mais informações, consulte Desabilitar HA.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando você configura servidores com suporte a HA e zona de disponibilidade e todas as zonas de disponibilidade estão operacionais.

• Operação entre zonas: Os aplicativos cliente MySQL conectam-se ao servidor primário usando o FQDN (nome de domínio totalmente qualificado) do servidor de banco de dados. Evite usar o endereço IP do servidor primário porque o endereço IP pode ser alterado, inclusive durante failovers.

  Banco de Dados do Azure para MySQL usa uma configuração ativa-passiva na qual o servidor primário manipula todas as conexões e consultas de banco de dados na zona de disponibilidade primária. O servidor de réplica em espera não atende ao tráfego do cliente durante operações normais.

• Replicação de dados entre zonas: As gravações são confirmadas no servidor primário e gravadas de forma síncrona nos logs do servidor em espera usando o ZRS. O servidor primário não aguarda que o servidor em espera aplique os logs, mas como os logs estão no ZRS, eles continuam disponíveis mesmo se ocorrer uma falha de zona ou réplica.

  Os efeitos da replicação são diferentes dependendo da configuração da zona de disponibilidade que o servidor usa:

  • Com redundância de zona: Como os servidores estão em zonas separadas, essa abordagem garante zero perda de dados durante uma falha de zona. Esta situação também é conhecida por alcançar um objetivo de ponto de recuperação (RPO) de zero para falhas de zona.

    No entanto, a replicação entre zonas pode introduzir uma pequena quantidade de latência extra. Em média, você pode esperar de 5% a 10% maior latência para gravações e confirmações de aplicativo, mas o impacto varia de acordo com a carga de trabalho, a SKU selecionada e a região.

  • Redundância local: Nenhum tráfego é replicado entre zonas.

  Observação

  O sistema replica todas as alterações em tempo real para o servidor de réplica em espera, incluindo erros de usuário não intencionais, como uma queda acidental de uma tabela ou atualizações de dados incorretas. Devido à replicação imediata, você não pode usar a réplica em espera para recuperação. Para se recuperar de erros do usuário, você deve realizar uma restauração pontual no tempo a partir de um backup. Para obter mais informações, consulte Cópia de Segurança e Restauração.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar ao configurar servidores com HA e suporte a zonas de disponibilidade, quando ocorre uma indisponibilidade em uma zona de disponibilidade.

• Detecção e resposta: Azure verifica periodicamente a integridade dos servidores primários e em espera. Após vários pings, se o monitoramento de integridade detectar que um servidor primário não é acessível, o serviço inicia um failover automático para o servidor em espera. O algoritmo de monitoramento de saúde usa vários pontos de dados para evitar situações de falso positivo.

  Se ocorrer uma falha de zona, o comportamento será diferente dependendo da configuração da zona de disponibilidade que o servidor usa:

  • Zone-redundante: Banco de Dados do Azure para MySQL detecta automaticamente falhas em zonas de disponibilidade por meio do monitoramento contínuo de múltiplos endpoints do servidor. Para obter mais informações, consulte Como a detecção automática de failover funciona em servidores habilitados para HA.

    Para ver os possíveis tipos de status de HA, consulte Monitorar HA. Quando uma zona falha, o Azure inicia um failover não planejado para o servidor em espera sem exigir ação.

  • Redundante local: Os servidores primários e em espera ficarão indisponíveis se a zona de disponibilidade que hospeda um servidor com redundância local ficar indisponível. Nesse cenário, o serviço não fornece failover automático. Você é responsável por detectar a interrupção da zona e executar ações de recuperação, como restaurar backups com redundância de zona para um servidor separado em outra zona ou região de disponibilidade.

• Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.

  Banco de Dados do Azure para MySQL gera um evento Azure Resource Health quando ocorre um failover não planejado.

• Solicitações ativas: Quando uma zona de disponibilidade fica indisponível, as solicitações em andamento para servidores na zona afetada podem ser encerradas. Os aplicativos devem repetir essas solicitações. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: A quantidade de perda de dados depende da configuração da zona de disponibilidade do servidor.

  • Com redundância de zona: Espera-se que não haja perda de dados durante o failover de zona devido à replicação síncrona entre o servidor primário e o servidor de espera em diferentes zonas.

  • Redundância local: Os dados em servidores na zona afetada não estão disponíveis até que a zona se recupere.

• Tempo de inatividade esperado: A quantidade de tempo de inatividade depende da configuração da zona de disponibilidade usada pelo servidor.

  • Redundância de zona: O failover normalmente é concluído em 60 a 120 segundos. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

  • Redundante local: Os servidores em uma zona afetada ficam indisponíveis até que a zona de disponibilidade se recupere.

• Redistribuição: O comportamento de redirecionamento de tráfego depende da configuração da zona de disponibilidade usada pelo servidor.

  • Com redundância de zona: Após o failover, o servidor em espera se torna o novo servidor primário e começa a aceitar novas conexões. Azure estabelece automaticamente um servidor em espera na zona primária original após a recuperação. Para obter mais informações, consulte failover não planejado.

  • Redundância local: Quando uma zona está indisponível, seu servidor também fica indisponível. Se você tiver um servidor separado pré-criado em outra zona ou região de disponibilidade, será responsável por redirecionar o tráfego para esse servidor.

Recuperação de zona

O comportamento de recuperação de zona depende da configuração da zona de disponibilidade usada pelo servidor.

• Redundante por zona: Quando a zona de disponibilidade se recupera, o Banco de Dados do Azure para MySQL recria automaticamente o servidor em espera na zona recuperada e o sincroniza com o servidor primário atual. Depois, a zona recuperada serve como local de espera. O serviço não move automaticamente a função primária de volta para a zona original para evitar interrupções desnecessárias. Se você quiser retornar o primário para a zona original, poderá iniciar manualmente um failover planejado.

• Redundante local: Quando a zona estiver íntegra, os servidores na zona estarão disponíveis novamente. Você é responsável pelos procedimentos de recuperação de zona e pela sincronização de dados que suas cargas de trabalho exigem.

Testar falhas em zonas

As opções para testar falhas de zona dependem da configuração da zona de disponibilidade usada pela sua instância.

• Com redundância de zona: Você pode testar a resiliência do aplicativo a falhas iniciando um failover planejado. Use um failover planejado para simular uma interrupção não planejada enquanto sua carga de trabalho é executada e observe o tempo de inatividade do aplicativo. Execute simulações em ambientes de não produção ou em um momento silencioso. Para obter mais informações, consulte Failover planejado.

• Redundante local: Você não pode simular uma interrupção de zona completa, mas pode simular que o servidor está indisponível de maneira semelhante ao que ocorre durante uma interrupção de zona. Para obter mais informações, consulte os seguintes artigos:

  • Portal do Azure: Pare e inicie uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL.

  • CLI do Azure: reinicie, pare e inicie uma instância de servidor Banco de Dados do Azure para MySQL flexível.

Resiliência a falhas em toda a região

Banco de Dados do Azure para MySQL dá suporte a réplicas de leitura entre regiões, que podem ser usadas para manter uma cópia sincronizada do banco de dados em uma região diferente para uma recuperação mais rápida.

Você também pode usar backups com redundância geográfica, em regiões com suporte, para fornecer recuperação entre regiões. No entanto, os backups normalmente envolvem mais tempo de inatividade e perda de dados do que replicação. Para obter mais informações, consulte Cópia de Segurança e Restauração.

Réplicas de leitura entre regiões

Implante réplicas de leitura para proteger seus bancos de dados contra falhas no nível da região. Cada réplica de leitura é um servidor Banco de Dados do Azure para MySQL separado. Quando você coloca uma réplica de leitura em uma segunda região da Azure, o servidor de banco de dados pode fornecer resiliência a um problema na região. Você pode implantar até 10 réplicas de leitura, que opcionalmente podem estar em diferentes regiões do Azure.

A tecnologia de replicação física do MySQL atualiza as réplicas de leitura de forma assíncrona a partir do servidor de origem na região primária, o que significa que as réplicas podem ficar defasadas em relação à origem. As réplicas de leitura entre regiões podem, opcionalmente, suportar cargas de trabalho somente leitura para reduzir a latência de aplicativos distribuídos globalmente ou para aliviar o tráfego de leitura do servidor de origem. Para obter mais informações sobre recursos e considerações de réplica de leitura, consulte Réplicas de leitura.

Se a sua região primária falhar, você poderá executar um failover manualmente para tornar sua réplica secundária o servidor primário. Para realizar o failover manualmente, você interrompe o processo de replicação, que promove a réplica de leitura a um servidor de leitura e gravação. Devido à replicação assíncrona, o failover pode resultar em perda de dados. Seu aplicativo precisa se conectar ao novo servidor primário e você é responsável pela reconfiguração do aplicativo.

Requisitos

• Region support: Você pode criar réplicas de leitura entre regiões em qualquer região que dê suporte a Banco de Dados do Azure para MySQL. Você não está limitado às regiões emparelhadas do Azure.

• Camadas de computação: As camadas de computação com Uso Geral e Otimizado para Memória dão suporte a réplicas de leitura. A camada Intermitível não dá suporte a réplicas de leitura.

Considerações

• Diferenças de configuração: Quando você cria uma réplica, ela herda várias configurações do servidor de origem, incluindo a geração de computação, vCores e armazenamento. Você pode personalizar esses valores na réplica de leitura depois de criá-la, mas é melhor usar valores iguais ou maiores para garantir que a réplica possa acompanhar as alterações na origem.

• Monitorando o atraso de replicação: O processo de replicação assíncrona requer um atraso de replicação, que pode variar dependendo de vários fatores. Quando o atraso de replicação é muito alto, o servidor pode ter problemas. É importante monitorar o atraso de replicação para que você possa atenuar os problemas antes que eles aumentem. Para obter mais informações, consulte a replicação do Monitor.

• HA: As réplicas de leitura não podem ter a HA habilitada e, quando fazem failover para se tornarem o servidor primário, elas também não têm HA. Você é responsável por configurar a HA depois de fazer failover em uma réplica.

Custo

As réplicas de leitura incorrem em custos de computação e armazenamento, bem como custos de transferência de dados entre regiões para replicação. Para obter informações detalhadas sobre preços, consulte os preços de Azure Database para MySQL e os preços de largura de banda.

Configurar o suporte a várias regiões

• Crie uma réplica de leitura: Para saber como criar uma réplica de leitura, consulte os seguintes artigos:

  • Azure portal: Como criar e gerenciar réplicas de leitura no Servidor Flexível do Banco de Dados do Azure para MySQL usando o portal do Azure

  • CLI do Azure: como criar e gerenciar réplicas de leitura no servidor flexível Banco de Dados do Azure para MySQL usando o CLI do Azure

  Você pode configurar réplicas depois de criar o servidor de origem somente se o servidor de origem estiver em execução e acessível.

• Interromper a replicação: Para saber como interromper a replicação, consulte Parar replicação em um servidor de réplica.

• Excluir uma réplica de leitura: Para saber como excluir uma réplica de leitura, consulte Excluir um servidor de réplica.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando você configura seu servidor com uma réplica de leitura em outra região e todas as regiões estão operacionais:

• Roteamento de tráfego entre regiões: Durante as operações normais, seu aplicativo deve direcionar o tráfego de leitura/gravação para o servidor de origem na região primária. Opcionalmente, você pode direcionar solicitações de leitura para sua réplica de leitura.

• Replicação de dados entre regiões: As réplicas de leitura entre regiões usam replicação assíncrona para minimizar o impacto no desempenho do servidor de origem. A quantidade de retardo de replicação depende de vários fatores, incluindo a carga de gravação e a latência entre o servidor de origem e as réplicas. O atraso de replicação normalmente é de pelo menos vários minutos, mas pode ser muito mais longo. Para obter mais informações, consulte Monitor replication e, para obter instruções detalhadas, consulte Monitor replication no Portal do Azure.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando você configura um servidor com suporte a réplica de leitura entre regiões e ocorre uma interrupção na região primária.

• Detecção e resposta: Você é responsável por detectar uma interrupção na região primária e disparar manualmente um failover. Essa ação pode resultar na perda de dados não duplicados.

  Importante

  Você é responsável por disparar o failover. Azure não faz failover para ler réplicas automaticamente, mesmo que ocorra uma falha na região.

  O failover exige que você execute as seguintes etapas:

  1. Interromper a replicação. Esse procedimento é irreversível e o servidor não pode ser transformado em uma réplica novamente. O processo resulta em perda de dados. Para obter mais informações sobre as implicações dessa ação, consulte Parar replicação.

  2. Reconfigure seu aplicativo para usar o novo servidor primário.

  Para obter mais informações, confira Failover.

• Notification: Microsoft não notifica automaticamente quando uma região está inoperante. No entanto, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas na região, e pode configurar alertas Service Health para notificar você sobre problemas.

• Solicitações ativas: Todas as conexões ativas com a região de origem serão descartadas se o servidor de origem não estiver disponível. Os aplicativos precisam tentar novamente fazer conexões com o novo servidor primário após a conclusão do processo de failover.

• Perda de dados esperada: Durante uma interrupção de região, você deve executar um failover que interrompe a replicação. Esse processo resulta em perda permanente de dados não duplicados.

  A quantidade de perda de dados depende do atraso de replicação no momento da interrupção. O atraso de replicação normalmente é de pelo menos vários minutos, mas pode ser muito mais longo. Para obter mais informações, consulte a replicação do Monitor.

• Tempo de inatividade esperado: A interrupção da replicação normalmente é concluída dentro de dois minutos depois que você dispara a ação. Você é responsável por reconfigurar seus aplicativos para se conectar ao novo servidor primário. O tempo necessário para você executar a reconfiguração também contribui para o tempo de inatividade geral.

• Redirecionamento de tráfego: Você é responsável por reconfigurar seus aplicativos para se conectar ao novo servidor primário.

  Observação

  Depois que você executar o failover de uma réplica de leitura para que ela se torne o servidor primário, o servidor não terá alta disponibilidade (HA) habilitada. Você deve habilitar a HA manualmente ou incluí-la em sua automação.

Recuperação de região

Quando a região se recupera, você é responsável pelas atividades de failback para retomar as operações na região primária. Microsoft não move automaticamente o servidor primário. Você pode criar uma nova réplica de leitura na região primária e, em seguida, executar outro processo de failover para restaurar as operações na região primária. Considere uma das seguintes abordagens, dependendo se seu aplicativo pode tolerar tempo de inatividade ou perda de dados:

• Coloque seu aplicativo offline e aguarde até que a replicação acompanhe todas as alterações. Essa abordagem requer um tempo de inatividade do aplicativo que é aproximadamente o mesmo que o atraso de replicação.

• Execute o failover e aceite a perda de dados não duplicados.

Lembre-se de que você também é responsável por reconfigurar seus aplicativos para se conectar ao novo servidor primário conforme necessário.

Teste de falhas na região

Teste regularmente os procedimentos de failover de réplica de leitura para garantir que seus processos sejam válidos e que os recursos atendam aos requisitos de RTO (objetivo de tempo de recuperação) e RPO.

Você pode realizar o failover de uma réplica de leitura para se tornar o servidor primário a qualquer momento, mesmo quando todas as regiões estiverem funcionando normalmente. Recomendamos que você execute esses testes em um ambiente de não produção porque ele pode causar perda de dados e requer failback manual.

Como parte de sua estratégia de recuperação de desastres, realize regularmente testes completos de recuperação. Essas simulações incluem validação de dados, testes de funcionalidade do aplicativo e procedimentos documentados de reversão.

Backup e restauração

Banco de Dados do Azure para MySQL faz backup dos dados automaticamente para que você possa restaurá-los a qualquer ponto no tempo dentro do período de retenção de backup. Essa proteção ajuda você a evitar corrupção acidental e exclusão de dados. Microsoft gerencia totalmente os backups sem interromper a disponibilidade do servidor. Os backups incluem backups completos e backups de log de transações.

• Armazenamento de backup: Se você configurar o servidor com HA com redundância de zona, o sistema armazenará backups no ZRS. Para servidores configurados sem HA ou com HA com redundância local, o sistema armazena backups em LRS.

  Nas regiões do Azure que têm pares correspondentes, você pode configurar o armazenamento com redundância geográfica (GRS) para os backups ao criar o servidor. Essa abordagem replica os backups para a região emparelhada do Azure para fornecer proteção adicional contra falhas regionais. O sistema replica os backups de forma assíncrona.

  O período de retenção de backup padrão é de 7 dias, mas você pode estender a retenção até 35 dias. Todos os backups são criptografados.

• Restaurar: A PITR (restauração pontual) permite restaurar seu banco de dados a qualquer momento dentro do período de retenção de backup. O processo de restauração cria um novo servidor de banco de dados com um novo nome de servidor fornecido pelo usuário. Você pode usar o novo servidor as-is ou copiar dados dele.

  Ao restaurar um backup com redundância geográfica, você cria um novo servidor na região emparelhada. Em algumas regiões, você pode usar o Geo-Restore Universal para restaurar um backup com redundância geográfica para uma região que não seja a região emparelhada da sua região primária.

  Use essa funcionalidade para se recuperar de modificações acidentais de dados, erros de aplicativo ou cenários de teste.

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

Para obter mais informações, consulte Backup e restauração no Banco de Dados do Azure para MySQL.

Resiliência à manutenção do serviço

Banco de Dados do Azure para MySQL lida automaticamente com tarefas críticas de manutenção, incluindo a aplicação de patch do hardware subjacente, do sistema operacional e do mecanismo de banco de dados. O serviço inclui atualizações de segurança, atualizações de software e atualizações de versão secundárias como parte da manutenção planejada. Para obter mais informações, consulte Manutenção agendada no Banco de Dados do Azure para MySQL.

Para garantir que o servidor permaneça disponível durante as janelas de manutenção, siga estas recomendações:

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Banco de Dados do Azure para MySQL fornece SLAs de disponibilidade diferentes com base na configuração do servidor:

• Servidores configurados com HA com redundância de zona.
• Servidores configurados com HA com redundância local.
• Servidores configurados sem HA.

Conteúdo relacionado

• Confiabilidade do Azure
• práticas recomendadas de arquitetura para Banco de Dados do Azure para MySQL
• Visão geral da continuidade de negócios com o Banco de Dados do Azure para MySQL