Recursos de desempenho do Banco de Dados do Azure para MySQL – Servidor Flexível
Você pode criar servidores flexíveis do Banco de Dados do Azure para MySQL com base em uma das três camadas de serviço: Com capacidade de intermitência, Uso geral e Comercialmente Crítico. As camadas de serviço fornecem um nível crescente de computação e tamanho de armazenamento, bem como o número máximo de conexões e operações de E/S por segundo (IOPS). Um servidor flexível do MySQL pode hospedar vários bancos de dados. Você pode monitorar as métricas de desempenho do servidor flexível do MySQL, como uso de CPU > memória, desempenho de E/S, métricas de consulta e muito mais, para tomar decisões de capacidade informadas.
Tamanho da computação: RAM e núcleos
Cada uma das três camadas de serviço fornece SKUs de VM subjacentes diferentes. A camada Com capacidade de intermitência usa VMs da série B, a camada Uso Geral usa VMs da série D e a camada Comercialmente Crítico usa VMs da série E. A série de 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. Alterar o tamanho do armazenamento não requer uma reinicialização.
Para cargas de trabalho de não produção (desenvolvimento, preparação, teste, etc.), considere usar servidores baseados na camada Burstable, que fornece uma solução econômica para cargas de trabalho que não usam continuamente a CPU inteira. 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 houver muitas intermitências de uso alto, considere a atualização para as camadas Uso geral ou Comercialmente Crítico para evitar degradação de 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. Embora a camada Com capacidade de intermitência possa dar suporte a até 20 vCores e à camada de Uso Geral possa dar suporte a até 64 vCores, com suporte para até 96vCores, a camada Comercialmente Crítico fornece o nível mais alto de poder de computação. A camada Comercialmente Crítico 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 versus Dimensionamento Automático
O número de operações de leitura e gravação que podem ser executadas por segundo é chamado de IOPS de armazenamento (operações de E/S por segundo). Configurações de IOPS mais altas fornecem 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á enfrentar 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 o IOPS ou usa o recurso IOPS de Dimensionamento Automático.
Com IOPS pré-provisionado, você aloca um número específico de IOPS para fornecer um desempenho consistente e previsível, o que funciona bem se a carga não se aproximar do limite em que as operações de E/S se tornam limitadas. Embora você sempre possa alocar IOPS adicional à medida que as demandas de carga de trabalho aumentam, isso requer intervenção manual.
Com o recurso Dimensionamento Automático IOPS habilitado, sua escala de IOPS 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 estiver 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 “out” (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 em sincronia usando a replicação de log binário do MySQL (binlog). À medida que os aplicativos crescem, eles precisam dimensionar recursos de computação e armazenamento (como o banco de dados). O dimensionamento do componente de aplicativo é simplificado pelo provisionamento de novas VMs usando o AKS (Serviço de Kubernetes do Azure), Conjuntos de Dimensionamento de Máquinas Virtuaise Serviço de Aplicativo. À medida que esses recursos de computação aumentam e os dados armazenados aumentam, eles aumentam a carga no banco de dados, o que geralmente 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 dê 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 outras consultas não podem usar índices. Pode ser impraticável ou até mesmo disruptivo adicionar índices para todos os padrões de consulta, pois 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 você precisar de dados mais recentes do que seu ciclo de atualização, usar uma réplica de leitura será uma ótima maneira de executar consultas "grandes" sem interromper operações críticas de leitura/gravação.
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 atingem a réplica do banco de dados primário.