Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Recuperação de volumes de armazenamento com falha e reconstrução do banco de dados Cassandra

Colaboradores

Você deve executar um script que reformata e remonta o armazenamento em volumes de armazenamento com falha e reconstrói o banco de dados Cassandra no nó de armazenamento se o sistema determinar que é necessário.

  • Tem de ter o Passwords.txt ficheiro.

  • As unidades de sistema no servidor devem estar intactas.

  • A causa da falha deve ter sido identificada e, se necessário, o hardware de armazenamento de substituição já deve ter sido adquirido.

  • O tamanho total do armazenamento de substituição deve ser o mesmo que o original.

  • Você verificou que a desativação de um nó de storage não está em andamento ou interrompeu o procedimento de desativação do nó. (No Gerenciador de Grade, selecione Manutenção tarefas de Manutenção Decommission.)

  • Você verificou que uma expansão não está em andamento. (No Gerenciador de Grade, selecione Manutenção tarefas de manutenção expansão.)

  • Analisou os avisos sobre a recuperação do volume de armazenamento.

    1. Conforme necessário, substitua o armazenamento físico ou virtual com falha associado aos volumes de armazenamento com falha identificados e desmontados anteriormente.

      Depois de substituir o storage, verifique novamente ou reinicialize para ter certeza de que ele é reconhecido pelo sistema operacional, mas não remonte os volumes. O armazenamento é remontado e adicionado em /etc/fstab um passo posterior.

    2. Faça login no nó de storage com falha:

      1. Introduza o seguinte comando: ssh admin@grid_node_IP

      2. Introduza a palavra-passe listada no Passwords.txt ficheiro.

      3. Digite o seguinte comando para mudar para root: su -

      4. Introduza a palavra-passe listada no Passwords.txt ficheiro.

        Quando você estiver conetado como root, o prompt mudará de $ para #.

    3. Use um editor de texto (vi ou vim) para excluir volumes com falha do /etc/fstab arquivo e, em seguida, salve o arquivo.

      Observação Comentar um volume com falha /etc/fstab no arquivo é insuficiente. O volume deve ser excluído fstab, pois o processo de recuperação verifica se todas as linhas no fstab arquivo correspondem aos sistemas de arquivos montados.
    4. Reformate quaisquer volumes de armazenamento com falha e reconstrua o banco de dados Cassandra, se necessário. Introduza: reformat_storage_block_devices.rb

      • Se os serviços de armazenamento estiverem em execução, ser-lhe-á pedido que os pare. Digite: Y

      • Você será solicitado a reconstruir o banco de dados do Cassandra, se necessário.

        • Reveja os avisos. Se nenhum deles se aplicar, reconstrua o banco de dados Cassandra. Digite: Y

        • Se mais de um nó de armazenamento estiver offline ou se outro nó de armazenamento tiver sido reconstruído nos últimos 15 dias. Digite: N

          O script sairá sem reconstruir o Cassandra. Entre em Contato com o suporte técnico.

      • Para cada unidade rangedb no nó de armazenamento, quando for solicitado: Reformat the rangedb drive <name> (device <major number>:<minor number>)? [y/n]?, Insira uma das seguintes respostas:

        • y para reformatar uma unidade com erros. Isso reformata o volume de armazenamento e adiciona o volume de armazenamento reformatado ao /etc/fstab arquivo.

        • n se a unidade não contiver erros e você não quiser reformatá-la.

          Observação Selecionar n sai do script. Monte a unidade (se você acha que os dados na unidade devem ser retidos e a unidade foi desmontada por erro) ou remova a unidade. Em seguida, execute o reformat_storage_block_devices.rb comando novamente.
        Observação Alguns procedimentos de recuperação do StorageGRID usam o Reaper para lidar com reparos do Cassandra. As reparações ocorrem automaticamente assim que os serviços relacionados ou necessários tiverem sido iniciados. Você pode notar saída de script que menciona "reaper" ou "Cassandra repair." se você vir uma mensagem de erro indicando que o reparo falhou, execute o comando indicado na mensagem de erro.

      Na saída de exemplo a seguir, a unidade /dev/sdf deve ser reformatada e o Cassandra não precisa ser reconstruído:

    root@DC1-S1:~ # reformat_storage_block_devices.rb
    Storage services must be stopped before running this script.
    Stop storage services [y/N]? **y**
    Shutting down storage services.
    Storage services stopped.
    Formatting devices that are not in use...
    Skipping in use device /dev/sdc
    Skipping in use device /dev/sdd
    Skipping in use device /dev/sde
    Reformat the rangedb drive /dev/sdf (device 8:64)? [Y/n]? **y**
    Successfully formatted /dev/sdf with UUID c817f87f-f989-4a21-8f03-b6f42180063f
    Skipping in use device /dev/sdg
    All devices processed
    Running: /usr/local/ldr/setup_rangedb.sh 12075630
    Cassandra does not need rebuilding.
    Starting services.
    
    Reformatting done.  Now do manual steps to
    restore copies of data.