Skip to main content
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Recuperar volúmenes de almacenamiento fallidos y reconstruir la base de datos de Cassandra

PDF

Debe ejecutar un script que reformatee y vuelva a montar el almacenamiento en volúmenes de almacenamiento fallidos, y reconstruya la base de datos de Cassandra en el nodo de almacenamiento si el sistema determina que es necesario.

Antes de empezar

  • Tú tienes el Passwords.txt archivo.

  • Las unidades del sistema en el servidor están intactas.

  • Se ha identificado la causa de la falla y, de ser necesario, ya se ha adquirido hardware de almacenamiento de reemplazo.

  • El tamaño total del almacenamiento de reemplazo es el mismo que el original.

  • Ha verificado que no se está realizando un desmantelamiento de un nodo de almacenamiento o ha pausado el procedimiento de desmantelamiento del nodo. (En el Administrador de red, seleccione MANTENIMIENTO > Tareas > Desmantelamiento.)

  • Has comprobado que no hay ninguna expansión en curso. (En el Administrador de cuadrícula, seleccione MANTENIMIENTO > Tareas > Expansión.)

  • Tienes"revisó las advertencias sobre la recuperación del volumen de almacenamiento" .

Pasos

  1. Según sea necesario, reemplace el almacenamiento físico o virtual fallido asociado con los volúmenes de almacenamiento fallidos que identificó y desmontó anteriormente.

    No vuelva a montar los volúmenes en este paso. El almacenamiento se vuelve a montar y se agrega a /etc/fstab en un paso posterior.

  2. En el Administrador de cuadrícula, vaya a NODOS > appliance Storage Node > Hardware. En la sección Dispositivo StorageGRID de la página, verifique que el modo RAID de almacenamiento esté en buen estado.

  3. Inicie sesión en el nodo de almacenamiento fallido:

    1. Introduzca el siguiente comando: ssh admin@grid_node_IP

    2. Introduzca la contraseña que aparece en el Passwords.txt archivo.

    3. Introduzca el siguiente comando para cambiar a root: su -

    4. Introduzca la contraseña que aparece en el Passwords.txt archivo.

      Cuando inicia sesión como root, el mensaje cambia de $ a # .

  4. Utilice un editor de texto (vi o vim) para eliminar los volúmenes fallidos del /etc/fstab archivo y luego guarde el archivo.

    Nota Cómo comentar un volumen fallido en el /etc/fstab El archivo es insuficiente. El volumen debe eliminarse de fstab A medida que el proceso de recuperación verifica que todas las líneas en el fstab El archivo coincide con los sistemas de archivos montados.

  5. Reformatee cualquier volumen de almacenamiento fallido y reconstruya la base de datos de Cassandra si es necesario. Ingresar: reformat_storage_block_devices.rb

    • Cuando se desmonta el volumen de almacenamiento 0, aparecerán avisos y mensajes que indican que se está deteniendo el servicio Cassandra.

    • Se le pedirá que reconstruya la base de datos de Cassandra si es necesario.

      • Revise las advertencias. Si ninguno de ellos aplica, reconstruya la base de datos de Cassandra. Ingresar: y

      • Si más de un nodo de almacenamiento está fuera de línea o si se ha reconstruido otro nodo de almacenamiento en los últimos 15 días. Ingresar: n

        El script saldrá sin reconstruir Cassandra. Póngase en contacto con el soporte técnico.

    • Para cada unidad rangedb en el nodo de almacenamiento, cuando se le pregunte: Reformat the rangedb drive <name> (device <major number>:<minor number>)? [y/n]? , ingrese una de las siguientes respuestas:

      • y para reformatear una unidad que tenía errores. Esto reformatea el volumen de almacenamiento y agrega el volumen de almacenamiento reformateado al /etc/fstab archivo.

      • n si la unidad no contiene errores y no desea formatearla.

        Nota Al seleccionar n se sale del script. Monte la unidad (si cree que los datos de la unidad deben conservarse y la unidad se desmontó por error) o retire la unidad. Luego, ejecute el reformat_storage_block_devices.rb Comando de nuevo.
        Nota Algunos procedimientos de recuperación de StorageGRID utilizan Reaper para manejar las reparaciones de Cassandra. Las reparaciones se producen automáticamente tan pronto como se hayan iniciado los servicios relacionados o requeridos. Es posible que notes que la salida del script menciona "reaper" o "reparación de Cassandra". Si ve un mensaje de error que indica que la reparación ha fallado, ejecute el comando indicado en el mensaje de error.

      En el siguiente ejemplo de salida, la unidad /dev/sdf debe reformatearse y no fue necesario reconstruir Cassandra:

    root@DC1-S1:~ # reformat_storage_block_devices.rb
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 b951bfcb-4804-41ad-b490-805dfd8df16c
All devices processed
Running: /usr/local/ldr/setup_rangedb.sh 12368435
Cassandra does not need rebuilding.
Starting services.
Informing storage services of new volume

Reformatting done.  Now do manual steps to
restore copies of data.

Una vez que los volúmenes de almacenamiento se hayan reformateado y vuelto a montar y se hayan completado las operaciones necesarias de Cassandra, puede"restaurar datos de objetos usando Grid Manager" .