Comment 4 for bug 1285380

On 2014-02-28 15:11, Ovais Tariq wrote:
> Hi Alex,
>
> Perhaps we could have an option so that we can control when the state
> transfer times out. Since wsrep_sst_donor now accepts multiple
> hostnames, so timing out the state transfer request on one node, would
> allow PXC to proceed with the SST using the second node. Or does it
> already do it that way?

Yes.

> I have a customer who experienced the long waits when the node
> specified
> for the wsrep_sst_donor option is in desynced state. The node that is
> specified as the donor is also used to do backups and the node is put
> in
> a desynced state when running the backup. Now if a SST is needed at the
> same time that the backup is running, the joiner simply waits.

What was the exact wsrep_sst_donor value? Did it imply failover to some
other node? Otherwise, if that node was the only one in the list and
there was no trailing comma, then it is treated as precise instruction
to use ONLY THAT node for SST and, since that node is busy, what other
option is there but wait?

> --
> You received this bug notification because you are a member of
> Codership, which is subscribed to Percona XtraDB Cluster.
> https://bugs.launchpad.net/bugs/1285380
>
> Title:
> Donor in desynced state makes the joiner wait indefinitely
>
> Status in Percona XtraDB Cluster - HA scalable solution for MySQL:
> Confirmed
>
> Bug description:
> If a particular node is setup to be the donor via setting
> wsrep_sst_donor and the donor node is in desynced state for some
> reason, then the joiner simply waits for the donor to become synced
> again. May be the joiner should error out, or log a message to the
> error log.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1285380/+subscriptions

--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011