Não estou preocupado com a divisão do cérebro, pois a conexão entre os dois servidores é sólida (e porque não tenho uma terceira máquina)
Quero ter alguma replicação MariaDB com failover automático para que, mesmo que um banco de dados morra, ele continue funcionando. Já vi o MaxScale, mas como só tenho duas máquinas, ele teria que rodar na mesma máquina que um dos servidores e se esse servidor morrer, nada funciona. AFAIK, clusters MariaDB Galera se recusarão a permitir que eu execute em apenas dois e tenha failover automático (exigirá quorum). No entanto, talvez eu consiga executar um árbitro em outra máquina ou até mesmo executar outro banco de dados nela, mas seria lento.
Além disso, o back-end é PHP - estou disposto a alterar a configuração do mysqli e tal, mas não sei se ou o que teria que alterar lá.
EDIT: Estou disposto a renunciar ao failover automático, mas o comportamento que eu desejaria seria o seguinte:
Se eu conectar ao Servidor A, ele se conecta ao Banco de Dados A (mestre) e lê/grava normalmente.
Se eu conectar ao Serer B, ele se conectará ao Banco de Dados B (escravo somente leitura) e lerá perfeitamente. Se for necessário escrever, será capaz, mas os enviará para o Banco de Dados A.
Isso seria possível usando MaxScale em ambos os servidores ou algo parecido?
Responder1
Você tem dois nós. Não use nenhum tipo de mestre-mestre, pois é incrivelmente propenso a dividir o cérebro em dois nós (é quase garantido que isso aconteça eventualmente).
Não se pode esperar que esse tipo de aplicativo com estado lide muito bem com uma implantação de cluster de dois nós por si só - será necessária a intervenção do operador ou um CRM para tornar o cluster robusto em caso de falha - que é a razão pela qual é agrupados em primeiro lugar.
Você tem um cluster de dois nós. Você absolutamente deveria estar preocupado com o cérebro dividido, porque essa arquitetura é muito propensa a condições de cérebro dividido. Só porque o link de rede entre nós é sólido hoje não significa que sempre será assim, e este é um dos maiores componentes de risco em um cluster de dois nós. Perder esse link dividirá instantaneamente o cérebro do cluster, a menos queCERCAouQUORUMé estabelecido entre os nós. Esta é uma das maiores considerações em um cluster de dois nós, já que a cerca reduz as chances de condições de cérebro dividido de altas para quase zero.
Eu recomendaria lidar com isso com Pacemaker/Corosync. É uma pilha complicada, mas fornece os mecanismos necessários para gerar um cluster de nível de produção em dois nós. Eu também recomendaria usar apenas uma instância mestre por vez, em vez de vários mestres, mesmo quando sob a aplicação de tal gerenciador de cluster.
Existe um bom guia para HA MariaDB que pode servir como ponto de partida. NÃO cobre o uso de cercas. Se você não conseguir realizar o isolamento, o Corosync também terá a capacidade de usar um pequeno nó arbitrador executando um daemon de votação para fornecer quorum à implementação geral sem nenhum custo adicional do aplicativo (consulte as informações sobre o Corosync qdevice).
Está atrás de um mural de assinaturas, mas é umguia completo sobre como configurar um cluster MySQL ativo-passivo, executando em um nó por vez e replicando o armazenamento em bloco entre nós
Os tipos de recursos avançados do Pacemaker cobrem a maioria das suas questões sobre como orquestrar o failover de maneira elegante, com a capacidade de agrupar recursos em cadeias de dependência lineares, bem como expressar semântica de eleição de líder multiestado para executar mais de uma instância de um aplicativo em nós.Isso pode ser encontrado aqui.
Os pacotes são uma forma de realizar o isolamento de aplicativos no Pacemaker por meio de tempos de execução de contêiner como Docker e RKT. Isso abre outra via de proteção, já que esses pacotes aparecem para o cluster como os próprios nós do Pacemaker - para que possam ser "protegidos" pelo cluster independentemente de outros aplicativos.Isso pode ser encontrado aqui.
Responder2
Executei vários bancos de dados (Mongo, Elasticsearch, SQL Server, outros) com a mesma filosofia "Não me importo com problemas, só posso executar dois nós".
Foi um MUNDO de dor.
Se você executar master-slave, tudo bem. Mas haverá dores de cabeça.
Depois de anos contornando o problema e lidando com várias dores de cabeça de devops criadas pela minha insistência em apenas dois nós (nos quais insisti porque nossos bancos de dados eram muito grandes e o custo de um terceiro nó era significativo), finalmente comecei a executar três nós.
E então tudo melhorou.
A lição que tirei de anos de dança é: Existem duas opções:
- Nó único com ish sobressalente quente (por exemplo, mestre-escravo)
- Três nós
Pela minha experiência, eu nunca executaria dois nós ativo-ativo novamente (a menos que haja uma peça mágica que impeça completamente a divisão do cérebro, o que eu vi e que é muito feio).
De cinco anos executando vários bancos de dados de 0,5 a 1,5 TB em várias pilhas.
Responder3
Uma opção seria executar a replicação mestre-mestre assíncrona com keepalived para fazer failover em um IP flutuante. Não é ótimo, mas cobriria o cenário de falha total do servidor.
Você tem OIT ou alguma outra maneira de fazer com que uma máquina desligue a outra à força (STONITH)? Isto é realmente necessário para evitar falhas parciais, por exemplo, uma máquina trava, mas não completamente, de modo que ainda esteja viva o suficiente para responder aos pacotes de pulsação, mas de outra forma não esteja funcionando. Isso pode fazer com que o failover não ocorra quando deveria.