maria-developers team mailing list archive

[Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx>]

On Mon, 15 Mar 2010 10:57:41 +0100, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> 
> Right.
> 
> So if I understand you correctly, with "internal implementation details"
> we do
> not mean just that the APIs expose internals of the SQL server which we
> want
> to shield plugins from. Rather, the way the interface is designed it
makes
> assumptions about how the plugin that will use the iterface will be
> implemented, thus making it unsuitable for other plugins that have other
> ideas about what to do.

Exactly. And it does not only affect plugin construction. It may simply
become hard to see the "forest" behind the implementation detail "trees".
So you really wan to go abstract here.
 
> I had a brief but inspiring discussion with Serg about this at our
meeting
> two
> weeks ago. So basically, what we could aim for is to make the entire
> current
> MySQL replication into a set of plugins. These plugins would be made
> against a
> new plugin interface that would support not only the existing MySQL
> replication for backwards compatibility, but also things like Galera and
> Tungsten, and other ideas. So while the compatibility *plugins* would
> contain
> the legacy MySQL binlog storage and relay service, the plugin
*interface*
> would not.
> 
> I think this is what you had in mind?

I'm afraid that "compatibility plugins" you mention is a bit too
idealistic a picture. My concern is that the current built-in replication
code just cannot be mated with new API extension points. Also it may be
that too many shops have grown dependent on the old style replication and
the drawbacks that it has. So what I had in mind was just to leave current
built-in replication as it is. And then, when a better replacement plugin
is made, just gradually phase it out. From what I understand it is quite
doable. But I think you guys have better judgment here.

>> - It does not care to introduce a concept of global transaction ID.
> 
> Right. As I wrote earlier, this seems to be central to many of the ideas
> involved in this project.
> 
> What I am wondering at the moment is if the concept of global
transaction
> ID
> should be a part of the new API, or if it is really an implemtation
detail
> of
> the reduncancy service.
> 
> On the one hand, if we make it part of the API, can we make it general
> enough
> to support everything we want? For example, some plugin will need the ID
> to be
> generated at the start of a transaction. Some will need it to be
generated
> at
> the end of the transaction.
> 
> On the other hand, if we make it _not_ part of the API, we run the risk
of
> making the API overly general and just pushing the problem down for each
> plugin to try to solve individually.

I'd go about it in the following way. We have an SQL server proper. And it
has a state (database). And it is a state of the server that we want to be
redundant (replicate, log, whatever). The particular server state is
identified by a global transaction ID. From here is follows that global
transaction ID should be the same regardless of the plugin.

It is also quite clear that each plugin will be using its own ID format
internally. E.g. binlogger will be obviously using file offsets and Galera
will be using 64-bit signed integers. Then plugins will just have to
implement their own mapping to the ID defined in API. Which in most cases
will be trivial.

Having a unified global transaction ID is unbelievably good, especially
when you have cascading replication, where each cascade can use its own
plugin. It is so good that you will never ever have any troubles with it,
and no troubles with global transaction ID amounts to nirvana. ;)

Regards,
Alex
-- 
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011