Installation and Administration Guide for the Cisco TelePresence Exchange System Release 1.0
Corrupted MySQL Database Recovery
Downloads: This chapterpdf (PDF - 89.0KB) The complete bookPDF (PDF - 2.64MB) | Feedback

Corrupted MySQL Database Recovery

Table Of Contents

Corrupted MySQL Database Recovery

Diagnosing a Corrupted MySQL Database

Recovering from a Corrupted MySQL Database


Corrupted MySQL Database Recovery


Revised June 30, 2011

This chapter includes the following sections:

Diagnosing a Corrupted MySQL Database

Recovering from a Corrupted MySQL Database

Diagnosing a Corrupted MySQL Database

Use this procedure to determine whether your database servers have a corrupted MySQL database.

Procedure


Step 1 Log in to the CLI of each database server.

Step 2 On each database server, enter the utils service database status command.

Step 3 If the output indicates the following conditions, then the database servers have a corrupted MySQL database.

The connection state (cs) is "Connected."

The disk state (ds) value is "Inconsistent/Inconsistent."

The role (ro) values are "Secondary/Secondary" on both servers.

The current HA role is "secondary" for both servers.

Because both servers have the secondary HA role, the MySQL database cannot run.

Step 4 To recover from a corrupted MySQL database, proceed to the "Recovering from a Corrupted MySQL Database" section.


Example

In the following example, the status indicates that the nodes have a corrupted MySQL database.

admin: utils service database status 
--------------------------------------------------------------------------------
The initial configured HA role of this node      : secondary
The current HA role of this node                 : secondary 
The database vip address                         : 10.22.130.54
The database primary node name                   : ctx-db-1
The database primary node IP address             : 10.22.130.49
The database secondary node name                 : ctx-db-2
The database secondary node IP address           : 10.22.130.57
Mon status                                       : Not running (only runs on primary)
MySQL status                                     : Not running (only runs on primary)
Heartbeat status                                 : Running pid 19984
--------------------------------------------------------------------------------
drbd driver loaded OK; device status:
version: 8.3.2 (api:88/proto:86-90)
m:res    cs         ro                   ds                 p  mounted  fstype
0:mysql  Connected  Secondary/Secondary  UpToDate/UpToDate  C
--------------------------------------------------------------------------------

Related Topics

Command Reference, page C-1

Recovering from a Corrupted MySQL Database

Before You Begin

Make sure that the database servers are correctly cabled. See the "Cabling Requirements for the Database Servers" section on page 4-3.

Complete the "Diagnosing a Corrupted MySQL Database" section to confirm that your system has a corrupted MySQL database.

From the administration console, back up the database. See the "Performing a Manual Database Backup" section on page 23-3.


Caution All data in the MySQL database will be lost during this procedure and will not be recoverable.

Procedure


Step 1 Log in to the CLI of the database server that you want to have the primary HA role.

Step 2 Enter the utils service database drbd force-mysql-reset command.

admin: utils service database drbd force-mysql-reset 
This command will make this node as Primary
This command will make this node as Primary
Trying to assume primary role......... [Done]
Temporarily stopping mon services...
Stopping mon daemon: [FAILED]
Stopping MySQL...
 ERROR! MySQL manager or server PID file could not be found!
Ensuring DRBD volume unmounted...
Rebuilding DRBD filesystem...
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
5898240 inodes, 11796480 blocks
589824 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=12582912
360 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424

Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 21 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
Remounting DRBD volume...
Retrieving backup MySQL files...
Starting MySQL...
Starting MySQL. ERROR! Manager of pid-file quit without updating file.
Starting mon...
Starting mon daemon: [  OK  ]
 [Done]

The server then restarts, is assigned the primary HA role, and initiates the synchronization process.


What To Do Next

From the administration console, restore the database. See the "Restoring a Database Server Backup" section on page 23-4.