Hi!
"Arjen" == Arjen Lentz <arjen@openquery.com> writes:
<cut>
Filtering on current database (or on whatever for row-based) might be more feasible, though there would still be the additional overhead of decoding each event before sending to each slave.
Arjen> Kristian, your comment, while sounding entirely sensible, is beyond Arjen> hilariously funny. Arjen> Because currently, the db filtering works on the default db. Arjen> So if you say ignore-db bar, and your default db is foo, and then you Arjen> do INSERT INTO bar.t1. it'll happily insert. That was something that was done by design and consensus, after talking with developers and user of MySQL. This solved tricky issues when you had statements with more than one database involved. The solution has it's pitfalls, as you showed, but it was then to be best solution we could come up with. But enough about history... Arjen> There's also an intrinsic potential race condition with either method, Arjen> when dealing with multi-table update and delete: Arjen> what do you do if one db is allowed and the other is not? And INSERT .... SELECT ...
But it is good to keep in mind that the general problem has wider scope, thanks for your comment!
Arjen> Ye spending time on the existing stuff just seems like a waste to me. Arjen> I'd rather see something more sensible, even if it's still on basis of Arjen> current db. That'd already be more valuable. We have to work with the existing stuff, as the intention is to be a drop-in replacement of MySQL. There are a lot of users that are depending on the current model and we can't just 'fix' things without thinking through things... So the right way to go forward is with small steps and add do it with new options that doesn't break old behavior. Regards, Monty