Hi Jay, This really goes against the design that we currently have. There is no requirement for any applier plugin to maintain a store of the messages for later retrieval. And COMMIT_ID really only applies to the InnoDB replication plugin. Each applier is supposed to do something different with the messages. Forcing them each to store in a manner similar to the InnoDB replication plugin seems counterproductive (if I'm understanding your request correctly). If each is doing the same thing, why even bother having more than one? They'd each just be storing the same message.
So the idea behind the applier plugin API is that you don't have to worry about what's going on in the kernel. If you want to store the message locally, great. If not, do whatever you want with it (send it off to another machine, save it in a file, etc). Does that make sense? -Dave On Mon, Apr 18, 2011 at 8:47 PM, [email protected] < [email protected]> wrote: > Hi all, > I've been looking through the replication code and it seems to me that > Drizzle could use a few extra interfaces for plugins to use. I definitely > don't know all the discussion that has already occurred around this, or > exactly how early or not it is in the development of the replication > plugins, so please pardon any ignorance on my part of any master plan in all > this. > > On the master side, it seems like there should be some common api call to > collect data from the replication logs, regardless of how it is stored. The > current 'slave' plugin simply connects to the master and selects off of the > SYS_REPLICATION table, which (I believe) is only updated by the innodb > replicator. Wouldn't it be better to either a) define a common table to > select from and require all master replicator plugins to use that table, or > b) use some SQL construct that says something to the effect of 'GET > COMMIT_ID=x' or equivalent, and let the master plugins implement the hook > for that however it wants. I'm writing this without knowledge whatever SQL > standards that drizzle uses, so excuse me there. This would allow the > plugin to simply focus how to efficiently store (or not) and serve the data > to the slaves as rapidly as possible, and would allow the two existing > master replication plugins to work regardless of the plugin used on the > slave side. > > Similarly on the slave side, some simple api to manage the connection to > the master and get replication data in the standard way above would be > handy, as well as some standard api to 'apply this master commit id that I > have' call. Again, here, I see advantage in plugins focusing on how to > efficiently buffer replication from the master (or not) and apply it to the > local drizzle instance. > > In both cases (master and slave), with the common apis any metadata and > status stored about replication could be done identically (or at least with > separate plugins) so people experimenting with various ways to manage the > replication stream wouldn't have to muck with replication metadata and > vice-versa. This would allow conventions about changing masters, seeing > slave status, etc. to not have to change between plugins unless the > replication model was dramatically different from the standard enough that > those standards wouldn't make sense anyway. > > > Jay Janssen > > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
