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 aqui sobre o desempenho e a disponibilidade de região da computação Ev5.
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:
| Tamanho da computação | vCores | Tamanho da memória (GiB) | Máximo de IOPS com suporte | Máximo de conexões | Armazenamento Temporário (SSD) GiB |
|---|---|---|---|---|---|
| Com capacidade de intermitência | |||||
| Standard_B1s | 1 | 1 | 320 | 171 | 4 |
| Standard_B1ms | 1 | 2 | 640 | 341 | 4 |
| Standard_B2s | 2 | 4 | 1280 | 683 | 4 |
| Standard_B2ms | 2 | 8 | 1.700 | 1365 | 16 |
| Standard_B4ms | 4 | 16 | 2400 | 2731 | 32 |
| Standard_B8ms | 8 | 32 | 3100 | 5461 | 64 |
| Standard_B12ms | 12 | 48 | 3800 | 8193 | 96 |
| Standard_B16ms | 16 | 64 | 4300 | 10923 | 128 |
| Standard_B20ms | 20 | 80 | 5.000 | 13653 | 160 |
| Uso Geral | |||||
| Standard_D2ads_v5 | 2 | 8 | 3200 | 1365 | 75 |
| Standard_D2ds_v4 | 2 | 8 | 3200 | 1365 | 75 |
| Standard_D4ads_v5 | 4 | 16 | 6400 | 2731 | 150 |
| Standard_D4ds_v4 | 4 | 16 | 6400 | 2731 | 150 |
| Standard_D8ads_v5 | 8 | 32 | 12800 | 5461 | 300 |
| Standard_D8ds_v4 | 8 | 32 | 12800 | 5461 | 300 |
| Standard_D16ads_v5 | 16 | 64 | 20000 | 10923 | 600 |
| Standard_D16ds_v4 | 16 | 64 | 20000 | 10923 | 600 |
| Standard_D32ads_v5 | 32 | 128 | 20000 | 21845 | 1200 |
| Standard_D32ds_v4 | 32 | 128 | 20000 | 21845 | 1200 |
| Standard_D48ads_v5 | 48 | 192 | 20000 | 32768 | 1800 |
| Standard_D48ds_v4 | 48 | 192 | 20000 | 32768 | 1800 |
| Standard_D64ads_v5 | 64 | 256 | 20000 | 43691 | 2400 |
| Standard_D64ds_v4 | 64 | 256 | 20000 | 43691 | 2400 |
| Comercialmente Crítico | |||||
| Standard_E2ds_v4 | 2 | 16 | 5.000 | 2731 | 75 |
| Standard_E2ads_v5 | 2 | 16 | 5.000 | 2731 | 75 |
| Standard_E4ds_v4 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E4ads_v5 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E8ds_v4 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E8ads_v5 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E16ds_v4 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E16ads_v5 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E20ds_v4 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E20ads_v5 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E32ds_v4 | 32 | 256 | 38.000 | 43691 | 1200 |
| Standard_E32ads_v5 | 32 | 256 | 38.000 | 43691 | 1200 |
| Standard_E48ds_v4 | 48 | 384 | 48000 | 65536 | 1800 |
| Standard_E48ads_v5 | 48 | 384 | 48000 | 65536 | 1800 |
| Standard_E64ds_v4 | 64 | 504 | 64000 | 86016 | 2400 |
| Standard_E64ads_v5 | 64 | 504 | 64000 | 86016 | 2400 |
| Standard_E80ids_v4 | 80 | 504 | 72000 | 86016 | 2400 |
| Standard_E2ds_v5 | 2 | 16 | 5.000 | 2731 | 75 |
| Standard_E4ds_v5 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E8ds_v5 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E16ds_v5 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E20ds_v5 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E32ds_v5 | 32 | 256 | 38.000 | 43691 | 1200 |
| Standard_E48ds_v5 | 48 | 384 | 48000 | 65536 | 1800 |
| Standard_E64ds_v5 | 64 | 512 | 64000 | 87383 | 2400 |
| Standard_E96ds_v5 | 96 | 672 | 80000 | 100000 | 3600 |
Para obter mais detalhes sobre a série de computação disponível, consulte a documentação do Azure VM para Capacidade de intermitência (série B), Uso Geral Dadsv5-seriesDdsv4-series e Comercialmente crítico Edsv4/Edsv5-series/Eadsv5-series
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).
Limitações de desempenho de instâncias da série com capacidade de intermitência
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 continuarão a ser executadas. Quando o servidor é definido como somente leitura, todas as operações de gravação subsequente e a transação comentem falha. 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 escalado automaticamente, não pode ser 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 um determinado número de 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.