Share via


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

Crie 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. As camadas de serviço são diferenciadas pelo SKU da VM subjacente usada nas séries B, D e E. A escolha da camada de computação e do tamanho determina a memória e os vCores disponíveis no servidor. A mesma tecnologia de armazenamento é usada em todas as camadas 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.

Recurso/camada Com capacidade de intermitência Uso Geral Comercialmente Crítico
Série da VM Série B Dadsv5-seriesDdsv4-series Edsv4/Edsv5-series*/Eadsv5-series
vCores 1, 2, 4, 8, 12, 16, 20 2, 4, 8, 16, 32, 48, 64 2, 4, 8, 16, 32, 48, 64, 80, 96
Memória por vCore Variável 4 GiB 8 GiB **
Tamanho de armazenamento 20 GiB a 16 TiB 20 GiB a 16 TiB 20 GiB a 16 TiB
Período de retenção do backup de banco de dados 1 a 35 dias 1 a 35 dias 1 a 35 dias

** Com exceção de 64, 80 e 96 vCores, que têm 504 GiB, 504 GiB e 672 GiB de memória, respectivamente.

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

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

Camada de computação Cargas de trabalho de destino
Com capacidade de intermitência Ideal para cargas de trabalho que não precisam de toda a CPU continuamente.
Uso Geral A maioria das cargas de trabalho que exigem a computação e a memória balanceadas com a taxa de transferência de E/S escalonável. Os exemplos incluem servidores para hospedar aplicativos Web e móveis e outros aplicativos empresariais.
Comercialmente Crítico Cargas de trabalho de banco de dados de alto desempenho que exigem desempenho na memória para o processamento de transações mais rápido e com simultaneidade mais alta. Os exemplos incluem servidores para o processamento de dados em tempo real e aplicativos analíticos ou transacionais de alto desempenho.

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 da computação exige uma reinicialização e leva entre 60 a 120 segundos, enquanto a colocação em escala do armazenamento não exige a reinicialização. Você também pode ajustar de forma independente o período de retenção de backup para cima ou para baixo. 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.

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

Tamanho da computação vCores Tamanho de memória física (GiB) Tamanho total da memória (GiB) Máximo de IOPS com suporte Máximo de conexões Armazenamento Temporário (SSD) GiB
Standard_B1s 1 1 1,1 320 171 0
Standard_B1ms 1 2 2,2 640 341 0
Standard_B2s 2 4 4.4 1280 683 0
Standard_B2ms 2 8 8.8 1.700 1365 0
Standard_B4ms 4 16 17.6 2400 2731 0
Standard_B8ms 8 32 35.2 3100 5461 0
Standard_B12ms 12 48 52,8 3800 8193 0
Standard_B16ms 16 64 70.4 4300 10923 0
Standard_B20ms 20 80 88 5.000 13653 0

As especificações detalhadas dos tipos de servidor disponíveis são as seguintes para Uso Geral:

Tamanho da computação vCores Tamanho de memória física (GiB) Tamanho total da memória (GiB) Máximo de IOPS com suporte Máximo de conexões Armazenamento Temporário (SSD) GiB
Standard_D2ads_v5 2 8 11 3200 1365 53
Standard_D2ds_v4 2 8 11 3200 1365 53
Standard_D4ads_v5 4 16 22 6400 2731 107
Standard_D4ds_v4 4 16 22 6400 2731 107
Standard_D8ads_v5 8 32 44 12800 5461 215
Standard_D8ds_v4 8 32 44 12800 5461 215
Standard_D16ads_v5 16 64 88 20000 10923 430
Standard_D16ds_v4 16 64 88 20000 10923 430
Standard_D32ads_v5 32 128 176 20000 21845 860
Standard_D32ds_v4 32 128 176 20000 21845 860
Standard_D48ads_v5 48 192 264 20000 32768 1290
Standard_D48ds_v4 48 192 264 20000 32768 1290
Standard_D64ads_v5 64 256 352 20000 43691 1720
Standard_D64ds_v4 64 256 352 20000 43691 1720

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

