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.

  • Debe tener la Passwords.txt archivo.

  • Las unidades del sistema del servidor deben estar intactas.

  • Hay que identificar la causa del fallo y, en caso necesario, hay que adquirir hardware de almacenamiento de sustitución.

  • El tamaño total del almacenamiento de reemplazo debe ser 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.

    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.

      Una vez que se sustituye el almacenamiento, asegúrese de volver a analizar o reiniciar para asegurarse de que el sistema operativo reconozca, pero no vuelva a montar los volúmenes. El almacenamiento se vuelve a montar y se añade a. /etc/fstab en un paso posterior.

    2. 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 #.

    3. 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.

    4. 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

      • Si los servicios de almacenamiento se están ejecutando, se le solicitará que los detenga. Introduzca: Y

      • 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
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.