On Mon, Mar 19, 2012 at 6:16 PM, Henrik Ingo <[email protected]> wrote: > Might be worth renaming "replicator" to "notification api" or similar > to avoid confusion in the future.
I thought about this some more, it seems depending on use case the replicator thing is also correctly seen as replication-related. I can think of 3 relevant use cases: *asynchronous replication* Best implemented via a fool proof, crash safe, atomically written transaction log, from which slaves read transactions at their leisure. This is exactly what we have. *synchronous replication* Replicator plugin needs to receive events synchronously, at commit time and need to have ability to also reject the commit. There is no need for a transaction log (unless you want it for other reasons) because transactions are immediately committed also on slave nodes. The replicator/applier thing seems to be at least close to this, I don't know the details. But my point is, this is just as much replication as the transaction-log/slave approach, so my suggestion for name change was perhaps premature. *notifications* Anything that is not synchronous and doesn't need a transaction log but still wants to know in a "push" or "notification" style about committed transactions. This could be a plugin that sends (replicates) the transactions to gearman or rabbitmq, or it could be a plugin that creates statistics or an audit log of executed transactions. (How does query_log do it?) Key question here is whether you are ok with missing transactions in the case of crashes. If yes, then it is ok if the api just pushes out protobuf messages as they arrive. If not, (and you probably aren't) then you really need the transaction log again, and the notification api just asynchronously reads the transaction log just like any other slave. (But it can still be provided as a friendly notification api instead of requiring all readers to implement their own code to select from the transaction log directly.) Hence it seems the last use case can be implemented as a subset of either of the previous ones. But there really is need for both synchronous and asynchronous replication modes and they need to be implemented differently. henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
