I first noticed the issue when I attempted an automated backup using Drush.
The issue seemed to be due to a previous issue where our web server ran out of hard disk space, which resulted many of the databases becoming locked.
In my case, when I needed to perform a backup Drush resulted in the following error:
“Database dump failed”
To further inspect the problem I initiated a manual mysqldump that also returned an error, but this time there was additional information provided along with the error.
mysqldump: Got error: 144: Table ‘./databasename/watchdog’ is marked as crashed and last
(automatic?) repair failed when using LOCK TABLES
To correct this issue, I logged into MySQL via the command line using the credentials for the problematic database and switched over to the correct database.
Access MySQL via the command line:
Log into MySQL
$ mysql -u username -p
Change to desired database:
mysql> use database databasename;
The first thing I did was run the check command on the watchdog table, to see if there were any warnings or errors present.
mysql> check table watchdog;
In my case, there were 3 warnings and 2 errors with the ‘watchdog’ table, so from here the next step was to attempt a repair.
mysql> repair table watchdog;
The repair tool will output data informing you of the status of the repair task. If everything worked like it was suppose to, you should be able to perform the ‘check table’ command once again to confirm that the table is no longer corrupt.
After performing the repair, I was then able to resume my normal site backup process using the drush arb command.