Keeping Your Data Safe: An Introduction to Data-at-Rest Encryption in Percona XtraDB Cluster.
Data breaches are a major concern today. Whether you’re a business owner or value your privacy, the thought of your sensitive information being exposed is unsettling. Fortunately, data-at-rest encryption can help.
Think of it as a sophisticated lock that scrambles your data, making it unreadable to anyone without the proper key. Even if unauthorized individuals access your storage device, they’ll see only gibberish instead of your confidential files.
Percona Server for MySQL implements data-at-rest encryption. That means all data is encrypted before being stored on HDD or SSD and decrypted when it is read from the file to internal buffers. This includes encryption of tablespace, binlog, redo, and undo log files.
Percona XtraDB Cluster, built on top of Percona Server for MySQL, inherits these data-at-rest encryption features. However, until recently (version 8.0.30), there were a few exceptions. These were Record-Set (aka Write-Set) cache files and GCache files. With the release of version 8.0.31, Percona XtraDB Cluster now offers full data-at-rest encryption, providing an extra layer of security for your sensitive information.
This blog post is the first part of a two-part series. Here, we cover the basic idea of Record-Set and GCache encryption and how it works from a user’s perspective. In part two, we go deeper into the technical details, explaining how configuration settings influence the encryption process under the hood.
Record-Set cache
When the transaction runs and DML statements are executed, rows’ keys are collected. These keys will act as the certification key when the transaction is replicated. Additionally, when the transaction is being committed, all binlog events related to it are copied to a dedicated buffer. If the transaction is small, all data fits into RAM memory. But if it is a long, big transaction, certification keys and the data itself may exceed RAM buffer sizes, which will cause disk off-pages creation. This mechanism is described in the Understanding GCache and Record-Set Cache in Percona XtraDB Cluster blog post.
When the transaction is over, Record-Set cache files are deleted; nevertheless, what is important here is that transaction data may reach storage at this point.
GCache
GCache acts as a ring buffer for write sets replicated over the cluster. Its main part is a RingBuffer file (by default named galera.cache). Its size is constant and configurable via the gcache.size parameter. This file’s lifetime exceeds the server’s lifetime, which means that after the server restarts, the RingBuffer file content is still valid.
If the transaction is too big to be stored in RingBuffer, on-demand pages (aka off-pages) are created. These files extend the capacity of RingBuffer. Off-pages are allocated when needed and deallocated as soon as possible. They also do not survive server restarts. The All You Need to Know About GCache (Galera-Cache) blog post describes the internals of GCache, but this is another place where data reaches the storage.
So we’ve got two kinds of places where data is stored:
- Persistent: GCache RingBuffer
- Transient: Record-Set cache off-pages and GCache off-pages
Yet another conclusion is that encrypting short-lived files with a random file key is enough, while for long-lived GCache RingBuffers, we need a mechanism to rotate the encryption key.
In action
First, let’s examine the content of the RingBuffer file. The same is true for GCache and Record-Set cache off-pages, but RingBuffer content is easier to examine because we don’t need huge transactions, and the file lifetime is not limited to the transaction lifetime.
Execute some queries:
|
1 2 3 4 5 6 7 8 |
mysql> create database test; Query OK, 1 row affected (0,08 sec) mysql> use test; Database changed mysql> create table t1 (a int primary key, t text); Query OK, 0 rows affected (0,21 sec) mysql> insert into t1 values (0, "The quick brown fox jumps over the lazy dog"); Query OK, 1 row affected (0,04 sec) |
…and examine the RingBuffer file:
|
1 2 3 4 5 6 |
$ grep -ao "create database test" galera.cache create database test $ grep -ao "create table t1 (a int primary key, t text)" galera.cache create table t1 (a int primary key, t text) $ grep -ao "The quick brown fox jumps over the lazy dog" galera.cache The quick brown fox jumps over the lazy dog |
As we see, all DDL queries are there, and data related to DML queries is also there as opened text.
Now, enable GCache encryption. In my.cnf, add gcache.encrypt option to wsrep_provider_options:
|
1 |
wsrep_provider_options=”<already_existing_options>;gcache.encryption=yes” |
Also, the keyring plugin/component has to be installed. Add the following in my.cnf
|
1 2 |
early-plugin-load="keyring_file=keyring_file.so" keyring_file_data=/mysecret_keyring |
…and restart the server. Enabling/disabling encryption needs the server restart. In such a case GCache content is wiped out.
Execute a new bunch of queries:
|
1 2 3 4 5 6 7 8 |
mysql> create database test2; Query OK, 1 row affected (0,08 sec) mysql> use test2; Database changed mysql> create table t2 (a int primary key, t text); Query OK, 0 rows affected (0,25 sec) mysql> insert into t2 values (0, "The slow brown fox jumps over the lazy dog"); Query OK, 1 row affected (0,04 sec) |
…and examine RingBuffer file:
|
1 2 3 |
$ grep -ao "create database test2" galera.cache $ grep -ao "create table t2 (a int primary key, t text)" galera.cache $ grep -ao "The slow brown fox jumps over the lazy dog" galera.cache |
No open text user-entered content was found.
Similarly, Record-Set cache off-pages encryption is controlled via allocator.disk_pages_encryption parameter specified in wsrep_provider_options.
Other configuration parameters allow you to fine-tune encryption memory consumption and performance, and we examine them in part two of the blog post.
MySQL Performance Tuning is an essential guide covering the critical aspects of MySQL performance optimization.
Unlock the full potential of your MySQL database today!
