Anyone help with MYSQL and oversized log_actions.MYD file?

macguy
New Contributor II

I have come up against this error "Lookup logs:java.sql.SQLException: com.jamfsoftware.HTTPRequestActions.Controller.processRequest: SQLException from executeQuery: java.sql.SQLException: Table './jamfsoftware/log_actions' is marked as crashed and should be repaired
org.apache.jasper.JasperException: org.apache.jasper.JasperException: java.lang.NullPointerException"

when i go to Policy -> chose on any policy -> click on view status -> then the error above show up.

I checked the size of the log_actions.MYD and its 121GB!!! Yikes

I have tried a repair tables through Casper and a Repair whilst trying to backup but both state that the MYD is marked as crashed.

Anyone have any pointers of which way to go with this one, I do have a good backup from 2 days ago - but restoring that will most likely only postpone the issue not fix what us causing the inflated MYD

Look forward to any replays

Karl

1 ACCEPTED SOLUTION

macguy
New Contributor II

For those interested here is an update:

JAMF Support have been awesome in there assistance and come to the rescue by helping me repair the table in question by using /usr/local/mysql/bin/mysqlcheck --repair jamfsoftware -u root -p

This actually did repair the table when other methods had failed, now optimising the tables to try to reduce the size.

Will give final outcome when I know more of how it is all going to end up.

Update after optimisation I truncated the table that was offending and now have my Database backing up again.

Props to Drew at JAMF Support - in Amsterdam, he was a wealth of knowledge - JAMF support is amazing - a lot of software vendors could take a leaf out there book. This is how you expect support to be.

The cause of all my drama was bringing in old machines that had been enrolled in our previous Casper install, All the action_logs files had been download to the database from these machines forcing the table to blow out to 121GB.

So rule of thumb before enrolling a machine from a previous casper install to a new capser install - delete the logs files on the client and save the heart attack later.

Regards

Karl

View solution in original post

1 REPLY 1

macguy
New Contributor II

For those interested here is an update:

JAMF Support have been awesome in there assistance and come to the rescue by helping me repair the table in question by using /usr/local/mysql/bin/mysqlcheck --repair jamfsoftware -u root -p

This actually did repair the table when other methods had failed, now optimising the tables to try to reduce the size.

Will give final outcome when I know more of how it is all going to end up.

Update after optimisation I truncated the table that was offending and now have my Database backing up again.

Props to Drew at JAMF Support - in Amsterdam, he was a wealth of knowledge - JAMF support is amazing - a lot of software vendors could take a leaf out there book. This is how you expect support to be.

The cause of all my drama was bringing in old machines that had been enrolled in our previous Casper install, All the action_logs files had been download to the database from these machines forcing the table to blow out to 121GB.

So rule of thumb before enrolling a machine from a previous casper install to a new capser install - delete the logs files on the client and save the heart attack later.

Regards

Karl