maria-developers team mailing list archive

[Simon Mudd <simon.mudd@xxxxxxxxxxx>]

Hi Kristian,

> On 21 Oct 2016, at 13:22, Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> wrote:
> 
> Simon Mudd <simon.mudd@xxxxxxxxxxx> writes:
> 
>> I have not looked at the code in detail but a couple of questions
>> related to the implementation come to mind:
> 
> The author is probably the best to answer, but I can tell what I know from
> reviewing the patch:
> 
>> (1) Why not use a single compressed event type and encapsulate the whole original event inside ?
> 
> This would result in higher overhead on each event. There is a fixed header
> to each event, which cannot be compressed (without significantly more
> changes to the code, at least). Thus, a single event encapsulating another
> full compressed event would require two headers, one uncompressed and one
> compressed.

Ok. I’ve been assuming the headers were small (from some casual browsing of things
related to the binlog router some time ago), but that may be wrong.

> There might be other pros and cons to each method, this was just what
> occured to me.
> 
>> Is it not possible to have a "generic compressed event”? Mark mentions
>> allowing selection of the compression type and that seems useful and I
>> would expect the the compressed event to have this information and the
>> compressed content.
> 
> The current patch has reserved three bits for the compression method. Thus,
> it would be possible in the future to add more compression types (up to a
> maximum of 8, at least).

Ok. good to know.
> 
> Actually, it would be good if the code would check the compression type and
> fail if it is unknown. This will help get proper errors on old slaves if new
> compression types are added in the future.

Indeed, one of the things about the current binlog format is that there’s little
complete documentation outside of the code. Code changes and there’s no
clear specification. It makes things much better if what’s currently implicit is
explicit and also if the specs are outside of the code.  That’s something I
tried to mention to Oracle with the new X protocol and obviously out of scope of
this discussion but the intricacies of the binlog traffic are quite hard to follow
for mere mortals…

> 
>> (2) Senders would try to compress the event as requested. If the
>> compressed event is not any smaller then do not bother compressing it,
>> just send the original event.
> 
> This is not in the current patch, but it could be added easily enough. It
> might not be needed though, the log_bin_compress_min_len kind of serves a
> similar purpose.

It just saves the receiver doing extra work and I’d expect that allowing that
would be trivial even if not implemented now. Just a thought anyway.

…

>> Perhaps I am missing something but the need to compress events
>> individually probably requires quite a bit more logic and will not be
>> as extensible.
> 
> Perhaps. In any case, the patch at hand is based on individually compressed
> events. Even with individual event types, the patch is nice and clean and
> leaves much of the existing logic unchanged.
> 
> My guess is that this will primarily be useful for row-based binlogging,
> where reasonable compression rates can be expected in many cases where
> row-based binlogging has particularly high overhead compared to
> statement-based. Per-event compression is in any case of limited use for
> events that are small in size.

Sure so workload clearly affects the usefulness of a patch such as this one.
That said I’ve seen SBR traffic with very large packets as many bulk changes
are massaged to fit to max_allowed_packet, so here even in SBR you can
make a huge size saving if you have such statements.

Minimal RBR can help reduce some of the space concerns that RBR generates,
and I use it a lot (and requested this functionality) specifically for this reason.
However there are use cases where it can not be used (exporting data to
external systems that may need/want to have the whole “change log stream”)
so clearly compression here may be a good bit of extra functionality.

Fixing the case for RBR is good but I feel the focus may be too narrow,
especially if the approach can be used more generically.

I certainly have some SBR machines which generate large volumes of bin logs
and to be able to compress the events they generate on disk would be most helpful.

Thanks for sharing your thoughts.

Simon