Troubleshooting de base vPostgres en vCenter – ¿Como eliminar inconsistencias?

Que tal gente, hace algunos días (en realidad al menos 1 mes) me encontraba listo para realizar una demo de Horizon Suite para el grupo de ingeniería preventa de VMware México, por lo que encendí mi laboratorio y oh sorpresa… mi appliance de vCenter Server no levantaba… algo extraño ocurría  en el momento de levantar la base de datos embebida, lo primero que me paso por la mente fue verificar si desde la consola web de administración podía conectarme a la base y pues bueno este fue el resultado:

web-basenocontecta

 

 

Como pueden ver efectivamente no se tenia conexión con la base, por lo que comencé a investigar un poco y con apoyo de algunos colegas internamente pude verificar que efectivamente se tenia un problema con la base de datos y esto era registrado en el log “postgresql.log”:

  db: pid:18939 LOG:  database system was interrupted while in recovery at 2013-04-16 08:51:20 CDT
db: pid:18939 HINT:  This probably means that some data is corrupted and you will have to use the last backup for recovery.
db: pid:18939 LOG:  database system was not properly shut down; automatic recovery in progress
db: pid:18939 LOG:  consistent recovery state reached at 3/6B08B9E8
db: pid:18939 LOG:  redo starts at 3/6AF58C50
db: pid:18939 PANIC:  checksum mismatch: disk has 0x39835139, should be 0x76213af3 filename base/16385/17482_fsm, BlockNum 2, block specifier 1663/16385/17482/1/2 —> bloque corrupto
db: pid:18939 CONTEXT:  xlog redo insert: rel 1663/16385/17482; tid 2/31
db: pid:18937 LOG:  startup process (PID 18939) was terminated by signal 6: Aborted
db: pid:18937 LOG:  aborting startup due to startup process failure

Por lo que claramente tuve que recurrir a apoyo de el excelente equipo de soporte que tenemos (GSS – Global Support Services, Marcelo y Andrew) ellos me apoyaron a poder resolver el problema y poder levantar mi appliance virtual, básicamente se tuvo que ejecutar un comando que detecta inconsistencias en los checksums, pero esto en el appliance virtual funciona un poco distinto que en el caso de vPostgres en otro SO, esto debido a que el usuario “postgres” no tiene definido bash en el archivo /etc/passwd lo cual requiere una modificación de este archivo para cambiar:

/bin/false

a

/bin/bash

Con esto podemos continuar y realizar dos tareas, un respaldo de seguridad de la base de datos y después intentar corregir las inconsistencias:

  • obtenemos el password para podernos conectar a la base de datos embebida, para esto, ejecutamos el comando:

cat /etc/vmware-vpx/embedded_db.cfg

lo cual nos desplegará información de la base de datos, solo copiamos el password que podemos encontrar después de “EMB_DB_PASSWORD”

Screen Shot 2013-06-25 at 2.36.47 PM

  • Una vez obtenida la password es necesario realizar el respaldo como medida de seguridad antes de trabajar con la base de datos, para esto, necesitamos ejecutar los siguientes comandos:

su postgres      —> esto nos cambiará el usuario de Root a postgres

cd /opt/vmware/vpostgres/1.0/bin  —> esto nos cambiará el directorio de trabajo para poder ejecutar el respaldo

./pg_dump VCDB > /storage/db/vpostgres/VCDB.bak   —> esto realizará el respaldo, se nos pedirá el password

Screen Shot 2013-06-25 at 2.44.08 PM

  • Después de haber realizado el respaldo es momento de identificar las inconsistencias y resolverlas, para esto debemos ejecutar el siguiente comando donde debemos especificar el bloque o los bloques corruptos (estos aparecen en el log, pueden comprobarlo en el inicio del post):

/opt/vmware/vpostgres/1.0/bin/postgres –single -D /storage/db/vpostgres -c fix_block_checksum=”1663/16385/17482/1/2

Screen Shot 2013-06-25 at 2.50.26 PM

Después de haber realizado estas tareas mi appliance virtual de vCenter levantó (¡Gran felicidad para mi! no tenia que reconstruir mi lab que incluye vCD,etc!!) como lo podemos ver en la imagen:

Screen Shot 2013-06-25 at 2.52.36 PM

RECORDEMOS QUE ESTO SOLO ES PARA MOTIVOS EDUCACIONALES Y DE PRUEBAS, EN EL CASO QUE SE ENCUENTREN EN ESTE MISMO PROBLEMA DEBEN DE LEVANTAR TICKET DE SOPORTE CON VMWARE, ESTO DEBE DE SER MANEJADO A TRAVÉS DE GSS.

 

 

Leave a Reply