repairing database..

[sugacapra]

hi there,
i think that the command used to repair the database
(the know myisamchk --silent --force --fast --update-state -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /var/lib/mysql/*/*.MYI )

would be a great add on admin function directly on zoneminder web pages.. maybe just a click on the option and (stopping the capture) you can check the db and repair if necessary..

happen just to me that when the system shutdown wrongly (power down of club and others sucky situation) the db is corrupted? and none else other than me here know that this simple command reput the zoneminder in his full function?
i think i can add a script call on rc.zoneminder and launch this before of the eventual restart.. but a option on the web site would help others users here learn that if the events are unreadable was because the database have some table error..

hope that my rusty english and late hours wont leave the idea just on my mind and not too unreadable in this post

bye all

[john_l_b]

I had to shut down zm and the web functioning to make it work. As long as there is any connection with a browser to the zm html, it errors and says that there is a connection to the database.

Even without that, it is taking a long time - about 3 hours now and still running, yet Ksysmonitor shows most processes as taking 0 user and 0 system time. The graphic display does show CPU usage, but I can't identify where it is at.

I did remove the --error and added in -r (repair).

The count of events was over 202000 after 6 months of 4 cameras and the last 3 months with 2 additional cameras.

I will be creating a script to do it every week or month depending on the time to do it after all the past defects are corrected.

John

[ktheking]

This is why I made feature request : Freeze , Pause for overall ZM engine

http://www.zoneminder.com/forums/viewtopic.php?t=11879


Only this would enable one to do a restorable backup of the database without shutting ZM down.

[john_l_b]

This system had gotten bad enough so that the database repair couldn't fix all the problems, even after repeated attempts. It would finish with some errors fixed each time. I ended up putting a new hard drive in and reinstalling everything. The drive wasn't bad, but I'm saving it to recover data on while the system runs on a new drive.

A process of running a script in cron at appropriate times (say 3:00 AM) to take zm down, scan and repair the database, and restart zm is probably a good way to do it.