📝 Publicado originalmente em 25/06/2018 e reescrito em 26/10/2026 com o Flexible Server no lugar do Single Server, os tiers atuais, a criação pelo Azure CLI e os cuidados de rede e custo.
Criando um Azure Database for MySQL você ganha um servidor MySQL gerenciado pela Microsoft: sem instalar sistema operacional, sem aplicar patch do banco na mão e com backup automático desde o primeiro minuto. Você escolhe a versão do MySQL, o tamanho da máquina e o armazenamento, e o Azure cuida do resto.
Este artigo foi escrito em 2018, quando o serviço tinha outra cara. Abaixo eu mostro as telas originais da criação, explico o que mudou desde então e como fazer o mesmo hoje pelo portal e pelo Azure CLI. A configuração de acesso de rede ficou para o artigo seguinte, sobre o firewall do Azure Database for MySQL.
O que mudou desde 2018
Em 2018 existia uma única opção de implantação, que depois passou a se chamar Single Server. A Microsoft lançou o Flexible Server, aposentou o Single Server e tirou a documentação dele do Microsoft Learn. Hoje, criar um Azure Database for MySQL significa criar um Flexible Server.
As diferenças que mais aparecem para quem vem das telas antigas:
- Tiers: os antigos Basic, General Purpose e Memory Optimized deram lugar a Burstable, General Purpose e Memory-Optimized. Em algumas telas do portal e da documentação o último aparece como Business Critical.
- Gerações de hardware: as opções Gen 4 e Gen 5 sumiram. Agora você escolhe direto o tamanho da VM, como
Standard_B1msouStandard_D2ads_v5. - Versões: o servidor de 2018 nasceu com MySQL 5.7. No Flexible Server as opções atuais incluem 8.0 e 8.4.
- Rede: a escolha entre acesso público (com regras de firewall) e acesso privado (integração com VNet) acontece já na criação.
- Usuário de login: no Single Server o login tinha o formato
usuario@nomedoservidor. No Flexible Server é só o nome do usuário.
A criação em 2018, passo a passo
Na época, o caminho começava pelo Marketplace: buscar Azure Database for MySQL, selecionar o item publicado pela Microsoft e clicar em Create.
A tela MySQL server pedia o nome do servidor, a assinatura, o resource group, a origem (em branco ou a partir de backup), o login e a senha do administrador, a região (Brazil South), a versão 5.7 e o tier de preço. O custo mensal estimado aparecia no rodapé.
Em Pricing tier ficavam os três planos da época, a geração do hardware, os vCores, o armazenamento, a retenção de backup (7 dias no exemplo) e a redundância do backup (localmente redundante). No texto original eu selecionei o plano Basic.
Depois do Create, o portal mostrava a notificação de implantação em andamento no resource group escolhido.
Com o deploy concluído, a página Overview do servidor exibia o status Available, a região, a versão do MySQL, a configuração de desempenho e o SSL obrigatório habilitado. O menu lateral já trazia Connection security, onde ficava o firewall.
Criando pelo portal hoje
No portal atual, busque por Azure Database for MySQL flexible servers e clique em Criar. O assistente é dividido em abas, e as escolhas que pesam são estas:
- Básico: assinatura, resource group, nome do servidor (vira parte do endereço
nome.mysql.database.azure.com), região e versão do MySQL. - Computação + armazenamento: tier, tamanho da VM, armazenamento e retenção de backup. O armazenamento só pode ser aumentado depois, nunca reduzido.
- Alta disponibilidade: cria uma réplica em espera na mesma zona ou em outra zona. Não está disponível no Burstable.
- Autenticação: só MySQL, só Microsoft Entra ID ou as duas. Com Entra ID dá para usar identidade gerenciada na aplicação em vez de senha.
- Rede: acesso público com regras de firewall ou acesso privado dentro de uma VNet.
Antes de clicar em Revisar + criar, confira o custo estimado na aba de computação. O portal mostra o valor mensal da combinação escolhida.
Criando pelo Azure CLI
O mesmo servidor sai em um comando. O exemplo cria um Burstable pequeno em Brazil South, sem nenhum acesso público liberado:
az group create --name rg-mysql-lab --location brazilsouth
az mysql flexible-server create \
--resource-group rg-mysql-lab \
--name mysql-lab-blog \
--location brazilsouth \
--admin-user adminmysql \
--admin-password '<senha-forte>' \
--tier Burstable \
--sku-name Standard_B1ms \
--storage-size 32 \
--version 8.0.21 \
--public-access NoneO parâmetro --public-access aceita None, um IP, uma faixa de IPs ou All. Comece com None e libere só o necessário depois. Para conferir o resultado e criar um banco dentro do servidor:
az mysql flexible-server show \
--resource-group rg-mysql-lab \
--name mysql-lab-blog \
--query "{estado:state, versao:version, fqdn:fullyQualifiedDomainName}" \
--output table
az mysql flexible-server db create \
--resource-group rg-mysql-lab \
--server-name mysql-lab-blog \
--database-name appdbSe você prefere o Cloud Shell, o passo a passo de como criar um banco MySQL no Azure Shell mostra o mesmo fluxo de dentro do portal.
Qual tier escolher
O Burstable usa VMs da série B, que acumulam créditos de CPU quando estão ociosas e gastam esses créditos nos picos. Sem créditos, o servidor fica preso na linha de base de CPU. A própria Microsoft não recomenda esse tier para produção, e ele não oferece alta disponibilidade nem réplicas de leitura.
O General Purpose atende a maioria das aplicações web e corporativas. O Memory-Optimized é para cargas que precisam de muita memória por vCore e de mais concorrência. Trocar de tier depois é possível, mas exige reinício do servidor.
Cuidados depois da criação
- Libere o acesso com critério. Prefira regras de firewall com IPs específicos ou acesso privado. O artigo sobre o firewall do Azure Database for MySQL trata disso em detalhe.
- Mantenha o TLS. O servidor exige conexão segura por padrão. Desligar isso para “fazer funcionar” costuma esconder um problema no driver da aplicação.
- Pare o que não usa. O Flexible Server pode ser parado. Enquanto parado, você não paga computação, mas segue pagando o armazenamento.
- Monitore o armazenamento. Se o disco chegar perto do limite, o servidor entra em modo somente leitura. O crescimento automático de armazenamento evita isso e vem habilitado nos servidores novos.
- Planeje a migração de bancos antigos. Quem ainda tem dados em outro provedor pode seguir a ideia da migração de banco ClearDB para MySQL.
Conclusão
Criar um Azure Database for MySQL hoje é criar um Flexible Server: escolher versão, tier e tamanho, decidir o modelo de rede e definir como a aplicação vai autenticar. As telas de 2018 mudaram bastante, mas a lógica continua a mesma. Comece pequeno, deixe o acesso fechado e só abra o que a aplicação precisa.
Referências oficiais
- Criar um Azure Database for MySQL Flexible Server pelo portal (Microsoft Learn)
- Tiers de serviço, computação e armazenamento (Microsoft Learn)
- az mysql flexible-server (Azure CLI Reference)
Interessado em saber mais sobre artigos relacionados a Microsoft Azure CLIQUE AQUI
🚀 Vamos nos conectar?
Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, AWS, Kubernetes e DevOps em primeira mão.
Dica: no Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!
💬 Dúvidas ou problemas?
Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!
Muito obrigado pela visita e até o próximo post!
Jefferson Castilho Especialista em Cloud & DevOps.Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.