Base de Dados do Azure para MySQL

Concluído

Nesta unidade, você examina como o Banco de Dados do Azure para MySQL pode ajudar a criar um armazenamento de dados resiliente, eficiente e fácil de manter para seu aplicativo baseado na Web. Considerando a criticidade esperada dos negócios e a alta demanda, você está interessado em sua capacidade de dimensionar recursos de computação e armazenamento. Você também deseja garantir que o Banco de Dados do Azure para MySQL minimize a sobrecarga de gerenciamento e manutenção como um serviço gerenciado, permitindo que você se concentre no desenvolvimento de software.

Quais são as principais características do Banco de Dados do Azure para MySQL?

O Banco de Dados do Azure para MySQL - Servidor Flexível foi projetado para oferecer compatibilidade completa com seus aplicativos MySQL existentes, suportando as versões 5.7 e 8.0 do MySQL Community Server amplamente utilizadas. Esta opção de hospedagem é particularmente eficaz para cenários que exigem:

  • Controle detalhado sobre configurações de computação e armazenamento.
  • Desempenho consistentemente elevado.
  • Confiável, alta disponibilidade e continuidade de negócios.
  • Estratégias eficientes de gestão de custos.

Além disso, o Servidor Flexível melhora a segurança com seu firewall interno para pontos de extremidade públicos e dá suporte à conectividade privada por meio da integração da Rede Virtual do Azure (rede virtual) e do Azure Private Link, que protege seus dados contra acesso não autorizado.

Computação

O Banco de Dados do Azure para MySQL - Servidor Flexível está disponível em três camadas de computação, com cada camada voltada para um caso de uso específico:

  • Burstable: Ideal para desenvolvimento ou projetos temporários com demandas de desempenho intermitentes.
  • Objetivo geral: Adequado para uma ampla gama de cargas de trabalho de produção que exigem computação e memória equilibradas.
  • Business Critical: Ideal para aplicativos que precisam de alto desempenho de computação e resiliência.

O nome da camada específica é derivado do nome da série SKU (Unidade de Manutenção de Estoque) da VM do Azure que hospeda a implantação gerenciada do MySQL Server. Dentro de cada camada, você pode escolher entre vários tamanhos de VM diferentes, cada um oferecendo um número diferente de vCores (variando de 1 a 96) e quantidade de memória (variando de 4 gigabytes (GB) a cerca de 700 GB).

A camada de computação Burstable usa VMs da série B, o General Purpose depende das VMs das séries Dadsv5 (AMD) e Ddsv4 (Intel) e o Business Critical é executado em VMs Standard Eadsv5-series (AMD) e Edsv5-series (Intel).

No portal do Azure, durante o processo de criação do servidor, você pode selecionar a opção de camada na página Noções básicas, em Detalhes do servidor, ou na página Computação flexível do servidor + armazenamento, em Computação.

Captura de tela da seção Computação da página Computação+armazenamento exibindo as opções de tamanhos de computação da camada de computação otimizada para memória.

Armazenamento

Ao provisionar um servidor ou em qualquer ponto depois disso, você pode aumentar a quantidade de armazenamento alocado até o limite de 16.384 gibibytes (GiB), ou 16 tebibytes (TiB) para as camadas Burstable e de Uso Geral, e 32 TiB para a camada Crítica de Negócios. O limite inferior (20 GiB) é o mesmo, independentemente da camada de computação e do tamanho selecionados. Além disso, o dimensionamento do armazenamento é independente da camada de computação e do tamanho escolhido, e você também pode habilitar o crescimento automático do armazenamento.

Nota

Depois de aumentar a quantidade de armazenamento, você não pode diminuí-lo.

