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 de servidor flexível do Banco de Dados do Azure para MySQL em uma das três camadas de serviço diferentes: Com capacidade de intermitência, Uso Geral e Comercialmente Crítico. 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 de servidor flexível do Banco de Dados do Azure para MySQL. Um servidor pode ter um ou vários bancos de dados.

** Exceto 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 de criar um servidor, a camada de computação, o tamanho da computação e o tamanho do armazenamento pode ser alterado. 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, consulte a seção Recursos de dimensionamento.

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. vCores representam o CPU lógico do hardware subjacente.

Com capacidade de intermitência

As especificações detalhadas dos tipos de servidor disponíveis são as seguintes para Capacidade de intermitência:

Uso Geral

As especificações detalhadas dos tipos de servidores disponíveis são as seguintes para o nível de serviço de 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 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 servidor flexível do Banco de Dados do Azure para MySQL fornece um tamanho total de memória (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 Memory Percent (memory_percent) representa a porcentagem 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 Memory Percent exibe um valor de 60, significa que o processo do MySQL Server 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 de operações de banco de dados. Ao iniciar, ele inicializa componentes totais como o pool de buffers InnoDB e o cache de threads, utilizando memória com base na configuração e nas demandas da carga de trabalho. Por exemplo, o pool de buffers InnoDB armazena em cache dados e índices acessados com frequência para melhorar 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 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 entrada/saída de disco, melhorando o desempenho. O parâmetro InnoDB Buffer Pool Size é 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.

Threads

As conexões de cliente são gerenciadas por threads dedicados manipulados pelo gerenciador de conexões. Esses threads lidam com autenticação, execução de consultas e 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, consulte a documentação de VM do Azure para tamanhos de máquina virtual de capacidade de intermitência (série B), Dadsv5-seriesDdsv4-series de Uso Geral e Edsv4/Edsv5-series/Eadsv5-series 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 extrapole seu 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 passa 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 o dimensionamento do servidor para camadas mais altas, como Uso Geral ou Comercialmente Crítica.

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 é recomendável 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 Servidor flexível do Banco de Dados do Azure para MySQL 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, consulte este guia.

Armazenamento

O armazenamento que você provisiona é a capacidade de armazenamento disponível para seu 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 níveis de serviço de 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 é dimensionado 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. Consulte o artigo de 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ê provisionou 110 GiB de armazenamento e a utilização real for de 105 GiB, o servidor é marcado como somente leitura. Como alternativa, se você tiver provisionado 5 GiB de armazenamento, o servidor é 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 subsequentes 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ê configure um alerta para notificar quando o armazenamento do servidor estiver se aproximando do limite, para evitar entrar no estado somente leitura. Para mais informações, consulte a documentação de alerta em como configurar um alerta.

Aumento 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ê provisionou 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 dimensionado 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 O IOPS mínimo é 360 em todos os tamanhos de computação e o IOPS máximo é determinado 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á dimensionar a computação do seu servidor se precisar de mais IOPS do que o máximo de IOPS baseado na computação.

IOPS pré-provisionado

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 de 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 o IOPS pré-provisionado, 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. O IOPS pré-provisionado permite provisionar IOPS adicional acima do limite de IOPS. Usando esse recurso, você pode aumentar ou diminuir o número de IOPS provisionados com base em seus requisitos de carga de trabalho a qualquer momento.

IOPS de dimensionamento automático

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 dimensione automaticamente o desempenho de 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 dimensionem o IOPS sob demanda sem precisar pré-provisionar uma certa quantidade de I/O por segundo. Com o IOPS de escala automática ativado, agora você pode aproveitar o gerenciamento de IO sem preocupações no servidor flexível do Banco de Dados do Azure para MySQL, pois o servidor aumenta ou diminui os IOPs automaticamente, dependendo das necessidades da carga de trabalho. O IOPS de Dimensionamento Automático é escalado automaticamente para o ‘IOPS máximo 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 o Autoscale IOPS, 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 Nível 1 crítico podem alcançar um desempenho consistente disponibilizando E/S adicional para a carga de trabalho a qualquer momento. O IOPS de dimensionamento automático elimina a administração necessária para fornecer o melhor desempenho com o menor custo para clientes do servidor flexível do Banco de Dados do Azure para MySQL.

Dimensionamento dinâmico: o IOPS de dimensionamento automático 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: o IOPS de dimensionamento automático permite que seu banco de dados lide perfeitamente com picos ou flutuações de carga de trabalho sem comprometer o desempenho de 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 do IOPS pré-provisionado, que especifica um limite fixo de IOPS e é pago independentemente do uso, o Autoscale IOPS permite pagar apenas pelo número de 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. O dimensionamento dos recursos pode ser feito 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 as informações mais recentes sobre preços, consulte 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 tipo de implantação para personalizar as opções.

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

• Dimensione 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 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

• Crie uma instância de servidor flexível do Banco de Dados do Azure para MySQL no portal
• Limitações do serviço