KNOWNHOST WIKI

User Tools

Site Tools


developmental:troubleshooting-database-connection-errors

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
developmental:troubleshooting-database-connection-errors [2019/10/11 08:25]
Karson N.
developmental:troubleshooting-database-connection-errors [2020/06/10 09:23] (current)
Karson N.
Line 27: Line 27:
   - Invalid or mismatched credentials in the site's database configuration file as compared to those stored in cPanel/MySQL.   - Invalid or mismatched credentials in the site's database configuration file as compared to those stored in cPanel/MySQL.
   - PHP has been upgraded, but the site isn't yet compatible with PHP 7 (still uses the deprecated function mysql_connect).   - PHP has been upgraded, but the site isn't yet compatible with PHP 7 (still uses the deprecated function mysql_connect).
- 
  
 This article discusses in detail how to deal with the following variations of errors you may see logged in different locations in your server: This article discusses in detail how to deal with the following variations of errors you may see logged in different locations in your server:
Line 42: Line 41:
   * The system failed to open the session file "/var/cpanel/sessions/raw/root:########"  because of an error:  Disk quota exceeded at /usr/local/cpanel/Cpanel/Session.pm line 277.    * The system failed to open the session file "/var/cpanel/sessions/raw/root:########"  because of an error:  Disk quota exceeded at /usr/local/cpanel/Cpanel/Session.pm line 277. 
  
 +\\
 ===== Out of Memory Errors ===== ===== Out of Memory Errors =====
  
 If the error is intermittent, you should check for OOMs, or Out of Memory errors. To check for OOMs, you can run the following command: If the error is intermittent, you should check for OOMs, or Out of Memory errors. To check for OOMs, you can run the following command:
 +<code>
   grep -i 'kill\|oom' /var/log/messages   grep -i 'kill\|oom' /var/log/messages
-  +</code> 
 You may see output with errors similar to these: You may see output with errors similar to these:
  
Line 55: Line 56:
  
 If no abuse is occurring, you may want to check the output of sar to determine how long they have been occurring so that you can determine whether you are running your server with insufficient RAM. Sar only stores the last 30 days of information, but will at least give you an overview of RAM usage over the last month. Here is how to check the current day's RAM usage with sar: If no abuse is occurring, you may want to check the output of sar to determine how long they have been occurring so that you can determine whether you are running your server with insufficient RAM. Sar only stores the last 30 days of information, but will at least give you an overview of RAM usage over the last month. Here is how to check the current day's RAM usage with sar:
 +<code>
   sar -r   sar -r
 +</code>
  
 The following command can be used to check the RAM usage on the prior day dated the 13th: The following command can be used to check the RAM usage on the prior day dated the 13th:
 +<code>
   sar -f /var/log/sa/sa13   sar -f /var/log/sa/sa13
 +</code>
  
 You can use the above command to check any day of the last 30-31 days by replacing '13' with the date that you want to check. If 'dd' represents the day, then the following is a generalization: You can use the above command to check any day of the last 30-31 days by replacing '13' with the date that you want to check. If 'dd' represents the day, then the following is a generalization:
 +<code>
   sar -f /var/log/sa/sadd   sar -f /var/log/sa/sadd
 +</code>
  
 Just replace 'dd' with the day of the month that you want to review RAM usage.  Just replace 'dd' with the day of the month that you want to review RAM usage. 
- 
  
 Also, you can use the following command to check for the total number of OOMs that have occurred on your VPS (this command doesn't work for non-virtualized containers): Also, you can use the following command to check for the total number of OOMs that have occurred on your VPS (this command doesn't work for non-virtualized containers):
 +<code>
   grep oom /proc/user_beancounters   grep oom /proc/user_beancounters
 +</code>
  
 The last number listed is the count of OOMs. If no OOMs have occurred, then your output will look like this: The last number listed is the count of OOMs. If no OOMs have occurred, then your output will look like this:
  
-{{:developmental:beancounters.png?nolink&1000|}}+{{:developmental:beancounters.png?nolink&1200|}}
  
 If OOMs have occurred, as in the case of the following server which has had 126K, you will see the number of OOMs that have occurred: If OOMs have occurred, as in the case of the following server which has had 126K, you will see the number of OOMs that have occurred:
  
