maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #01075
Re: WL40: Notes/questions
Arjen Lentz <arjen@xxxxxxxxxxxxx> 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.
But it is good to keep in mind that the general problem has wider scope,
thanks for your comment!
(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).
- Kristian.
Follow ups
References