Camadas de serviço do Banco de Dados do Azure para MySQL – Servidor Flexível

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor Flexível

Você pode criar uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL em uma das três camadas de serviço: Burstable, General Purpose e Business Critical. O SKU da VM subjacente diferencia as camadas de serviço usadas da série B, série D e série E. A escolha do nível de computação e do tamanho determina a memória e as vCores disponíveis no servidor. A mesma tecnologia de armazenamento é usada em todas os níveis de serviço. Todos os recursos são provisionados no nível da instância do Servidor Flexível do Banco de Dados do Azure para MySQL. Um servidor pode ter um ou vários bancos de dados.

** Exceto os vCores 64,80 e 96, que têm 504 GiB, 504 GiB e 672 GiB de memória, respectivamente.

* A computação Ev5 tem o melhor desempenho entre outras séries de VM em relação a QPS e latência. Saiba mais sobre o desempenho e a disponibilidade de região da computação Ev5 aqui.

Níveis de serviço do Servidor Flexível

Para escolher uma camada de computação, use a tabela a seguir como ponto de partida.

Depois que você criar um servidor, a camada de computação, o tamanho da computação e o tamanho do armazenamento poderão ser alterados. O dimensionamento de computação requer uma reinicialização e leva de 60 a 120 segundos, enquanto o dimensionamento de armazenamento não. Você também pode ajustar de forma independente o período de retenção de backup para mais ou para menos. Para obter mais informações, veja a seção Escalar recursos.

Camadas de serviço, tamanho e tipos de servidores

Os recursos de computação podem ser selecionados com base na camada e no tamanho. Isso determina os vCores e o tamanho da memória. Os vCores representam a CPU lógica do hardware subjacente.

Com capacidade de intermitência

As especificações detalhadas dos tipos de servidor disponíveis são descritos a seguir para a camada de serviço Com capacidade de intermitência.

Observação: A camada de computação burstable foi projetada para cargas de trabalho não produtivas, como ambientes de desenvolvimento, preparo ou teste e, portanto, não se qualifica para suporte 24/7 ou análise de causa raiz (RCA).

Uso Geral

As especificações detalhadas dos tipos de servidores disponíveis são as seguintes para o nível de serviço Uso Geral

Comercialmente Crítico

As especificações detalhadas dos tipos de servidor disponíveis são as seguintes para o nível de serviço Comercialmente Crítico.

Gerenciamento de memória no Servidor Flexível do Banco de Dados do Azure para MySQL

No MySQL, a memória desempenha um papel importante em várias operações, incluindo o processamento e cache de consultas. O Servidor Flexível do Banco de Dados do Azure para MySQL otimiza a alocação de memória para o processo do servidor MySQL (mysqld), garantindo que ele receba recursos de memória suficientes para processamento eficiente de consultas, cache, gerenciamento de conexões de cliente e manipulação de thread. Saiba mais sobre como o MySQL usa a memória.

Tamanho da memória física (GB)

O Tamanho da Memória Física (GB) na tabela abaixo representa a memória de acesso aleatório (RAM) disponível em gigabytes (GB) no Servidor Flexível do Banco de Dados do Azure para MySQL.

Tamanho total da memória (GB)

O Azure Database for MySQL Flexible Server fornece o Tamanho Total de Memória em GB. Isso representa a memória total disponível para o seu servidor, que é uma combinação de memória física e uma quantidade definida de armazenamento temporário no componente SSD. Essa exibição unificada é projetada para otimizar o gerenciamento de recursos, permitindo que você se concentre apenas na memória total disponível para o processo do MySQL Server do Azure (mysqld). A métrica Percentual de Memória (memory_percent) representa o percentual de memória ocupada pelo processo do MySQL Server do Azure (mysqld). Essa métrica é calculada com base no Tamanho Total da Memória (GB). Por exemplo, quando a métrica Porcentagem de Memória exibe um valor de 60, isso significa que o processo do Servidor MySQL do Azure está utilizando 60% do tamanho total da memória (GB) disponível no Servidor Flexível do Banco de Dados do Azure para MySQL.

