Você quer começar a usar o banco de dados de código aberto mais popular do mundo e se pergunta como deve configurar sua hospedagem MySQL? Muitos são padronizados para o Amazon RDS, quando o MySQL funciona excepcionalmente bem no Azure Cloud. Embora o Microsoft Azure ofereça uma solução gerenciada, o Banco de Dados do Azure, a solução tem algumas limitações importantes que você deve conhecer antes de migrar suas implantações do MySQL. Nesta postagem, descrevemos a melhor maneira de hospedar o MySQL no Azure, incluindo soluções gerenciadas, tipos de instância, replicação de alta disponibilidade, backup e tipos de disco a serem usados para otimizar o desempenho do banco de dados na nuvem.
MySQL DBaaS x MySQL autogerenciado
A primeira coisa a considerar ao ponderar entre o autogerenciamento e uma solução MySQL Database-as-a-Service (DBaaS) é quais recursos internos você tem disponíveis. Se você está lendo isso, provavelmente já conhece a magnitude das tarefas operacionais associadas à manutenção de uma implantação de produção, mas para uma rápida recapitulação, há provisionamento, desprovisionamento, configurações mestre-escravo, backups, dimensionamento, upgrades, rotações de log, patches de SO , e monitoramento para citar alguns.
Um especialista interno em MySQL ou uma equipe de DBAs, dependendo do tamanho do seu aplicativo, certamente pode lidar com isso com sua organização para você, mas a questão é onde você deseja que os esforços de sua equipe se concentrem . Muitos decidem migrar para um MySQL DBaaS para automatizar essas tarefas demoradas para que possam se concentrar mais no desenvolvimento e na otimização de seus bancos de dados de aplicativos. Um bom exemplo seria a análise de consulta lenta. Embora quase todos os DBaaS ofereçam uma ferramenta MySQL Slow Query Analyzer para ajudar a identificar consultas de problemas, essa tarefa ainda requer habilidade e intuição humana para determinar como otimizar essas consultas que afetam o desempenho de seus aplicativos.
Seja você uma empresa iniciante ou uma empresa da Fortune 500, você descobrirá que muitas organizações optam por alavancar um DBaaS para otimizar o tempo de seus DBAs, enquanto os mesmos tipos e tamanhos de negócios também opte por manter a autogestão interna. Para muitas empresas, a decisão se resume em grande parte à personalização e ao controle. É por isso que alertamos contra o padrão do Banco de Dados do Azure, ou de seu concorrente da AWS, o Amazon RDS, pois eles não permitem que você mantenha o acesso de superusuário do MySQL ou mesmo o acesso SSH às suas máquinas. Além disso, a capacidade de personalizar sua configuração de implantação é altamente limitada, como os tipos de instância, RAM, tamanho do disco ou IOPS que você pode usar. Você aprenderá mais sobre os melhores tipos de instância e discos a serem usados abaixo e poderá conferir esta comparação de provedores MySQL para ver as vantagens e limitações das quatro principais soluções MySQL gerenciadas, ScaleGrid, Compose, Azure Database e Amazon RDS.
Implantação de alta disponibilidade
Se você estiver implantando em produção, você deve sempre configurar o MySQL como uma implantação mestre-escravo. As implantações independentes são um único nó sem qualquer replicação e devem ser usadas apenas para ambientes de desenvolvimento ou teste. Com as implantações mestre-escravo, você pode configurar alta disponibilidade para que, se um de seus nós ficar inativo, você possa fazer failover para um escravo sem tempo de inatividade. Isso normalmente é configurado como um mestre-escravo-escravo de 3 nós ou um mestre-escravo-quorum de 2+1 nós. A vantagem de usar um quorum é que é uma alternativa de menor custo, mas a desvantagem é que você tem apenas 2 nós de suporte de dados, pois o outro atua como um nó de quorum para determinar o melhor curso de failover. Se seu aplicativo puder ler do escravo, você precisará fazer o dimensionamento de leitura para que eles retornem os mesmos dados do volume do cluster com atraso mínimo.
A melhor maneira de hospedar o MySQL no Azure CloudClick To Tweet
Ao usar uma configuração mestre-escravo do MySQL, recomendamos configurar a replicação semisíncrona para melhorar a integridade de seus dados com redundância de dados. Isso garante que, quando um commit for retornado com sucesso, os dados existirão tanto no master quanto no slave, portanto, caso um datacenter fique inativo, seu MySQL master pode fazer failover para um slave sem perda de dados. Você pode fazer isso com replicação assíncrona ou semissíncrona e saiba mais sobre isso em nossa postagem no blog MySQL High Availability Explained – Parte II.
Então, como configuramos a alta disponibilidade para MySQL no Azure? Precisamos distribuir nossas instâncias escravas em diferentes zonas de disponibilidade (AZ) do Azure. Portanto, queremos ter certeza de que escolhemos uma região do Azure que tenha pelo menos 3 AZs, colocando cada instância em uma AZ diferente. Fazemos isso porque as garantias de disponibilidade estão em todas as AZs, portanto, se 1 zona ficar inativa, seu banco de dados de aplicativos ainda poderá permanecer online nas outras 2 AZs. As zonas de disponibilidade são relativamente novas no Azure, portanto, se você estiver trabalhando em uma região que não oferece AZs, terá a opção de usar conjuntos de disponibilidade. Eles são um pouco mais fracos que os de AZ, mas garantem que você seja implantado em diferentes domínios e racks para protegê-lo contra uma possível interrupção. Também há a opção de implantar em várias regiões, mas essa é uma configuração mais complicada, por isso recomendamos entrar em contato para discutir antes da implementação.
Redes Virtuais do Azure
A melhor maneira de proteger seu banco de dados da Internet é implantá-lo em uma sub-rede privada para garantir que ele não seja exposto. O Azure facilita a configuração por meio do uso de uma Rede Virtual (VNET) que pode ser configurada para seus servidores MySQL. Com uma VNET do Azure para MySQL, você pode configurar comunicações seguras entre seus servidores, a Internet e até mesmo sua rede de nuvem privada local. Normalmente, eles são configurados para se comunicar em uma única rede, mas se você precisar conectar mais de uma região, poderá criar várias VNETs para se comunicar por meio do emparelhamento de rede virtual.
Além disso, você pode gerenciar seu controle de acesso MySQL por meio de regras de NSG (Network Security Groups) sem ter que lidar com listas brancas de IP. Isso não está disponível por meio do Banco de Dados do Azure para MySQL, mas VNET e NSG podem ser configurados por meio de nossos planos MySQL Bring Your Own Cloud (BYOC) no Azure, onde você pode hospedar seus clusters por meio de sua própria conta de nuvem.
Tipos de instância do Azure
Outro aspecto importante a ser considerado é o desempenho de suas instâncias MySQL na nuvem pública. A nuvem do Azure oferece vários tipos de instância que podem ser usados para sua hospedagem MySQL, incluindo Es2 v3, Ds2, v2 e Ls4.
Recomendamos começar com tipos de instância com otimização de memória, pois os bancos de dados exigem muita RAM e procuram a velocidade de disco mais rápida possível para obter o melhor desempenho. A série Es2 é normalmente um bom ponto de partida para a maioria das cargas de trabalho do MySQL de aplicativos. A partir daí, você pode fazer alguns testes de desempenho para ver se precisa de mais CPU; nesse caso, tipos de instância balanceados ou tipos de instância com uso intensivo de CPU podem atender melhor às suas necessidades do MySQL, como os tipos de instância Dv3. Seus testes de desempenho também podem mostrar que você precisa de mais E/S (entrada/saída), você pode mudar para um tipo de instância com uso intensivo de disco.
Se você planeja aproveitar o Azure como seu provedor de nuvem MySQL nos próximos 1 a 3 anos e manter configurações de implantação bastante consistentes, você também pode considerar instâncias reservadas. Estas são essencialmente instâncias pré-pagas que permitem que você obtenha economias de custo consideráveis para sua hospedagem MySQL. Em média, você pode economizar cerca de 20% a 30% para instâncias reservadas de um ano e 40% a 50% nas instâncias reservadas de 3 anos.
Tipos de disco do Azure
A primeira determinação que você precisa fazer quando se trata de escolher um tipo de disco do Azure para suas implantações do MySQL é se deve optar por um disco gerenciado ou não gerenciado. Os discos não gerenciados são os discos herdados que o Azure oferece em que você precisa configurar a conta de armazenamento, mapear seu disco para a conta de armazenamento e monitorar o uso e os limites de IOPS para essa conta de armazenamento. É altamente recomendável usar discos gerenciados e, se você ainda estiver implantando com discos não gerenciados, considere migrar para o gerenciado.
Ambientes de desenvolvimento/teste MySQL:discos padrão
Existem vários tipos de discos gerenciados disponíveis por meio do Azure, sendo o padrão os discos padrão. Os discos padrão podem suportar até 500 IOPS (operações de entrada/saída por segundo) e são bons para operações de desenvolvimento e teste, pois podem ser redimensionados dinamicamente, mas não devem ser usados para implantações de produção do MySQL.
Implantações de produção do MySQL:discos premium
Para seus servidores de produção MySQL, é altamente recomendável aproveitar os discos premium do Azure. Há uma grande variedade de discos premium que você pode escolher. Para cada disco premium, você pode escolher o melhor tamanho, e cada tamanho vem com diferentes IOPS provisionadas para que você possa selecionar o que melhor atende às necessidades do seu aplicativo.
Implantações de produção do MySQL:SSD local
Os SSDs locais do Azure são uma alternativa de alto desempenho para discos premium, normalmente mais adequados para clusters grandes. Os SSDs locais fornecem um desempenho de E/S muito maior e a melhor taxa de transferência no Azure. Mas eles têm uma desvantagem, pois são discos efêmeros, não um armazenamento permanente; portanto, se você interromper a instância, os dados desaparecerão. Recomendamos a série Ls v2 que é muito rápida, mas cuidado que a CPU é muito fraca o que pode causar gargalos na máquina.
Backups do MySQL no Azure
A melhor maneira de fazer backup de seus dados MySQL no Azure é usando instantâneos de disco gerenciados. Um instantâneo é uma versão pontual somente leitura de um disco. Esses backups podem ser lidos, copiados ou excluídos, mas observe que eles não podem ser modificados. É uma boa ideia fazer backups completos para que todos os seus bancos de dados, usuários e configurações sejam copiados na instância caso você precise recuperar um banco de dados MySQL. Também é uma boa ideia criptografar seus instantâneos de backup para que o backup só possa ser restaurado na máquina em que o backup foi feito.
Seus backups do MySQL resultarão em cobranças adicionais de armazenamento de dados do Azure, a menos que você esteja aproveitando uma solução completa do MySQL no Azure, como nossos planos de hospedagem dedicada no ScaleGrid. Para controlar os custos, é uma boa ideia automatizar seus backups por meio de uma programação personalizável que permite configurar a frequência dos backups, o número máximo de backups a serem retidos e seu destino de backup. Obviamente, isso também ajuda a garantir que seus dados MySQL sejam regularmente copiados em caso de perda de dados em sua implantação de produção, para que você possa recuperar rapidamente com um backup recente.
Se você tiver alguma dúvida sobre a melhor maneira de hospedar o MySQL no Azure, deixe um comentário abaixo ou entre em contato conosco em support@scalegrid. io. Você também pode iniciar uma avaliação gratuita de 30 dias para explorar as vantagens de aproveitar um serviço MySQL totalmente gerenciado para melhorar o desempenho de suas implantações.
