Clever donor election

Registered by Frederic Descamps on 2013-05-22

It would be great to have a smart mechanism to elect the donor.

For example if you have 3 nodes (A, B and C) and you stop B and C.

If you start the nodes again (one by one), if gcache is large enough, the cluster will promote A as donor and perform IST. Then when C is back online, the cluster may elect B as donor for C and then IST won't be possible and SST will be started even if IST would have been possible if A was chosen as donor.

It would be great that the cluster checks if IST is possible from a donor before electing one.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
milestone icon future-5.5

Related branches

Sprints

Whiteboard

1 )Currently the way I see it,

there are 3 ways a donor is chosen

a) The one who sends the request himself wants to be the
donor. - used by RSU

b) There is already a donor chosen by name. - wsrep_sst_donor (http://www.percona.com/doc/percona-xtradb-cluster/wsrep-system-index.html )

c) Otherwise,

    for (idx = 0; idx < group->num; idx++) {
        gcs_node_t* node = &group->nodes[idx];
        if (status == node->status &&
            strcmp (node->name, GCS_ARBITRATOR_NAME)) // avoid arbitrator
            return idx;
    }

2)
One more thing, wsrep_sst_donor is a dynamic variable.

3)
The simplest way is to try IST with all nodes (or a pre-determined list of nodes) and only then SST.

4) Related bug https://bugs.launchpad.net/galera/+bug/1129512

5) Another related bug https://bugs.launchpad.net/galera/+bug/1147066

I think http://www.codership.com/wiki/doku.php?id=notification_command can be used here to select the oldest.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.