Tamanho da computação vCores Tamanho de memória física (GiB) Tamanho total da memória (GiB) Máximo de IOPS com suporte Máximo de conexões Armazenamento Temporário (SSD) GiB
Standard_E2ds_v4 2 16 22 5.000 2731 37
Standard_E2ads_v5 2 16 22 5.000 2731 37
Standard_E4ds_v4 4 32 44 10000 5461 75
Standard_E4ads_v5 4 32 44 10000 5461 75
Standard_E8ds_v4 8 64 88 18000 10923 151
Standard_E8ads_v5 8 64 88 18000 10923 151
Standard_E16ds_v4 16 128 176 28000 21845 302
Standard_E16ads_v5 16 128 176 28000 21845 302
Standard_E20ds_v4 20 160 220 28000 27306 377
Standard_E20ads_v5 20 160 220 28000 27306 377
Standard_E32ds_v4 32 256 352 38.000 43691 604
Standard_E32ads_v5 32 256 352 38.000 43691 604
Standard_E48ds_v4 48 384 528 48000 65536 906
Standard_E48ads_v5 48 384 528 48000 65536 906
Standard_E64ds_v4 64 504 693 64000 86016 1224
Standard_E64ads_v5 64 504 693 64000 86016 1224
Standard_E80ids_v4 80 504 693 72000 86016 1224
Standard_E2ds_v5 2 16 22 5.000 2731 37
Standard_E4ds_v5 4 32 44 10000 5461 75
Standard_E8ds_v5 8 64 88 18000 10923 151
Standard_E16ds_v5 16 128 176 28000 21845 302
Standard_E20ds_v5 20 160 220 28000 27306 377
Standard_E32ds_v5 32 256 352 38.000 43691 604
Standard_E48ds_v5 48 384 528 48000 65536 906
Standard_E64ds_v5 64 512 704 64000 87383 1208
Standard_E96ds_v5 96 672 924 80000 100000 2004

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 MySQL Server do Azure, mysqld, serve como o mecanismo principal para 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 Capacidade de intermitência (série B), Uso Geral Dadsv5-seriesDdsv4-series e Comercialmente crítico Edsv4/Edsv5-series/Eadsv5-series.

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

Observação

Na camada de computação com capacidade de intermitência (série B) se a VM for iniciada/interrompida ou reiniciada, os créditos poderão ser perdidos. Para obter mais informações, consulte Perguntas frequentes sobre capacidade de intermitência (Série B).

A camada 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. Essa camada é 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. Se o servidor da camada com capacidade de intermitência estiver executando uma carga de trabalho que exija mais desempenho de CPU do que o nível base e tiver esgotado seus créditos de CPU, o servidor poderá enfrentar limitações de desempenho e, eventualmente, poderá afetar várias operações do sistema, como Parar/Iniciar/Reiniciar do servidor.

Observação

Para servidores na camada de computação da série B (com capacidade de intermitência), como Standard_B1s/Standard_B1ms/Standard_B2s, o tamanho de memória de host relativamente menor delas pode levar a falhas (sem memória) sob cargas de trabalho contínuas, mesmo que a métrica memory_percent não tenha atingido 100%.

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. A camada com capacidade de intermitência não dá suporte à funcionalidade de criação de recursos de Réplicas de leitura e Alta disponibilidade. 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.

Crédito de CPU Consumido: 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.

Crédito de CPU Restante: 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 provisionado é a quantidade de capacidade de armazenamento disponível para o Banco de Dados do Azure 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. Em todas as camadas de serviço, o armazenamento mínimo compatível é de 20 GiB e o máximo é de 16 TiB. O armazenamento é dimensionado em incrementos de 1 GiB e pode ser escalado verticalmente após a criação do servidor.

Observação

O armazenamento só pode ser escalado verticalmente, não horizontalmente.

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çando 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 subsequente e a transação comentem falha. As consultas de leitura continuam a funcionar sem interrupções.

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 de 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.

Observação

O aumento automático de armazenamento é habilitado por padrão para um servidor configurado para alta disponibilidade, e não pode ser desabilitado.

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. Saiba mais. As IOPS mínimas são 360 em todos os tamanhos de computação e as IOPS máximas são determinadas pelo tamanho de computação selecionado. Para saber mais sobre o máximo de IOPS por tamanho de computação veja a tabela.

Importante

**O mínimo de IOPS é 360 em todos os tamanhos de computação
**O máximo de IOPS é determinado pelo tamanho computacional selecionado.

Você pode monitorar o consumo de E/S no portal do Azure (com Azure Monitor) usando a métrica de porcentagem de E/S. Se precisar de mais IOPS do que o IOPS máximo com base na computação, você precisará escalar a computação do servidor.

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 é sua capacidade de obter o melhor desempenho para cargas de trabalho de camada 1, que pode ser aprimorada ao permitir que o servidor escale automaticamente o desempenho (E/S) dos seus servidores de banco de dados sem complicações, de acordo com as 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 recurso de IOPS de dimensionamento automático habilitado, você pode desfrutar do gerenciamento de E/S no servidor flexível do Banco de Dados do Azure para MySQL sem preocupações, porque o servidor aumenta ou reduz verticalmente o IOPS de modo automático, dependendo das necessidades da carga de trabalho.

Com o IOPS de dimensionamento automático, 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.

Escala dinâmica: o 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: 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 em que um limite de IOPS fixo é especificado e pago independentemente do uso, o IOPS de Escala automática permite que você pague apenas pelo número de operações de E/S que você consome.

Backup

O serviço faz backups do servidor automaticamente. É possível definir um período de retenção no intervalo de um 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 aumentado ou reduzido. O período de retenção de backup pode ser aumentado ou reduzido de um 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.

Observação

O tamanho de armazenamento só pode ser aumentado. Você não poderá voltar para um tamanho de armazenamento menor após o aumento.

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ços

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.