Escalões de serviço da Base 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: Burstable, General Purpose e Business Critical. As camadas de serviço são diferenciadas pela SKU de 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 todos os níveis de serviço. Todos os recursos são provisionados no Banco de Dados do Azure para o nível de instância de servidor flexível do MySQL. Um servidor pode ter um ou vários bancos de dados.
| Recurso / Camada | Burstable | Fins Gerais | Negócios Críticos |
|---|---|---|---|
| Série das VMs | Série B | Dadsv5-série Ddsv4-series | Edsv4 série Edsv5*/série Eadsv5/ |
| 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 do 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 tem 504 GiB, 504 GiB e 672 GiB de memória, respectivamente.
* A computação Ev5 oferece o melhor desempenho entre outras séries de VM em termos de QPS e latência. saiba mais sobre o desempenho e a disponibilidade da região da computação Ev5 aqui.
Para escolher uma camada de computação, use a tabela a seguir como ponto de partida.
| Escalão de computação | Cargas de trabalho de destino |
|---|---|
| Expansível | Ideal para cargas de trabalho que não precisam da CPU completa continuamente. |
| Fins Gerais | A maioria das cargas de trabalho de negócios que exigem computação e memória equilibradas com taxa de transferência de E/S escalável. Os exemplos incluem servidores de alojamento de aplicações para dispositivos móveis e Web, entre outras aplicações empresariais. |
| Crítico para a Empresa | Cargas de trabalho de banco de dados de alto desempenho que exigem desempenho na memória para processamento de transações mais rápido e maior simultaneidade. Os exemplos incluem servidores para processamento de dados em tempo real e aplicações com elevado desempenho transacional ou analítico. |
Depois de criar um servidor, a camada de computação, o tamanho da computação e o tamanho do armazenamento podem ser alterados. O dimensionamento de computação requer uma reinicialização e leva entre 60 e 120 segundos, enquanto o dimensionamento de armazenamento não requer reinicialização. Você também pode ajustar independentemente o período de retenção de backup para cima ou para baixo. Para obter mais informações, consulte a seção Recursos de escala .
Camadas de serviço, tamanho e tipos de servidor
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 a CPU lógica do hardware subjacente.
As especificações detalhadas dos tipos de servidor disponíveis são as seguintes:
| Tamanho de computação | vCores | Tamanho da memória (GiB) | IOPS Máximo Suportado | Máx. Ligações | Armazenamento temporário (SSD) GiB |
|---|---|---|---|---|---|
| Burstable | |||||
| 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 | 1700 | 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 | 5000 | 13653 | 160 |
| Fins Gerais | |||||
| 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 | 20 000 | 10923 | 600 |
| Standard_D16ds_v4 | 16 | 64 | 20 000 | 10923 | 600 |
| Standard_D32ads_v5 | 32 | 128 | 20 000 | 21845 | 1200 |
| Standard_D32ds_v4 | 32 | 128 | 20 000 | 21845 | 1200 |
| Standard_D48ads_v5 | 48 | 192 | 20 000 | 32768 | 1800 |
| Standard_D48ds_v4 | 48 | 192 | 20 000 | 32768 | 1800 |
| Standard_D64ads_v5 | 64 | 256 | 20 000 | 43691 | 2400 |
| Standard_D64ds_v4 | 64 | 256 | 20 000 | 43691 | 2400 |
| Negócios Críticos | |||||
| Standard_E2ds_v4 | 2 | 16 | 5000 | 2731 | 75 |
| Standard_E2ads_v5 | 2 | 16 | 5000 | 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 | 38000 | 43691 | 1200 |
| Standard_E32ads_v5 | 32 | 256 | 38000 | 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 | 5000 | 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 | 38000 | 43691 | 1200 |
| Standard_E48ds_v5 | 48 | 384 | 48000 | 65536 | 1800 |
| Standard_E64ds_v5 | 64 | 512 | 64000 | 87383 | 2400 |
| Standard_E96ds_v5 | 96 | 672 | 80 000 | 100000 | 3600 |
Para obter mais detalhes sobre a série de computação disponível, consulte a documentação da VM do Azure para Burstable (série B), Dadsv5-seriesDdsv4-series e Business Critical Edsv4/Edsv5-series/Eadsv5-series
Nota
Para a camada de computação Burstable (série B), se a VM for iniciada/interrompida ou reiniciada, os créditos podem ser perdidos. Para obter mais informações, consulte Perguntas frequentes sobre Burstable (série B).
Limitações de desempenho de instâncias de série burstable
A camada de computação Burstable foi projetada para fornecer uma solução econômica para cargas de trabalho que não exigem CPU completa contínua continuamente. Essa camada é ideal para cargas de trabalho que não são de produção, como ambientes de desenvolvimento, preparação ou teste. A característica única da camada de computação burstable é sua capacidade de "burst", 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 graças a 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 fique acima do desempenho da CPU base.
No entanto, é importante notar que, uma vez que uma instância burstable esgota seus créditos de CPU, ela opera em seu desempenho de CPU base. Por exemplo, o desempenho da CPU base de um Standard_B1ms é de 20%, ou seja, 0,2 Vcore. Se o servidor de camada Burstable estiver executando uma carga de trabalho que exija mais desempenho da CPU do que o nível básico 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 para o seu servidor.
Nota
Para servidores na camada de computação Burstable (série B), como Standard_B1s/Standard_B1ms/Standard_B2s, seu tamanho de memória de host relativamente menor pode levar a falhas (falta de memória) sob carga de trabalho contínua, 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 níveis mais altos, como níveis de uso geral ou de negócios críticos .
Portanto, embora a camada de computação Burstable ofereça vantagens significativas de custo e flexibilidade para certos tipos de cargas de trabalho, ela não é recomendada para cargas de trabalho de produção que exigem desempenho consistente da CPU. A camada Burstable não suporta a funcionalidade de criação de réplicas de leitura e recurso de alta disponibilidade . Para essas cargas de trabalho e recursos, outras camadas de computação, como o Propósito Geral ou o Crítico de Negócios são mais apropriados.
Para obter mais informações sobre o modelo de crédito de CPU da série B do Azure, consulte as instâncias burstable da série B e o modelo de crédito da CPU da série B.
Monitorando créditos de CPU em nível burstable
Monitorar o saldo de crédito da CPU é crucial para manter o desempenho ideal na camada de computação Burstable. O Banco de Dados do Azure para Servidor Flexível MySQL fornece duas métricas principais relacionadas a créditos de CPU. O limite ideal para disparar um alerta depende da sua carga de trabalho específica e dos requisitos de desempenho.
Crédito de CPU consumido: essa métrica indica o número de créditos de CPU consumidos pela sua instância. O monitoramento dessa métrica pode ajudá-lo a entender os padrões de uso da CPU da instância e gerenciar seu desempenho de forma eficaz.
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 ajudá-lo a evitar que sua instância se degrade em desempenho devido ao esgotamento de seus créditos de CPU. Se a métrica CPU Credit Remaining cair abaixo de um determinado nível (por exemplo, menos de 30% do total de créditos disponíveis), isso indicaria que a instância corre o risco de esgotar seus créditos de CPU se a carga atual da CPU continuar.
Para obter mais informações sobre como configurar alertas em métricas, consulte este guia.
Armazenamento
O armazenamento que aprovisiona é a quantidade de capacidade de armazenamento disponível para o seu servidor flexível. O armazenamento é usado para os arquivos de banco de dados, arquivos temporários, logs de transações e os logs do servidor MySQL. Em todos os escalões de serviço, o armazenamento mínimo suportado é de 20 GiB e o máximo é de 16 TiB. O armazenamento é dimensionado em incrementos de 1 GiB e pode ser ampliado após a criação do servidor.
Nota
O armazenamento só pode ser aumentado verticalmente e não reduzido.
Você pode monitorar seu consumo de armazenamento no portal do Azure (com o 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 métricas.
Atingir o limite de armazenamento
Quando o armazenamento consumido no servidor estiver quase a atingir o limite aprovisionado, o servidor é posto no modo só de leitura para proteger eventuais escritas perdidas no mesmo. Servidores com menos de 100 GiB de armazenamento provisionado são marcados como somente leitura se o armazenamento livre for inferior a 5% do tamanho do armazenamento provisionado. Servidores com mais de 100 GiB de armazenamento provisionado são marcados somente leitura quando o armazenamento gratuito é inferior a 5 GiB.
Por exemplo, se você provisionou 110 GiB de armazenamento e a utilização real ultrapassa 105 GiB, o servidor será marcado como somente leitura. Como alternativa, se você tiver provisionado 5 GiB de armazenamento, o servidor será marcado como somente leitura quando o armazenamento livre atingir menos de 256 MB.
Apesar de o serviço tentar tornar o servidor só de leitura, todos os novos pedidos de transação de escrita são bloqueados e as transações ativas existentes continuam a executar. Quando o servidor estiver definido como só de leitura, todas as subsequentes operações de escrita e de transação falham. As consultas de leitura continuam a trabalhar sem interrupções.
Para que o servidor saia do modo só de leitura, tem de aumentar o armazenamento aprovisionado no servidor. Pode fazê-lo no portal do Azure ou na CLI do Azure. Uma vez aumentado, o servidor está pronto para aceitar transações de gravação novamente.
Recomendamos que você 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 obter mais informações, consulte a documentação sobre como configurar um alerta.
Crescimento automático do armazenamento
O crescimento automático do armazenamento impede que o servidor fique sem armazenamento e se torne somente leitura. Se o crescimento automático do armazenamento estiver habilitado, o armazenamento crescerá automaticamente sem afetar a carga de trabalho. O crescimento automático de armazenamento é habilitado por padrão para todas as novas criações de servidor. Para servidores com menos de 100 GB de armazenamento provisionado, o tamanho do armazenamento provisionado é aumentado em 5 GB quando o armazenamento gratuito está abaixo de 10% do armazenamento provisionado. Para os servidores com um armazenamento aprovisionado superior a 100 GB, o tamanho do armazenamento aprovisionado é aumentado em 5% quando o espaço livre de armazenamento estiver abaixo de 10 GB do tamanho de armazenamento aprovisionado. Aplicam-se limites máximos de armazenamento, conforme especificado acima. Atualize a instância do servidor para ver o armazenamento aprovisionado atualizado em Definições na página Computação + Armazenamento .
Por exemplo, se você provisionou 1000 GB de armazenamento e a utilização real ultrapassa 990 GB, o tamanho do armazenamento do servidor é aumentado para 1050 GB. Como alternativa, se você tiver provisionado 20 GB de armazenamento, o tamanho do armazenamento será aumentado para 25 GB quando menos de 2 GB de armazenamento estiver livre.
Lembre-se de que o armazenamento, uma vez dimensionado automaticamente, não pode ser reduzido.
Nota
O crescimento automático de armazenamento está habilitado por padrão para um servidor configurado de Alta Disponibilidade e não pode ser desabilitado.
IOPS
O Banco de Dados do Azure para servidor flexível MySQL dá suporte a IOPS pré-provisionadas e IOPS de dimensionamento automático. Mais informações. 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 IOPS máximo por tamanho de computação, consulte a tabela.
Importante
**O IOPS mínimo é de 360 em todos os tamanhos de computação
**As IOPS máximas são determinadas pelo tamanho de computação selecionado.
Você pode monitorar seu consumo de E/S no portal do Azure (com o Azure Monitor) usando a métrica de porcentagem de E/S. Se você precisar de mais IOPS do que o máximo de IOPS com base na computação, precisará dimensionar a computação do seu servidor.
IOPS pré-provisionadas
O servidor flexível do Banco de Dados do Azure para MySQL oferece IOPS pré-provisionadas, permitindo que você aloque um número específico de IOPS para sua 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 IOPS pré-provisionadas, você pode definir um limite de IOPS específico para seu volume de armazenamento, garantindo a capacidade de lidar com um determinado número de solicitações por segundo. Isso resulta em um nível confiável e garantido de desempenho. IOPS pré-provisionadas permite provisionar IOPS adicionais acima do limite de IOPS . Com esta funcionalidade, também pode aumentar ou diminuir o número de IOPS aprovisionados com base nos seus requisitos de carga de trabalho a qualquer momento.
IOPS de dimensionamento automático
A pedra angular do Banco de Dados do Azure para servidor flexível MySQL é sua capacidade de alcançar o melhor desempenho para cargas de trabalho de camada 1, que pode ser melhorada permitindo que o servidor dimensione automaticamente o desempenho (IO) de seus servidores de banco de dados sem problemas, dependendo das necessidades de carga de trabalho. Este é um recurso de aceitação que permite aos usuários dimensionar IOPS sob demanda sem ter que pré-provisionar uma certa quantidade de E/S por segundo. Com as IOPS de dimensionamento automático habilitadas, agora você pode aproveitar o gerenciamento de E/S sem preocupações no Banco de Dados do Azure para servidor flexível MySQL, porque o servidor dimensiona IOPs automaticamente para cima ou para baixo, dependendo das necessidades de carga de trabalho.
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 eles não estão usando totalmente, economizando tempo e dinheiro. Além disso, os aplicativos de nível 1 de missão crítica podem alcançar um desempenho consistente disponibilizando E/S adicionais 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 ao menor custo para o Banco de Dados do Azure para clientes de servidor flexível MySQL.
Dimensionamento dinâmico: o dimensionamento automático de IOPS 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 manual.
Lidando com picos de carga de trabalho: IOPS de dimensionamento automático permitem que seu banco de dados lide perfeitamente com picos ou flutuações de carga de trabalho sem comprometer o desempenho de seus aplicativos. Este recurso garante uma resposta consistente, mesmo durante os períodos de pico de uso.
Economia de custos: Ao contrário das IOPS pré-provisionadas, em que um limite de IOPS fixo é especificado e pago independentemente do uso, as IOPS de dimensionamento automático permitem que você pague apenas pelo número de operações de E/S que você consome.
Backup
O serviço faz backups automaticamente do seu servidor. Você pode selecionar um período de retenção de um intervalo de 1 a 35 dias. Saiba mais sobre backups no artigo Conceitos de backup e restauração.
Dimensionar recursos
Depois de criar o servidor, você pode alterar independentemente 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 dimensionado para cima ou para baixo. O período de retenção de backup pode ser ampliado de 1 para 35 dias. O tamanho do armazenamento só pode ser aumentado. O dimensionamento dos recursos pode ser feito por meio do portal ou da CLI do Azure.
Nota
O tamanho do armazenamento só pode ser aumentado. Não é possível voltar a 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 o período em que o sistema muda para o novo servidor, não se pode estabelecer nenhuma nova ligação e todas as transações não confirmadas são revertidas. Esta janela varia, mas na maioria dos casos, é entre 60-120 segundos.
Dimensionar o armazenamento e alterar o período de retenção de backup são operações on-line e não exigem uma reinicialização do servidor.
Preços
Para obter as informações de preços mais atualizadas, consulte a página de preços de serviço. Para ver o custo da configuração desejada, o portal do Azure mostra o custo mensal na guia Computação + armazenamento com base nas opções selecionadas. Se não tiver uma subscrição do Azure, pode utilizar 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 você gostaria de otimizar o custo do servidor, você pode considerar as seguintes dicas:
- Reduza sua camada de computação ou tamanho de computação (vCores) se a computação estiver subutilizada.
- Considere mudar para a camada de computação Burstable se sua carga de trabalho não precisar da capacidade de computação total continuamente das camadas de uso geral e crítica para os negócios.
- Pare o servidor quando não estiver em uso.
- Reduza o período de retenção de backup se não for necessária uma retenção mais longa de backup.
Próximos passos
- Saiba como criar uma instância de servidor flexível do Banco de Dados do Azure para MySQL no portal.
- Saiba mais sobre as limitações do serviço.