Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.1.26
Description
When running on the donor node, the mariabackup and xtrabackup-v2 SST scripts unnecessarily convert the joiner's provided address to its host name. This happens in the following block of code:
setup_ports()
|
{
|
if [[ "$WSREP_SST_OPT_ROLE" == "donor" ]];then
|
SST_PORT=$(echo $WSREP_SST_OPT_ADDR | awk -F '[:/]' '{ print $2 }')
|
REMOTEIP=$(echo $WSREP_SST_OPT_ADDR | awk -F ':' '{ print $1 }')
|
REMOTEHOST=$(getent hosts $REMOTEIP | awk '{ print $2 }')
|
if [[ -z $REMOTEHOST ]];then
|
REMOTEHOST=$REMOTEIP
|
fi
|
lsn=$(echo $WSREP_SST_OPT_ADDR | awk -F '[:/]' '{ print $4 }')
|
sst_ver=$(echo $WSREP_SST_OPT_ADDR | awk -F '[:/]' '{ print $5 }')
|
else
|
SST_PORT=$(echo ${WSREP_SST_OPT_ADDR} | awk -F ':' '{ print $2 }')
|
fi
|
}
|
This is probably not usually a big deal. However, it can cause issues when users try to work around the following socat bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695885
The existing functionality makes it difficult to work around this bug, because even if wsrep_node_address is set to a host name or IP address that is compatible with socat, the SST script might still resolve the provided address to one that causes socat to break with the following error:
2017/12/08 10:33:46 socat[23963] E getaddrinfo("10-1-1-237.mydomain.com", "(null)", {5,2,1,6}, {}): Name or service not known
|
Attachments
Issue Links
- causes
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
Hi anikitin,
I agree with you that we shouldn't necessarily redesign our products to work around 3rd party bugs. However, in this case, it looks like our product might be doing something unnecessary that is causing users to run into a 3rd party bug. Do you have any idea why the xtrabackup-v2 and mariabackup SST scripts do a DNS lookup on the IP address or host name provided by the joiner? It seems unnecessary, since the donor could just use the address provided by the joiner as-is.
As a fix, I believe that we would just need to remove the DNS lookup:
REMOTEHOST=$(getent hosts $REMOTEIP | awk '{ print $2 }')
|
Obviously, if this DNS lookup serves some important purpose, then we probably would not want to do that, but I'm not sure what purpose the extra lookup is supposed to serve.
The folks at Codership pointed out that their xtrabackup-v2 SST script does not contain this DNS lookup, so they are not sure why our script does this. See here:
+1 for removing DNS lookups here too.
Also since the introduction of IPv6 addresses in 83664e21e4fb6755c8c0c90d3dee8819d36928c9 this setup_ports is totally incompatible. Copy it from the xtrabackup-v2, use the variables from wsrep_sst_common. sst_ver probably needs to be handled, wouldn't hurt to put that in wsrep_sst_common too like https://github.com/grooverdan/mariadb-server/commit/3b00d1d2d016f3e7e49b702c7c170e88d60a4471 / https://github.com/grooverdan/mariadb-server/commit/81e243fa8df3a4df648823e184dfe891d0875ad2
MDEV-14030 would remove these divergences.
in 10.1, wsrep_sst_xtrabackup-v2.sh does not even have such setup_ports phase.
So this issue concerns only wsrep_sst_mariabackup.sh. I will remove the REMOTEHOST usage there and prepare a pull request with that
I understand the problem, but don't understand what fix is expected. If Users want to work around some 3rd party bug , then they should be able to modify sst script or create a customised copy of that script and configure Galera nodes correspondingly.