Escalões de serviço da Base 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: Burstable, General Purpose e Business Critical. A SKU de VM subjacente diferencia as camadas de serviço usadas nas séries B, D e E. A camada de computação e a escolha de tamanho determinam a memória e os vCores disponíveis no servidor. A tecnologia de armazenamento exata é 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 | Tamanhos de máquinas virtuais expansíveis da 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 32 TiB |
| Período de retenção do backup do banco de dados | 1 a 35 dias | 1 a 35 dias | 1 a 35 dias |
** Exceto 64,80 e 96 vCores, 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 da região da computação Ev5 aqui.
Camadas de serviço flexíveis do servidor
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 continuamente não precisam da CPU completa. |
| Fins Gerais | A maioria das cargas de trabalho de negócios requer 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, você pode alterar a camada de computação, o tamanho da computação e o tamanho do armazenamento. 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 independentemente o período de retenção de backup para cima ou para baixo. Consulte a seção Recursos de escala para obter mais informações.
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.
Expansível
As especificações detalhadas dos tipos de servidor disponíveis são as seguintes para a camada de serviço Burstable.
| Tamanho de computação | vCores | Tamanho da memória física (GiB) | Tamanho total da memória (GiB) | IOPS Máximo Suportado | Máx. Ligações | Armazenamento temporário (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 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 | 5000 | 13653 | 0 |
Fins Gerais
As especificações detalhadas dos tipos de servidor disponíveis são as seguintes para a camada de serviço de uso geral
| Tamanho de computação | vCores | Tamanho da memória física (GiB) | Tamanho total da memória (GiB) | IOPS Máximo Suportado | Máx. Ligaçõ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 | 20 000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20 000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20 000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20 000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20 000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20 000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20 000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20 000 | 43691 | 1720 |
Crítico para a Empresa
As especificações detalhadas dos tipos de servidor disponíveis são as seguintes para a camada de serviço Business Critical.
| Tamanho de computação | vCores | Tamanho da memória física (GiB) | Tamanho total da memória (GiB) | IOPS Máximo Suportado | Máx. Ligações | Armazenamento temporário (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 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 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 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_E80ds_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 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 | 38000 | 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 | 80 000 | 100000 | 2004 |
Resiliência de Zona Padrão no Banco de Dados do Azure para MySQL – Nível Crítico de Negócios de Servidor Flexível: A partir de meados de dezembro de 2024, todos os novos servidores provisionados no Banco de Dados do Azure para MySQL – Camada Crítica de Negócios de Servidor Flexível virão com resiliência de zona interna — sem custo extra! Isso significa que seus dados e arquivos de log serão armazenados automaticamente no armazenamento com redundância de zona, garantindo uma rápida recuperação de interrupções zonais. Mesmo sem a alta disponibilidade habilitada, você se beneficiará de uma proteção perfeita com backups com redundância de zona. Visão geral da continuidade de negócios com o Banco de Dados do Azure para MySQL - Servidor Flexível.
Gerenciamento de memória no Banco de Dados do Azure para servidor flexível MySQL
No MySQL, a memória desempenha um papel vital em várias operações, incluindo processamento de consultas e cache. O banco de dados do Azure para servidor flexível 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ão de cliente e manipulação de threads. 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 seu Banco de Dados do Azure para servidor flexível MySQL.
Tamanho total da memória (GB)
O Banco de Dados do Azure para servidor flexível MySQL fornece um Tamanho Total de Memória (GB). Isso representa a memória total disponível para o servidor, que é uma combinação de memória física e uma quantidade definida de componente SSD de armazenamento temporário. Essa exibição unificada foi projetada para simplificar o gerenciamento de recursos, permitindo que você se concentre apenas na memória total disponível para seu processo do Azure MySQL Server (mysqld). A métrica Porcentagem de Memória (memory_percent) representa a porcentagem de memória ocupada pelo processo do servidor MySQL do Azure (mysqld). Esta métrica é calculada a partir do Tamanho Total da Memória (GB). Por exemplo, quando a métrica Porcentagem de memória exibe um valor de 60, isso significa que seu processo do Azure MySQL Server está utilizando 60% do tamanho total de memória (GB) disponível em seu banco de dados do Azure para servidor flexível MySQL.
Servidor MySQL (mysqld)
O processo do servidor MySQL do Azure, mysqld, é o mecanismo de operações de banco de dados principal. Após a inicialização, ele inicializa o total de componentes, como o pool de buffers InnoDB e o cache de threads, utilizando memória com base em configurações e demandas de 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 da consulta, enquanto o cache de threads gerencia threads de conexão do cliente. Mais informações.
Mecanismo de armazenamento InnoDB
Como mecanismo de armazenamento padrão do MySQL, o InnoDB usa 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 InnoDB armazena dados de tabela e índices na memória para minimizar a E/S do 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 InnoDB disponível no Banco de Dados do Azure para o servidor flexível MySQL.
Threads
As conexões de cliente são gerenciadas por meio de 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 clientes. Mais informações.
Para obter mais detalhes sobre a série de computação disponível, consulte a documentação da VM do Azure para tamanhos de máquina virtual burstable da série B, Dadsv5-seriesDdsv4-series e Business Critical Edsv4 Edsv5-series//Eadsv5-series.
Limitações de desempenho de instâncias de série burstable
Nota
Para tamanhos de máquina virtual burstable da série B, se a VM for iniciada/interrompida ou reiniciada, os créditos poderão ser perdidos. Para obter mais informações, consulte Tamanhos de máquinas virtuais burstable da série B.
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. Suponha que o servidor de camada Burstable esteja executando uma carga de trabalho que exija mais desempenho da CPU do que o nível básico 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.
Nota
Para servidores em tamanhos de máquina virtual burstable da série B, como Standard_B1s/Standard_B1ms/Standard_B2s, seu tamanho de memória 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 oferece suporte à funcionalidade de criar 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 . Outras camadas de computação, como a Finalidade Geral ou a Crítica de Negócios, são mais apropriadas para essas cargas de trabalho e recursos.
Para obter mais informações sobre o modelo de crédito de CPU da série B do Azure, consulte os tamanhos de máquina virtual burstable da série B e o modelo de crédito de CPU da série B.
Monitore 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 e dos requisitos de 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 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.
Monitorar o Banco de Dados do Azure para MySQL - Servidor Flexível: essa métrica mostra o número de créditos de CPU restantes para sua instância. O monitoramento dessa métrica pode ajudar a evitar que sua instância se degrade em desempenho devido ao esgotamento dos créditos da 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 provisionado é a capacidade de armazenamento disponível para 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. Para os níveis de serviço Burstable e de uso geral, a faixa de armazenamento vai de um mínimo de 20 GiB a um máximo de 16 TiB. Por outro lado, o suporte ao armazenamento se estende até 32 TiB para o nível de serviço crítico para os negócios. Em todos os níveis de serviço, 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 está perto de atingir o limite provisionado, o servidor é colocado no modo somente leitura para proteger quaisquer gravações perdidas no servidor. 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 como somente leitura quando o armazenamento livre é inferior a 5 GiB.
Por exemplo, se você provisionou 110 GiB de armazenamento e a utilização real excede 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.
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 e confirmações de transação subsequentes falham, mas as consultas de leitura continuam a funcionar ininterruptamente.
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ê tiver provisionado 1.000 GB de armazenamento e a utilização real exceder 990 GB, o tamanho do armazenamento do servidor será aumentado para 1.050 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. 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 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 Monitor Azure Database for MySQL - Flexible Server . Você precisa dimensionar a computação do servidor se precisar de mais IOPS do que o IOPS máximo baseado na computação.
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 algumas 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. Isso pode ser melhorado permitindo que o servidor dimensione automaticamente o desempenho (E/S) de seus servidores de banco de dados sem problemas, dependendo das necessidades de carga de trabalho. Esse recurso de aceitação permite que os usuários dimensionem IOPS sob demanda sem ter que pré-provisionar uma certa quantidade de E/S por segundo. Com o recurso de IOPS de dimensionamento automático habilitado, agora você pode aproveitar o gerenciamento de E/S sem preocupações no Banco de Dados do Azure para servidor flexível MySQL, pois o servidor dimensiona IOPs automaticamente para cima ou para baixo, dependendo das necessidades de carga de trabalho. O AutoScale IOPS é dimensionado automaticamente até o 'Max Supported IOPS' 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 dimensionamento
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 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: o Autoscale IOPS permite 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, que especificam um limite de IOPS fixo e são pagas 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 backup automaticamente do servidor. Você pode selecionar um período de retenção 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, e o período de retenção de backup pode ser dimensionado para cima ou para baixo 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 deve ser reiniciado para que o novo tipo de servidor entre em vigor. Quando 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. Esta janela varia, mas na maioria dos casos, é entre 60 e 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ço
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.