Hi all,
> On 8 Sep 2017, at 16:48, andrei.el...@pp.inet.fi wrote:
>
> Kristian, hello.
>
> Now to the implementation matter,
>
>> The procedure to fix it will then be:
>>
>> 1. FLUSH BINARY LOGS, note the new GTID position.
>>
>> 2. Ensure that all slaves are past the problematic point with
>
Hi Kristian,
Sorry for the late response.
> On 12 Sep 2017, at 10:21, Kristian Nielsen wrote:
>
> Simon Mudd writes:
>
>> ids. Obviously once all appropriate bin logs have been purged
>> (naturally by other means) then no special processing will be needed.
>
>
Hi Andrei,
> On 25 Sep 2017, at 20:17, andrei.el...@pp.inet.fi wrote:
...
> the "vanilla" FLUSH-LOGS is not binlogged by decision commented in
> reload_acl_and_cache():
In the normal case I think it makes sense to not trigger another flush and to
not binlog the command.
> if (options & REFRES
Hi,
> On 2 Sep 2018, at 11:27, Sachin Setiya wrote:
>
> Hi Everyone!
>
> Suppose this case
>
> CREATE USER
> user1@localhost IDENTIFIED BY 'BsG9#9.cem#!85',
> user2@localhost IDENTIFIED BY 'x';
>
> user2 has too short passowrd which will give error (if we use security plugin)
>
> IN the ca
omehow can be used or verified later?
> Questions by Simon Mudd.
…
>>> * this behaviour should be configurable?
> Yes.
>>> - new global variable on the master to allow injection of this changed
>>> event stream?
> Right , `BINLOG_SPLIT_ALTER`
>>> - a new
Hi,
Compressed binlogs are something that have interested me for some time[1] so it
is nice to see patches which provide this functionality.
I have not looked at the code in detail but a couple of questions related to
the implementation come to mind:
(1) Why not use a single compressed event
Hi Kristian,
> On 21 Oct 2016, at 13:22, Kristian Nielsen wrote:
>
> Simon Mudd 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, b
> On 21 Oct 2016, at 17:34, Kristian Nielsen wrote:
>
> Simon Mudd writes:
>
>>> This would result in higher overhead on each event. There is a fixed header
>
>> Ok. I’ve been assuming the headers were small (from some casual browsing of
>> things
>&
Hi,
On 28 Oct 2016, at 06:18, 陈福荣 mailto:vinche...@gmail.com>>
wrote:
Thanks for knielsen's nice replay. I would like to add some comments
…
>> (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 sen
9 matches
Mail list logo