MySQL Server (mysqld)

O processo do servidor MySQL do Azure, mysqld, é o principal mecanismo das operações de banco de dados. Ao iniciar, ele inicializa componentes totais como o pool de buffers do InnoDB e o cache de threads, utilizando a memória com base na configuração e nas demandas da carga de trabalho. Por exemplo, o pool de buffers do InnoDB armazena em cache dados e índices acessados com frequência para aprimorar a velocidade de execução das consultas, enquanto o cache de threads gerencia as conexões de cliente. Saiba mais.

Mecanismo de armazenamento do InnoDB

Como o mecanismo de armazenamento padrão do MySQL, o InnoDB utiliza memória para armazenar em cache dados acessados com frequência e gerenciar estruturas internas como o pool de buffers do InnoDB e o buffer de log. O pool de buffers do InnoDB armazena dados de tabelas e índices na memória para minimizar as operações de E/S de disco, aprimorando o desempenho. O parâmetro Tamanho do Pool de Buffers do InnoDB é calculado com base no tamanho da memória física (GB) disponível no servidor. Saiba mais sobre os tamanhos do Pool de Buffers do InnoDB disponíveis no Servidor Flexível do Banco de Dados do Azure para MySQL.

Fios

As conexões de cliente são gerenciadas por threads dedicados processados pelo gerenciador de conexões. Esses threads processam a autenticação, a execução de consultas e a recuperação de resultados para interações com o cliente. Saiba mais.

Para obter mais detalhes sobre a série de computação disponível, veja a documentação de VM do Azure para tamanhos de máquina virtual com capacidade de intermitência da série B, série Dadsv5série Ddsv4 de Uso Geral e série Edsv4/série Edsv5/série Eadsv5 de Comercialmente Crítico.

Limitações de desempenho de instâncias da série com capacidade de intermitência

O nível de computação com capacidade de intermitência foi projetada para fornecer uma solução econômica para cargas de trabalho que não exigem toda a CPU continuamente. Esse nível é ideal para cargas de trabalho de não produção, como ambientes de desenvolvimento, preparo ou teste. O recurso exclusivo da camada de computação com capacidade de intermitência é valer-se da "intermitência", ou seja, utilizar mais do que seu desempenho de CPU de linha de base, usando até 100% da vCPU quando a carga de trabalho exigir. Isso é possível por um modelo de crédito de CPU, que permite que instâncias da série B acumulem “créditos de CPU” durante períodos de baixo uso da CPU. Esses créditos podem ser gastos durante períodos de alto uso da CPU, permitindo que a instância estoure o desempenho base da CPU.

No entanto, é importante observar que, uma vez que uma instância com capacidade de intermitência consuma seus créditos de CPU, ela transmite a operar no desempenho base da CPU. Por exemplo, o desempenho base da CPU de uma Standard_B1ms é de 20%, ou seja, 0,2 Vcore. Suponha que o servidor do nível com capacidade de intermitência esteja executando uma carga de trabalho que exija mais desempenho de CPU do que o nível base e tenha esgotado seus créditos de CPU. Nesse caso, o servidor pode enfrentar limitações de desempenho e, eventualmente, pode afetar várias operações do sistema, como Parar/Iniciar/Reiniciar para o servidor.

Devido a essa limitação, o servidor pode encontrar problemas de conectividade e as operações do sistema podem ser afetadas. Nessas situações, o curso de ação recomendado é pausar a carga de trabalho no servidor para acumular créditos de acordo com o modelo bancário de crédito da série B ou considerar a escala do servidor para camadas mais altas, como Uso Geral ou Comercialmente Crítico.

Portanto, embora a camada de computação com capacidade de intermitência ofereça vantagens significativas de custo e flexibilidade para determinados tipos de cargas de trabalho, não recomendamos para cargas de trabalho de produção que exigem um desempenho consistente da CPU. O nível com capacidade de intermitência não dá suporte à funcionalidade de criar as Réplicas de leitura no Banco de Dados do Azure para MySQL – Servidor Flexível e conceitos de alta disponibilidade no recurso Banco de Dados do Azure para MySQL – Servidor Flexível. Para essas cargas de trabalho e recursos, outras camadas de computação, como o Uso Geral ou Comercialmente Crítico, são mais apropriadas.

