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 con fallos y reconstruir la base de datos de Cassandra

Colaboradores
PDF

Debe ejecutar una secuencia de comandos que reformatea y remonta el almacenamiento en volúmenes de almacenamiento con fallos y reconstruye la base de datos Cassandra en el nodo de almacenamiento si el sistema determina que es necesario.

Antes de empezar

  • Usted tiene la Passwords.txt archivo.

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

  • Se ha identificado la causa del fallo y, si es necesario, ya se ha adquirido un hardware de almacenamiento de reemplazo.

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

  • Comprobó que un decomisionado del nodo de almacenamiento no está en curso o que ha pausado el procedimiento para decomisionar el nodo. (En Grid Manager, seleccione MANTENIMIENTO > tareas > misión.)

  • Ha comprobado que una expansión no está en curso. (En Grid Manager, seleccione MANTENIMIENTO > tareas > expansión.)

  • Ya tienes "se revisaron las advertencias sobre la recuperación del volumen de almacenamiento".

Pasos

  1. Según sea necesario, reemplace el almacenamiento físico o virtual con errores asociado a los volúmenes de almacenamiento con errores que ha identificado y desmontado anteriormente.

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

  2. En Grid Manager, vaya a NODES > appliance Storage Node > Hardware. En la sección StorageGRID Appliance de la página, compruebe que el modo RAID de almacenamiento esté en buen estado.

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

    1. Introduzca el siguiente comando: ssh admin@grid_node_IP

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

    3. Introduzca el siguiente comando para cambiar a la raíz: su -

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

      Cuando ha iniciado sesión como root, el símbolo del sistema cambia de $ para #.

  4. Utilice un editor de texto (vi o vim) para eliminar los volúmenes con errores del /etc/fstab y, a continuación, guarde el archivo.

    Nota Comentando un volumen fallido en el /etc/fstab el archivo no es suficiente. Debe eliminarse el volumen de fstab a medida que el proceso de recuperación verifica que todas las líneas del fstab el archivo coincide con los sistemas de archivos montados.

  5. Vuelva a formatear los volúmenes de almacenamiento con fallos y vuelva a generar la base de datos de Cassandra si es necesario. Introduzca: reformat_storage_block_devices.rb

    • Cuando se desmonta el volumen de almacenamiento 0, las solicitudes y los mensajes indicarán que el servicio Cassandra se está deteniendo.

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

      • Revise las advertencias. Si no se aplica ninguno de ellos, vuelva a generar la base de datos Cassandra. Introduzca: Y

      • Si hay más de un nodo de almacenamiento desconectado o si se ha reconstruido otro nodo de almacenamiento en los últimos 15 días. Introduzca: N

        La secuencia de comandos se cerrará sin reconstruir Cassandra. Póngase en contacto con el soporte técnico.

    • Para cada unidad de configuración del nodo de almacenamiento, cuando se le solicite lo siguiente: Reformat the rangedb drive <name> (device <major number>:<minor number>)? [y/n]?, escriba una de las siguientes respuestas:

      • y para volver a formatear una unidad con errores. De esta forma, se vuelve a formatear el volumen de almacenamiento y se agrega el volumen de almacenamiento reformateado al /etc/fstab archivo.

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

        Nota Al seleccionar n, se sale de la secuencia de comandos. Monte la unidad (si cree que los datos en ella deben conservarse y que la unidad se ha desmontado de error) o quite la unidad. A continuación, ejecute el reformat_storage_block_devices.rb comando de nuevo.
        Nota Algunos procedimientos de recuperación de StorageGRID usan Reaper para gestionar las reparaciones de Cassandra. Las reparaciones se realizan automáticamente tan pronto como se hayan iniciado los servicios relacionados o necesarios. Puede que note un resultado de script que menciona "relativamente" o ""reparación de Cassandra"". Si aparece 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, la unidad /dev/sdf Se debe volver a formatear y Cassandra no tuvo que ser reconstruida:

    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 se reformateen y se vuelvan a montar los volúmenes de almacenamiento y se completen las operaciones de Cassandra necesarias, es posible "Restaurar datos de objetos con Grid Manager".