Answers.Body: <p>Found the problem. Corrupt log tables. Causes MEGA-chaos for poor mysql. It's crash-a-roo anytime a CiviCRM table is used.</p>
  
  <p>To resolve, </p>
  
  <p>Find where the civicrm databases are stored. If on a typical *nix distribution and using mysql, likely /var/lib/mysql/civicrm</p>
  
  <p>Shutdown mysql (service mysql stop)</p>
  
  <p>Create a new directory (mkdir logtables), now move all the log tables into that directory (mv civicrm.log_* logtables)</p>
  
  <p>Clear out the error.log files so you can see what is happening each time you start mysql. To do that cat /dev/null >/var/log/mysql/error.log (this assumes the mysql server log file is located at /var/log/mysql, which you'd check before issuing that command)</p>
  
  <p>Start mysql (service mysql start)</p>
  
  <p>If you do not have root privileges the OS will freak out when you attempt to move the log tables. Suggest elevating your privileges to root either using sudo (e.g. sudo mv civicrm.log_*) or su root, then go crazy but not too crazy. Remember, there's no undo in Unix/Linux. After starting mysql, check the mysql server's log file to see if it's happy again.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-02T08:35:36.387Z
Answers.Text: MySQL & derivatives have issues with the ARCHIVE format being prone to corruption. If you can trade some diskspace for more reliable storage, convert all `log_*` tables to InnoDB. If you stick with ARCHIVE, you may find that next time this happens you can just `DROP` the table in question. CiviCRM can regenerate log tables (maybe someone can clarify process?), or you can grab the `CREATE TABLE` statement (& data) from a recent backup. There's also a hook to exclude specific tables from logging, see [CRM-18104](https://issues.civicrm.org/jira/browse/CRM-18104). Or, turn off DB logging! 
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-02T08:38:58.263Z
Answers.Text: Should I have posted that comment as several different answers to let people vote for their preferred way to deal with ARCHIVE tables?   
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-03T12:49:55.073Z
Answers.Text: Hey Chris, thanks for the update. Just an FYI, once the table gets corrupted, attempts to drop it or even truncate it all fail. Even a simple command like SHOW TABLES; MySQL freaks out and dies. Very nasty
Answers.UserDisplayName: carclubadmin
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-01T18:26:52.013Z
Answers.LastActivityDate: 2017-02-01T18:26:52.013Z
Answers.UserDisplayName: carclubadmin
Body: <p>On Drupal 7.52 and CiviCRM 4.7.13</p>
  
  <p>Recently I discovered Civicrm couldn't connect to MySQL. This wonderful error popped up when registering someone for an event:</p>
  
  <pre><code>DB Error: no database selected
  </code></pre>
  
  <p>Checking the SQL log I see the following over and over</p>
  
  <pre><code>Couldn't repair table: civicrm.log_civicrm_status_pref
  </code></pre>
  
  <p>How do I get rid of the problem? MySQL seems unhappy at start up when it says</p>
  
  <pre><code>1:55:43 UTC - mysqld got signal 11 ;
  </code></pre>
  
  <p>Followed by a bunch of mundane stuff, none appearing error related then </p>
  
  <pre><code>Some pointers may be invalid and cause the dump to abort.
  Query (7fc4005eff10): is an invalid pointer
  Connection ID (thread ID): 9
  Status: NOT_KILLED
  </code></pre>
  
  <p>I've heard that if I drop the table civicrm.log_civicrm_status_pref this will fix the problem. Really? Is there anything else I should know? Is it really as simple as </p>
  
  <pre><code>SELECT civicrm
  DROP TABLE civicrm.log_civicrm_status_pref
  </code></pre>
  
  <p>Then the world returns to normal?</p>
  
  <p>What if I think MySQL is pooched and I want to re-install it. Will I then find a database server with no databases? Thanks for any help the community can provide. Until now CiviCRM has been running great. This is the only serious problem I've had with it but it seems to be quite a problem. I've tried recovering from backup. No go. Same error.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-27T02:20:16.103Z
Comments.Text: Still getting the following error, using debug and backtrace  DB Error: unknown error
  
  Return to home page.
  Sorry but we are not able to provide this at the moment.
  DB Error: no database selected
  Database Error Code: MySQL server has gone away, 2006
Comments.UserDisplayName: carclubadmin
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-27T08:20:49.950Z
Comments.Text: Did you run out of disk space?  That causes a load of problems in MySQL.  Have you tried the [repair table](https://dev.mysql.com/doc/refman/5.7/en/repair-table.html) commands in MySQL?
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-27T16:04:49.973Z
Comments.Text: Just checked and I'm using 3 gigs on a 40 gig volume. Space looks good. When I run the command myslqcheck it runs fine all the way to the table log_civicrm_action_schedule, then the error 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE'. Attempting to DROP  or REPAIR instantly creates the error ERROR 2006 (HY000): MySQL server has gone away. use civicrm; show tables; fails as well. Backup of the data has the same problem.
Comments.UserDisplayName: carclubadmin
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-27T16:13:41.447Z
Comments.Text: I'm curious about something. The file log_civicrm_status_pref.ARN is 38,780,277 in size. A 38 meg file when most of the log_ files are < 15k. Is that weird? Is mysql having a memory problem?
Comments.UserDisplayName: carclubadmin
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-27T19:07:54.233Z
Comments.Text: Don't know ... but it's definitely a MySQL issue rather than Civi directly.  If you don't get any answers here you could try https://forums.mysql.com/
Comments.UserDisplayName: Aidan
Tags: <mysql><mysql-archive-format><db-logging>
Title: Site broken. How do I fix Couldn't repair table: civicrm.log_civicrm_status_pref?
ThreadText: # Site broken. How do I fix Couldn't repair table: civicrm.log_civicrm_status_pref?
  
  (Asked by: username_0 on 2017-01-27)
  
  On Drupal 7.52 and CiviCRM 4.7.13
  Recently I discovered Civicrm couldn't connect to MySQL. This wonderful error popped up when registering someone for an event:
  DB Error: no database selected
  
  Checking the SQL log I see the following over and over
  Couldn't repair table: civicrm.log_civicrm_status_pref
  
  How do I get rid of the problem? MySQL seems unhappy at start up when it says
  1:55:43 UTC - mysqld got signal 11 ;
  
  Followed by a bunch of mundane stuff, none appearing error related then 
  Some pointers may be invalid and cause the dump to abort.
  Query (7fc4005eff10): is an invalid pointer
  Connection ID (thread ID): 9
  Status: NOT_KILLED
  
  I've heard that if I drop the table civicrm.log_civicrm_status_pref this will fix the problem. Really? Is there anything else I should know? Is it really as simple as 
  SELECT civicrm
  DROP TABLE civicrm.log_civicrm_status_pref
  
  Then the world returns to normal?
  What if I think MySQL is pooched and I want to re-install it. Will I then find a database server with no databases? Thanks for any help the community can provide. Until now CiviCRM has been running great. This is the only serious problem I've had with it but it seems to be quite a problem. I've tried recovering from backup. No go. Same error.
  
  **Tags:** mysql, mysql-archive-format, db-logging
  
  > **Comments:**
  > **username_0**: Still getting the following error, using debug and backtrace  DB Error: unknown error  Return to home page. Sorry but we are not able to provide this at the moment. DB Error: no database selected Database Error Code: MySQL server has gone away, 2006  
  > **username_1**: Did you run out of disk space?  That causes a load of problems in MySQL.  Have you tried the [repair table](https://dev.mysql.com/doc/refman/5.7/en/repair-table.html) commands in MySQL?  
  > **username_0**: Just checked and I'm using 3 gigs on a 40 gig volume. Space looks good. When I run the command myslqcheck it runs fine all the way to the table log_civicrm_action_schedule, then the error 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE'. Attempting to DROP  or REPAIR instantly creates the error ERROR 2006 (HY000): MySQL server has gone away. use civicrm; show tables; fails as well. Backup of the data has the same problem.  
  > **username_0**: I'm curious about something. The file log_civicrm_status_pref.ARN is 38,780,277 in size. A 38 meg file when most of the log_ files are < 15k. Is that weird? Is mysql having a memory problem?  
  > **username_1**: Don't know ... but it's definitely a MySQL issue rather than Civi directly.  If you don't get any answers here you could try https://forums.mysql.com/  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-02-01. Score: 2 | Accepted answer
  
  Found the problem. Corrupt log tables. Causes MEGA-chaos for poor mysql. It's crash-a-roo anytime a CiviCRM table is used.
  
  To resolve,
  
  Find where the civicrm databases are stored. If on a typical \*nix distribution and using mysql, likely /var/lib/mysql/civicrm
  
  Shutdown mysql (service mysql stop)
  
  Create a new directory (mkdir logtables), now move all the log tables into that directory (mv civicrm.log\_\* logtables)
  
  Clear out the error.log files so you can see what is happening each time you start mysql. To do that cat /dev/null >/var/log/mysql/error.log (this assumes the mysql server log file is located at /var/log/mysql, which you'd check before issuing that command)
  
  Start mysql (service mysql start)
  
  If you do not have root privileges the OS will freak out when you attempt to move the log tables. Suggest elevating your privileges to root either using sudo (e.g. sudo mv civicrm.log\_\*) or su root, then go crazy but not too crazy. Remember, there's no undo in Unix/Linux. After starting mysql, check the mysql server's log file to see if it's happy again.
  
  > **Comments:**
  > **username_2**: MySQL & derivatives have issues with the ARCHIVE format being prone to corruption. If you can trade some diskspace for more reliable storage, convert all `log_*` tables to InnoDB. If you stick with ARCHIVE, you may find that next time this happens you can just `DROP` the table in question. CiviCRM can regenerate log tables (maybe someone can clarify process?), or you can grab the `CREATE TABLE` statement (& data) from a recent backup. There's also a hook to exclude specific tables from logging, see [CRM-18104](https://issues.civicrm.org/jira/browse/CRM-18104). Or, turn off DB logging!   
  > **username_2**: Should I have posted that comment as several different answers to let people vote for their preferred way to deal with ARCHIVE tables?     
  > **username_0**: Hey Chris, thanks for the update. Just an FYI, once the table gets corrupted, attempts to drop it or even truncate it all fail. Even a simple command like SHOW TABLES; MySQL freaks out and dies. Very nasty  
  
  ---
  
  