Mailing List Archive: development for fully supporting multi-master-replication of dbmail data with multiple nodes

I am running dbmail 3.0.2 in a MySQL multi-master (2) replication
configuration.

I understand that this will work fine as long as the IMAP unique_id does
not become invalid due to the same user connecting to both nodes
concurrently or because of a failure in the replication and the user
connecting to both nodes during the fault.

I understand that a proposed resolution to these issues is discussed here:

http://www.dbmail.org/dokuwiki/doku.php/unique_id_guid

Can someone confirm that this *is* the current status of full support
for complete multi-head database replication? Namely, "that this is the
last thing holding DBMail back from a complete failover system using
MySQL replication"? (Quoted from the URL'ed page.)

I am willing to pay for this development to be done... if someone here
would like to do it. Any takers? Let me know how much you want for the
work. Otherwise, I am willing to do the development, myself, pointers
appreciated.

(I recognize that 3.0.2 isn't the latest release. It is just the latest
one in Fedora which I installed via 'yum'. I am willing to update, of
course.)

Thanks,

Lee.
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev

On 05-03-14 03:12, Lee Howard wrote:
> I am running dbmail 3.0.2 in a MySQL multi-master (2) replication
> configuration.
>
> I understand that this will work fine as long as the IMAP unique_id does
> not become invalid due to the same user connecting to both nodes
> concurrently or because of a failure in the replication and the user
> connecting to both nodes during the fault.

It's not just concurrent connections by the same user, iirc. Basically,
IMAP relies on consistency at the storage level. Any change to a mailbox
or message should be visible in the same way to all connected clients.
However, in case of asynchronous replication that becomes just about
impossible: no way to tell if the slave has caught up with the master.

One proposal was to introduce a token-passing mechanism that would be
used to implement two-phased commit style transactions at the
application layer: ask the broker to generate a new primary key which
doesn't return until it was successfully inserted on all the
participating nodes. Given the complexity of such a solution it was
never actually attempted. Of course, now we're 10 years later and there
are some good tools to build such stuff, but also, two-phase commits are
now provided by most rdbm systems.

> I understand that a proposed resolution to these issues is discussed here:
>
> http://www.dbmail.org/dokuwiki/doku.php/unique_id_guid

That page references a lot of email threads urls that are no longer
available. But yes, this was discussed quite extensively.

> Can someone confirm that this *is* the current status of full support
> for complete multi-head database replication? Namely, "that this is the
> last thing holding DBMail back from a complete failover system using
> MySQL replication"? (Quoted from the URL'ed page.)

No idea who wrote that.

> I am willing to pay for this development to be done... if someone here
> would like to do it. Any takers? Let me know how much you want for the
> work. Otherwise, I am willing to do the development, myself, pointers
> appreciated.

I would put my money on synchronous replication. So mariadb or mysqldb
with galera.

http://codership.com/content/using-galera-cluster

--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
www.nfg.nl/info@nfg.nl/+31.85.877.99.97
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev