On 9/6/08, Arjen Lentz <[EMAIL PROTECTED]> wrote:

> Actually, replication filtering came up a few weeks back, and I noted that
> it's annoying to have the filtering either client-side or messing with what
> gets logged on the server-side. In the brief discussion that followed we
> found that a) people agreed with the assessment and b) the general consensus
> was that we could make a slave-configured filtering profile that gets sent
> to the master on connect which then gets used for that slave connection.
> So while this is new foo, it seriously cleans up all the replicate/ignore
> blah which is, really, a big ugly mess to deal with in the real world.
>
> I'd much prefer a blueprint in this direction, rather than tweaking the
> brokenness.


Arjen,

Since you have the knowledge, feel free to make a blueprint....

I'm confused as to how "a slave-configured filtering profile" is different
from the current "replicate/ignore blah" that MySQL currently has.  Isn't it
just a "better" form of "ignore blah"?  (and the only reason the
"replicate/ignore blah" is hard to deal with in the real world is because 1)
you have 2 choices, either "don't log" (bad idea!) or "don't apply" (good
idea), and 2) before community version 5.0.67, they didn't actually work
(and I've yet to test in 5.0.67, though it was fixed in an earlier
Enterprise version, so I'd hope it got into the Community stack as well).

-Sheeri
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to