So, you keep insisting that it's important to have information about
server_id of all servers that ever were a master for the database even
with gtid_strict_mode = 1. :(
I don't agree with that, because I believe this information can be
useful only in circular replication or something similar. But
Pavel Ivanov piva...@google.com 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 error slave has
diverged. What gives? It's not diverged, it's just behind.
Yes, it is diverged.
S1 has binlog state '0-3-10'. This
Kristian,
I'm sorry for reviving this old thread, but I think it still doesn't
work correctly. So I took the latest 10.0-base (rev 3690) and started
to simulate different situations when slave is restored from backup
that is too old and thus it can't replicate from master. I've setup
servers S1
Pavel Ivanov piva...@google.com writes:
I took 10.0-base r3685. Started new just bootstrapped server with
server_id = 1. It has @@global.gtid_binlog_pos,
@@global.gtid_slave_pos and @@global.gtid_current_pos empty. Then I
execute
set global gtid_binlog_state = '0-10-10'
After that
Pavel Ivanov piva...@google.com writes:
Could you say are you working on these? Is there an ETA?
This is blocking us from pushing MariaDB into testing in the
near-production environment, and I'm hesitant to implement fixes
myself because I'd think you'll do it completely differently.
If you
Kristian Nielsen kniel...@knielsen-hq.org writes:
If you have time to test this then that would be a nice help. I'll see if I
can come up with a quick patch (ie. later today or tomorrow).
Please try this patch and let me know if you find any issues. I still need to
implement test cases, but it
Pavel Ivanov piva...@google.com writes:
I think to fix this bug we should stop using gtid_slave_pos as
indication of the current db state. We should make it possible to
Agree.
change gtid_binlog_pos when there's no events in binlogs. And when
Ok. Actually, I think we should expose the real
Pavel Ivanov piva...@google.com writes:
Have I misunderstood what you said?
Yes, totally :-(
By that you are basically saying: I need to support those
who set up lousy multi-master replication, thus I won't treat
domain_id as a single replication stream, I'll treat a pair
(domain_id,
Vilho Raatikka vilho.raati...@skysql.com writes:
Is this documented profoundly already? Should be because probably we'll see
at least some users as ignorant as I am asking the same questions soon.
I wrote up some comprehensive documentation in the knowledgebase, and also
wrote a series of
SHOW VARIABLES or SELECT @@GLOBAL.gtid_strict_mode will show the current
value. But there is no way to check if it was enabled eg. two weeks ago, if
that is what you are asking (the value is not stored in the binlog).
That is really pity. Is it really so useful to give the user opportunity to
Jan Lindström jplin...@mariadb.org writes:
I found this disturbing and not fully follow what kind of holes are
possible. These GTIDS can be used by human users to start slaves on
For example, if you use some of the many filtering options, like
--replicate-ignore-*. Then there will be GTIDs on
Pavel Ivanov piva...@google.com writes:
Note that the patch I've attached have test case that should reproduce the
problems.
Thanks, I've now gone through the testcases also. Let me number the individual
tests as follows:
1. Check that gap in seq_no without binlogs doesn't allow to replicate
Hi,
On 08/13/2013 09:49 AM, Kristian Nielsen wrote:
You can always use the contents of the binlogs to know this. You can
search the binlogs for your GTID and determine if it was a) logged in
an earlier binlog that was purged, b) found in the binlog, c) a hole
due to filtering or whatever, or
Jan Lindström jplin...@mariadb.org writes:
Hi,
On 08/13/2013 09:49 AM, Kristian Nielsen wrote:
You can always use the contents of the binlogs to know this. You can
search the binlogs for your GTID and determine if it was a) logged
in an earlier binlog that was purged, b) found in the
Vilho Raatikka vilho.raati...@skysql.com writes:
What exactly does it require for the user to enable strict or 'relaxed'
(=disasterous imho) mode?
Technically, one needs to SET GLOBAL gtid_strict_mode=1 with root privileges
(config file option works as well of course). That's it.
The
Kristian Nielsen kniel...@knielsen-hq.org writes:
BTW, for the normal non-advanced user, I think silly stuff like running random
manual transactions on slaves that get into the binlog is a far more common
mistake. Gtid strict mode will cause errors on this, so it needs to be
explictly enabled
I took a close look at your patch for MDEV-4820.
I think there is a fundamental disconnect. In MariaDB GTID, I do not require
or rely on monotonically increasing seqeunce numbers (monoticity is requred
per-server-id, but not between different servers). Nor do I enforce or rely on
absence of holes
Hi,
On 08/12/2013 02:59 PM, Kristian Nielsen wrote:
I took a close look at your patch for MDEV-4820.
I think there is a fundamental disconnect. In MariaDB GTID, I do not require
or rely on monotonically increasing seqeunce numbers (monoticity is requred
per-server-id, but not between different
18 matches
Mail list logo
