Banco de Dados do Azure para MySQL - Camadas de serviço de Servidor Único

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

Você pode criar um Banco de Dados do Azure para o servidor MySQL em uma das três camadas de serviço diferentes: Básica, Finalidade Geral e Memória Otimizada. As camadas de serviço são diferenciadas pela quantidade de computação em vCores que pode ser provisionada, memória por vCore e a 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.

Para escolher um nível de preço, use a tabela a seguir como ponto de partida.

Depois de criar um servidor de uso geral ou otimizado para memória, o número de vCores, a geração de hardware e a camada de preços podem ser alterados para cima ou para baixo em segundos. Você também pode ajustar de forma independente a quantidade de armazenamento e o período de retenção de backup para cima ou para baixo, sem tempo de inatividade do aplicativo. Não é possível alterar o tipo de armazenamento de backup após a criação de um servidor. Para obter mais informações, consulte a seção Recursos de escala .

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. China East 1, China North 1, US DoD Central e US DoD East utilizam CPUs lógicas Gen 4 baseadas em processadores Intel E5-2673 v3 (Haswell) de 2,4 GHz. Todas as outras regiões utilizam CPUs lógicas Gen 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 seu Banco de Dados do Azure para o servidor MySQL. O armazenamento é usado para os arquivos de banco de dados, arquivos temporários, logs de transações e os logs do servidor MySQL. A quantidade total de armazenamento provisionada também define a capacidade de E/S disponível para o servidor.

O Banco de Dados do Azure para MySQL – Servidor Único dá suporte ao seguinte: o armazenamento de back-end para os servidores.

Armazenamento básico

O armazenamento básico é o armazenamento de back-end que suporta os servidores do escalão de preço Básico. O armazenamento básico usa o armazenamento padrão do Azure no back-end, onde as iops provisionadas não são garantidas e a latência é variável. A camada básica é mais adequada para cargas de trabalho que exigem computação leve, baixo custo e desempenho de E/S para desenvolvimento ou aplicativos usados com pouca frequência em pequena escala.

Armazenamento para fins gerais

O armazenamento de uso geral é o armazenamento de back-end que suporta o servidor de camadas de uso geral e otimizado para memória. No armazenamento para Fins Gerais, o IOPS dimensiona-se com o tamanho de armazenamento aprovisionado numa proporção de 3:1. Existem duas gerações de armazenamento para fins gerais, conforme descrito abaixo:

Armazenamento para fins gerais v1 (suporta até 4 TB)

O armazenamento de uso geral v1 é baseado na tecnologia de armazenamento legado, que pode suportar até 4 TB de armazenamento e 6000 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 MySQL para cache local e backups. O processo de backup no armazenamento de uso geral v1 lê os dados e os arquivos 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 io do armazenamento durante os backups é relativamente maior.

Todas as regiões do Azure dão suporte ao armazenamento de uso geral v1

Para servidor de uso geral ou otimizado para memória no armazenamento de uso geral v1, recomendamos que você considere

• Planeje a camada de sku de computação que representa 10-30% de excesso de memória para armazenamento em cache 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/S de backup
• Como alternativa, migre para o armazenamento de uso geral v2 descrito abaixo, que oferece suporte a armazenamento de até 16 TB se a infraestrutura de armazenamento subjacente estiver disponível em suas regiões preferidas do Azure compartilhadas abaixo.

Armazenamento para fins gerais v2 (suporta armazenamento de até 16 TB)

O armazenamento de fins gerais v2 tem por base a mais recente infraestrutura de armazenamento, que pode suportar até 16 TB e 20 000 IOPS. Num subconjunto de regiões do Azure no qual a infraestrutura esteja disponível, todos os servidores recém-aprovisionados recebem o armazenamento de fins gerais v2 por predefinição. O armazenamento de uso geral v2 não consome memória do nó de computação do MySQL e fornece latências de E/S mais previsíveis em comparação com o armazenamento v1 de uso geral. Os backups nos servidores de armazenamento v2 de uso geral são baseados em snapshot, sem sobrecarga adicional de E/S. No armazenamento v2 de uso geral, 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á custo adicional para armazenamento de uso geral que suporta armazenamento de até 16 TB. Para obter assistência com a migração para armazenamento de 16 TB, abra um tíquete de suporte do portal do Azure.

O armazenamento de uso geral v2 é suportado nas seguintes regiões do Azure:

Como posso determinar em qual tipo de armazenamento meu servidor está sendo executado?

Você pode encontrar o tipo de armazenamento do seu servidor indo para Configurações>Computação + página de armazenamento

• Se o servidor for provisionado usando SKU Básico, o tipo de armazenamento será Armazenamento Básico.
• Se o servidor for provisionado usando SKU de uso geral ou 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 mudar do armazenamento de uso geral v1 para o armazenamento de uso geral v2? Em caso afirmativo, como e existe algum custo adicional?

