On Mon, Mar 25, 2013 at 4:30 AM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> fixes. Meanwhile I've found one more bug in your code. In
>> Gtid_log_event::do_apply_event() you assume that mysql_parse() always
>> succeeds, you don't check thd->is_error(
On Mon, Mar 25, 2013 at 10:39 AM, Pavel Ivanov wrote:
> On Mon, Mar 25, 2013 at 4:30 AM, Kristian Nielsen
> wrote:
>> Pavel Ivanov writes:
>>
>>> fixes. Meanwhile I've found one more bug in your code. In
>>> Gtid_log_event::do_apply_event() you assume th
On Tue, Mar 26, 2013 at 2:45 AM, Kristian Nielsen
wrote:
> So, I did this in my 10.0-mdev26 tree, which is based on 10.0-base. I noticed
> at least two things from your patch that are not part of this:
>
> - The --let $keep_gtid_events= 1 statements. I am not sure how this
>$keep_gtid_events
On Tue, Mar 26, 2013 at 6:48 AM, Kristian Nielsen
wrote:
> The other problem was a wrong locking order seen sometimes in main.plugin,
> should be fixed now also.
Kristian, apparently with the fix to this locking problem you
introduced "variable may be used uninitialized" warning again --
variable
Kristian,
Unfortunately with your recent commit (revision 3546) test
rpl.rpl_gtid_startpos doesn't work when GTID patch is applied on top
of 10.0.1 tarball. It works okay in 10.0-mdev26 though, so I'm not
sure if you'll want to look at the problem now.
In particular the problematic addition is
i
On Thu, Mar 28, 2013 at 2:42 AM, Kristian Nielsen
wrote:
> Kristian Nielsen writes:
>
>> Pavel Ivanov writes:
>
>>> Unfortunately with your recent commit (revision 3546) test
>>> rpl.rpl_gtid_startpos doesn't work when GTID patch is applied on top
>
&g
On Wed, Apr 17, 2013 at 11:14 PM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> Could you please tell me, in your implementation of GTIDs did you make
>> something special for the case when mysql database is replicated? I
>> guess mysql.rpl_slave_state can
On Thu, Apr 18, 2013 at 1:02 AM, Kristian Nielsen
wrote:
>>> To change the
>>> GTID position, use SET GLOBAL gtid_pos='0-1-10', which will update
>>> mysql.rpl_slave_state as needed.
>>
>> Hm... In what situation this could be necessary?
>
> It's not really needed. You might use it to specify star
Kristian,
I can't find the answer to my questions in the code and don't know if
there's some documentation I can use (is there such thing?), so I'm
writing my questions here.
As I understand GTID is constructed as --. Is it guaranteed that sequence numbers are
always increasing inside the domain
, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> As I understand GTID is constructed as -> id>-. Is it guaranteed that sequence numbers are
>> always increasing inside the domain id? So
>
> The intention is that the user/DBA should configure things so that th
Thank you Kristian.
On Wed, May 1, 2013 at 8:19 AM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> What will happen with MariaDB if sem-sync master is enabled, some
>> transactions is completed, but before it gets any semi-sync acks all
>> slaves get disconnected?
This was changed on the way
(http://bazaar.launchpad.net/~maria-captains/maria/10.0-mdev26/revision/3554).
Instead of "CHANGE MASTER TO master_gtid_pos=auto" you need to use
"CHANGE MASTER TO master_use_gtid=1". If you want to actually set
gtid_pos you need to set @@global.gtid_pos.
Pavel
On Wed,
Friendly warning: I've discovered a critical bug in GTID
implementation https://mariadb.atlassian.net/browse/MDEV-4473. So use
the feature carefully.
Pavel
On Wed, May 1, 2013 at 10:30 PM, Kristian Nielsen
wrote:
> Giuseppe Maxia writes:
>
>> I was using:
>>
>> CHANGE MASTER TO master_gtid_pos=
On Fri, May 3, 2013 at 3:26 AM, Kristian Nielsen
wrote:
> In the bug report, you wondered why there are multiple GTIDs for one domain_id
> in Gtid_list_log_event (there is one for each server id).
>
> This is needed to be able to locate any given GTID in the binlogs, without
> relying on sequence
On Fri, May 3, 2013 at 7:45 AM, Kristian Nielsen
wrote:
> Maybe the deeper issue is that you would prefer a design where sequence number
> is assumed unique by itself (or (domain_id, sequence_number) if using
> multi-source). And the code is allowed to silently break if this assumption is
> violat
On Fri, May 3, 2013 at 12:01 PM, Kristian Nielsen
wrote:
>> slave fully synced with master, the last GTID in binlogs (and I guess
>> the value of @@global.gtid_pos) is 0-1-100. Now let's say there's a
>> bug that didn't configure slave read-only, or for whatever other
>> unwanted reason slave got
On Fri, May 3, 2013 at 1:46 PM, Kristian Nielsen
wrote:
>> This is exactly my concern currently (wasn't initially). So let's say
>> as you said above extra transaction was executed when slave was
>> connected, or (more probable case if possible) when IO thread was
>> already disconnected but SQL t
On Fri, May 3, 2013 at 2:05 PM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> Thinking about such situation more it still seems to me that it would
>> be beneficial to have an additional flag that will require for seq_no
>> in GTIDs of committed transactions to be
Kristian,
I've realized that the way slaves are processed now on the master
allows them to connect even if they request non-existent GTID. Is it
"works as intended" and will be different in the "strict mode" or you
didn't want for such things to happen even in non-strict mode?
I've attached a tes
On Sun, May 5, 2013 at 11:09 PM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> I've realized that the way slaves are processed now on the master
>> allows them to connect even if they request non-existent GTID.
>
> What happens here is that S3 requests GTID
Kristian,
You've mentioned that in future implementation of parallel replication
MariaDB will use multiple domains to replicate from one master to a
slave. It means for me that I need to understand how multiple domains
will work. And I realized that I don't know how the following
situation can be
Helping Kristian to answer questions (see below). He can elaborate if
he wish to.
On Tue, May 7, 2013 at 12:52 PM, Alex Yurchenko
wrote:
> On 2013-05-07 17:13, Kristian Nielsen wrote:
>>
>> Alex Yurchenko writes:
>>
>>> From the documentation the purpose of domain ID in GTID is quite
>>> clear.
t in this context), you can
> safely discard server ID from the GTID, no?
>
> Regards,
> Alex
>
>
> On 2013-05-08 02:02, Pavel Ivanov wrote:
>>
>> Helping Kristian to answer questions (see below). He can elaborate if
>> he wish to.
>>
>> On Tue,
hat explicitly by issuing the command START SLAVE
UNTIL. If he issues regular START SLAVE that may mean that he really
wants S4 to be a master and doesn't intend to switch later. And then
he will be surprised why replication doesn't progress.
Pavel
On Wed, May 8, 2013 at 12:22 AM, Kristian
On Tue, May 7, 2013 at 3:52 AM, Kristian Nielsen
wrote:
>> written by the slaves, and thus the name matches, but I wonder if the master
>> should write this table (or a similar one) to keep track of its progress in
>
> Right. Actually, I've carefully avoided writing the table on the master, to
> a
Sorry, I didn't quite understand.
On Sun, May 12, 2013 at 10:24 PM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> I was thinking about your words above and they make me wonder: if we
>> have a master and it doesn't write its current state into
>> rpl_
Thank you, Kristian. Could you please make just one more clarification:
On Mon, May 13, 2013 at 12:02 AM, Kristian Nielsen
wrote:
> At server startup, if we detect that binlog was properly closed and we do not
> need to do crash recovery, the in-memory struct rpl_binlog_state is
> initialised fro
On Mon, May 13, 2013 at 12:08 PM, Kristian Nielsen
wrote:
> I have a hunch that what you are really asking is how to take a backup of the
> master server and restore this on a new server to provision a new slave?
That's right, I'm thinking about taking backup and restoring.
> My intention for th
On Tue, May 14, 2013 at 5:31 AM, Kristian Nielsen
wrote:
> Though I wonder - if you are not copying binlog files, how do you deal with
> transactions inside InnoDB that are in the prepared state when the consistent
> filesystem copy is taken? Normally, the binlog is used to recover correctly,
> by
On Wed, May 15, 2013 at 1:11 AM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> We reaching consistency in the backup by shutting down the server. I
>
> So thinking about this again ...
>
> So if we shut down the server gracefully, copy over everything to a new
>
Kristian,
There's a well-known problem in MySQL that relay_log.info is not
always in sync with the database state, and killing and restarting
server at an unfortunate time will cause it to re-execute last
statement and potentially break replication. Did you fix this
situation with GTIDs and rpl_sl
I'm glad to hear that. :)
On Tue, May 21, 2013 at 2:31 PM, Kristian Nielsen
wrote:
> There is currently a bug when restarting the *master* while the slave is still
> scanning for the GTID start position, but this will be fixed before GA of
> course.
Could you please elaborate what kind of bug is
Thank you for the explanation.
Pavel
On Tue, May 21, 2013 at 10:54 PM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> Could you please elaborate what kind of bug is that?
>
> The slave connects to master with GTID. The binlog dump thread on the master
> starts sca
Kristian,
On Tue, May 21, 2013 at 2:31 PM, Kristian Nielsen
wrote:
>> GTIDs it's really easy to solve the problem -- rpl_slave_state has
>> GTID of the last executed transaction, so on restart one needs just to
>> ignore all relay logs and re-connect to master with the last GTID. Did
>
> Yes. Tha
On Sat, May 25, 2013 at 8:51 PM, Kristian Nielsen
wrote:
>> yet). But from time to time we see failures of rpl.rpl_gtid_crash test
>> with the output like this:
>
> Hm, strange, it does not fail in our Buildbot, which runs hundreds of tests on
> different hosts...
Well, either our build environme
On Sat, May 25, 2013 at 9:06 PM, Pavel Ivanov wrote:
>> I can't think of anything else right now, but if you send the files then
there
>> is a good chance I can say more.
>
> OK. I'll try to catch log files next time this happens.
See logs in attachment. It looks cle
the line "using_gtid=1". After finish of rpl.rpl_gtid_crash it could be
even several lines of extra text with one more line "using_gtid=1" at the
end. So probably you will want to fix this at some point...
Pavel
On Mon, May 27, 2013 at 2:11 AM, Kristian Nielsen
wrote:
> P
On Tue, May 28, 2013 at 4:56 AM, Kristian Nielsen
wrote:
> > 4) Probably with a separate flag we want to prohibit any writes to
> binlog on
> > the slave except from the slave thread(s), i.e. whenever MASTER_HOST is
> > configured server works as if sql_log_bin = 0 globally except for the
> slave
> From the above I'd say:
> 911 928 - number of executed queries (1x LOCK_tdc per query)
> 1 835 243 / 911 928= ~2 - LOCK_open was acquired 2x per query
> 4 194 896 / 911 928= ~4 - LOCK_plugin was acquired 4x per query
>
> Most probably it means that table definition cache is full and every query
>
Kristian,
You have the following comment in the queue_event() in sql/slave.cc:
/*
Do not queue any format description event that we receive after a
reconnect where we are skipping over a partial event group received
before the reconnect.
(If we queued such an event, a
> So suppose now we have a two-statement transaction:
>
> BEGIN; UPDATE t1 SET a=a+1; UPDATE t2 SET b=b-1; COMMIT
>
> and that slave IO thread reconnects in the middle (between the two updates).
>
> First we receive the BEGIN and the first UPDATE and write it to relay log 1:
>
> Format_Desc
VERSION)?
Pavel
On Thu, Aug 29, 2013 at 6:24 AM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>>> But this must be the same problem with normal replication? Whenever the
>>> slave
>>> decides to rotate the relay log, it will write a format description
On Fri, Aug 30, 2013 at 1:44 AM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> The attached patch doesn't work properly because the format
>> description event it saves is different from what master has sent. It
>> has different number_of_event_types and p
Kristian,
Currently MariaDB (as well as MySQL of all previous versions) has a
very big problem related to replicating same server_id. There is
--replicate-same-server-id flag which as I understand (when set to 0)
controls two things:
1) It doesn't allow slave to connect to a master with the same s
On Tue, Sep 3, 2013 at 3:55 AM, Kristian Nielsen
wrote:
>>> If you are interested in helping with testing this, I can write a patch
>>> later,
>>> but I need a way to test it without having to spend unreasonable amounts of
>>> time on it.
>>
>> Sure, I'll be happy to test.
>
> Ok, great.
>
> Atta
On Wed, Sep 4, 2013 at 3:23 AM, Kristian Nielsen
wrote:
>> Thanks. This patch works for me.
>
> Ok, I'll push it then.
I've just noticed that my claim that patch works is based on my tree
which also includes fixes from
https://mariadb.atlassian.net/browse/MDEV-4645, in particular *_3
patch is of
Krisitan,
Did you figure out what would be the best solution here?
Thank you,
Pavel
On Tue, Sep 3, 2013 at 2:05 AM, Kristian Nielsen
wrote:
> Kristian Nielsen writes:
>
>> The main problem I see is what should be the default? I suppose we cannot
>> safely change the default for --replicate-sam
Krisitan,
I found what I think is a bug in IO and SQL thread accounting. How to reproduce:
1) Set up two servers S1 and S2. S1 is a master, S2 is slave with
master_using_gtid = current_pos.
2) Execute some transactions on the master, e.g.
create database d;
create table d.t (n int);
insert into d
s gtid_current_pos is
0-1-1). And now I see even more confusing "The binlog on the master is
missing the GTID 0-1-1 requested by the slave (even though both a
prior and a subsequent sequence number does exist)". I'm sorry, which
prior sequence number exists?
Do you think you can fix
milar. But okay, I
understand your point...
Pavel
On Sun, Sep 15, 2013 at 5:46 AM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> 3. Set gtid_binlog_state and gtid_slave_pos to '0-3-10' on S1 and to
>> '0-1-1' on S2. Try to start slave on S2. Now I get
Here's my approach to fixing both of these problems if you are interested.
Pavel
On Thu, Sep 12, 2013 at 12:14 AM, Pavel Ivanov wrote:
> Krisitan,
>
> I found what I think is a bug in IO and SQL thread accounting. How to
> reproduce:
> 1) Set up two servers S1 and S2. S
Looking at the code it looks like most places (including THD::awake)
assume that thd->mysys_var->current_mutex and
thd->mysys_var->current_cond can be changed only when
thd->mysys_var->mutex is locked. debug_sync.cc is breaking this
assumption. I've found that Item_func_sleep::val_int(),
THD::enter
On Wed, Feb 26, 2014 at 8:12 PM, Michael Widenius wrote:
> Pavel> And then it said that slave died with the stack trace
>
> Pavel> sql/transaction.cc:139(trans_begin(THD*, unsigned int))[0x788e20]
> Pavel>
> sql/log_event.cc:6478(Gtid_log_event::do_apply_event(rpl_group_info*))[0x93a685]
> Pavel>
AFAIK, timestamp for a binlog event is the time when corresponding
statement started to execute. The order of statements in the binlog is
according to the time when statements were committed, which of course
doesn't have anything to do with the time statement started to execute.
That's why timestam
Note that to make CREATE USER atomic mysql.user table will need to be
made to use InnoDB storage engine rather than MyISAM. And that would
involve pretty significant amount of changes throughout the code base.
And yes, MySQL switched mysql.user table (as well as other mysql.*
tables) to use InnoDB
Hi,
I see that in MariaDB 10.0.14 Michael disabled replication safety
warning for the case of INSERT ON DUPLICATE KEY UPDATE with several
unique keys with a comment "We should assume that the store engine
will report the first duplicate key for this case."
http://bazaar.launchpad.net/~maria-captai
t too many unsafe
> logging errors in a short time.
>
> as expected at sql_class.cc
>
>
> This is to not overflow the error log with meaningless errors.
>
> - Each error code is suppressed and counted separately.
> - We do a 5 minute suppression of new errors if we get m
sorry for the delayed reply; I am at a conference in Oxford and
> didn't have an reliable internet connection until now.
>
>>>>>> "Pavel" == Pavel Ivanov writes:
>
> Pavel> Hi,
> Pavel> I see that in MariaDB 10.0.14 Michael disabled replication
;t see how it can be
related to the error suppression. So I think making
LIMIT_UNSAFE_WARNING_ACTIVATION_TIMEOUT configurable would be much
better, though it should apply to all possible error suppressions.
Thank you,
Pavel
On Fri, Oct 17, 2014 at 1:43 PM, Michael Widenius
wrote:
>
> Hi!
&
On Sun, Nov 2, 2014 at 3:27 PM, Michael Widenius wrote:
>>> This is the same order that keys are presented in SHOW CREATE TABLE
>
> Pavel> Why is it safe to assume that keys have the same order on master and
> on slave?
>
> Primary and Unique keys should always be ordered the same way on
> master
n't work for me either.
>
> It did feel a bit strange to not be able to do computer work for more
> than a week, but the lovely people in China who took care of me did
> compensate for that.
>
>>>>>> "Pavel" == Pavel Ivanov writes:
>
> Pavel>
of quality the product that is developed with such principles in
mind can have?
Sergei Golubchik, I believe you are the technical leader of MariaDB
project. Could you please tell me what you think about this issue?
On Tue, Nov 4, 2014 at 6:32 AM, Michael Widenius
wrote:
>
> Hi!
>
>&g
Hi all,
Effective immediately the full opensource tree of changes made to
MariaDB by Google to make it work for our internal applications is
available at https://code.google.com/p/google-mysql/.
Note: I didn't update the main page on the site to reflect the changes
yet, but the sources are there
On Thu, Dec 4, 2014 at 5:49 AM, Kristian Nielsen
wrote:
> I discussed with Monty, and we came up with some more suggested changes for
> the options used to configure the optimistic parallel replication feature
> (MDEV-6676, https://mariadb.atlassian.net/browse/MDEV-6676).
>
> The biggest change is
On Thu, Dec 18, 2014 at 12:24 AM, Oleksandr Byelkin
wrote:
> Hi!
>
> On 18.12.14 08:52, Alexander Barkov wrote:
>>
>> The same behaviour is observed with DROP USER.
>
> IMHO it is general problem for all our "multi-" commands, or it is solved
> somehow for DROP TABLE or multi row INSERT (for examp
On Thu, Dec 18, 2014 at 11:18 PM, Alexander Barkov wrote:
The same behaviour is observed with DROP USER.
>>>
>>> IMHO it is general problem for all our "multi-" commands, or it is solved
>>> somehow for DROP TABLE or multi row INSERT (for example)?
>>
>> Note that I believe this is a general
On Wed, Mar 11, 2015 at 10:10 AM, Sergei Golubchik wrote:
>> diff --git a/mysql-test/t/enforce_storage_engine.test
>> b/mysql-test/t/enforce_storage_engine.test
>> new file mode 100644
>> index 000..80839e2
>> --- /dev/null
>> +++ b/mysql-test/t/enforce_storage_engine.test
>> @@ -0,0 +1,64 @@
I'm not sure why you saw this the first time in two years, I was
seeing this since pretty much the beginning of 10.0:
https://mariadb.atlassian.net/browse/MDEV-4447. And even though the
bug is marked Fixed, Windows line endings have never disappeared from
MariaDB tarballs.
On Thu, May 7, 2015 at 2
68 matches
Mail list logo
