Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Restaurez des volumes de stockage défaillants et reconstruisez la base de données Cassandra

Contributeurs
PDF

Vous devez exécuter un script qui reformate et remonte le stockage sur les volumes de stockage défaillants, puis rereconstruit la base de données Cassandra sur le nœud de stockage si le système détermine qu'elle est nécessaire.

  • Vous devez avoir le Passwords.txt fichier.

  • Les lecteurs système du serveur doivent être intacts.

  • La cause de la défaillance doit avoir été identifiée et, si nécessaire, du matériel de stockage de remplacement doit déjà avoir été acquis.

  • La taille totale du stockage de remplacement doit être identique à celle de l'original.

  • Vous avez vérifié qu'une mise hors service du nœud de stockage n'est pas en cours ou que vous avez interrompu la procédure de mise hors service du nœud. (Dans le Gestionnaire de grille, sélectionnez MAINTENANCE tâches mise hors service.)

  • Vous avez vérifié qu'une extension n'est pas en cours. (Dans le Gestionnaire de grille, sélectionnez MAINTENANCE tâches extension.)

  • Vous avez vérifié les avertissements concernant la restauration du volume de stockage.

    1. Si nécessaire, remplacez le stockage physique ou virtuel défectueux associé aux volumes de stockage défectueux que vous avez identifiés et démontés précédemment.

      Après avoir remplacé le stockage, effectuez une nouvelle analyse ou un redémarrage pour vous assurer qu'il est reconnu par le système d'exploitation, mais ne remontez pas les volumes. Le stockage est remonté et ajouté à /etc/fstab dans une étape ultérieure.

    2. Connectez-vous au noeud de stockage défaillant :

      1. Saisissez la commande suivante : ssh admin@grid_node_IP

      2. Entrez le mot de passe indiqué dans le Passwords.txt fichier.

      3. Entrez la commande suivante pour passer à la racine : su -

      4. Entrez le mot de passe indiqué dans le Passwords.txt fichier.

        Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.

    3. Utilisez un éditeur de texte (vi ou vim) pour supprimer les volumes ayant échoué du /etc/fstab puis enregistrez le fichier.

      Remarque Ajout d'un commentaire sur un volume en panne dans le /etc/fstab le fichier est insuffisant. Le volume doit être supprimé de fstab pendant que le processus de récupération vérifie que toutes les lignes de l' fstab les fichiers correspondent aux systèmes de fichiers montés.

    4. Reformatez les volumes de stockage défaillants et reconstruisez la base de données Cassandra si nécessaire. Entrez : reformat_storage_block_devices.rb

      • Si des services de stockage sont en cours d'exécution, vous serez invité à les arrêter. Saisissez : y

      • Si nécessaire, vous serez invité à reconstruire la base de données Cassandra.

        • Examinez les avertissements. Si aucune d'entre elles ne s'applique, reconstruisez la base de données Cassandra. Saisissez : y

        • Si plus d'un nœud de stockage est hors ligne ou si un autre nœud de stockage a été reconstruit au cours des 15 derniers jours. Saisissez : n

          Le script s'quittera sans reconstruire Cassandra. Contactez l'assistance technique.

      • Pour chaque lecteur de rancedb sur le nœud de stockage, lorsque vous êtes invité à : Reformat the rangedb drive <name> (device <major number>:<minor number>)? [y/n]?, entrez l'une des réponses suivantes :

        • y pour reformater un lecteur qui a eu des erreurs. Cette opération reformate le volume de stockage et ajoute le volume de stockage reformaté à la /etc/fstab fichier.

        • n si le lecteur ne contient aucune erreur et que vous ne voulez pas le reformater.

          Remarque La sélection de n ferme le script. Montez le lecteur (si vous pensez que les données du lecteur doivent être conservées et que le lecteur a été démonté par erreur) ou retirez le lecteur. Ensuite, exécutez le reformat_storage_block_devices.rb commande de nouveau.
        Remarque Certaines procédures de restauration StorageGRID utilisent Reaper pour traiter les réparations Cassandra. Les réparations sont effectuées automatiquement dès que les services connexes ou requis ont commencé. Vous remarquerez peut-être des résultats de script mentionnant « couche » ou « réparation Cassandra ». Si un message d'erreur indiquant que la réparation a échoué, exécutez la commande indiquée dans le message d'erreur.

      Dans l'exemple de sortie suivant, le lecteur /dev/sdf Reformaté. Cassandra n'a pas besoin d'être reconstruite :

    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.