depois de um enorme problema de dados do meu provedor no GER, agora sou forçado a lidar com cenários de failover. Mas há algumas perguntas para as quais não consigo encontrar respostas reais. Então espero que alguém possa me ajudar aqui.
Atualmente tenho o server1 executando dois bancos de dados MySQL em contêineres docker separados. Agora eles devem ser replicados em um segundo servidor. Caso o servidor1 falhe, posso mudar para o servidor2 de forma relativamente rápida por meio de um ClusterIP.
Caso seja importante saber: o software que utiliza o banco de dados é um sistema de gerenciamento de competições esportivas que realiza muitas operações de gravação no banco de dados (não testado, mas no total não há operações de gravação e leitura).
As perguntas para mim agora são:
- Qual método de replicação é o mais adequado?
- Pelo que entendi, MASTER <-> MASTER seria o mais apropriado. Mas também li aqui repetidamente que podem surgir problemas.
- Com MASTER <-> SLAVE surge a questão de que o escravo só pode ler. O que acontece se o mestre falhar? O escravo então se torna automaticamente o mestre e também pode escrever?
- Ou um cluster é a melhor solução? No momento só tenho um nó ativo. Outro nó de banco de dados nos EUA poderá ser adicionado no futuro. Mas no momento isso não existe.
Eu realmente aprecio qualquer ajuda, porque preciso de uma solução que funcione rapidamente e esse tópico geral parece ser muito grande e não tão fácil.
Responder1
Você levanta duas questões.
Topologia MySQLEm ordem (de OK a Melhor)
- Primário -> Réplica – Um "failover" pode ser alcançado, mas é necessário esforço manual e, portanto, tempo.
- Primário <=> Primário - É apenas um pouco mais complexo de configurar, ao mesmo tempo que fornece uso "instantâneo" do outro servidor.
- Cluster de pelo menos 3 servidores. Isso automatiza ainda mais o failover. Consulte "InnoDB CLuster" (MySQL 8) ou "Galera" (incluído no MariaDB).
Geografia – Esteja ciente de que até mesmo um data center pode falhar. Por exemplo, quanto, digamos, da Flórida, pode ser desativado por um único furacão?
Esteja ciente do cenário de “cérebro dividido”. É aqui que você tem apenas dois servidores e ambos estão funcionando e bem, mas a rede está inoperante. Eles não podem dizer e você não pode dizer qual é a situação. Se cada um pensar que é o único servidor ativo e continuar recebendo gravações, você acabará em uma bagunça. Então, em vez disso, você deve assumir que todo o sistema está inoperante.
Resumindo - você precisa de pelo menos 3 servidores, fisicamente separados.
Procurador
Ainda há o problemaclientessaber qual parte do sistema de banco de dados está ativa (para leitura e/ou gravação). Quando apenas a "leitura" é importante, muitas topologias com qualquer número de réplicas são suficientes - e fornecem escalabilidade 'ilimitada'. "Escritas" são onde estão os verdadeiros desafios.
Existem vários produtos de terceiros que são bons em perceber que um servidor está inativo e "fazer a coisa certa" ao redirecionar para outro servidor. Pesquise-os.
Codificação
Quando ocorre uma falha, é provável que seu código receba algum tipo de erro. Você deve verificar se há erros, alguns não são auto-reparáveis. E a maioria dos erros de rede leva algum tempo para ser detectada.