O recurso de marca-passo mestre / escravo de múltiplos estados do MySQL falha ao iniciar nos nós do cluster

Question

Configuração

Estou configurando um cluster de alta disponibilidade para um aplicativo da web usando dois servidores físicos em um cluster gerenciado do Corosync / Pacemaker.

Após descobrindo que eu estava indo na direção errada , decidi usar o agente de recursos do MySQL do heartbeat para gerenciar minhas instâncias do MySQL em todo o cluster.

Atualmente, existe uma configuração mestre / escravo em funcionamento de node1 (atual mestre ) para node2 (atual escravo ). Agora gostaria que o Pacemaker gerenciasse minhas instâncias do MySQL para que ele possa promover / rebaixar o mestre ou o escravo.

De acordo com esta (antiga) página wiki , eu deveria ser capaz de realizar a configuração por Fazendo isso:

primitive p_mysql ocf:heartbeat:mysql \
  params binary="/usr/sbin/mysqld" \
  op start timeout="120" \
  op stop timeout="120" \
  op promote timeout="120" \
  op demote timeout="120" \
  op monitor role="Master" timeout="30" interval="10" \
  op monitor role="Slave" timeout="30" interval="20"

ms ms_mysql p_mysql \
  meta clone-max=3

Como você pode ver, alterei ligeiramente o intervalo para o segundo parâmetro op monitor , pois sei que o Pacemaker identifica as ações por Nome do recurso (aqui, p_mysql ), nome da ação e intervalo. O intervalo era a única maneira de diferenciar a ação do monitor em um nó escravo da ação do monitor em um nó mestre.

Problema

Depois de confirmar as alterações no CID e abrir um crm_mon interativo, percebi que o Pacemaker não conseguiu iniciar o recurso em todos os nós. Veja capturas de tela anexadas:

Sorry cannot upload more than 2 links because I do not have enough reputation yet... Screenshots in comments

E ele faz um loop repetidamente, tentando definir o mestre atual para um escravo, o escravo atual para um escravo, depois para um mestre ... Ele está claramente em loop e não instancia corretamente instâncias do MySQL.

Para referência, meu crm configure show :

node 1: primary
node 2: secondary
primitive Failover ocf:onlinenet:failover \
    params api_token=108efe5ee771368557869c7a837361a7c786f210 failover_ip=212.129.48.135
primitive WebServer apache \
    params configfile="/etc/apache2/apache2.conf" statusurl="http://127.0.0.1/server-status" \
    op monitor interval=40s \
    op start timeout=40s interval=0 \
    op stop timeout=60s interval=0
primitive p_mysql mysql \
    params binary="/usr/sbin/mysqld" \
    op start timeout=120 interval=0 \
    op stop timeout=120 interval=0 \
    op promote timeout=120 interval=0 \
    op demote timeout=120 interval=0 \
    op monitor role=Master timeout=30 interval=10 \
    op monitor role=Slave timeout=30 interval=20
ms ms_mysql p_mysql \
    meta clone-max=3
clone WebServer-clone WebServer
colocation Failover-WebServer inf: Failover WebServer-clone
property cib-bootstrap-options: \
    dc-version=1.1.12-561c4cf \
    cluster-infrastructure=corosync \
    cluster-name=ascluster \
    stonith-enabled=false \
    no-quorum-policy=ignore

    

Answer 1

Solução

Graças às pessoas que investigaram comigo, consegui encontrar a solução para o meu problema e agora tenho uma configuração de trabalho. Se você se sentir corajoso o suficiente, você pode ler os comentários sobre a pergunta original, mas aqui está um resumo dos passos que me ajudaram a resolver o meu problema.

Leia a fonte

A primeira coisa a fazer ao configurar recursos de alta disponibilidade será o típico, mas RTFM . Não a sério, saiba como funciona o software que você está planejando usar. Nesse caso em particular, meu primeiro erro foi não ler e compreender cuidadosamente como funciona o agente de recursos (RA). Como eu estava usando o mysql RA fornecido por Heartbeat , o script de origem do RA estava disponível em Repo GitHub dos agentes de recursos do ClusterLabs .

Do not forget to read the source of included files!

Verifique se o seu software está atualizado

Não foi claramente identificado como um problema em meu caso específico, mas como @gf_ & @remote mind sugerido, é sempre bom ter uma versão do RA que funcione com a versão do software .

Preencha o maldito params

Number one rule in HA: do not rely on default values.

Isso não é verdade, às vezes você pode, mas honestamente, se eu tivesse fornecido todos os parâmetros opcionais que eu pudesse para o RA, eu teria corrigido meu problema muito mais rápido .

Este é o lugar onde a parte Leia a fonte é importante, pois permitirá que você realmente entenda porque existem parâmetros necessários. No entanto, como elas geralmente são descritas resumidamente, talvez seja necessário ir além do meta-data e descobrir onde estão os parâmetros usados. No meu caso, a coisa não funcionou por várias razões:

• Eu não forneci o caminho do soquete e o padrão para o script não corresponde ao padrão para o meu sistema (Debian 8).
• Eu não forneci test_user , test_passwd : estes estavam presentes no meta-data , mas achei que não precisava disso. Depois que decidi procurar o que era usado, descobri que esses parâmetros eram usados para executar um simples select count(*) no banco de dados. E como os padrões estão definidos para usar o usuário root sem senha, ele não funcionou no meu caso (porque nos meus bancos de dados, root precisa de uma senha para conectar o banco de dados). Esse passo em particular impedia que o RA executasse a verificação se o nó atual era escravo ou não.
• Alguns outros parâmetros também estavam faltando, e eu sabia que precisava deles apenas depois de descobrir onde as configurações padrão estavam escondidas .

Palavra final

Mais uma vez, muito obrigado a @gf_ por reservar um tempo para investigar comigo e fornecer leads para depurar minha configuração.

Boas configurações de HA não são tão fáceis de alcançar (especialmente ao começar do zero), mas se bem configuradas podem ser realmente poderosas e proporcionam paz de espírito.

Note: peace of mind not guaranteed ;)