Simular perda de potência com força desmontar?

1

Eu quero testar a recuperação de desastre dos RDBMs após a perda de energia com carga alta.

Minha idéia é montar o diretório de dados sob o novo ponto de montagem e, em seguida, executar umount -f durante o carregamento e investigar o resultado / estado dos arquivos.

Minha expectativa é que, com configurações não duráveis, os dados sejam inconsistentes e consistentes, de outra forma.

Alguém acha que é uma boa ideia e talvez outras dicas relacionadas (por exemplo, qual sistema de arquivos é melhor usar ou minha expectativa é irrelevante, então por que)?

    
por noonex 24.10.2017 / 05:35

1 resposta

1

Presumivelmente você está realmente removendo o poder. umount -f não é quase indelicado o suficiente para simular muitas falhas.

No Linux, umount (2) explica que a força é suportada apenas para sistemas de arquivos em rede.

   MNT_FORCE (since Linux 2.1.116)
          Ask the filesystem to abort pending requests before attempting
          the unmount.  This may allow the unmount to complete without
          waiting for an inaccessible server, but could cause data loss.
          If, after aborting requests, some processes still have active
          references to the filesystem, the unmount will still fail.  As
          at Linux 4.12, MNT_FORCE is supported only on the following
          filesystems: 9p (since Linux 2.6.16), ceph (since Linux
          2.6.34), cifs (since Linux 2.6.12), fuse (since Linux 2.6.16),
          lustre (since Linux 3.11), and NFS (since Linux 2.1.116).

Aqui estão mais algumas ideias sobre como fazer coisas muito desagradáveis em um sistema de banco de dados:

  • Desconecte fisicamente todas as fontes de alimentação do host. Quaisquer processos e a memória compartilhada desaparecerá de maneira muito desagradável.

  • Confirme o armazenamento com provisionamento thin e execute-o em 100%. Mesmo se o armazenamento fizesse algo sensato nesse cenário, o SGBD pode ser infeliz se seus volumes foram lidos apenas no meio de um escreva.

  • Desconecte todos os caminhos da SAN, para simular que "não perturba" manutenção de armazenamento que não é.

  • Encontre um processo que escreve e envie um sinal SIGKILL ou equivalente.

  • Bater o sistema operacional. Por exemplo, no Linux echo 'c' > /proc/sysrq-trigger

O estado dos dados restantes após o teste depende do armazenamento e do DBMS. Qualquer um poderia ter um diário que pudessem reproduzir, ou talvez não tivessem. Você provavelmente quer fazer um fsck ou equivalente no sistema de arquivos. Se o banco de dados puder se recuperar para um ponto consistente no tempo, de logs ou qualquer outro, você pode querer fazer isso. Se você tiver um verificador de integridade para o DBMS, use-o como uma verificação de integridade.

Espero que você já tenha feito um teste de restauração de seu backup apenas por precaução. Não assuma só porque algo exige recuperação de falhas, que funciona em todas as situações.

    
por 24.10.2017 / 08:12