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 servers). Nor do I enforce or rely on
absence of holes in the sequence numbers.
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
particular position. How do you know that there is really a hole in GTID
numbers instead that you started slave from incorrect position ? If you
set the starting point to the real hole, what happens, is the
replication started from next real GTID or from the beginning ?
Users could use GTID as a way to verify the slave state consistency
using their own software. If the actual implementation does not allow
this, it makes creating cluster replication state monitoring software
very hard to implement.
This decision was a hard one to make and I spent considerable thought on this
point quite early. It is true that this design reduces possibilities to detect
some kinds of errors, like missing events and alternate futures.
I found alternate futures also disturbing, in database field that would
mean that one server is on one state and another in different state and
that would lead to state where you do not know which one is consistent
or both are inconsistent.
R: Jan
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
