IST fallback to SST due to safe_ist_seqno

Hi,

i have a 5 nodes xtradb cluster with a high write workload 24h.
when a node fails for some reason, also if the gap could be served with a simple IST, often a SST is used instead (every node has about 7TB of data) and the node take about 2 days to sync.

i don’t know why, but here is the error log during the node startup:

2019-04-17T15:49:21.509734Z 1 [Note] WSREP: REPL Protocols: 8 (3, 2)
2019-04-17T15:49:21.509766Z 1 [Note] WSREP: New cluster view: global state: e604082f-bad8-11e6-80fd-fb21290a813a:1382209925, view# 548: Primary, number of nodes: 5, my index: 3, protocol version 3
2019-04-17T15:49:21.509791Z 1 [Note] WSREP: Setting wsrep_ready to true
2019-04-17T15:49:21.509807Z 1 [Warning] WSREP: Gap in state sequence. Need state transfer.
2019-04-17T15:49:21.509824Z 1 [Note] WSREP: Setting wsrep_ready to false
2019-04-17T15:49:21.510054Z 0 [Note] WSREP: Initiating SST/IST transfer on JOINER side (wsrep_sst_xtrabackup-v2 --role ‘joiner’ --address ‘easycluster4’ --datadir ‘/var/lib/mysql/data/’ --defaults-file ‘/etc/mysql/my.cnf’ --defaults-group-suffix ‘’ --parent ‘9260’ ‘’ )
encryption: using gcrypt 1.6.3
2019-04-17T15:49:23.781314Z 0 [Note] WSREP: (ab378b91, ‘tcp://0.0.0.0:4567’) turning message relay requesting off
2019-04-17T15:49:23.815028Z 1 [Note] WSREP: Prepared SST/IST request: xtrabackup-v2|easycluster4:4444/xtrabackup_sst//1
2019-04-17T15:49:23.815080Z 1 [Note] WSREP: Auto Increment Offset/Increment re-align with cluster membership change (Offset: 1 → 4) (Increment: 1 → 5)
2019-04-17T15:49:24.950137Z 1 [Note] WSREP: Assign initial position for certification: 1382209925, protocol version: 3
2019-04-17T15:49:24.950338Z 0 [Note] WSREP: Service thread queue flushed.
2019-04-17T15:49:24.950402Z 1 [Note] WSREP: Check if state gap can be serviced using IST
2019-04-17T15:49:24.950620Z 1 [Note] WSREP: IST receiver addr using tcp://easycluster4:4568
2019-04-17T15:49:24.951090Z 1 [Note] WSREP: Prepared IST receiver, listening at: tcp://10.0.0.82:4568
2019-04-17T15:49:24.951134Z 1 [Note] WSREP: State gap can be likely serviced using IST. SST request though present would be void.
2019-04-17T15:49:24.952964Z 0 [Note] WSREP: may fallback to sst. ist_seqno [1382202371] < safe_ist_seqno [1382204329]
2019-04-17T15:49:24.953001Z 0 [Note] WSREP: Member 3.0 (DBEasyUnix4) requested state transfer from ‘any’. Selected 0.0 (DBEasyUnix3)(SYNCED) as donor.
2019-04-17T15:49:24.953025Z 0 [Note] WSREP: Shifting PRIMARY → JOINER (TO: 1382209930)
2019-04-17T15:49:24.953070Z 1 [Note] WSREP: Requesting state transfer: success, donor: 0
2019-04-17T15:49:24.953097Z 1 [Note] WSREP: GCache history reset: e604082f-bad8-11e6-80fd-fb21290a813a:0 → e604082f-bad8-11e6-80fd-fb21290a813a:1382209925
2019-04-17T15:49:28.372694Z WSREP_SST: [INFO] Proceeding with SST…

first the error log says “State gap can be likely serviced using IST. SST request though present would be void.”
but later says “may fallback to sst. ist_seqno [1382202371] < safe_ist_seqno [1382204329]”

what is safe_isd_seqno is? and how can i avoid SST?