There is two things user need to carefully configure if key rotation is needed:

• --innodb-encryption-rotate-key-age=n ; where n is how old key can be before it is rotated
• --innodb-encryption-threads=n; number of threads used for key rotation

If you have innodb-encrypt-tables=OFF, you can set --innodb-encryption-threads=0. If you have innodb-encrypt-tables=ON|FORCE you still may configure --innodb-encryption-threads=0 but then you may not dynamically set encryption ON|OFF. These threads are also used to convert encrypted tables to unencrypted and unencrypted tables to encrypted if needed. Remember also that new tables using default mode i.e. create table t10() engine=innodb;
will be encrypted using these background threads.

Maybe we should have a new configuration variable to disable key rotation in case user does not really need it, scrubbing is already controlled by configuration variables.

As key rotation is based on key ages, only way to know does tablespace need key rotation or not is to iterate all tablespaces after certain times. Thus, if key rotation is not needed user may set number of background threads to 0 to disable it. That can't be done by default as AWS key management plugin does support key rotation and in InnoDB code base we do not know what plugin is used and does it support key rotation or not. In my opinion current behavior is as designed.

Hi jplindst,

Maybe we should have a new configuration variable to disable key rotation in case user does not really need it, scrubbing is already controlled by configuration variables.

I submitted MDEV-11587 for that feature request, in case you decide to implement that.

Correcting resolution

By design. A new variable can be implemented as an improvement stated in a previous comment.

Re-Tested with 10.1.20, CPU usage still high. The issue identified in MDEV-10368 has reduced the CPU usage by 50% but still very high. System stalls.....

Why you can't set innodb-encryption-threads=0 ? This does not mean that your tables are not encrypted.

Based on your statement - "Remember also that new tables using default mode i.e. create table t10() engine=innodb;
will be encrypted using these background threads.", so if we set innodb-encryption-threads =0, any table created using default mode will not be encrypted as the backgrounds threads are not present.

If you think too much resources are used you can use innodb-encryption-threads=[1|2] but that will make CPU spike longer.

Fine encrypting those default mode new tables do take CPU and it happens on background not immediately. Let me see if we can do something better in case where nothing really happens inside InnoDB i.e. no new tables, no new rows and no selects.

Re-opened because of user request.

We are also unnecessarily creating a redo log checkpoint at startup, which could slow down startup after crash recovery.
MDEV-11782 will remove that checkpoint if the innodb_encrypt_log setting is not changing. (If it is changing, the whole redo log would be rebuilt, and as part of that process, we would complete a checkpoint on the old redo log.)
The purpose of the log checkpoint is to guarantee that the redo log records seen by crash recovery will be either all clear or all encrypted, but not a mix of them.

commit 50eb40a2a8aa3af6cc271f6028f4d6d74301d030
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Tue Mar 14 12:56:01 2017 +0200

MDEV-11738: Mariadb uses 100% of several of my 8 cpus doing nothing

MDEV-11581: Mariadb starts InnoDB encryption threads
when key has not changed or data scrubbing turned off

Background: Key rotation is based on background threads
(innodb-encryption-threads) periodically going through
all tablespaces on fil_system. For each tablespace
current used key version is compared to max key age
(innodb-encryption-rotate-key-age). This process
naturally takes CPU. Similarly, in same time need for
scrubbing is investigated. Currently, key rotation
is fully supported on Amazon AWS key management plugin
only but InnoDB does not have knowledge what key
management plugin is used.

This patch re-purposes innodb-encryption-rotate-key-age=0
to disable key rotation and background data scrubbing.
All new tables are added to special list for key rotation
and key rotation is based on sending a event to
background encryption threads instead of using periodic
checking (i.e. timeout).

fil0fil.cc: Added functions fil_space_acquire_low()
to acquire a tablespace when it could be dropped concurrently.
This function is used from fil_space_acquire() or
fil_space_acquire_silent() that will not print
any messages if we try to acquire space that does not exist.
fil_space_release() to release a acquired tablespace.
fil_space_next() to iterate tablespaces in fil_system
using fil_space_acquire() and fil_space_release().
Similarly, fil_space_keyrotation_next() to iterate new
list fil_system->rotation_list where new tables.
are added if key rotation is disabled.
Removed unnecessary functions fil_get_first_space_safe()
fil_get_next_space_safe()

fil_node_open_file(): After page 0 is read read also
crypt_info if it is not yet read.

btr_scrub_lock_dict_func()
buf_page_check_corrupt()
buf_page_encrypt_before_write()
buf_merge_or_delete_for_page()
lock_print_info_all_transactions()
row_fts_psort_info_init()
row_truncate_table_for_mysql()
row_drop_table_for_mysql()
Use fil_space_acquire()/release() to access fil_space_t.

buf_page_decrypt_after_read():
Use fil_space_get_crypt_data() because at this point
we might not yet have read page 0.

fil0crypt.cc/fil0fil.h: Lot of changes. Pass fil_space_t* directly
to functions needing it and store fil_space_t* to rotation state.
Use fil_space_acquire()/release() when iterating tablespaces
and removed unnecessary is_closing from fil_crypt_t. Use
fil_space_t::is_stopping() to detect when access to
tablespace should be stopped. Removed unnecessary
fil_space_get_crypt_data().

fil_space_create(): Inform key rotation that there could
be something to do if key rotation is disabled and new
table with encryption enabled is created.
Remove unnecessary functions fil_get_first_space_safe()
and fil_get_next_space_safe(). fil_space_acquire()
and fil_space_release() are used instead. Moved
fil_space_get_crypt_data() and fil_space_set_crypt_data()
to fil0crypt.cc.

fsp_header_init(): Acquire fil_space_t*, write crypt_data
and release space.

check_table_options()
Renamed FIL_SPACE_ENCRYPTION_* TO FIL_ENCRYPTION_*

i_s.cc: Added ROTATING_OR_FLUSHING field to
information_schema.innodb_tablespace_encryption
to show current status of key rotation.