wsrep_sst_xtrabackup-v2 script, longer sleep needed before SST

[Thomas Daugherty]

In file/script wsrep_sst_xtrabackup-v2, there is a sleep before SST, which is set to 10 seconds be default. However on my systems it takes longer than 10 seconds for the joiner to delete existing files, before it start the socat receiver. To the donor waits 10 seconds, then tried to connect via socat to the joiner, which hasn't yet run socat.

I would say this sleep needs to be at least 20 seconds, to allow time to remove existing files on the joiner side.

        wsrep_log_info "Sleeping before data transfer for SST"
        sleep 10

percona-xtrabackup-2.2.3-4982.el6.x86_64

Running on RHEL 6.6.

[Nilnandan Joshi (nilnandan-joshi)]

Verified. Its hardcoded.

<code>
...
        tcmd="$ttcmd"
        if [[ -n $progress ]];then
            get_footprint
            tcmd="$pcmd | $tcmd"
        elif [[ -n $rlimit ]];then
            adjust_progress
            tcmd="$pcmd | $tcmd"
        fi

        wsrep_log_info "Sleeping before data transfer for SST"
        sleep 10

        wsrep_log_info "Streaming the backup to joiner at ${REMOTEIP} ${SST_PORT:-4444}"

        if [[ -n $scomp ]];then
            tcmd="$scomp | $tcmd"
        fi

...
<code>

[Raghavendra D Prabhu (raghavendra-prabhu)]

This is not a PXB bug, reported in wrong component.

[Raghavendra D Prabhu (raghavendra-prabhu)]

This issue has been fixed elsewhere, will be pushed to experimental repo in a few days.

[Przemek (pmalkowski)]

IMHO hardcoding such timeout is not the best idea. It may happen that in one case 3 seconds will be fair enough, but in others it may take even 30 seconds or more. But this is not the reason to make the SST wait for let's say 60 seconds in all cases even if not necessary. Why can't the script on the donor do a several retries if the joiner is ready? Some kind of SST readiness negotiations before the real transfer starts and then just long enough timeout if failed?

[Raghavendra D Prabhu (raghavendra-prabhu)]

No, it has not been hardcoded in the fix, nor the fix depends on it.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1793