Para obter mais informações sobre o modelo de crédito de CPU da série B do Azure, consulte Instâncias com capacidade de intermitência da série B e o Modelo de crédito de CPU da série B.

Monitorar créditos de CPU na camada com capacidade de intermitência

O monitoramento do saldo de créditos da CPU é crucial para manter o desempenho ideal na camada de computação com capacidade de intermitência. O Banco de Dados do Azure para MySQL – Servidor Flexível fornece duas métricas importantes relacionadas a créditos de CPU. O limite ideal para disparar um alerta depende dos requisitos específicos de sua carga de trabalho e desempenho.

Monitorar o Banco de Dados do Azure para MySQL – Servidor Flexível: essa métrica indica o número de créditos de CPU consumidos por sua instância. Monitorar essa métrica pode ajudar a entender os padrões de uso de CPU da sua instância e gerenciar o desempenho com eficiência.

Monitorar o Banco de Dados do Azure para MySQL – Servidor Flexívell: essa métrica mostra o número de créditos de CPU restantes para sua instância. Ficar de olho nessa métrica pode ajudar a evitar que sua instância se degrade no desempenho devido ao esgotamento dos créditos de CPU. Se a métrica de Crédito restante da CPU cair abaixo de um determinado nível (por exemplo, menos de 30% do total de créditos disponíveis), isso poderá indicar que a instância corre o risco de esgotar os créditos de CPU se a carga atual da CPU continuar.

Para obter mais informações, sobre como configurar alertas de métricas, veja este guia.

Armazenamento

O armazenamento provisionado é a capacidade de armazenamento disponível para o Servidor Flexível. O armazenamento é usado para os arquivos de banco de dados, os logs de transações e os logs do servidor MySQL. Para os níveis de serviço Uso Geral e Com capacidade de intermitência, o intervalo de armazenamento abrange de, no mínimo, 20 GiB a um máximo de 16 TiB. Por outro lado, o suporte ao armazenamento estende até 32 TiB para a camada de serviço Comercialmente Crítico. O armazenamento é escalado em incrementos de 1 GiB e pode ser escalado verticalmente após a criação do servidor.

Você pode monitorar seu consumo de armazenamento no portal do Azure (com Azure Monitor) usando o limite de armazenamento, a porcentagem de armazenamento e as métricas de armazenamento usadas. Veja o artigo sobre monitoramento para saber mais sobre as métricas.

Alcançar o limite de armazenamento

Quando o armazenamento consumido no servidor está próximo de atingir o limite provisionado, o servidor é colocado no modo somente leitura para proteger as gravações perdidas no servidor. Os servidores com armazenamento provisionado menor ou igual a 100 GiB serão marcados como somente leitura caso o armazenamento livre seja inferior a 5% do tamanho de armazenamento provisionado. Os servidores com mais de 100 GiB de armazenamento provisionado serão marcados como somente leitura quando o armazenamento livre for inferior a 5 GiB.

Por exemplo, se você tiver provisionado 110 GiB de armazenamento e a utilização real for de 105 GiB, o servidor será marcado como somente leitura. Como alternativa, se você tiver provisionado 5 GiB de armazenamento, o servidor será somente leitura quando o armazenamento livre atingir menos de 256 MB.

Enquanto o serviço tenta tornar o servidor somente leitura, todas as novas solicitações de transação de gravação são bloqueadas e as transações ativas existentes continuam a ser executadas. Quando o servidor é definido como somente leitura, todas as operações de gravação seguintes e confirmações de transação falham, mas as consultas de leitura continuam funcionando ininterruptamente.

Para retirar o servidor do modo somente leitura, você deve aumentar o armazenamento provisionado no servidor. Isso pode ser feito usando o portal do Azure ou a CLI do Azure. Uma vez aumentado, o servidor estará pronto para aceitar transações de gravação novamente.

