MySQL Server not startin - issue

[Danny Meyer]

Hello.

Seems that one of my installations have a corrupt database.

It prevents that the vsom instance starts.

170116 13:45:33  InnoDB: Using Linux native AIO
170116 13:45:33  InnoDB: Initializing buffer pool, size = 64.0M
170116 13:45:33  InnoDB: Completed initialization of buffer pool
170116 13:45:33  InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
170116 13:45:33  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 45.
InnoDB: You may have to recover from a backup.
170116 13:45:33  InnoDB: Page dump in ascii and hex (16384 bytes):

I wanted to star fresh with a new DB instance instad of reinstalling everyhting from scrach.

database_creat.sh does not work unless the mysql starts propery.

Any idea how I can fix this? Would deleteing the DBs and restart the sql service help?

Thanks for your hint.

Danny

[dazyparker123]

Hi Danny,

• Start up the configuration wizard. Delete the previous instance. This will close the configuration wizard.
• Start up the configuration wizard again. Create a new instance. Usually, this step will work and you are done.

Good Luck!

[Danny Meyer]

Hi.

Thanks very much for your hint. I fully agree, but in this case, the VSOM service does not start and therefore I have no access to any web gui.

My question would be: can I delete the database and run one of those db scripts?

I can live with a fresh setup, saves me still time than starting from scratch.

Danny

[Scott Olsen]

While it's possible the BU may not be pleased with me for relaying this information, there *is* a shell script in the upgrade packages that can quickly 'pave' a VSM install.

# Name : install_VSM.sh
# Description : Script to install/upgrade VSM.
# Input : Script require Cisco or/and OS RPM to install VSM.
# Action : This script is package in upgrade image file along with RPMs
# and will also be install under "/usr/BWhttpd/bin".
# This script can be use to perform the following tasks:
# 1. "-dev" option for developer to install only the Cisco RPMs.
# 2. "-uninstall" option to uninstall VSM.
# 3. "-uninstall-Cisco" option to uninstall Cisco RPMs.
# 4. Fresh install of Cisco & OS RPMs extracted from upgrade image.
# 5. Upgrade to new version.
# 6. Upgrade when VSM-version.xml file is missing.
# Output : All output are printed to stdout.

I typically run an '-uninstall' and then a typical install.  Be patient as the post processing after the script has ended may still be restarting services and triggering changes.

I've been keeping a VSM7.8 source directory tucked away in a media repo on our own lab server, along with recent manual backup of VSOM in the event that our VSOM mysql instance craters (which apparently is quite often).

Thankfully, at least Cisco is acknowledging they have a problem now:

CSCvc16759 Mysql fails to start after a hard power failure

[Danny Meyer]

Hi Scott.

Thanks for your helpful hint (again). I also was wandering through those many .sh files in the hope to find a useful one.

Indeed, the problem started with a power issue. Since this is one of mine own ones, no worries with TAC... :-)

Regards

Danny

[Scott Olsen]

Same boat for me.  Glad I could be of some assistance :-)

P.S. - I've since actually gone the extra step of getting a small USB UPS attached to the VSM lab box.  The LINUX 'NUT' project has rpms for whatever version of RHEL you're working with, and it's actually already saved my butt once here.  The one thing I still have to change (I believe) is the UPS shutdown script calls for a HALT (by default... I think)... and now I'm starting to believe it may need an actual full SHUTDOWN to succeed.  After the last local power event and manually bringing everything back up, the chassis still stopped at the OPROM for RAID adapter indicating it had detected a loss of power (loss of cache, etc...manually continue, blah blah blah), but once booted everything (all services) had come back up fine (no issue with mysql or VSOM , etc...) and the logs on the box indicated the UPS daemon did, in fact, do it's job and brought the server to a HALT state during the event.  I think the crucial butt saving portion is the graceful shutdown of the VSOM and mysql services (accomplished either way), but I'd also like to not have a crash cart required to bring this lab box back up!

[Danny Meyer]

Great idea. That is worth a try and I wonder why this is not already part of the GUI. Will have a talk to the PM about that in a few weeks.