Independentemente do tamanho do armazenamento, você também pode aumentar e diminuir o limite desejado de operações de entrada/saída por segundo (IOPS). O limite superior de IOPS disponíveis depende da camada de computação e do tamanho, atingindo 80.000 IOPS para o maior tamanho disponível do Business Critical SKU. Você pode usar essa funcionalidade de IOPS escalável para acomodar requisitos de recursos que mudam dinamicamente a qualquer momento e também permitir que as IOPS de dimensionamento automático sejam ajustadas automaticamente com base nas demandas de carga de trabalho.

Conectividade de rede

A Base de Dados do Azure para MySQL - Servidor Flexível suporta os três métodos de conectividade, acesso público, acesso privado e uma ligação privada.

Captura de tela da guia Rede exibindo as configurações de rede para um novo Banco de Dados do Azure para servidor MySQL.

Acesso público

Com o acesso público, que é fornecido por meio de um ponto de extremidade externo, você deve permitir explicitamente o acesso usando regras de firewall:

  • Para tráfego externo, você deve especificar um endereço IP individual ou um intervalo de endereços IP a partir do qual o tráfego é permitido.
  • Para o tráfego originado do Azure, você precisa permitir o acesso público de qualquer serviço do Azure.

Importante

Como o acesso público permite conexões de endereços IP alocados a qualquer recurso do Azure, incluindo conexões de assinaturas de outros clientes, ele só é recomendado para uso em cenários de desenvolvimento e teste.

Acesso privado

Use o suporte de integração de rede virtual para acesso privado por meio de redes virtuais designadas do Azure. Você pode usar o acesso privado para se conectar com segurança a um servidor flexível MySQL de dentro da mesma VNet, de uma VNet diferente usando emparelhamento ou até mesmo do local usando uma conexão ExpressRoute ou VPN. Se você habilitar essa opção, o servidor bloqueará automaticamente as conexões originadas da Internet.

Nota

Antes de habilitar o acesso privado, a resolução de nomes DNS (Serviço de Nomes de Domínio) personalizada deve ser implementada. Para obter mais informações, consulte Acesso à Rede Privada usando a integração de rede virtual para o Banco de Dados do Azure para MySQL - Servidor Flexível.

O link privado fornece um ponto de extremidade de endereço IP privado dentro de uma sub-rede VNet para se conectar diretamente ao servidor flexível MySQL. O Azure Private Link essencialmente traz os serviços do Azure para dentro de sua VNet privada por meio de um endereço IP como qualquer outro recurso de VNet. Você pode criar vários pontos de extremidade privados, por exemplo, um por aplicativo de conexão ou recurso PaaS do Azure. Combinado com as regras de firewall do NSG, os links privados fornecem controle refinado sobre quais serviços podem acessar o banco de dados.

Por padrão, o servidor impõe o Transport Layer Security (TLS 1.2) para ajudar a proteger a comunicação de rede de entrada.

Importante

Embora você possa permitir conexões não criptografadas após o provisionamento do servidor, isso não é recomendado.

Elevada disponibilidade

O Banco de Dados do Azure para MySQL - Servidor Flexível dá suporte à alta disponibilidade com failover automático para ajudar a garantir que os dados confirmados nunca sejam perdidos devido a falhas localizadas. Quando você habilita essa funcionalidade, a plataforma provisiona e gerencia automaticamente uma réplica em espera.

Existem dois modelos de arquitetura de alta disponibilidade, dependendo do posicionamento da réplica.

Alta disponibilidade com redundância de zona

Para maior resiliência, o modelo de alta disponibilidade com redundância de zona posiciona o banco de dados primário em uma zona de disponibilidade e sua réplica em espera em uma zona separada. Essa configuração foi projetada para proteger contra falhas no nível do data center, oferecendo um nível mais alto de proteção de dados, garantindo que os bancos de dados primários e de backup não estejam sujeitos aos mesmos riscos localizados. Esse modelo é recomendado para aplicativos críticos que têm a continuidade e a integridade dos dados como objetivos primordiais, pois permite que o serviço permaneça disponível mesmo que um data center inteiro fique offline.

Alta disponibilidade na mesma zona