Recomendamos que você ative o aumento automático do armazenamento ou configure um alerta para notificá-lo quando o armazenamento do servidor estiver se aproximando do limite para que você possa evitar entrar no estado somente leitura. Para mais informações, veja a documentação de alerta Como configurar um alerta.

Crescimento automático do armazenamento

O aumento automático do armazenamento impede que o servidor fique sem armazenamento e se torne somente leitura. Se o aumento automático do armazenamento estiver habilitado, o armazenamento aumentará automaticamente sem afetar a carga de trabalho. O aumento automático do armazenamento é habilitado por padrão em todos os novos servidores. Para servidores com menos de 100 GB de armazenamento provisionado, o tamanho do armazenamento provisionado é aumentado em 5 GB quando o armazenamento livre está abaixo de 10% do armazenamento provisionado. Para servidores com mais de 100 GB de armazenamento provisionado, o tamanho de armazenamento provisionado aumenta em 5% quando o espaço livre de armazenamento está abaixo de 10 GB do tamanho de armazenamento provisionado. Os limites máximos de armazenamento se aplicam conforme especificado anteriormente. Atualize a instância do servidor para ver o armazenamento atualizado provisionado em Configurações na página Computação + Armazenamento.

Por exemplo, se você tiver provisionado 1.000 GB de armazenamento e a utilização real passar de 990 GB, o tamanho do armazenamento será aumentado para 1.050 GB. Como alternativa, se você tiver provisionado 20 GB de armazenamento, o tamanho do armazenamento aumentará para 25 GB quando menos de 2 GB de armazenamento estiver disponível.

Lembre-se de que o armazenamento, uma vez escalado automaticamente, não pode ser verticalmente reduzido.

IOPS

O Servidor Flexível do Banco de Dados do Azure para MySQL dá suporte a IOPS pré-provisionado e IOPS de dimensionamento automático. IOPS de armazenamento no Banco de Dados do Azure para MySQL – Servidor Flexível: a IOPS mínima é 360 em todos os tamanhos de computação e a IOPS máxima é determinada pelo tamanho de computação selecionado. Para saber mais sobre o máximo de IOPS por tamanho de computação veja a tabela.

Você pode monitorar o consumo de E/S no portal do Azure (com o Azure Monitor) usando a métrica Monitorar Banco de Dados do Azure para MySQL – Servidor Flexível. Você precisará escalar a computação do servidor se precisar de mais IOPS do que o máximo de IOPS baseado na computação.

IOPS pré-provisionada

O Servidor Flexível do Banco de Dados do Azure para MySQL oferece IOPS pré-provisionado, permitindo que você aloque um número específico de IOPS para a instância do Servidor Flexível do Banco de Dados do Azure para MySQL. Essa configuração garante um desempenho consistente e previsível para suas cargas de trabalho. Com a IOPS pré-provisionada, você pode definir um limite de IOPS específico para o volume de armazenamento, garantindo a capacidade de lidar com algumas solicitações por segundo. Isso resulta em um nível de desempenho confiável e seguro. A IOPS pré-provisionada permite provisionar uma IOPS adicional acima do limite de IOPS. Usando esse recurso, você pode aumentar ou diminuir o número de IOPS provisionadas de acordo com seus requisitos de carga de trabalho a qualquer momento.

IOPS de escala automática

A base do Servidor Flexível do Banco de Dados do Azure para MySQL é a capacidade de obter o melhor desempenho para cargas de trabalho de nível 1. Isso pode ser aprimorado permitindo que o servidor escale automaticamente o desempenho dos seus servidores de banco de dados (E/S) diretamente dependendo das necessidades de carga de trabalho. Este é um recurso opcional que permite que os usuários escalem a IOPS sob demanda sem precisar pré-provisionar uma certa quantidade de E/S por segundo. Com o IOPS de Dimensionamento Automático habilitado, agora você pode desfrutar do gerenciamento de E/S sem preocupações no Servidor Flexível do Banco de Dados do Azure para MySQL porque o servidor dimensiona os IOPs para cima ou para baixo automaticamente dependendo das necessidades de carga de trabalho. A IOPS de escala automática é escalada automaticamente para a ‘IOPS máxima com suporte’ para cada camada de serviço e tamanho de computação, conforme especificado na documentação das camadas de serviço. Isso garante um desempenho ideal sem a necessidade de esforços manuais de escala

