MySQL Bugs: #7440: semi-sync replication

Bug #7440	semi-sync replication
Submitted:	20 Dec 2004 20:12	Modified:	1 Dec 2008 15:18
Reporter:	Dathan Pattishall	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S4 (Feature request)
Version:	4.1.x, 6.0	OS:	Linux (Linux AMD 64 Suse)
Assigned to:	Lars Thalmann	CPU Architecture:	Any

Description:

We want to make a reliable innodb transaction solution with a master slave setup. We have a need to ensure that a transaction returns ok if the transaction block makes it to the slave. It would be nice to have this feature in the advent that I need to move slaves onto a new master incase the primary fails.

Maybe a toggle that allows such a feature. I don't imagine a full-synchronous replication system would work for us since that would slow down the transaction way to much for our environment.

How to repeat:
Feature request for 4.1 branch

Suggested fix:
Feature request for 4.1 branch

Dathan,

thank you for this feature request. A very simple and small patch can add this semi-synchronous replication capability to InnoDB. It is important in making the MySQL replication a transactionally robust mechanism.

Best regards,

Heikki

Is the patch public? We are interested in it.

Mark,

unfortunately, the demand for this feature turned out to be so small that we never finished it.

But it is quite easy to program it yourself into MySQL :).

Regards,

Heikki

Mark,

May I focus your attention on another feature in 4.1, which, although not quite as  good as semi-sync replication is used a lot. It is      * --innodb-safe-binlog
       which adds consistency guarantees between the content of InnoDB tables and
       the binary log.

I think that we will move up to 5.0 and get the even more robust behavior that it provides for the binlog and InnoDB tx log. Both 4.1 and 5.0 provide features that make the binlog robust during server crashes. Semi-sync replication solves a different problem. Sometimes a master becomes unreachable and we don't want to wait for the server to come back to service. In that case, semi-sync replication makes it more likely that the new master doesn't lose any transactions from the old master. While MySQL Cluster also provides that level of service, I am not ready to move to it yet.

This is a very old bug.  We have now pushed the semi-sync interface
into 6.0 and it will be present there.  Semi-sync can then be loaded 
as a separate component.

More info:
https://code.launchpad.net/~hezx/mysql-server/semi-sync-replication
http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication

More info will be added to MySQL Manual.

See also WL#4398.

Semisynchronous replication is documented here:

http://dev.mysql.com/doc/refman/6.0/en/replication-semisync.html