10 messages in com.mysql.lists.mysqlRe: Innodb assertion failure after bi...
FromSent OnAttachments
Sp.Raja23 Jul 2004 06:42 
Sp.Raja23 Jul 2004 07:33 
Sp.Raja26 Jul 2004 07:14 
Heikki Tuuri27 Jul 2004 00:34 
Sp.Raja27 Jul 2004 05:41 
Heikki Tuuri27 Jul 2004 05:51 
Harald Fuchs27 Jul 2004 07:17 
Sp.Raja27 Jul 2004 07:50 
Mark Steele28 Jul 2004 12:48 
Heikki Tuuri28 Jul 2004 22:48 
Subject:Re: Innodb assertion failure after binary backup-restore
From:Heikki Tuuri (Heik@innodb.com)
Date:07/28/2004 10:48:09 PM
List:com.mysql.lists.mysql

Hi!

----- Original Message ----- From: ""Sp.Raja"" <spr@isofttech.com> Newsgroups: mailing.database.myodbc Sent: Tuesday, July 27, 2004 5:52 PM Subject: Re: Innodb assertion failure after binary backup-restore

Thanks for your replies.

Now I have three ways to go

1. replication=20 2. innodb hot backup tool 3. Make sure that no one is writing in to the database and start backup= when modified db pages in "BUFFER POOL AND MEMORY" becomes zero

#FLUSH TABLES WITH READ LOCK still_to_flush=3D1=20=20 while [ $still_to_flush !=3D 0 ] do still_to_flush=3D`/usr/local/mysql/bin/mysql -e "SHOW INNODB STATUS= \G" | grep "Modified db pages" | awk '{print $4}'` sleep 1 done #UNLOCK TABLES

Do you think #3 will work?

not in the general case, since purge or the insert buffer merge may still be running. You must wait that the status of the InnoDB main thread is 'Waiting for server activity'. Then, if you are sure that clients are not doing anything (calling COMMIT, for example), then probably all the buffer pool data has been flushed to files, nothing is being written to the ib_logfiles. I am not absolutely sure about this, I would need to check the code in log0log.c and srv0srv.c. You can then copy the data files and ib_logfiles as-is. To be safe, best that you check also the modification times of the files after copying them. Check that they did not change while you were copying.

Regards, Sp.Raja

Best regards,

Order MySQL technical support from https://order.mysql.com/