-{{:developmental:129kooms.png?nolink&1000|}}+{{:developmental:129kooms.png?nolink&1200|}}
  
 If OOMs are occurring too frequently to be logged via /var/log/messages, then you will want to watch this number. This does sometimes occur where OOMs are happening but are not being logged on the server, though the fail count is logged to /proc/user_beancounters.  If OOMs are occurring too frequently to be logged via /var/log/messages, then you will want to watch this number. This does sometimes occur where OOMs are happening but are not being logged on the server, though the fail count is logged to /proc/user_beancounters. 
Line 89: Line 93:
 You may also check for multiple instances of the same service running. A recent bug in cPanel causes many OOMs due to multiple instances of tailwatchd being instantiated repeatedly. If you find something like this occurring, chances are that cPanel is aware and have released a patch, so you can stop those services, remove them from the Service Manager for long enough to run an update, and then add the service back to the Service Manager once the update completes. If the issue persists, please open a support request with the KnownHost support team.  You may also check for multiple instances of the same service running. A recent bug in cPanel causes many OOMs due to multiple instances of tailwatchd being instantiated repeatedly. If you find something like this occurring, chances are that cPanel is aware and have released a patch, so you can stop those services, remove them from the Service Manager for long enough to run an update, and then add the service back to the Service Manager once the update completes. If the issue persists, please open a support request with the KnownHost support team. 
  
 +\\
 ===== Exceeded Disk Space ===== ===== Exceeded Disk Space =====
- 
  
 To find out if the disk space is exceeded, run the following command via SSH as root: To find out if the disk space is exceeded, run the following command via SSH as root:
 +<code>
   df -h   df -h
 +</code>
  
 You will see something similar to this showing that you have reached 100% disk space utilization, or are within MB of doing so: You will see something similar to this showing that you have reached 100% disk space utilization, or are within MB of doing so:
  
-{{:developmental:df-h_.png?nolink&800|}}+{{:developmental:df-h_.png?nolink&1200|}}
  
 Or try to log into WHM. The following error is typically shown when you have exceeded your disk space and try to access WHM: Or try to log into WHM. The following error is typically shown when you have exceeded your disk space and try to access WHM:
