databases

Repairing WordPress MySql Table corruption

Posted on by

We suffered a SAN outage which caused one of our wordpress servers to come back up with a corrupted table.

 

In the wordpress logs this presented as:

[error][client IP] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://example.com/

Not exactly clear error message.  Digging into the mysqld log was more illustrative of the problem:

[ERROR] /usr/libexec/mysqld: Table './db/wp_options' is marked as crashed and should be repaired

(The database name was changed to protect the innocent).

With the above error, I now understood the problem and how to approach fixing it.

# mysql -u root -p
Enter password:
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql> connect db;

Connection id: 2244
Current database: db

mysql> select * from wp_options limit 1;
ERROR 145 (HY000): Table ‘./db/wp_options’ is marked as crashed and should be repaired
mysql> repair table wp_options;
+—————————–+——–+———-+——————————————————-+
| Table | Op | Msg_type | Msg_text |
+—————————–+——–+———-+——————————————————-+
| db.wp_options | repair | info | Wrong block with wrong total length starting at 52540 |
| db.wp_options | repair | warning | Number of rows changed from 314 to 313 |
| db.wp_options | repair | status | OK |
+—————————–+——–+———-+——————————————————-+
3 rows in set (0.05 sec)

mysql> select * from wp_options limit 1;
+———–+————-+————————–+———-+
| option_id | option_name | option_value | autoload |
+———–+————-+————————–+———-+
| 1 | siteurl | https://example.com | yes |
+———–+————-+————————–+———-+
1 row in set (0.01 sec)

mysql> exit
Bye

And that quickly the site was back up and functional, no restart required!

Hope that helps someone or me in the future.

 

 

 

 

Testing Database Connectivity

Posted on by

Working with databases and new application installations can be really fun.  Problem is, when there is a problem, everyone starts the blame game.  Nothing unusual about that, part of an administrators job is to troubleshoot and prove where the problem starts.  When dealing with external databases, there can be numerous problem, the firewall could be blocking, the local or remote port could be blocked on the system, or the database credentials could be incorrect.  Testing for the last helps troubleshoot all of these.  Ruling out the database connection helps focus the application administrator on the real problem!  Testing a remote oracle database is pretty simple if you have the oracle client configured with tnsnames, etc.  But if that isn’t necessary you may not have it configured.  When you don’t this is the easiest way to test the database connection via the command line:

sqlplus 'user/pass@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=hostname.network)(Port=1521))(CONNECT_DATA=(SID=remote_SID)))'

Prior to this make sure your ORACLE_HOME environment variable is set correctly.  You may also need the LD_LIBRARY_PATH set to $ORACLE_HOME/lib.

UPDATE: 21may2015:

Now that you are in you may want to check a few things out.  To give you a quick reminder of the syntax here are a few to get the lay of the land:

To list all tables in a database (accessible to the current user):

SQL> select table_name from user_tables;

 

To list the contents of a specific table, type:

SQL> select * from name_of_table;

You can find more info about views all_tables, user_tables, and dba_tables in Oracle Documentation.