Hi Kristian On 02/10/2009, at 5:22 PM, Kristian Nielsen wrote:
Arjen Lentz <arjen@openquery.com> writes:
Current - the binlog options prevent things from getting logged locally, which is bad for point-in-time recovery. - the replicate options work on the slave end, so they still get transmitted which is a) slow and b) potential security issue.
Yes. So we filter either when generating the event or when applying the event. Whereas the better place to filter would be when sending to slave.
Of course, filtering when generating and/or applying is significantly easier, especially for statement-based replication. Since it is at those points we have a parsed statement available. At send-to-slave time we only have the currently selected database, and parsing each statement before sending to each slave may not be the right solution.
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.
Kristian, your comment, while sounding entirely sensible, is beyond hilariously funny. Because currently, the db filtering works on the default db. So if you say ignore-db bar, and your default db is foo, and then you do INSERT INTO bar.t1. it'll happily insert. There's also an intrinsic potential race condition with either method, when dealing with multi-table update and delete: what do you do if one db is allowed and the other is not?
But it is good to keep in mind that the general problem has wider scope, thanks for your comment!
Ye spending time on the existing stuff just seems like a waste to me. I'd rather see something more sensible, even if it's still on basis of current db. That'd already be more valuable.
(In this worklog we are looking at mysqlbinlog, not replication, and this discussion helps clarify why we may want different options in mysqlbinlog from in current replication).
Yea I got that. Still... Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org