Perda de dados devido ao script de failover do MySQL DRBD Heartbeat

4

Usando a versão DRBD: 8.2.6 (api: 88 / proto: 86-88)

Aqui está o conteúdo de /etc/ha.d/haresources

    db1     192.168.100.200/24/eth0 drbddisk::mysql Filesystem::/dev/drbd0::/drbd::ext3::defaults mysql

e /etc/ha.d/ha.cf

    logfile        /var/log/ha-log
    logfacility     local0
    keepalive 1
    deadtime 30
    warntime 10
    initdead 120
    udpport        694
    bcast  eth0, eth4  
    auto_failback off
    node    db1
    node    db2
    respawn hacluster /usr/lib64/heartbeat/ipfail
    apiauth ipfail gid=haclient uid=hacluster
    deadping 5

Ao testar o failover entre máquinas, executei os seguintes comandos no db2:

    service heartbeat stop
    service mysqld stop
    drbdadm down mysql
    service drbd stop

/ proc / drbd no db1 relatado

     0: cs:Connected st:Primary/Unknown ds:UpToDate/DUnknown C r---

O que aconteceu depois, depois:

  • Colocando os serviços online novamente no db2
  • Transferindo o primário para o db2 usando o script hb_primary
  • Tomando o db1 como acima
  • Colocando os serviços online novamente no db1
  • Transferindo o primário de volta para o db1 usando o script hb_primary

foi o db1 remontado no disco DRBD, assumiu o IP correto e iniciou o MySQL. Houve corrupção maciça na tabela MySQL; era tudo consertável (usando o modo de recuperação do InnoDB 6, mysqlcheck e o backup ocasional), mas como isso aconteceu?

Eu especulo:

  1. O DRBD desconectou o disco do sistema de arquivos enquanto estava sendo usado pelo MySQL, já que um desligamento limpo do MySQL não resultaria em dados corrompidos
  2. DRBD controlado por pulsação e parando o serviço de pulsação "puxou o plugue" no DRBD
  3. isso pode acontecer novamente no caso de um failover real (devido ao tempo limite do ping de pulsação)

Eu não tenho acesso a essa configuração novamente por algum tempo e gostaria de repetir o teste.

As configurações estão corretas?

A corrupção foi o resultado do meu teste manual?

Existe uma maneira melhor de testar o failover do que parar o serviço de heartbeat e permitir que ele execute os comandos haresources?

    
por Andy 02.06.2009 / 14:49

3 respostas

2

Isso provavelmente não é uma grande ajuda, mas isso tem sido discutido extensivamente ultimamente no Marcapasso e < href="http://lists.linux-ha.org/pipermail/linux-ha/"> listas de discussão do Linux-HA .

Eu não sou muito bom com o heartbeat, mas com o pacemaker eu criaria uma restrição que fazia com que o gerenciador de recursos do cluster esvaziasse discos com um bloqueio de gravação no disco (ou baixasse o mysql temporariamente) antes de tentar mudar. depois liberar a trava assim que a chave fosse completada.

    
por 04.06.2009 / 16:30
2

De tudo que li e da minha experiência limitada com pulsação, tudo o que você precisa fazer para fazer o failover manualmente de um servidor para outro é emitir o

service heartbeat stop
comando

. Tudo o que está no seu arquivo de origem é controlado por pulsação. Caso em questão, eu tenho um cluster que estou configurando que precisa executar os seguintes serviços:

snmpd
mysql

Aqui está a configuração de haresources

localhost00 \
drbddisk::home \
Filesystem::/dev/drbd0::/opt/local::ext3::defaults \
drbddisk::perf \
Filesystem::/dev/drbd1::/opt/local/perf::ext3::noatime,data=writeback \
IPaddr::1.1.1.1/24 \
mysqld \
snmpd 

e aqui estão os resultados que obtenho (minhas desculpas se for uma bagunça, não consigo quebras de linha no ponto certo):

[root@localhost00 ~]# service snmpd status
snmpd (pid 18558) is running...
[root@localhost00 ~]# service mysqld status
mysqld (pid 18509) is running...
[root@localhost00 ~]# service drbd status
drbd driver loaded OK; device status:
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:17
m:res      cs         st                 ds                 p  mounted           fstype
0:home  Connected  Primary/Secondary  UpToDate/UpToDate  C  /opt/local       ext3
1:perf  Connected  Primary/Secondary  UpToDate/UpToDate  C  /opt/local/perf  ext3
[root@localhost00 ~]# service heartbeat stop
Stopping High-Availability services:
                                                           [  OK  ]
[root@localhost00 ~]# service snmpd status
snmpd is stopped
[root@localhost00 ~]# service mysqld status
mysqld is stopped
[root@localhost00 ~]# service drbd status
drbd driver loaded OK; device status:
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:17
m:res      cs         st                   ds                 p  mounted  fstype
0:home  Connected  Secondary/Secondary  UpToDate/UpToDate  C
1:perf  Connected  Secondary/Secondary  UpToDate/UpToDate  C
[root@localhost00 ~]#
[root@zenoss00 ~]# service heartbeat start
Starting High-Availability services:
                                                           [  OK  ]
[root@zenoss00 ~]# service snmpd status
snmpd is stopped
[root@zenoss00 ~]# service mysqld status
mysqld is stopped
[root@zenoss00 ~]# service drbd status
drbd driver loaded OK; device status:
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-bu
m:res      cs         st                   ds                 p  mounted  fstype
0:zenhome  Connected  Secondary/Secondary  UpToDate/UpToDate  C
1:zenperf  Connected  Secondary/Secondary  UpToDate/UpToDate  C
[root@zenoss00 ~]# service snmpd status
snmpd (pid 23055) is running...
[root@zenoss00 ~]# service mysqld status
mysqld (pid 23006) is running...
[root@zenoss00 ~]# service drbd status
drbd driver loaded OK; device status:
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:17
m:res      cs         st                 ds                 p  mounted           fstype
0:zenhome  Connected  Primary/Secondary  UpToDate/UpToDate  C  /opt/zenoss       ext3
1:zenperf  Connected  Primary/Secondary  UpToDate/UpToDate  C  /opt/zenoss/perf  ext3
[root@zenoss00 ~]#

observe que parar a pulsação parou todos os serviços designados ao heartbeat (mysqld, snmpd); Observe também que o drbd ainda está em execução e o heartbeat NÃO o interrompeu. O DRBD precisa estar em execução o tempo todo para que o failover funcione.

Teste seu failover novamente, mas não execute os comandos drbd, e acho que você evitará a corrupção de dados.

    
por 24.07.2009 / 06:26
0

A maneira de testar o heartbeat seria que você emitirá uma parada de heartbeat de serviço em uma máquina e fará o failover para a outra máquina e automaticamente chamará todos os serviços no outro nó, e você também não desejará ativar os serviços drbd .

A outra maneira de testar é fazer um hard reboot em uma máquina.

    
por 02.06.2009 / 20:15