O modelo de alta disponibilidade da mesma zona situa o banco de dados primário e sua réplica em espera dentro da mesma zona de disponibilidade. Optar por uma implantação de mesma zona é benéfico para cenários em que a latência mínima é crucial para o desempenho do aplicativo. Manter a instância principal e sua réplica em estreita proximidade física garante que o processo de failover não afete significativamente os tempos de resposta. Essa configuração é ideal para aplicativos afetados até mesmo por diferenças mínimas de latência, que podem afetar a funcionalidade ou a experiência do usuário.

Continuidade do negócio

O Banco de Dados do Azure para MySQL - Servidor Flexível cria automaticamente backups point-in-time de seus bancos de dados. Ele os retém em armazenamento localmente redundante por até 35 dias ou 10 anos ao usar retenção de longo prazo. Ao configurar o backup, você pode escolher backups localmente redundantes, com redundância de zona ou com redundância geográfica, permitindo que você se recupere de uma interrupção que afeta toda uma região do Azure. Além disso, você pode executar backups sob demanda a qualquer momento para criar um instantâneo de backup fora do agendamento de backup regular.

O Banco de Dados do Azure para MySQL também dá suporte a janelas de manutenção gerenciadas destinadas à aplicação automatizada de patches de servidor, facilitando a continuidade de negócios. Ao especificar uma agenda de aplicação de patches personalizada, você pode minimizar o efeito de um tempo de inatividade temporário resultante da reinicialização do servidor.

Otimização de custos

O Banco de Dados do Azure para MySQL - Servidor Flexível oferece várias opções para otimizar custos.

  • Controle granular sobre a configuração de computação e armazenamento. Você pode ajustar a maioria das opções de configuração do servidor de forma independente, permitindo otimizar os custos de implantação com base em seus objetivos e no caso de uso pretendido. Por exemplo, você pode ajustar separadamente as opções para:

    • SKU de computação
    • A quantidade de armazenamento
    • IOPS
    • O período de retenção de backup

    Além disso, você também pode habilitar a funcionalidade de IOPS de dimensionamento automático para ajustar automaticamente as IOPS com base nas demandas de carga de trabalho. Ao contrário das IOPS pré-provisionadas, que especificam um limite de IOPS fixo e são pagas independentemente do uso, as IOPS de dimensionamento automático permitem que você pague apenas pelo número de operações de E/S que você consome.

  • A capacidade de parar e iniciar o servidor sob demanda. O faturamento da camada de computação é interrompido assim que você interrompe o servidor. Essa capacidade pode ajudá-lo a minimizar os custos durante as cargas de trabalho de desenvolvimento, teste e produção com um cronograma previsível e confiável.

  • A camada de computação Burstable. Aproveite o nível de computação Burstable para obter preços competitivos para suas cargas de trabalho que exigem baixa utilização da CPU com picos ocasionais de uso da CPU.

  • O desconto de instância reservada. Você pode se comprometer com um plano de compra de um ou três anos para obter o desconto de instância reservada, economizando mais de 60% do custo original sem desconto. Considere essa opção para cargas de trabalho de produção com requisitos de capacidade de computação previsíveis e de longo prazo.

  • Uma conta gratuita do Azure. Você pode usar uma conta gratuita do Azure para avaliar o Servidor Flexível sem custo por 12 meses, com limites mensais de até:

    • 750 horas de instância Burstable B1MS, horas suficientes para executar uma instância de banco de dados continuamente a cada mês.
    • 32 GB de armazenamento e 32 GB de armazenamento de backup.

Nota

Se você criar um servidor flexível do Banco de Dados do Azure para MySQL usando sua conta gratuita do Azure, um custo mensal estimado ainda aparecerá na folha Computação + Armazenamento: Resumo de Custos e na guia Revisão + Criar. No entanto, desde que você esteja usando sua conta gratuita do Azure e seu uso do serviço permaneça dentro dos limites mensais associados, você não será cobrado pelo serviço.