Com a IOPS de escala automática, você paga apenas pela E/S que o servidor usa e não precisa mais provisionar e pagar por recursos que não estão usando totalmente, economizando tempo e dinheiro. Além disso, os aplicativos de Camada 1 críticos podem alcançar um desempenho consistente disponibilizando E/S adicional para a carga de trabalho a qualquer momento. O Autoscale IOPS elimina a administração necessária para fornecer o melhor desempenho pelo menor custo para clientes do Banco de Dados do Azure para MySQL Flexible Server.

Escala dinâmica: a IOPS de escala automática ajusta dinamicamente o limite de IOPS do servidor de banco de dados com base na demanda real da carga de trabalho. Isso garante um desempenho ideal sem intervenção ou configuração manuais.

Como lidar com picos de carga de trabalho: a IOPS de escala automática permite que seu banco de dados lide perfeitamente com picos ou flutuações de carga de trabalho sem comprometer o desempenho dos seus aplicativos. Esse recurso garante uma capacidade de resposta consistente mesmo durante os períodos de pico de uso.

Economia de custos: ao contrário da IOPS pré-provisionada, que especifica um limite fixo de IOPS e é pago independentemente do uso, a IOPS de escala automática permite pagar apenas pelo número das operações de E/S que você consome.

Backup

O serviço faz backup do servidor automaticamente. É possível definir um período de retenção de 1 a 35 dias. Saiba mais sobre backups no artigo Conceitos de backup e restauração.

Escalar recursos

Após criar o servidor, você poderá alterar separadamente a camada de computação, o tamanho da computação (vCores e memória), a quantidade de armazenamento e o período de retenção de backup. O tamanho da computação pode ser ampliado ou reduzido, e o período de retenção de backup pode ser escalado verticalmente ou reduzido de 1 a 35 dias. O tamanho de armazenamento só pode ser aumentado. A escala dos recursos pode ser feita por meio do portal ou da CLI do Azure.

Quando você altera a camada de computação ou o tamanho da computação, o servidor é reiniciado para que o novo tipo de servidor entre em vigor. Durante um momento enquanto o sistema muda para o novo servidor, nenhuma nova conexão pode ser estabelecida e todas as transações não confirmadas são revertidas. Essa janela varia, mas, na maioria dos casos, está entre 60 e 120 segundos.

A colocação em escala do armazenamento e a alteração do período de retenção do backup são operações online e não exigem a reinicialização do servidor.

Preço

Para conferir as informações mais recentes sobre preços, veja a página de preços do serviço. Para ver os custos da configuração desejada, o portal do Azure mostra o custo mensal na guia Computação + armazenamento com base nas opções que você seleciona. Se você não tiver uma assinatura do Azure, poderá usar a calculadora de preços do Azure para obter um preço estimado. No site da Calculadora de preços do Azure, selecione Adicionar itens, expanda a categoria Bancos de dados, escolha Banco de Dados do Azure para MySQL e Servidor Flexível como o tipo de implantação para personalizar as opções.

Se quiser otimizar o custo do servidor, considere as seguintes dicas:

• Reduza verticalmente a camada de computação ou o tamanho da computação (vCores) se a computação estiver subutilizada.
• Considere alternar para a camada de computação Com Capacidade de Intermitência se a carga de trabalho não precisar da capacidade total de computação continuamente das camadas Uso Geral e Comercialmente Crítico.
• Pare o servidor quando ele não estiver em uso.
• Reduza o período de retenção do backup se uma retenção mais longa de backup não for necessária.

Conteúdo relacionado

• Criar uma instância do Servidor Flexível do Azure para Banco de Dados MySQL no portal
• Limitações do serviço