On Thu, Jul 23, 2009 at 7:39 PM, Arjen Lentz<[email protected]> wrote: > Hi Padraig, > > On 24/07/2009, at 9:04 AM, Padraig O'Sullivan wrote: >> >> Yesterday, I created a filtered replicator plugin based on the default >> replicator that Jay developed. It is a simple filtered replicator that >> can currently filter events based on a schema or table name. A user >> can specify a list of tables or schemas to filter replication events >> by. If an event is on a schema or table that is to be filtered, then >> the event will not be passed on to an applier by the replicator. > > Ehm, is that on the side of master, or slave?
It is on the side of the master. Sorry, I should have been clearer. > > As discussed previously, filtering should be done on master, not slave, e.g. > before sending events to slave. > This for security as well as traffic and load considerations. This is exactly how the filtered replicator currently works. I pushed the branch to launchpad if you want to look at it: lp:~posulliv/drizzle/filtered-replicator > Within Drizzle, you could create a filter plugin that can have several > filter profiles, and a slave would subscribe using one (or several?) filter > profiles. > > If the current replication concept doesn't allow this, we should redesign it > ;-) > > > Cheers, > Arjen. > -- > Arjen Lentz, Director @ Open Query (http://openquery.com) > Exceptional Services for MySQL at a fixed budget. > > Follow our blog at http://openquery.com/blog/ > OurDelta: free enhanced builds for MySQL @ http://ourdelta.org > > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
