We have a proposed behavioral change for PXC.  It occurs when PXB specifies it's own encryption settings.

PXB has it's own encryption/decryption methods

In PXC 5.7, this is the basically the same as the SST encrypt=1 setting.

However, when encrypt=0 is used and the xtrabackup options are set, a warning is issued because the SST will fail.  Actually, this should always fail, so I'm not sure why this is set to be a warning.

(it will fail, because the .cnf is not passed to "xtrabackup --prepare", and the prepare doesn't know what to do with the encrypted datadir).  If encrypt=1 is used, the settings are passed via the command-line and will override the command-line settings. If any of the other encrypt modes are used, it will also fail, although no warnings are issued in those cases.

In PXC 8.0, we have removed the encrypt=1 option, so the use of the xtrabackup settings will always fail. I think that our options here are to:

(1) Change the warning into an error (and the check will always be done no matter the encryption settings). Specifying the xtrabackup encryption settings are no longer allowed (when used for an SST).
(2) Keep the encrypt=1 PXC mode.

Since we're moving everything to SSL, I think it's preferable to do (1).  Plus, it will fail when pxc-encrypt-cluster-traffic is enabled.

Also, this used to work with encrypt=1, because this would set the command-line parameters to xtrabackup directly (and didn't need the .cnf file).

If the user uses the encryption options by adding them to the  [xtrabackup] section in my.cnf, this will lead to a failure when doing the prepare on the joiner side (we don't pass the cnf file during the prepare, so the xtrabackup instance will not know what to do with the encrypted data).

So we should also change the warning (when we see xtrabackup encrypt options) to an error, since the joiner will fail.

thanks to kamil for pointing out this warning.