Encrypting PXC Traffic

Percona XtraDB Cluster supports encryption for all traffic involved in cluster operation.

Securing Client-Server Communication Traffic

This refers to communication between client applications and cluster nodes. To secure client connections, you need to generate and use SSL keys and certificates.

The following example shows my.cnf configuration for server nodes and client instances to use SSL:



For more information, see the relevant sections about SSL certificates in Galera Cluster Documentation. and MySQL Server Documentation.

Securing SST Traffic

This refers to full data transfer that usually occurs when a new node (JOINER) joins the cluster and receives data from an existing node (DONOR).

For more information, see State Snapshot Transfer.

The following SST methods are available: rsync, mysqldump, and xtrabackup.


This SST method does not support encryption. Avoid using this method if you need to secure traffic between DONOR and JOINER nodes.


This SST method dumps data from DONOR and imports it to JOINER. Encryption in this case is performed using the SSL certificates configured for secure MySQL client-server communication.

Here is how to perform secure SST using mysqldump:

  1. Ensure that the DONOR node is configured for SSL encryption (both [mysqld] and [client] sections). For more information, see Securing Client-Server Communication Traffic.

  2. Create an SSL user on the DONOR node.

    mysql> GRANT USAGE ON *.* TO 'sslsst' REQUIRE SSL;
  3. Specify the DONOR superuser credentials in the wsrep_sst_auth variable.

  4. Start the JOINER node without Galera library (--wsrep_provider=none) and create an SSL user with the same name and grants as on the DONOR node.

  5. Configure SSL encryption on JOINER node with the same parameters as DONOR (both [mysqld] and [client] sections).

  6. Restart JOINER node with Galera library.

If you do everything correctly, mysqldump will connect to DONOR using SSL user, generate a dump file, and import it to JOINER node.

For more information, see the relevant section in Galera Cluster documentation.


This is the default SST method. It uses Percona XtraBackup to perform non-blocking transfer of files. For more information, see Percona XtraBackup SST Configuration.

Encryption mode for this method is selected using the encrypt option. Depending on the mode you select, other options will be required:

  • encrypt=0 is the default value, meaning that encryption is disabled.

  • encrypt=1 enables built-in XtraBackup encryption.


    This mode has been deprecated.


    In this example, you can set encrypt-key-file instead of encrypt-key.

    For more information, see Encrypted Backups.

  • encrypt=2 enables SST encryption based on OpenSSL with the certificate authority (tca) and certificate (tcert) files.


    This mode has been deprecated.


    For more information, see Securing Traffic Between two Socat Instances Using SSL <http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html>.

  • encrypt=3 enables SST encryption based on OpenSSL with the key (tkey) and certificate (tcert) files.


    This mode has been deprecated.


    Certificate verification is not performed in this mode, meaning that the validity of the joining nodes is not checked.

  • encrypt=4 enables SST encryption based on SSL files generated by MySQL.


    This is the recommended mode.


    For more information, see http://dev.mysql.com/doc/refman/5.6/en/creating-ssl-files-using-openssl.html

    The following procedure shows how to generate the ca.pem, server-cert.pem, and server-key.pem files.

    1. To generate the CA certificate:

      openssl genrsa 2048 > ca-key.pem
      openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca.pem
    2. To generate the server certificate, remove passphrase, and sign it:

      openssl req -newkey rsa:2048 -days 3600 -nodes -keyout server-key.pem -out server-req.pem
      openssl rsa -in server-key.pem -out server-key.pem
      openssl x509 -req -in server-req.pem -days 3600 -CA ca.pem -CAkey ca-key.pem -set_serial -1 -out server-cert.pem
    3. (Optional) To generate the client certificate, remove passphrase, and sign it:

      openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem -out client-req.pem
      openssl rsa -in client-key.pem -out client-key.pem
      openssl x509 -req -in client-req.pem -days 3600 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

    There are two ways to deploy SSL files across the cluster:

    • (Preferred) Use the same files for all machines in the configuration. Generate the files on one machine (or use the MySQL-generated files), and copy the files to each node in the cluster. Follow steps (1) and (2) in the previous procedure to manually generate the files.
    • (Alternative) Generate one CA file with separate server certificates signed by that one CA file. Do step (1) to generate the CA file and then do step (2) for each server using the same CA file. So each server will have different server-cert.pem files, but they will all share the same ca.pem file.


    Whatever method you use to generate the certificate and key files, the Common Name value used for the server and client certificates/keys must each differ from that value used for the CA certificate. Otherwise, the certificate and key files will not work for servers compiled using OpenSSL.

    The easiest way to do this is to give the CA file a common name (CN) as follows:

    openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca.pem -subj “/CN=my_cluster_name”


SSL clients require DH parameters to be at least 1024 bits, due to the logjam vulnearability <https://en.wikipedia.org/wiki/Logjam_(computer_security)>. However, versions of socat earlier than 1.7.3 use 512-bit parameters. If a dhparams.pem file of required length is not found during SST in the data directory, it is generated with 2048 bits, which can take several minutes. To avoid this delay, create the dhparams.pem file manually and place it in the data directory before joining the node to the cluster:

openssl dhparam -out dhparams.pem 2048

Securing IST Traffic, Write-Set Replication, and Service Messages

IST refers to transferring only missing transactions from DONOR to JOINER node. Write-set replication is the main workload in Percona XtraDB Cluster whenever a transaction is performed on one node, it is replicated to all other nodes. Service messages ensure that all nodes are synchronized.

All of this traffic is transferred via the same underlying communication channel used by Galera (gcomm). Securing this channel will ensure that IST traffic, write-set replication, and service messages are encypted.

To enable SSL for all internal node processes, define the paths to the key, certificate and certificate authority files using the following parameters:

To set these parameters, use the wsrep_provider_options variable.


For more information, see Index of wsrep provider options.


You must use the same server key and certificate files on all nodes, preferably those used for Securing Client-Server Communication Traffic.

Upgrading Certificates

The following example shows how to upgrade certificates used for securing IST traffic, write-set replication, and service messages, assumig there are two nodes in the cluster:

  1. Restart Node 1 with a socket.ssl_ca that includes both the new and the old certificates in a single file.

    For example, you can merge contents of old-ca.pem and new-ca.pem into upgrade-ca.pem as follows:

    cat old-ca.pem > upgrade-ca.pem && cat new-ca.pem >> upgrade-ca.pem

    Set the wsrep_provider_options variable similar to the following:

  2. Restart Node 2 with the new socket.ssl_ca, socket.ssl_cert, and socket.ssl_key.

  3. Restart Node 1 with the new socket.ssl_ca, socket.ssl_cert, and socket.ssl_key.


Contact Us

For free technical help, visit the Percona Community Forum.
To report bugs or submit feature requests, open a JIRA ticket.
For paid support and managed or professional services, contact Percona Sales.