Paquete de parche para FusionInsight falla al cargarse Resaltado

Pubilicado 2019-4-25 15:21:16 32 0 0 0

A continuación se describe y analizan los pasos a seguir cuando se presenta un problema durante la carga del paquete de parche para actualizar FusionInsight versión FusionInsightV100R002C60U10



Descripción del problema


Cuando el parche SPC002 está instalado en FusionInsightV100R002C60U10, el progreso de carga del parche se bloquea en el 94%. Como resultado, el parche no se puede cargar. El archivo de parche se ha cargado correctamente en el nodo activo, pero la sincronización en el nodo en espera falla.

 

Análisis del problema

 

1. Analizar los requisitos previos de problemas.

El archivo / srv / BigData / LocalBackup en el directorio de copia de seguridad se eliminó del nodo activo (11). La configuración del directorio de sincronización fue la siguiente:

<file name="/srv/BigData/LocalBackup" auto="no" delete="no"/>-------: indica que cuando se eliminó el nodo activo, el nodo en espera no se eliminó de forma síncrona y fue necesario para ser eliminado manualmente.

La siguiente figura muestra los registros del nodo 12 (nodo en espera).

 

download?uuid=81b9ac78aede48c1be1b2839fa


2. Analizar el proceso de actualización.

 

El archivo de configuración de HA correspondiente no se modificó cuando se modificó la dirección IP de la versión anterior. Como resultado, la HA del nodo 12 no se pudo iniciar después de la actualización.

Durante este período, el nodo 12 no pudo iniciarse. Como resultado, el contenido del directorio de copia de seguridad / srv / BigData / LocalBackup en los nodos activos y en espera fue incoherente.

 

3. Analizar el proceso de parche.

 

Después de la actualización, el nodo 12 se convirtió en el nodo activo. Después de reiniciar el nodo 12, la sincronización completa de archivos se activó de inmediato. Todos los archivos fueron sincronizados. El registro en el nodo en espera (11) del sistema HA registró los registros de sincronización de archivos (de 13:45:55 a 15:18:58).

 

El directorio de respaldo del nodo activo (12) se sincronizó y se registró en el registro, como se muestra a continuación:

 

Todos los archivos anteriores fueron sincronizados. A las 15:18:58, la sincronización se interrumpió porque se reinició el nodo 11 (nodo en espera). Los registros de operaciones indican que el nodo se reinicia manualmente. La siguiente figura muestra los registros detallados.


 download?uuid=b7d1372ecb2840abb4182b0831

 

4. Después de que se inició el nodo 11, los nodos activos y en espera se recuperaron.

 

El sistema activó automáticamente la sincronización completa de archivos y retransmitió la última sincronización de archivos. El período de sincronización fue de 15:22:11 a 16:48:23.

 

A las 16:48:23, el nodo 11 todavía estaba descargando archivos en el directorio de respaldo durante la sincronización de archivos.

 

La siguiente figura muestra los registros de registro.

  download?uuid=077891c358d746ab8570fc870b


 Causa principal


El parche se carga a las 15:27:30. En este momento, todos los archivos se sincronizan entre los nodos activos y en espera, y la sincronización del archivo de parche no se inicia. Como resultado, el parche de carga se agota.

 

 download?uuid=bb8bef9a0a084acd8e0aa9570e


 Solución


Medidas preventivas

 

1. Solución para el problema de que el directorio de copia de seguridad en los nodos OMS activos / en espera está lleno.

 

1. Inicie sesión en el nodo OMS activo.

 

2. Abra el archivo.

/opt/huawei/Bigdata/OMSV100R001C00x8664/workspace/ha/module/hasync/plugin/conf/filesync.xml

 

3. Elimine el parámetro delete = "no" de los elementos de configuración /srv/BigData/LocalBackup, /opt /huawei/Bigdata/LocalBackup, y /srv/BigData/Manager/bak. El contenido modificado se muestra en la Figura 1.

 

Figura 1 Contenidos modificados en el archivo de configuración de sincronización de la OMS.


download?uuid=15dff3f7a972490390432d8b9b

download?uuid=ddd875e8779f4c0985a329dd3e


4. Ejecute el comando "ps -ef | grep ha.bin | grep OMS" para consultar el PID del proceso HA. Ejecute el comando kill -9 <hapid> para detener el proceso de alta disponibilidad. En el comando, <hapid> indica el valor de la segunda columna en la salida del comando ps.

 

5. Unos dos minutos después, ejecute el comando ps -ef | grep ha.bin | grep OMS nuevamente para verificar si el proceso HA se ha iniciado.

 