Sim, a migração da v1 para o armazenamento de uso geral v2 é suportada 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 capacidade de armazenamento adicional durante e após a criação do servidor e permitir que o sistema aumente o armazenamento automaticamente com base no consumo de armazenamento da sua carga de trabalho.

Monitorização do consumo de E/S

Você pode monitorar seu consumo de E/S no portal do Azure ou usando comandos da CLI do Azure. As métricas relevantes a serem monitoradas são o limite de armazenamento, a porcentagem de armazenamento, o armazenamento usado e o percentual de E/S. As métricas de monitoramento para o servidor MySQL com armazenamento de uso geral v1 relatam a memória e E/S consumidas pelo mecanismo MySQL, mas podem não capturar o consumo de memória e E/S da camada de armazenamento, o que é uma limitação.

Atingir o limite de armazenamento

Os servidores com armazenamento aprovisionado igual ou inferior a 100 GB são marcados como só de leitura se o armazenamento livre for inferior a 5% do tamanho de armazenamento aprovisionado. Os servidores com mais de 100 GB de armazenamento aprovisionado serão marcados como só de leitura se o armazenamento livre for inferior a 5 GB.

Por exemplo, se você provisionou 110 GB de armazenamento e a utilização real ultrapassa 105 GB, o servidor será marcado como somente leitura. Como alternativa, se você tiver provisionado 5 GB 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. Depois de aumentar o armazenamento aprovisionado, o servidor fica pronto para aceitar novamente as transações de escrita.

Recomendamos que você ative o crescimento automático do armazenamento ou 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.

Aumento automático do armazenamento

O aumento automático do armazenamento impede que o servidor fique sem armazenamento e se torne só de leitura. Se o crescimento automático do armazenamento estiver habilitado, o armazenamento crescerá automaticamente sem afetar a carga de trabalho. Para os servidores com um armazenamento aprovisionado inferior ou igual a 100 GB, o tamanho do armazenamento aprovisionado é aumentado em 5 GB quando o armazenamento livre estiver abaixo de 10% do armazenamento aprovisionado. 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.

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 10 GB de armazenamento, o tamanho do armazenamento será aumentado para 15 GB quando menos de 1 GB de armazenamento estiver livre.

Lembre-se de que o armazenamento só pode ser ampliado e não reduzido.

Armazenamento de cópias de segurança

A Base de Dados do Azure para MySQL fornece até 100% do armazenamento do servidor aprovisionado como armazenamento de cópias de segurança sem custos adicionais. Qualquer armazenamento de backup que você usar além desse valor será 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 do servidor sem nenhum custo. O armazenamento para backups superiores a 250 GB é 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 do armazenamento de backup, consulte a documentação de backup.

Dimensionar recursos

Depois de criar o servidor, você pode alterar independentemente os vCores, a geração de hardware, a camada de preços (exceto de e para Basic), a quantidade de armazenamento e o período de retenção de backup. Não é possível alterar o tipo de armazenamento de backup após a criação de um servidor. O número de vCores pode ser aumentado ou diminuído verticalmente. O período de retenção de cópias de segurança pode ser aumentado ou diminuído verticalmente entre 7 e 35 dias. O tamanho do armazenamento só pode ser aumentado. O dimensionamento dos recursos pode ser feito através do portal ou da CLI do Azure. Para obter um exemplo de dimensionamento usando a CLI do Azure, consulte Monitorar e dimensionar um Banco de Dados do Azure para o servidor MySQL usando a CLI do Azure.

Quando você altera o número de vCores, a geração de hardware ou a camada de preço, uma cópia do servidor original é criada com a nova alocação de computação. Depois de o novo servidor estar a funcionar em pleno, as ligações são passadas para o novo servidor. 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. Esse tempo de inatividade durante o dimensionamento pode ser de cerca de 60 a 120 segundos. O tempo de inatividade durante o dimensionamento depende do tempo de recuperação do banco de dados, o que pode fazer com que o banco de dados fique online por mais tempo se você tiver uma atividade transacional intensa no servidor no momento da operação de dimensionamento. Para evitar um tempo de reinicialização mais longo, é recomendável executar operações de dimensionamento durante períodos de baixa atividade transacional no servidor.

Dimensionar o armazenamento e alterar o período de retenção de backup são verdadeiras operações on-line. Não há tempo de inatividade e a sua aplicação não é afetada. À medida que as IOPS são dimensionadas de acordo com o tamanho do armazenamento provisionado, você pode aumentar as IOPS disponíveis para o servidor dimensionando o armazenamento.

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 Nível de preço 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 e escolha Banco de Dados do Azure para MySQL para personalizar as opções.

Próximos passos

• Saiba como criar um servidor MySQL no portal.
• Saiba mais sobre os limites de serviço.
• Saiba como expandir com réplicas de leitura.