On Mon, 15 Mar 2010 10:57:41 +0100, Kristian Nielsen <kniel...@knielsen-hq.org> 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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
