Recuperar volúmenes de almacenamiento con fallos y reconstruir la base de datos de Cassandra
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.
- 
Usted tiene la Passwords.txtarchivo.
- 
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". 
- 
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/fstaben un paso posterior.
- 
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.
- 
Inicie sesión en el nodo de almacenamiento con errores: - 
Introduzca el siguiente comando: ssh admin@grid_node_IP
- 
Introduzca la contraseña que aparece en Passwords.txtarchivo.
- 
Introduzca el siguiente comando para cambiar a la raíz: su -
- 
Introduzca la contraseña que aparece en Passwords.txtarchivo.Cuando ha iniciado sesión como root, el símbolo del sistema cambia de $para#.
 
- 
- 
Utilice un editor de texto (vi o vim) para eliminar los volúmenes con errores del /etc/fstaby, a continuación, guarde el archivo.Comentando un volumen fallido en el /etc/fstabel archivo no es suficiente. Debe eliminarse el volumen defstaba medida que el proceso de recuperación verifica que todas las líneas delfstabel archivo coincide con los sistemas de archivos montados.
- 
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/fstabarchivo.
- 
n si la unidad no contiene errores, y no desea volver a formatearla. 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.rbcomando de nuevo.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. Es posible que note la salida de un script que menciona “reaper” o “Cassandra repair”. 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, la unidad /dev/sdfSe 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".
 PDF
PDF