Comments on: Getting rid of huge ibdata file, no dump required

By: shlomi

shlomi — Fri, 09 Nov 2012 04:34:16 +0000

@Michael,
Incorrect. The entire process runs on a slave; you loose none of InnoDB’s transactional features (except durability in case of crash in the middle of the process – but then you can start again).

The slave is single threaded (up to 5.5) and couldn’t care less about transactions on master. A failed transaction never reaches it. A committed transaction is just another command to execute.

I think you may be confusing with running this process on the master, which is entirely not something discussed here.

By: Michael Mior

Michael Mior — Thu, 08 Nov 2012 21:06:36 +0000

The bigger issue is that you lose all the transactional features of InnoDB while this process is taking place and your application is none the wiser. Not to mention the differing performance characteristics of the two storage engines.

While this can certainly be useful in some scenarios, you need to think very carefully as to whether your application can tolerate this kind of change.

By: shlomi

shlomi — Tue, 22 May 2012 13:58:40 +0000

Holger,
I’ve seen some cases where it would simply take too much time (two weeks or more) to dump and restore, and disk space would not be available to accommodate all binary logs.
Setting up a chain of slaves is another option, with longer pipes to accommodate all binary logs.

By: Holger Thiel

Holger Thiel — Tue, 22 May 2012 13:36:36 +0000

Hello,

This is a tricky and dangerous idea. The replication is in danger to break as the statement based replication is in need.

Normally another slave on the same machine can be installed and used to be built up.

Regards,
Holger