Atualmente, temos um único servidor MySQL 8 rodando em Oracle Linux. Ele roda em uma VM em um data center gerenciado no Texas.
Cerca de 95% do seu tempo é gasto em operações SELECT e cerca de 5% em INSERT e UPDATE.
Estamos trabalhando para adicionar outro servidor MySQL em um local separado (MO), principalmente para fins de redundância e recuperação de desastres.
Minha ideia é criar um túnel entre os dois locais e configurar a replicação do MySQL usando o local principal como mestre. Dessa forma, se ocorrer um desastre, eu poderia alternar as coisas para apontar para o servidor escravo. Uma desvantagem é que esse servidor escravo dedicado ficará parado, potencialmente sem trazer nenhum benefício, a menos que algo ruim aconteça.
Eu estava pensando em maneiras de utilizá-lo e talvez atualizar meu aplicativo para usar o servidor escravo para algumas das consultas/relatórios pesados.
Achei que era um ótimo plano até começar a ler sobre clustering MySQL. Na verdade, não temos condições de ter um terceiro servidor MySQL dedicado para configurar um cluster.
Minhas perguntas são:
Supondo que você tivesse 2 nós MySQL, em 2 locais, como você os utilizaria melhor?
Nossos servidores de aplicação executam tudo em contêineres Docker. Seria uma ideia maluca adicionar uma instância do MySQL (em um contêiner Docker) aos servidores de aplicação para construir um cluster MySQL em vez da replicação?
Se um cluster fosse realmente uma possibilidade (por meio de instâncias MySQL nos servidores de aplicação), meu entendimento é que as gravações podem ser potencialmente mais lentas, já que a gravação não é concluída até que todos os nós do cluster tenham escrito. Isso significa que ter os nós do cluster em vários locais pode realmente tornar as gravações significativamente mais lentas, já que haverá um pouco de latência entre os dois sites?
Qualquer conselho aqui é bem-vindo.
Eu usaria uma VPN.
Um túnel (com o qual presumo que você queira dizer
ssh -L) só funciona ponto a ponto e para apenas uma porta.Os túneis SSH também precisam ser executados em um host, então eles caem se o host for reinicializado ou se o processo for interrompido.
Eu sei que você disse que seu orçamento é limitado, mas usar um túnel SSH obriga você a trabalhar mais do que provavelmente espera para monitorar e reiniciar esse túnel.
Sim, essa é a ideia. Pode parecer caro fornecer recuperação de desastres. Você precisa de uma infraestrutura redundante, pronta para assumir todo o seu tráfego caso o site principal esteja indisponível.
Claro, mas lembre-se de que se seus aplicativos rodam no Texas e o servidor de réplica roda no Missouri, há uma latência de rede inevitável entre eles. O tempo de ping entre Austin, Texas, e Kansas City, Missouri, deve ser inferior a 25 ms. Isso pode não parecer alto, mas é muito maior do que a latência de <1 ms entre seu aplicativo e o banco de dados de origem na rede local.
A latência é aplicada a cada pacote enviado entre o seu aplicativo e o servidor de banco de dados réplica. Como uma consulta SQL típica envolve muitas comunicações de ida e volta entre o aplicativo e o banco de dados, e seu aplicativo pode executar várias consultas para um determinado relatório, isso pode se acumular.
Sugiro que você faça alguns experimentos de temporização para testar se seus relatórios parecem muito lentos quando você os executa em uma WAN.
Em um dos meus empregos anteriores, tínhamos um link WAN mais longo entre data centers: entre a região do Vale do Silício e a Carolina do Norte. O tempo de ping era superior a 60 ms. Às vezes, algum desenvolvedor reclamava "o banco de dados está lento!" e descobria que havia feito um failover acidentalmente no banco de dados ou nos aplicativos, mas não em ambos. Depois que eles se certificaram de que o banco de dados ativo e o aplicativo ativo estavam no mesmo data center, o problema de desempenho foi resolvido.
Outra consideração: se o seu aplicativo depende de consultas/relatórios pesados em execução no banco de dados réplica no MO, o que acontece quando ocorre um evento de recuperação de desastre e todas as consultas precisam ser executadas repentinamente no banco de dados no MO? Esse banco de dados consegue lidar com a carga de todas as consultas? É possível desativar temporariamente os relatórios?
Imagino que você esteja falando do InnoDB Cluster. Não é loucura, mas é preciso considerar o cenário de falha. Se o seu datacenter principal cair, incluindo os servidores de aplicativos, o que acontece com o seu cluster de banco de dados?
(Se você se refere ao MySQL NDB Cluster, então eu diria que não, não faça isso por uma WAN. O NDB Cluster é uma solução para HA, mas não entre data centers. Os nós de um NDB Cluster precisam estar colocalizados na mesma rede de baixa latência.)
Isso é configurável, pois seu aplicativo pode ter requisitos de consistência diferentes dos aplicativos de outra pessoa. Leia https://dev.mysql.com/doc/refman/8.4/en/group-replication-configuring-consistency-guarantees.html para obter detalhes.
Mas sim, como a latência da WAN é naturalmente maior que a latência da rede local, ela certamente adicionará alguma sobrecarga às gravações, não importa o nível de consistência escolhido.
Naquela tarefa com a replicação entre os EUA, não utilizamos o InnoDB Cluster. Usamos a replicação tradicional do MySQL, utilizando GUIDs e replicação baseada em ROW. Esta é uma replicação assíncrona, portanto, as gravações no banco de dados local são rápidas do ponto de vista dos aplicativos locais. O site da réplica é atualizado por meio de logs binários, que são baixados de forma assíncrona.
Os sites eram vinculados por uma VPN, o que era muito mais simples do que usar um túnel para cada conjunto de réplicas do MySQL (operávamos mais de 10.000 instâncias do MySQL em contêineres Docker).
As instâncias inativas do MySQL no datacenter de failover estavam quase totalmente inutilizadas pelos aplicativos no dia a dia. Os desenvolvedores podiam se conectar à instância inativa caso precisassem prototipar uma consulta de leitura ou inspecionar dados, mas a latência era alta o suficiente para que os aplicativos não pudessem executar consultas entre datacenters.
Eventos de failover em que um data center inteiro caiu eram raros. Lembro-me de que isso aconteceu duas vezes enquanto trabalhei naquela empresa por mais de 4,5 anos. É uma falha de alto impacto, é claro, e ter a capacidade de transferir tudo para o outro lado foi bom para o negócio.
Mas, para ser sincero, como o data center principal voltou a funcionar em menos de 24 horas, pode-se argumentar que é uma questão de bom senso para uma determinada empresa se ela prefere arcar com o custo de 24 horas de inatividade a cada 2 anos (em média) em vez do custo de gerenciar um site redundante de recuperação de desastres o tempo todo. Qualquer uma das respostas pode estar correta, depende das necessidades da empresa.