Using IP address in donor's socat with TLS/SSL and certificate
which doesn't contain IP address in CN or SubjectAltName causes
transfer to fail with message:
socat[5799] E certificate is valid but its commonName does not
match hostname.
This patch tries to reverse resolve IP address to hostname and
use it for transfer. If reverse resolution fails, IP address is
still used as fall-back, so proper A/AAAA and PTR records are
important, but not mandatory.
Certain certificates cannot contain IP addresses, e.g. FreeIPA's
Dogtag doesn't allow it, so in my case I would need to use self-
signed certificates instead, use verify=0 with socat or don't use
TLS/SSL at all. Issue is mentioned in MDEV-9403.
[Fix taken from https://github.com/percona/percona-xtradb-
cluster/commit/b3ee75949ed82b88f355ca2e26431350cc1c89ac]
During SST, the receiver node creates .sst directory under
datadir to process/prepare the received data and removes it
at the end of the process. In case of error, this directory,
however, was not removed, which later caused subsequent SSTs
to fail. Fixed by removing this directory at the beginning
of SST if it existed.
If any given variable the xtrabackup-v2 sst script looks for is specified
multiple times in cnf file then it tend to pick both of them causing
some of the follow-up command to fail.
Avoid this programatic mistake by honoring only the last variable assigned
setting as done by mysqld too.
Check https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1362830
Semantics:
---------
* Generally end-user will create a separate user with needed
privileges for
performing DONOR action.
* This user credentials are specified using wsrep_sst_auth.
* Along with this user there could be other user(s) created on the
server
that sysadmin may use for normal or other operations
* Credentials for these user(s) can be specified in same
cluster/server
cnf file as part of [client] section
When cluster act as DONOR and if wsrep_sst_auth is provided then it
should
strictly use it for performing SST based action.
What if end-user has same credentials for performing both SST action
and
normal admin work ?
* Then end-user can simply specify these credentials as part of
[client]
section in cnf file and skip providing wsrep_sst_auth.
Issue:
-----
MySQL client user/password parsing preference order is as follows:
* command line (through --user/--password)
* cnf file
* MYSQL_PWD enviornment variable.
Recent change tried passing sst user password through MYSQL_PWD
(and user though --user command line param as before).
On the system where-in admin had another user for performing non-SST
actions,
credentials for such user were present in cnf file under [client]
section.
Due to mysql client preference order, SST user name was used (as it
was
passed through command line) but password of other user (meant for
non-SST)
action was being used as it was passed through cnf file.
Password passed through MYSQL_PWD was completely ignored causing
user-name/password mismatch.
Solution:
---------
* If user has specified credentials for SST then pass them through
command
line so that they are used in priority.
(There could be security concern on passing things through command
line but
when I tried passing user-name and password through command line to
mysql
client and then did ps I saw this
./bin/mysql --user=sstuser --password=x xxxxxxxx -S /tmp/n1.sock
so seems like password is not shown)
- Add CA validation to wsrep_sst_xtrabackup-v2.sh.
- Also added a few {} around tpem for consistency.
- Abort if encryption is requested but socat is not ssl-enabled.
Patch contributed by : Klaas Demter
- LP1380697: wsrep_sst_xtrabackup-v2 doesn't stop when mysql is SIGKILLed. (full fix for this (as engineeered by Percona) requires Linux-specific patch that we don't carry, but keep xtrabackup scripts as close as possible)
- LP1399134: Log the innobackupex/SST logs in SST to syslog if possible. (fixed)
- LP1405668: Race condition between donor and joiner in PXB SST. (fixed)
- LP1405985: Fail early if xtrabackup_checkkpoints is missing. (fixed)
- LP1407599: wsrep_sst_xtrabackup-v2 script causes innobackupex to print a false positive stack trace into the log. (fixed)
- LP1441762: IST Fails with SST script error. (fixed)
- LP1451670: Fail when move-back fails in xtrabackup SST. (fixed)
1. Passes wsrep_sst_auth_value to SST scripts via WSREP_SST_OPT_AUTH envronmental variable, so it never appears on the command line
2. In mysqldump and xtrabackup* SST scripts which rely on MySQL authentication, instead of passing password on the command line, SST script sets MYSQL_PWD environment variable, so that password also never appears on the mysqldump/innobackupex command line.
xargs may split the input and execute them in batches for
large number of files. As a result xtrabackup sst script
may feed incorrect size to pv.
Fixed by piping the files to du directly (du --files0-from=-).
[Based on suggestions from Brad Jorgensen]
xargs may split the input and execute them in batches for
large number of files. As a result xtrabackup sst script
may feed incorrect size to pv.
Fixed by piping the files to du directly (du --files0-from=-).
[Based on suggestions from Brad Jorgensen]
pass --defaults-file and --defaults-extra-file
(whatever was specified, or none)
from mysqld down to SST scripts.
parse these options in SST scripts and pass them down
to mysqldump, my_print_defaults, and xtrabackup
Merged lp:maria/maria-10.0-galera up to revision 3879.
Added a new functions to handler API to forcefully abort_transaction,
producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These
were added for future possiblity to add more storage engines that
could use galera replication.