Line 108: Line 112:
  
 You can use  the following command to find what directory beneath root is using the most disk space: You can use  the following command to find what directory beneath root is using the most disk space:
 +<code>
   du -Hhsc --exclude virtfs  /*   du -Hhsc --exclude virtfs  /*
 +</code>
  
 You will get output similar to this: You will get output similar to this:
  
-{{:developmental:du.png?nolink&1000|}}+{{:developmental:du.png?nolink&1200|}}
  
 For this particular server, you can see that 22G is in /backup, and 11G in /home. If you wanted to look further into what is in /home, you can do so as follows: For this particular server, you can see that 22G is in /backup, and 11G in /home. If you wanted to look further into what is in /home, you can do so as follows:
 +<code>
   du -Hhsc --exclude virtfs /home/*   du -Hhsc --exclude virtfs /home/*
 +</code>
  
 If you find that most of the disk space under /home is under one account, let's say, account 'cpuser' you could then look under that account as follows: If you find that most of the disk space under /home is under one account, let's say, account 'cpuser' you could then look under that account as follows:
 +<code>
   du -Hhsc --exclude virtfs /home/cpuser/*   du -Hhsc --exclude virtfs /home/cpuser/*
 +</code>
  
 And then, if you find that the disk space under that account is mostly due to mail, you could find what email account is responsible with the following: And then, if you find that the disk space under that account is mostly due to mail, you could find what email account is responsible with the following:
 +<code>
   du -Hhsc --exclude virtfs /home/cpuser/mail/*   du -Hhsc --exclude virtfs /home/cpuser/mail/*
 +</code>
  
 Thus, you can get an idea of what is consuming the most space by examining the largest directories on the server using the //du// command.  Thus, you can get an idea of what is consuming the most space by examining the largest directories on the server using the //du// command. 
Line 131: Line 139:
 //Note:// The reason for the //--exclude virtfs// tag above is so that virtfs output is not included. The reason is that virtfs will show a lot of space being consumed, however, space is not actually consumed. The /home/virtfs consists of bind mounts. and does //not// actually take up disk space, even though it will show up as used disk space when you use du. **Do not** use //rm// or try to delete the /home/virtfs directory as doing so will also delete the content that it is mounted to and potentially render your server non-functional! If you want to remove these mounts, see the following link: //Note:// The reason for the //--exclude virtfs// tag above is so that virtfs output is not included. The reason is that virtfs will show a lot of space being consumed, however, space is not actually consumed. The /home/virtfs consists of bind mounts. and does //not// actually take up disk space, even though it will show up as used disk space when you use du. **Do not** use //rm// or try to delete the /home/virtfs directory as doing so will also delete the content that it is mounted to and potentially render your server non-functional! If you want to remove these mounts, see the following link:
  
-https://documentation.cpanel.net/display/68Docs/VirtFS+-+Jailed+Shell+[[https://documentation.cpanel.net/display/68Docs/VirtFS+-+Jailed+Shell]]
  
 +\\
 ===== Max Connections ===== ===== Max Connections =====
  
 To find out whether MySQL's configured max_connections are exceeded, you can compare the output of the following commands: To find out whether MySQL's configured max_connections are exceeded, you can compare the output of the following commands:
 +<code>
   mysql -e "SHOW STATUS" | grep -E 'Max|Upt'   mysql -e "SHOW STATUS" | grep -E 'Max|Upt'
   grep "max_con" /etc/my.cnf   grep "max_con" /etc/my.cnf
 +</code>
  
 You'll see output similar to the following: You'll see output similar to the following:
  
-{{:developmental:max_con.png?nolink&800|}}+{{:developmental:max_con.png?nolink&1200|}}
  
 If the value of Max_used_connections  from the first command is the value of max_connections + 1 or more, then the max_connections for MySQL have been exceeded.  For example, if the Max_used_connections is 51 but the max_connections is 50, then you did exceed your max_connections. As long as traffic looks legitimate and you have sufficient RAM to support the increase, you can increase this setting in the MySQL configuration file by doing the following: If the value of Max_used_connections  from the first command is the value of max_connections + 1 or more, then the max_connections for MySQL have been exceeded.  For example, if the Max_used_connections is 51 but the max_connections is 50, then you did exceed your max_connections. As long as traffic looks legitimate and you have sufficient RAM to support the increase, you can increase this setting in the MySQL configuration file by doing the following:
Line 150: Line 160:
  
 This can be accomplished with the following commands: This can be accomplished with the following commands:
 +<code>
   nano /etc/my.cnf   nano /etc/my.cnf
 +</code>
  
 Ctrl X to exit. You will be prompted to confirm the changes and the file name. Finally, restart MySQL: Ctrl X to exit. You will be prompted to confirm the changes and the file name. Finally, restart MySQL:
 +<code>
   service mysql restart   service mysql restart
 +</code>
  
 +\\
 ===== PHP ===== ===== PHP =====
  
 Did you recently upgrade PHP to version 7? If so, you will want to check the site for the function mysql_connect. This function has been deprecated, and the site software will need to upgraded to be compatible with PHP 7, ( use mysqli_connect instead). You can run the following search via SSH in your site's document root to check: Did you recently upgrade PHP to version 7? If so, you will want to check the site for the function mysql_connect. This function has been deprecated, and the site software will need to upgraded to be compatible with PHP 7, ( use mysqli_connect instead). You can run the following search via SSH in your site's document root to check:
 +<code>
   grep -Rli mysql_connect .   grep -Rli mysql_connect .
 +</code>
  
 Regarding Missing modules, this is rarely an issue. However, these are the modules often use to establish a database connection (varies depends on what EasyApache/CustomBuild and PHP versions you are using): Regarding Missing modules, this is rarely an issue. However, these are the modules often use to establish a database connection (varies depends on what EasyApache/CustomBuild and PHP versions you are using):
Line 171: Line 184:
   * sqlite3   * sqlite3
  
 +\\
 ===== Database Credentials Mismatch ===== ===== Database Credentials Mismatch =====
  
Line 197: Line 211:
 Now you can clear your browser cache and test whether or not this has resolved your Database Connection Error.  Now you can clear your browser cache and test whether or not this has resolved your Database Connection Error. 
  
 +\\
 ===== MySQL Failure, Corruption or Crashed MyIsam Tables ===== ===== MySQL Failure, Corruption or Crashed MyIsam Tables =====
  
 Finally, the worst possible issue... MySQL failure/corruption or crashed tables.  The worst case scenario isn't that bad thanks to KnownHost and their external backup system. If MySQL InnoDB corruption cannot be repaired, we can try to restore the server to a previous backup, which may not have as much corruption, and then be successful in repairing the corruption. Finally, the worst possible issue... MySQL failure/corruption or crashed tables.  The worst case scenario isn't that bad thanks to KnownHost and their external backup system. If MySQL InnoDB corruption cannot be repaired, we can try to restore the server to a previous backup, which may not have as much corruption, and then be successful in repairing the corruption.
  
- To check for these errors, the first thing that must be done is to check to see if MySQL is running: +To check for these errors, the first thing that must be done is to check to see if MySQL is running: 
 +<code>
   service mysql status   service mysql status
 +</code>
  
 Then you will want to check the MySQL logs for errors as shown below: Then you will want to check the MySQL logs for errors as shown below:
 +<code>
   tail -400 /var/lib/mysql/`hostname`.err   tail -400 /var/lib/mysql/`hostname`.err
 +</code>
  
 The command will show the last 400 errors.  You can adjust the number of errors to show as you see fit. If your error log is in a different location you will want to adjust the command accordingly.  The command will show the last 400 errors.  You can adjust the number of errors to show as you see fit. If your error log is in a different location you will want to adjust the command accordingly. 
  
 This should give you a clue as to what the issue is. If you are still unsure //and// MySQL was running in the previous check, you can tail the MySQL error logs while attempting to restart MySQL in another ssh session and this should give you more clues as to why these errors are occurring. Tail the log with this command: This should give you a clue as to what the issue is. If you are still unsure //and// MySQL was running in the previous check, you can tail the MySQL error logs while attempting to restart MySQL in another ssh session and this should give you more clues as to why these errors are occurring. Tail the log with this command:
 +<code>
   tail -f /var/lib/mysql/`hostname`.err   tail -f /var/lib/mysql/`hostname`.err
 +</code>
  
 And, in another terminal, restart MySQL with the following command: And, in another terminal, restart MySQL with the following command:
 +<code>
   service mysql restart   service mysql restart
 +</code>
  
 +\\
 ===== Syntax Error ===== ===== Syntax Error =====
  
 If a syntax error is present in the MySQL configuration file, an error will be logged detailing the exact error. You can then edit /etc/my.cnf to comment out or place the symbol # in front of the statement with the syntax error to disable it. Then, try to start MySQL: If a syntax error is present in the MySQL configuration file, an error will be logged detailing the exact error. You can then edit /etc/my.cnf to comment out or place the symbol # in front of the statement with the syntax error to disable it. Then, try to start MySQL:
 +<code>
   service mysql start   service mysql start
 +</code>
  
 If there is no apparent syntax error and the error log fills with a lot of 0's,  .'s, and it just seems that MySQL is incoherent and drunkenly logging to the error log, then it is likely that InnoDB corruption is to blame. The logs may explicitly reference an article from MySQL about InnoDB Forced Recovery as well.  If this is the case, InnoDB Forced Recovery must be done.  If there is no apparent syntax error and the error log fills with a lot of 0's,  .'s, and it just seems that MySQL is incoherent and drunkenly logging to the error log, then it is likely that InnoDB corruption is to blame. The logs may explicitly reference an article from MySQL about InnoDB Forced Recovery as well.  If this is the case, InnoDB Forced Recovery must be done. 
  
 +\\
 ===== InnoDB Forced Recovery ===== ===== InnoDB Forced Recovery =====
  
Line 232: Line 254:
  
 ** IMPORTANT** Make sure you have sufficient RAM and OOMs are not occurring before you recover InnoDB! Also, make sure you remove MySQL from the Service Manager before you perform any of the recovery steps below, and then be certain to reverse this once you have recovered InnoDB! You can toggle 'monitored' on and off using a WHM API command. The command below turns it off (replace the '0' with '1' for 'monitored' to re-enable): ** IMPORTANT** Make sure you have sufficient RAM and OOMs are not occurring before you recover InnoDB! Also, make sure you remove MySQL from the Service Manager before you perform any of the recovery steps below, and then be certain to reverse this once you have recovered InnoDB! You can toggle 'monitored' on and off using a WHM API command. The command below turns it off (replace the '0' with '1' for 'monitored' to re-enable):
 +<code>
   whmapi1 configureservice service=mysql enabled=1 monitored=0   whmapi1 configureservice service=mysql enabled=1 monitored=0
 +</code>
  
 The first thing you'll want to do is open a second terminal and watch the MySQL error log as you force InnoDB recovery. You can watch the error log using the following command: The first thing you'll want to do is open a second terminal and watch the MySQL error log as you force InnoDB recovery. You can watch the error log using the following command:
 +<code>
   tail -f /var/lib/mysql/`hostname`.err   tail -f /var/lib/mysql/`hostname`.err
 +</code>
  
 Watching the error log while performing the steps below will allow you to determine whether InnoDB corruption has been repaired or not because you will no longer see the error that indicates InnoDB corruption is present and MySQL will be working again.  Watching the error log while performing the steps below will allow you to determine whether InnoDB corruption has been repaired or not because you will no longer see the error that indicates InnoDB corruption is present and MySQL will be working again. 
  
 If MySQL is stopped, you may also want to run the following before you start just to make sure that no crashed MyISAM tables prevent your mysqldumps from completing: If MySQL is stopped, you may also want to run the following before you start just to make sure that no crashed MyISAM tables prevent your mysqldumps from completing:
 +<code>
   myisamchk -rf /var/lib/mysql/*/*   myisamchk -rf /var/lib/mysql/*/*
 +</code>
  
- To perform Forced InnoDB Recovery, you must do the following:+To perform Forced InnoDB Recovery, you must do the following:
  
   - edit the /etc/my.cnf file and add the following:  innodb_force_recovery=1   - edit the /etc/my.cnf file and add the following:  innodb_force_recovery=1
Line 253: Line 278:
  
 If MySQL starts, then proceed with the following steps: If MySQL starts, then proceed with the following steps:
 +<code>
 +  mysqldump --all-databases > /root/support/alldbs.sql
 +</code>
  
-  mysqldump --all-databases > /root/support/alldbs.sql 
-   
 Now, stop MySQL: Now, stop MySQL:
 +<code>
   service mysql stop   service mysql stop
 +</code>
  
 While stopped, do the following: While stopped, do the following:
 +<code>
   mkdir -p /root/support/mysql-bak/   mkdir -p /root/support/mysql-bak/
   mv /var/lib/mysql/* /root/support/mysql-bak/   mv /var/lib/mysql/* /root/support/mysql-bak/
   cp -pr /root/support/mysql-bak/mysql/ /var/lib/mysql/   cp -pr /root/support/mysql-bak/mysql/ /var/lib/mysql/
 +</code>
  
 Now, edit /etc/my.cnf and comment out (place the symbol # in front of)  innodb_force_recovery=1.  Now, edit /etc/my.cnf and comment out (place the symbol # in front of)  innodb_force_recovery=1. 
 +<code>
   service mysql start   service mysql start
   mysql < /root/support/alldbs.sql   mysql < /root/support/alldbs.sql
 +</code>
  
 If MySQL still fails, try repeating Innodb forced recovery with a higher setting. If you reach 6 without success, you may want to request that the support team restores /var/lib/mysql from a previous date when the corruption is hopefully not as bad, and then re-attempt InnoDB forced recovery.  If MySQL still fails, try repeating Innodb forced recovery with a higher setting. If you reach 6 without success, you may want to request that the support team restores /var/lib/mysql from a previous date when the corruption is hopefully not as bad, and then re-attempt InnoDB forced recovery. 
Line 277: Line 305:
 If you see neither of the errors above (syntax errors nor InnoDB corruption), you can check for crashed MyISAM tables.  If you see neither of the errors above (syntax errors nor InnoDB corruption), you can check for crashed MyISAM tables. 
  
 +\\
 ===== Crashed MyIsam Tables ===== ===== Crashed MyIsam Tables =====
  
 To check for crashed MyISAM tables, run the following command, and if errors are present, check that the date for which they are present is, in fact, the current date (cPanel will detect and automatically fix crashed tables for you in most cases, which is why you would need to check the date of the errors): To check for crashed MyISAM tables, run the following command, and if errors are present, check that the date for which they are present is, in fact, the current date (cPanel will detect and automatically fix crashed tables for you in most cases, which is why you would need to check the date of the errors):
 +<code>
   grep -i crash /var/lib/mysql/`hostname`.err   grep -i crash /var/lib/mysql/`hostname`.err
 +</code>
  
 You will see errors such as this: You will see errors such as this:
 +<code>
   [ERROR] mysqld: Table './database_name/wp_revslider_css' is marked as crashed and should be repaired   [ERROR] mysqld: Table './database_name/wp_revslider_css' is marked as crashed and should be repaired
 +</code>
  
 Fortunately, repairing MyISAM tables is actually pretty easy. You can do so by running the following commands: Fortunately, repairing MyISAM tables is actually pretty easy. You can do so by running the following commands:
 +<code>
   mysql   mysql
   use DATABASE;   use DATABASE;
   repair table TABLENAME;   repair table TABLENAME;
   exit;   exit;
 +</code>
  
 **IMPORTANT** Make sure you have sufficient RAM and OOMs are not occurring before you repair your tables! **IMPORTANT** Make sure you have sufficient RAM and OOMs are not occurring before you repair your tables!
  
 You could even use the following alternate means to repair the table as well: You could even use the following alternate means to repair the table as well:
 +<code>
   myisamchk --recover TABLENAME   myisamchk --recover TABLENAME
 +</code>
  
 Or the following to repair the database: Or the following to repair the database:
 +<code>
   mysqlcheck --repair --databases DATABASE   mysqlcheck --repair --databases DATABASE
 +</code>
  
 Note that //myisamchk// can be run while MySQL is not running, whereas //mysqlcheck// and //repair table// can only be run while MySQL is running.  Note that //myisamchk// can be run while MySQL is not running, whereas //mysqlcheck// and //repair table// can only be run while MySQL is running. 
Line 312: Line 346:
 Here is what this type of repair looks like: Here is what this type of repair looks like:
  
-{{:developmental:repairing_crashed_myisam_table_.png?nolink&800|}}+{{:developmental:repairing_crashed_myisam_table_.png?nolink&1200|}}
  
 Occasionally, this repair will fail due to a temporary table. The error will read something similar to this: Occasionally, this repair will fail due to a temporary table. The error will read something similar to this:
 +<code>
   myisamchk: error: Can't create new tempfile: './DATABASE_NAME/TABLE_NAME.TMD'   myisamchk: error: Can't create new tempfile: './DATABASE_NAME/TABLE_NAME.TMD'
 +</code>
  
 Here is what this error looks like when you encounter it after attempting to repair a table via the MySQL CLI: Here is what this error looks like when you encounter it after attempting to repair a table via the MySQL CLI:
  
-{{:developmental:temp-table_error_.png?nolink&1000|}} +{{:developmental:temp-table_error_.png?nolink&1200|}}
  
 //Note that 'TMD' will actually be capitalized in your server, whereas the actual '/DATABASE_NAME/TABLE_NAME' will be lowercase. // //Note that 'TMD' will actually be capitalized in your server, whereas the actual '/DATABASE_NAME/TABLE_NAME' will be lowercase. //
  
 If this occurs, you will need to remove the temporary table. I prefer to rename it to preserve the copy, which can be done via the following command: If this occurs, you will need to remove the temporary table. I prefer to rename it to preserve the copy, which can be done via the following command:
 +<code>
   mv /var/lib/mysql/DATABASE/TABLENAME.TMD  /var/lib/mysql/DATABASE/TABLENAME.TMD.bak   mv /var/lib/mysql/DATABASE/TABLENAME.TMD  /var/lib/mysql/DATABASE/TABLENAME.TMD.bak
 +</code>
  
 You should now be able to run the repair successfully.  You should now be able to run the repair successfully. 
  
 If you have multiple crashed tables, you can use the following command to check, analyze, optimize, and repair all tables (some of these functions only work with certain storage engines, such as repair with MyISAM): If you have multiple crashed tables, you can use the following command to check, analyze, optimize, and repair all tables (some of these functions only work with certain storage engines, such as repair with MyISAM):
 +<code>
   mysqlcheck -Aa; mysqlcheck -Ace; mysqlcheck -Arv; mysqlcheck -Ao   mysqlcheck -Aa; mysqlcheck -Ace; mysqlcheck -Arv; mysqlcheck -Ao
 +</code>
  
 You may want to watch the error log in a separate terminal while running this command: You may want to watch the error log in a separate terminal while running this command:
 +<code>
   tail -f /var/lib/mysql/`hostname`.err   tail -f /var/lib/mysql/`hostname`.err
 +</code>
  
 If your databases are very large, then you may want to use the screen utility to run the command above in to make sure that it can complete even if you log out: If your databases are very large, then you may want to use the screen utility to run the command above in to make sure that it can complete even if you log out:
 +<code>
   screen   screen
 +</code>
  
 +\\
 ===== Conclusion ===== ===== Conclusion =====
  
developmental/troubleshooting-database-connection-errors.1570800303.txt.gz · Last modified: 2019/10/11 08:25 by Karson N.