GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

Error unlocking tables at end of backup.

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error unlocking tables at end of backup.

    On a slave server, I'm having a problem with this persistent error condition following a backup. The backup has finished with the InnoDB tables, has locked and flushed the MyISAM tables successfully, and has even completed backing up the MyISAM tables. Following this, the statement to unlock tables is sent and an error is produced. I'm hoping someone may have some advice how to get around this problem.

    Here is the output at the point of the error:


    111209 08:12:44 innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt filesinnobackupex: Resuming ibbackupxtrabackup: The latest check point (for incremental): '148:282374854'>> log scanned up to (148 282374854)xtrabackup: Transaction log of lsn (148 131244836) to (148 282374854) was copied.innobackupex: Error: mysql child process has died: ERROR 2006 (HY000) at line 13: MySQL server has gone away while waiting for reply to MySQL request: 'UNLOCK TABLES;' at /usr/bin/innobackupex line 336.


    The server is still running fine, except that innobackupex exits and leaves the Slave SQL thread down. So, I've had to go in and restart it manually. The time between locking the tables and unlocking them is approximately 12 minutes. Could this be a timeout issue of some kind?

    Thanks,
    Dave

  • #2
    Looks like it is a timeout issue. An upcoming release has some timeout fixes that might resolve this.

    Comment


    • #3
      Thanks, Baron. I'll be on the lookout for an update.

      Comment


      • #4
        Do you have any idea about till when this new version of slave server will be released??

        Comment


        • #5
          A beta should be released this month, from what I understand. However, this is a forward-looking statement and might not be true

          Comment

          Working...
          X