Thread Previous • Date Previous • Date Next • Thread Next |
Hi, On 08/12/2013 02:59 PM, Kristian Nielsen wrote:
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 ?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.
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.
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.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.
R: Jan
Thread Previous • Date Previous • Date Next • Thread Next |