Banco de Dados do Azure para MySQL - Recursos de desempenho do Servidor Flexível
Você pode criar o Banco de Dados do Azure para servidores flexíveis MySQL com base em uma das três camadas de serviço: Burstable, General Purpose e Business Critical. As camadas de serviço fornecem um nível crescente de computação e tamanho de armazenamento, bem como o número máximo suportado de conexões e operações de E/S por segundo (IOPS). Um servidor flexível MySQL pode hospedar vários bancos de dados. Você pode monitorar as métricas de desempenho do seu servidor MySQL, como uso de CPU e memória, desempenho de E/S, métricas de consulta e muito mais, para tomar decisões de capacidade informadas.
Tamanho de computação: RAM e núcleos
Cada uma das três camadas de serviço fornece SKUs de VM subjacentes diferentes. A camada Burstable usa VMs da série B, a camada de uso geral usa VMs da série D e a camada Crítica de negócios usa VMs da série E. A série VM usada determina o número de vCores e RAM disponíveis no servidor.
Você pode alterar a camada de computação, o tamanho da computação e o tamanho do armazenamento depois de criar um servidor. Alterar a camada de computação ou o tamanho da computação requer uma reinicialização que normalmente leva entre um a dois minutos para ser concluída. A alteração do tamanho do armazenamento não requer uma reinicialização.
Para cargas de trabalho que não são de produção (desenvolvimento, preparação, testes, etc.), considere o uso de servidores baseados na camada Burstable, que fornece uma solução econômica para cargas de trabalho que não usam continuamente a CPU completa. Durante períodos de baixo uso, os servidores que usam VMs da série B acumulam créditos de CPU que podem ser usados em períodos de alto uso para "estourar" o desempenho acima da linha de base. Se a linha de base for muito alta ou se houver muitas picas de uso altas, considere atualizar para as camadas de uso geral ou críticas para os negócios para evitar a degradação do desempenho.
Tamanhos de computação da camada de serviço
Cada uma das três camadas de serviço fornece diferentes níveis de poder de computação. Enquanto a camada Burstable pode suportar até 20 vCores e a camada de uso geral pode suportar até 64 vCores, com suporte para até 96vCores, a camada Business Critical fornece o mais alto nível de poder de computação. A camada Business Critical também fornece as VMs da série Ev5, que até 30% mais QPS e latência 50% menor do que as VMs da série Ev4.
IOPS: Pré-provisionado vs Autoscale
O número de operações de leitura e gravação que podem ser executadas por segundo é conhecido como IOPS de armazenamento (operações de E/S por segundo). Configurações de IOPS mais altas proporcionam melhor desempenho de armazenamento: operações de leitura/gravação mais simultâneas resultam em recuperação de dados mais rápida, persistência de dados, atualizações de índice e eficiência geral do banco de dados. Se as configurações de IOPS forem muito baixas, o banco de dados poderá sofrer atrasos de processamento e desempenho degradado. No entanto, se as configurações de IOPS forem muito altas, seus custos poderão aumentar sem que você perceba melhorias de desempenho.
Com o Banco de Dados do Azure para MySQL – Servidor Flexível, você pré-provisiona IOPS ou usa o recurso IOPS de dimensionamento automático.
Com IOPS pré-provisionadas, você aloca um número específico de IOPS para fornecer um desempenho consistente e previsível, que funciona bem se a carga não se aproximar do limite no qual as operações de E/S ficam limitadas. Embora você sempre possa alocar IOPS adicionais à medida que suas demandas de carga de trabalho aumentam, isso requer intervenção manual.
Com o recurso de IOPS de dimensionamento automático habilitado, suas IOPS são dimensionadas sob demanda com base na atividade de carga de trabalho e você paga com base no consumo. À medida que a carga de trabalho aumenta, o servidor dimensiona o desempenho de E/S perfeitamente, permitindo que sua instância lide com picos de carga de trabalho sem pagar pela capacidade não utilizada quando o tráfego é baixo.
Em ambos os casos, o IOPS não pode exceder o máximo do servidor. Para obter informações sobre o IOPS máximo por tamanho de computação, consulte o artigo Documentação de computação e armazenamento.
Réplicas de leitura
À medida que o tráfego do banco de dados aumenta, você pode dimensionar sua capacidade horizontalmente ou "para fora" (número de nós de computação), ou verticalmente ou "para cima" (tamanho dos nós de computação). As réplicas de leitura fornecem dimensionamento horizontal.
Uma réplica de leitura é uma cópia somente leitura de um banco de dados que permanece sincronizado usando a replicação de log binário (binlog) do MySQL. À medida que os aplicativos crescem, eles precisam dimensionar recursos de computação e armazenamento (como o banco de dados). O dimensionamento de componentes de aplicativo é simplificado pelo provisionamento de novas VMs usando o Serviço Kubernetes do Azure (AKS), Conjuntos de Dimensionamento de Máquina Virtual e Serviço de Aplicativo. À medida que esses recursos de computação são dimensionados e os dados armazenados crescem, eles aumentam a carga sobre o banco de dados, o que muitas vezes acaba sendo um gargalo na arquitetura do aplicativo.
O uso de uma réplica de leitura permite desviar operações somente leitura para bancos de dados secundários para que o servidor primário ofereça suporte a operações de leitura/gravação. O Banco de Dados do Azure para MySQL fornece réplicas de leitura gerenciadas. Você pode replicar um servidor de origem para até 10 réplicas. Isso pode ajudar em casos de uso, como relatórios e análises, que geralmente consultam grandes quantidades de dados.
Usar uma réplica de leitura é particularmente útil quando, por um motivo ou outro, as consultas não podem usar índices. Pode ser impraticável ou até mesmo perturbador adicionar índices para todos os padrões de consulta, porque coloca carga adicional no servidor (processamento, E/S de disco, armazenamento, tempo de transação, etc.). Se um data warehouse não estiver disponível ou se você precisar de dados mais recentes do que seu ciclo de atualização, usar uma réplica de leitura é uma ótima maneira de executar consultas "grandes" sem interromper as operações críticas de leitura/gravação.
As réplicas de leitura não são imediatamente síncronas, da mesma forma que uma configuração de alta disponibilidade. As réplicas de leitura não introduzem a latência transacional associada a uma solução de HA, mas pode haver um pequeno atraso à medida que os dados chegam à réplica do banco de dados primário.