Camadas de serviço do Banco de Dados do Azure para MySQL – Servidor único
APLICA-SE A:
Banco de Dados do Azure para MySQL – Servidor único
Importante
O Banco de Dados do Azure para servidor único MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para o servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?
Você pode criar um servidor do Banco de Dados do Azure para MySQL em uma das três camadas de serviço diferentes: Básico, Uso Geral e Otimizado para Memória. As camadas de serviço são diferenciados pela quantidade de computação nos vCores que pode ser provisionada, pela memória por vCore e pela tecnologia de armazenamento usada para armazenar os dados. Todos os recursos são provisionados no nível do servidor MySQL. Um servidor pode ter um ou vários bancos de dados.
| Atributo | Basic | Uso Geral | Otimizado para memória |
|---|---|---|---|
| Geração de computação | Gen 4, Gen 5 | Gen 4, Gen 5 | Gen 5 |
| vCores | 1, 2 | 2, 4, 8, 16, 32, 64 | 2, 4, 8, 16, 32 |
| Memória por vCore | 2 GB | 5 GB | 10 GB |
| Tamanho de armazenamento | 5 GB a 1 TB | 5 GB a 16 TB | 5 GB a 16 TB |
| Período de retenção do backup de banco de dados | 7 a 35 dias | 7 a 35 dias | 7 a 35 dias |
Para escolher um tipo de preço, use a tabela a seguir como ponto de partida.
| Camada de serviço | Cargas de trabalho de destino |
|---|---|
| Basic | Cargas de trabalho que exigem desempenho de E/S e computação leve. Os exemplos incluem servidores usados para desenvolvimento ou teste ou aplicativos de pequena escala usados com pouca frequência. |
| 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. |
| Otimizado para memória | 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. |
Observação
No momento, não há suporte para o dimensionamento dinâmico nas camadas de serviço Básico. Os servidores de SKUs de Camada Básica não podem ser dimensionados para Camadas de Uso Geral ou Otimizado para Memória.
Depois de criar um servidor de Uso Geral ou Otimizado para Memória, o número de vCores, a geração de hardware e o tipo de preço podem ser alterados para cima ou para baixo em segundos. Você pode também, independentemente, ajustar a quantidade de armazenamento de backup e o período de retenção de backup para cima ou para baixo sem tempo de inatividade do aplicativo. Não será possível alterar o tipo de armazenamento de backup depois que um servidor é criado. Para obter mais informações, consulte a seção Recursos de dimensionamento.
Gerações de computação e vCores
Os recursos de computação são fornecidos como vCores, que representam a CPU lógica do hardware subjacente. Leste da China 1, Norte da China 1, US DoD Central e Leste do US DoD usam CPUs lógicas de geração 4 baseadas em processadores Intel E5-2673 v3 (Haswell) de 2,4 GHz. Todas as outras regiões usam CPUs lógicas de geração 5 baseadas em processadores Intel E5-2673 v4 (Broadwell) de 2,3 GHz.
Armazenamento
O armazenamento provisionado é a quantidade de capacidade de armazenamento disponível para o Banco de Dados do Azure para servidor MySQL. O armazenamento é usado para os arquivos de banco de dados, os logs de transações e os logs do servidor MySQL. A quantidade total de armazenamento que você provisiona também define a capacidade disponível para o servidor.
Banco de Dados do Azure para MySQL – o Servidor Único permite o seguinte armazenamento de back-end para os servidores.
| Tipo de armazenamento | Basic | Uso geral v1 | Uso geral v2 |
|---|---|---|---|
| Tamanho de armazenamento | 5 GB a 1 TB | 5 GB a 4 TB | 5 GB a 16 TB |
| Tamanho do incremento de armazenamento | 1 GB | 1 GB | 1 GB |
| IOPS | Variável | 3 IOPS/GB Mín 100 IOPS Máx 6000 IOPS |
3 IOPS/GB Mín 100 IOPS Máx. 20.000 IOPS |
Observação
O armazenamento Básico não oferece garantia de IOPS. No armazenamento Uso Geral, o IOPS é dimensionado com o tamanho do armazenamento provisionado em uma proporção de 3:1.
Armazenamento Básico
O armazenamento Básico é o armazenamento de back-end compatível com servidores de tipo de preço Básico. O armazenamento Básico usa o armazenamento padrão do Azure no back-end em que IOPS provisionados não são garantidos e a latência é variável. A camada básica é mais adequada para cargas de trabalho que exigem computação leve, baixo custo e baixo desempenho de E/S para desenvolvimento ou aplicativos pouco usados em pequena escala.
Armazenamento de Uso Geral
O armazenamento de Uso Geral é o armazenamento de back-end compatível com o Uso Geral e ao servidor de camada Otimizado para memória. No armazenamento Uso Geral, o IOPS é dimensionado com o tamanho do armazenamento provisionado em uma proporção de 3:1. Há duas gerações de armazenamento de uso geral, conforme descrito abaixo:
Armazenamento de Uso Geral v1 (compatível com até 4 TB)
O armazenamento de Uso Geral v1 baseia-se na tecnologia de armazenamento herdada que pode permitir armazenamento de até 4 TB e 6.000 IOPS por servidor. O armazenamento de Uso Geral v1 é otimizado para aproveitar a memória dos nós de computação que executam o mecanismo do MySQL para cache e backups locais. O processo de backup no armazenamento de Uso Geral v1 lê os arquivos de dados e de log na memória dos nós de computação e os copia para o armazenamento de backup de destino para retenção de até 35 dias. Como resultado, o consumo de memória e E/S de armazenamento durante backups é relativamente maior.
Todas as regiões do Azure são compatíveis com o armazenamento de Uso Geral v1
Para Uso Geral ou servidor com otimização para memória no armazenamento de Uso Geral v1, recomendamos que você considere
- Planejar a contabilização da camada de SKU de computação para memória em excesso de 10% a 30% para cache de armazenamento e buffers de backup
- Provisionar IOPS 10% maiores do que o exigido pela carga de trabalho do banco de dados para levar em conta as E/Ss de backup
- Como alternativa, migrar para o armazenamento de Uso Geral v2 descrito abaixo que permite até 16 TB de armazenamento se a infraestrutura de armazenamento subjacente estiver disponível em suas regiões do Azure preferenciais compartilhadas abaixo.
Armazenamento de Uso Geral v2 (permite até 16 TB de armazenamento)
O armazenamento de Uso Geral v2 se baseia na infraestrutura de armazenamento mais recente que permite até 16 TB e 20.000 IOPS. Em um subconjunto de regiões do Azure em que a infraestrutura está disponível, todos os servidores recém-provisionados são disponibilizados no armazenamento de Uso Geral v2 por padrão. O armazenamento de Uso Geral v2 não consome nenhuma memória do nó de computação do MySQL e oferece latências de E/S mais previsíveis em comparação com o armazenamento de Uso Geral v1. Os backups nos servidores de armazenamento de Uso Geral v2 são baseados em instantâneo sem sobrecarga adicional de E/S. No armazenamento de Uso Geral v2, espera-se que o desempenho do servidor MySQL seja maior em comparação com o armazenamento de Uso Geral v1 para o mesmo armazenamento e IOPS provisionados. Não há nenhum custo adicional para armazenamento de Uso Geral que permita armazenamento de até 16 TB. Para obter assistência com a migração para o armazenamento de 16 TB, abra um tíquete de suporte no portal do Azure.
Há compatibilidade com o armazenamento de Uso Geral v2 nas seguintes regiões do Azure:
| Região | Disponibilidade do armazenamento de Uso Geral v2 |
|---|---|
| Leste da Austrália | ✔️ |
| Sudeste da Austrália | ✔️ |
| Brazil South | ✔️ |
| Canadá Central | ✔️ |
| Leste do Canadá | ✔️ |
| Centro dos EUA | ✔️ |
| Leste dos EUA | ✔️ |
| Leste dos EUA 2 | ✔️ |
| Leste da Ásia | ✔️ |
| Leste do Japão | ✔️ |
| Oeste do Japão | ✔️ |
| Coreia Central | ✔️ |
| Sul da Coreia | ✔️ |
| Norte da Europa | ✔️ |
| Centro-Norte dos EUA | ✔️ |
| Centro-Sul dos Estados Unidos | ✔️ |
| Sudeste Asiático | ✔️ |
| Sul do Reino Unido | ✔️ |
| Oeste do Reino Unido | ✔️ |
| Centro-Oeste dos EUA | ✔️ |
| Oeste dos EUA | ✔️ |
| Oeste dos EUA 2 | ✔️ |
| Europa Ocidental | ✔️ |
| Índia Central | ✔️ |
| França Central* | ✔️ |
| Norte dos EAU* | ✔️ |
| Norte da África do Sul* | ✔️ |
Observação
*Regiões em que o Banco de Dados do Azure para MySQL tem um armazenamento para uso geral v2 em Versão Prévia Pública
*Nessas regiões do Azure, você terá a opção de criar um servidor no armazenamento para uso geral v1 e v2. Para os servidores criados com o armazenamento de uso geral v2 na visualização pública, a seguir estão as limitações,
- Backup com redundância geográfica não será compatível
- O servidor de réplica deve estar nas regiões que permitem o armazenamento de Uso Geral v2.
Como posso determinar em qual tipo de armazenamento meu servidor está em execução?
Encontre o tipo de armazenamento do servidor acessando a página Configurações>Computação + armazenamento
- Se o servidor for provisionado usando o SKU Básico, o tipo de armazenamento será Básico.
- Se o servidor for provisionado usando SKU de uso geral ou de memória otimizada, o tipo de armazenamento será armazenamento de uso geral
- Se o armazenamento máximo que pode ser provisionado no servidor for de até 4 TB, o tipo de armazenamento será armazenamento de Uso Geral v1.
- Se o armazenamento máximo que pode ser provisionado no servidor for de até 16 TB, o tipo de armazenamento será armazenamento de Uso Geral v2.
Posso passar do armazenamento de Uso Geral v1 para o armazenamento de Uso Geral v2? Se sim, há algum custo adicional? De quanto?
Sim, a migração da v1 para o armazenamento de Uso Geral v2 é compatível se a infraestrutura de armazenamento subjacente estiver disponível na região do Azure do servidor de origem. A migração e o armazenamento v2 estão disponíveis sem custo adicional.
Posso aumentar o tamanho do armazenamento depois que o servidor é provisionado?
Você pode adicionar mais capacidade de armazenamento durante e após a criação do servidor e permitir que o sistema aumente o armazenamento automaticamente com base no uso do espaço de armazenamento de sua carga de trabalho.
Importante
O armazenamento só pode ser escalado verticalmente, não horizontalmente.
Monitoramento do consumo de E/S
Você pode monitorar o consumo de E/S no Portal do Azure ou usando os comandos da CLI do Azure. As métricas relevantes a monitorar são limite de armazenamento, percentual de armazenamento, armazenamento usado e porcentagem de E/S. As métricas de monitoramento para o servidor MySQL com armazenamento de Uso Geral v1 relatam a memória e a E/S consumidas pelo mecanismo MySQL, mas podem não capturar a memória e o consumo de E/S da camada de armazenamento, o que é uma limitação.
Alcançando o limite de armazenamento
Os servidores com armazenamento provisionado menor ou igual a 100 GB 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 GB de armazenamento provisionado serão marcados como somente leitura quando o armazenamento livre for inferior a 5 GB.
Por exemplo, se você provisionou 110 GB de armazenamento e a utilização real for de 105 GB, o servidor é marcado como somente leitura. Como alternativa, se você tiver provisionado 5 GB 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. Após aumentar o armazenamento provisionado, o servidor estará pronto para aceitar transações de gravação novamente.
Recomendamos que você ative o aumento automático do armazenamento ou configure um alerta para notificá-lo 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 em como configurar um alerta.
Aumento automático do armazenamento
O aumento automático do armazenamento impede que o servidor fique sem armazenamento e se torne somente leitura. Se o aumento automático do armazenamento estiver habilitado, o armazenamento aumentará automaticamente sem afetar a carga de trabalho. Para servidores com menos de 100 GB ou com 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.
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 10 GB de armazenamento, o tamanho do armazenamento aumentará para 15 GB quando menos de 1 GB de armazenamento estiver disponível.
Não esqueça de que o armazenamento só pode ser escalado verticalmente, não horizontalmente.
Armazenamento de backup
O Banco de Dados do Azure para MySQL fornece até 100% de seu armazenamento de servidor configurado como armazenamento de backup sem custo adicional. Qualquer armazenamento de backup usado além desse valor é cobrado em GB por mês. Por exemplo, se você provisionar um servidor com 250 GB de armazenamento, terá 250 GB de armazenamento adicional disponível para backups de servidor, sem custo adicional. O armazenamento para backups além de 250 GB será cobrado de acordo com o modelo de preços. Para entender os fatores que influenciam o uso do armazenamento de backup, o monitoramento e o controle do custo de armazenamento de backup, veja documentação de backup.
Escalar recursos
Após criar o servidor, você poderá, independentemente, alterar vCores, a geração de hardware, o tipo de preço (exceto em Básico), a quantidade de armazenamento e o período de retenção de backup. Não será possível alterar o tipo de armazenamento de backup depois que um servidor é criado. O número de vCores pode ser dimensionado para cima ou para baixo. Os vCores e o período de retenção de backup podem ser aumentados ou reduzidos de 7 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. Para obter um exemplo de dimensionamento usando a CLI do Azure, consulte Monitorar e dimensionar um servidor do Banco de Dados do Azure para MySQL usando a CLI do Azure.
Ao alterar o número de vCores, a geração de hardware ou o tipo de preço, uma cópia do servidor original é criada com a nova alocação de computação. Depois que o novo servidor entra em execução, as conexões são alternadas para o novo servidor. 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. Esse tempo de inatividade durante o dimensionamento pode ser de cerca de 60-120 segundos. O tempo de inatividade durante o dimensionamento depende do momento da recuperação do banco de dados, o que pode fazer com que o banco de dados fique online por mais tempo se você tiver intensa atividade transacional no servidor no momento da operação de dimensionamento. Para evitar tempo de reinício mais longo, é recomendável executar operações de dimensionamento durante períodos de baixa atividade transacional no servidor.
O dimensionamento do armazenamento e a alteração do período de retenção de backup são operações realmente online. Não há nenhum tempo de inatividade e o aplicativo não é afetado. Conforme o IOPS é dimensionado com o tamanho do armazenamento provisionado, você pode aumentar o IOPS disponível para seu servidor aumentando o armazenamento.
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 Tipo de preço 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 e escolha Banco de Dados do Azure para MySQL para personalizar as opções.
Próximas etapas
- Saiba como criar um servidor MySQL no portal.
- Conheça os limites de serviço.
- Saiba como fazer a expansão com réplicas de leitura.