6. Inicie sesión en el nodo OMS en espera y compruebe si el contenido del paso 3 se modifica en el archivo /opt/huawei/Bigdata/OMSV100R001C00x8664/workspace/ha/module/hasync/plugin/conf/filesync.xml. Si el contenido no está sincronizado, elimínelo manualmente.

 

7. Repita los pasos 4 y 5 en el nodo OMS en espera. Reinicie el proceso de alta disponibilidad.

 

8. Inicie sesión en el nodo OMS activo, cambie a user omm y ejecute el comando /opt/huawei/Bigdata/ OMSV100R001C00x8664/workspace/ha/module/hacom/tools/ha_client_tool -- syncallfile para sincronizar todos los archivos.

 

9. Una vez completada la sincronización completa, espere unos dos minutos y compruebe si los archivos redundantes en los directorios anteriores se eliminan del nodo OMS en espera.

 

2. Solución para el problema de que el directorio de copia de seguridad en los nodos DBServer activos / en espera está lleno.

 

1. Inicie sesión en el nodo DBServer activo.

 

2. Abra el archivo siguiente /opt/huawei/Bigdata/FusionInsight/dbservice/setup/conf/ha_plugin/ha_sync_conf/dbservice_sync.xml. Elimine el parámetro delete = "no" del elemento de configuración #DBSERVICE_INSTALL_HOME#/bak. El contenido modificado se muestra en la Figura 2.

 

Figura 2 Contenidos modificados en el archivo de configuración inicial del servicio DBS.

download?uuid=e9097775bac249cba0d3be0a09

 

 

3. Abra el archivo /opt/huawei/Bigdata/FusionInsight/dbservice/ha/module/hasync/ plugin/conf/dbservice_sync.xml

 

4. Elimine el parámetro delete = "no" del elemento de configuración /opt/huawei/Bigdata/ FusionInsight_V100R002C60XXX/dbservice/bak. Para detalles sobre los contenidos modificados, vea la Figura 3. XXX varía según la versión específica.

 

Figura 3 Contenidos modificados en el archivo de configuración de sincronización del DBService

download?uuid=e1026f91227b4ebeac8b1e14f7


 

5. Ejecuta el ps -ef | grep ha.bin | grep dbservice comando para consultar el PID del proceso HA. Ejecute el comando kill -9 <hapid> para detener el proceso de alta disponibilidad. En el comando, <hapid> indica el valor de la segunda columna en la salida del comando ps.

 

6. Espere unos 2 minutos y ejecute el comando ps -ef | grep ha.bin | grep dbservice de nuevo para verificar si el proceso HA se ha iniciado.

 

7. Inicie sesión en el nodo DBServer en espera y compruebe si el contenido del paso 3 se modifica en el archivo /opt/huawei/Bigdata/FusionInsight/dbservice/ha/module/hasync/plugin/conf/dbservice_sync.xml. Si el contenido no está sincronizado, elimínelo manualmente.

 

8. Repita los pasos 4 y 5 en el nodo DBServer en espera para reiniciar el proceso de alta disponibilidad.

 

9. Inicie sesión en el nodo DBServer activo, cambie a user omm y ejecute el comando /opt/huawei/ Bigdata/FusionInsight/dbservice/ha/module/hacom/tools/ha_client_tool --syncallfile para realizar la sincronización completa de los archivos HA.

 

Una vez completada la sincronización completa, espere unos dos minutos y compruebe si los archivos redundantes en los directorios anteriores se eliminan del nodo DBServer en espera.

 

Compruebe si los archivos en el directorio de copia de seguridad / srv / BigData / LocalBackup en los nodos OMS activos y en espera son consistentes. Si los archivos son inconsistentes, haga una copia de seguridad de los archivos en el directorio de respaldo en otros discos y elimine los archivos de los directorios en los nodos activos y en espera.

 

Compruebe si los archivos en / opt / huawei / Bigdata / FusionInsight / dbservice / bak en los nodos DBService activos y en espera son coherentes. Si los archivos son inconsistentes, haga una copia de seguridad de los archivos en el directorio de respaldo en otros discos y elimine los archivos de los directorios en los nodos activos y en espera.

 

El problema de que la cantidad de archivos en el directorio de copia de seguridad en el nodo OMS en espera y el nodo DBServer en espera aumentan continuamente se soluciona en el FusionInsight HD V100R002C60U10SPC003.


 Sugerencias


Este problema es causado por el error de software. Debido al error, la cantidad de archivos en el directorio de copia de seguridad aumenta continuamente y el espacio en el disco puede estar completamente ocupado después de mucho tiempo. Este problema se puede evitar en la etapa de diseño inicial o instalando el parche C60U10SPC003.


  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente
Respuesta rápida Desplácese hasta arriba