Comments on: No more MySQL Crash Safe Replication in 5.0 ?

By: Lowercases

Lowercases — Wed, 11 Aug 2010 03:24:30 +0000

An update on this issue.

As reported in http://bugs.mysql.com/bug.php?id=34058, this has since been fixed (this bug was marked as duplicate of http://bugs.mysql.com/bug.php?id=22540) at version 5.0.46.

From two tests conducted on 5.0.91 (latest in 5.0 series):

error log (snipped):
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 517, file name mysql-bin.000002
InnoDB: Last MySQL binlog file position 0 98, file name ./mysql-bin.000002

error log (snipped):
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 1604, file name mysql-bin.000001
InnoDB: Last MySQL binlog file position 0 98, file name ./mysql-bin.000001

The difference is consistently 27, which corresponds to unimportant binlog events:

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 517
#100810 18:54:31 server id 1 end_log_pos 544 Xid = 18
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

Notice that previous value was an unrelated integer.

By: I

Mon, 02 Mar 2009 09:57:08 +0000

Mysql doesn’t have synchronous replication and this sux a lot, since postgres has at least 2 projects with this.

By: peter

peter — Wed, 06 Feb 2008 23:19:16 +0000

Baron did:
http://bugs.mysql.com/bug.php?id=34058 and it is mentioned in the post

By: Konstantin Osipov

Konstantin Osipov — Wed, 06 Feb 2008 23:07:05 +0000

File a bug?

By: mike503

mike503 — Wed, 30 Jan 2008 07:29:17 +0000

I hope it is not a “few years”!

That would be a Microsoft-style release cycle… not an open source one!

In a few years I would expect MySQL to be fully enterprise-ready, with clustering/replication/etc, proxying, etc. all being easy to setup, configure and automate.

I think MySQL is so close on so many fronts already…

By: peter

peter — Wed, 30 Jan 2008 05:32:50 +0000

Mike,

Absolutely. It is best if MySQL Replication would not break in case of power failure and have single command ways to resync slave from the master (or from the slave) if it out of sync for some reason. Until that is done however we have to relay on various scripts and tools and sometimes these tools require certain underlying functionality to do their job.

Google is working a lot with replication safety and deal between Google and MySQL may mean we will see results of those efforts in MySQL mainline in a few years.

By: mike503

mike503 — Tue, 29 Jan 2008 23:56:22 +0000

What I’d like to see is auto-healing replication. Instead of people having to create different custom scripts to do CHANGE MASTER and all that, why can’t something simple be added into the replication protocol itself. Basically you tell a master to replicate to a slave, and the slave marks itself as offline/unusable until it catches up.

I *believe* ibpool does this already (from what the docs say) – it does require some sort of proxy/middle layer to be able to mark servers offline/online, but it would allow a bunch of slaves to basically “subscribe” to the master at any point in time and “catch up” as fast as it can, and once it is caught up, mark itself as open for business.

I think it is close to being there, with tools such as maatkit, ibpool, people’s custom scripts, and replication enhancements. It would be nice to see MySQL actually just build this in so we don’t need those custom things anymore and can rely on MySQL itself to sync itself… that’s been my biggest fear and the reason I have not adopted it yet. Once a slave is out of sync, I have to take the master down, or put it in read-only until the slave catches up…

Help me Obiwan, you’re my only hope!