Bug #85969 Failed to start after killing MySQL with undo + redo log encryption enabled
Submitted: 17 Apr 2017 7:38 Modified: 19 Nov 2017 12:50
Reporter: Shahriyar Rzayev Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious)
Version:8.0.1 OS:Linux
Assigned to: CPU Architecture:Any

[17 Apr 2017 7:38] Shahriyar Rzayev
Description:
Hi dear all,
After reading:

http://mysqlserverteam.com/the-mysql-8-0-1-milestone-release-is-available/

Tried to enable undo and redo log encryption, here is the config:

[mysqld]
early-plugin-load=keyring_file.so
keyring_file_data=/home/shahriyar.rzaev/sandboxes/msb_8_0_1/tmp/keyring

innodb_redo_log_encrypt=ON
innodb_undo_tablespaces=77
innodb_undo_logs=77
innodb_undo_log_encrypt=ON

And it is started as expected:

2017-04-17T07:03:15.602545Z 1 [Note] InnoDB: Read redo log encryption metadata successful.
2017-04-17T07:03:15.646958Z 1 [Note] InnoDB: Creating UNDO Tablespace Data file .//undo148
2017-04-17T07:03:15.646977Z 1 [Note] InnoDB: Setting file .//undo148 size to 10 MB
2017-04-17T07:03:15.646980Z 1 [Note] InnoDB: Physically writing the file full
2017-04-17T07:03:15.746673Z 1 [Note] InnoDB: Undo log encryption is enabled.

Trying to encrypt table and while doing this I have killed MySQL with -9:

> alter table sbtest1 encryption='Y';
ERROR 2013 (HY000): Lost connection to MySQL server during query

The result:

2017-04-17T07:12:04.224396Z 1 [Note] InnoDB: Read redo log encryption metadata successful.
2017-04-17T07:12:04.225692Z 1 [Note] InnoDB: Log scan progressed past the checkpoint lsn 1215614189
2017-04-17T07:12:04.318112Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1220856832
2017-04-17T07:12:04.409770Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1226099712
2017-04-17T07:12:04.503264Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1231342592
2017-04-17T07:12:04.597369Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1236585472
2017-04-17T07:12:04.694239Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1241828352
2017-04-17T07:12:04.788307Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1247071232
2017-04-17T07:12:04.882653Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1252314112
2017-04-17T07:12:04.975955Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1257556992
2017-04-17T07:12:05.067409Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1262799872
2017-04-17T07:12:05.091107Z 1 [Note] InnoDB: Read encryption metadata from ./sbtest/#sql-2402_4.ibd successfully, encryption of this tablespace enabled.
2017-04-17T07:12:05.163462Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1219546112
2017-04-17T07:12:05.257656Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1224788992
2017-04-17T07:12:05.353259Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1230031872
2017-04-17T07:12:05.450112Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1235274752
2017-04-17T07:12:05.546873Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1240517632
2017-04-17T07:12:05.643414Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1245760512
2017-04-17T07:12:05.741763Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1251003392
2017-04-17T07:12:05.837505Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1256246272
2017-04-17T07:12:05.932143Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1261489152
2017-04-17T07:12:06.026912Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1266732032
2017-04-17T07:12:06.063717Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1268755203
2017-04-17T07:12:06.064344Z 1 [Note] InnoDB: Database was not shutdown normally!
2017-04-17T07:12:06.064350Z 1 [Note] InnoDB: Starting crash recovery.
2017-04-17T07:12:06.118888Z 1 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
2017-04-17T07:12:07.092282Z 1 [Note] InnoDB: Apply batch completed
2017-04-17T07:12:10.789225Z 1 [ERROR] InnoDB: Expected to open 77 undo tablespaces but was able to find only 0 undo tablespaces. Set the innodb_undo_tablespaces parameter to the correct value and retry. Suggested value is 0
2017-04-17T07:12:10.789247Z 1 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2017-04-17T07:12:11.390024Z 1 [ERROR] Failed to initialize DD Storage Engine
2017-04-17T07:12:11.390198Z 0 [ERROR] Data Dictionary initialization failed.
2017-04-17T07:12:11.390218Z 0 [ERROR] Aborting

2017-04-17T07:12:11.390232Z 0 [Note] Binlog end
2017-04-17T07:12:11.390356Z 0 [Note] Shutting down plugin 'MyISAM'
2017-04-17T07:12:11.390373Z 0 [Note] Shutting down plugin 'CSV'
2017-04-17T07:12:11.390378Z 0 [Note] Shutting down plugin 'InnoDB'
2017-04-17T07:12:11.390386Z 0 [Note] Shutting down plugin 'keyring_file'
2017-04-17T07:12:11.390782Z 0 [Note] /home/shahriyar.rzaev/MySQL_Servers/8.0.1/bin/mysqld: Shutdown complete

Setting innodb_undo_tablespaces to 0 as suggested:

2017-04-17T07:26:50.193782Z 0 [Note] /home/shahriyar.rzaev/MySQL_Servers/8.0.1/bin/mysqld: ready for connections.
Version: '8.0.1-dmr'  socket: '/tmp/mysql_sandbox8001.sock'  port: 8001  MySQL Community Server (GPL)
2017-04-17T07:26:50.992316Z 0 [ERROR] InnoDB: Can't set undo log tablespace to be encrypted, since it is a shared tablespace.

How to repeat:
See description
[17 Apr 2017 7:49] Shahriyar Rzayev
It seems to be even not related to altering table to enable encryption.
The simplest way to reproduce:

1. Successfully start with:

[mysqld]
early-plugin-load=keyring_file.so
keyring_file_data=/home/shahriyar.rzaev/sandboxes/msb_8_0_1/tmp/keyring

innodb_redo_log_encrypt=ON
innodb_undo_tablespaces=77
innodb_undo_logs=77
innodb_undo_log_encrypt=ON

2. kill -9
[26 Apr 2017 8:58] MySQL Verification Team
Hello Shahriyar,

Thank you for the report.
I just followed the steps presented in the bug report but not seeing the reported issue and was able to restart. Could you please pass on exact conf, start up command etc?

Thanks,
Umesh
[26 Apr 2017 8:59] MySQL Verification Team
test results

Attachment: 85969.results (application/octet-stream, text), 10.86 KiB.

[8 May 2017 8:56] Shahriyar Rzayev
Hi Umesh, sorry for late reply, I was off.

So the config file is:

[mysql]
prompt='mysql [\h] {\u} (\d) > '
#

[client]
user               = msandbox
password           = msandbox
port               = 8001
socket             = /tmp/mysql_sandbox8001.sock

[mysqld]
user               = shahriyar.rzaev
port               = 8001
socket             = /tmp/mysql_sandbox8001.sock
basedir            = /home/shahriyar.rzaev/Percona_Servers/8.0.1
datadir            = /home/shahriyar.rzaev/sandboxes/msb_8_0_1/data
tmpdir             = /home/shahriyar.rzaev/sandboxes/msb_8_0_1/tmp
lower_case_table_names = 0
pid-file           = /home/shahriyar.rzaev/sandboxes/msb_8_0_1/data/mysql_sandbox8001.pid
bind-address       = 127.0.0.1
# slow-query-log = on
# slow-query-log-file=/home/shahriyar.rzaev/sandboxes/msb_8_0_1/data/msandbox-slow.log
# general-log = on
# general-log-file=/home/shahriyar.rzaev/sandboxes/msb_8_0_1/data/msandbox-general.log
#
# additional options passed through 'my_clause' 
#
log-error=msandbox.err

early-plugin-load=keyring_file.so
keyring_file_data=/home/shahriyar.rzaev/sandboxes/msb_8_0_1/tmp/keyring

innodb_redo_log_encrypt=ON
innodb_undo_tablespaces=77
innodb_undo_logs=77
innodb_undo_log_encrypt=ON

Just kill the server with -9 and then start.

2017-05-08T08:54:07.174124Z 1 [ERROR] InnoDB: Expected to open 77 undo tablespaces but was able to find only 0 undo tablespaces. Set the innodb_undo_tablespaces parameter to the correct value and retry. Suggested value is 0
2017-05-08T08:54:07.174147Z 1 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2017-05-08T08:54:07.674794Z 1 [ERROR] Failed to initialize DD Storage Engine
2017-05-08T08:54:07.674922Z 0 [ERROR] Data Dictionary initialization failed.
2017-05-08T08:54:07.674932Z 0 [ERROR] Aborting
[9 May 2017 9:33] MySQL Verification Team
Still no luck even with exact conf file, and with ALTER.. or without. After kill -9, mysqld again comes back without any issue:

cat docs/INFO_SRC
commit: 69ffe6a6a2083eff81307ddc3651a1b0c51fb92c
date: 2017-03-23 05:26:01 +0100
build-date: 2017-03-23 05:52:29 +0100
short: 69ffe6a
branch: mysql-8.0.1-dmr-release

MySQL source 8.0.1

rm -rf data/
bin/mysqld  --defaults-file=./my.cnf --initialize-insecure -v
bin/mysqld --defaults-file=./my.cnf --core-file 2>&1 &

Created keyvalue table with 9m records, later started ALTER... encryption='Y'; and killed mysqld in middle of ALTER and later restarted mysqld came up without any issues:

root@localhost [test]> CREATE TABLE `keyvalue` (
    ->   `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
    ->   `name1` varchar(250),
    ->   `name2` varchar(250),
    ->   `name3` varchar(250),
    ->   `name4` varchar(250),
    ->   PRIMARY KEY (`id`, name1(10))
    -> ) ENGINE=innodb;
Query OK, 0 rows affected (0.00 sec)

root@localhost [test]>
root@localhost [test]> set @id:=0;
Query OK, 0 rows affected (0.00 sec)

root@localhost [test]>
root@localhost [test]>  insert into `keyvalue` values
    ->   (@id:=@id+1,md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000))
    -> ,  (@id:=@id+1,md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000))
    -> , (@id:=@id+1,md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000))
    -> , (@id:=@id+1,md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000));
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

root@localhost [test]>
root@localhost [test]>  insert into `keyvalue`(`id`,`name1`,`name2`,`name3`,`name4`)
    ->    select  @id:=@id+1,md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000),md5(rand()*1000000)  from
    ->     `keyvalue` k1, `keyvalue` k2, `keyvalue` k3, `keyvalue` k4,`keyvalue` k5,`keyvalue` k6, `keyvalue` k7, `keyvalue` k8, `keyvalue` k9,
    -> `keyvalue` k0,`keyvalue` ka, `keyvalue` kb, `keyvalue` kc, `keyvalue` kd limit  9000000;
Query OK, 9000000 rows affected (3 min 18.18 sec)
Records: 9000000  Duplicates: 0  Warnings: 0

root@localhost [test]> alter table keyvalue encryption='Y';
.... killed -9 `pidofmysqld`

ERROR 2013 (HY000): Lost connection to MySQL server during query
root@localhost [test]>
root@localhost [test]> \q
Bye
[1]+  Killed                  bin/mysqld --defaults-file=./my.cnf --core-file 2>&1
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.1:
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.1: bin/mysqld --defaults-file=./my.cnf --core-file 2>&1 &
[1] 31239

.
2017-05-09T09:23:03.761175Z 1 [Note] InnoDB: Read redo log encryption metadata successful.
2017-05-09T09:23:03.763819Z 1 [Note] InnoDB: Log scan progressed past the checkpoint lsn 2411909826
2017-05-09T09:23:03.900027Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2417152512
2017-05-09T09:23:04.037642Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2422395392
2017-05-09T09:23:04.174967Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2427638272
2017-05-09T09:23:04.309382Z 1 [Note] InnoDB: Read encryption metadata from ./test/#sql-770d_4.ibd successfully, encryption of this tablespace enabled.
2017-05-09T09:23:04.312633Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2432881152
2017-05-09T09:23:04.451227Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2438124032
2017-05-09T09:23:04.589846Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2443366912
2017-05-09T09:23:04.728388Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2448609792
2017-05-09T09:23:04.867072Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2453852672
2017-05-09T09:23:05.005738Z 1 [Note] InnoDB: Doing recovery: scanned up to .
2017-05-09T09:23:06.921350Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2474076984
2017-05-09T09:23:06.921959Z 1 [Note] InnoDB: Database was not shutdown normally!
2017-05-09T09:23:06.921969Z 1 [Note] InnoDB: Starting crash recovery.
2017-05-09T09:23:06.946659Z 1 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
2017-05-09T09:23:07.774095Z 1 [Note] InnoDB: Apply batch completed
2017-05-09T09:23:08.150089Z 1 [Note] InnoDB: Opened 77 undo tablespaces
2017-05-09T09:23:08.150114Z 1 [Note] InnoDB: 77 undo tablespaces made active
2017-05-09T09:23:08.189553Z 1 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 18 row operations to undo
2017-05-09T09:23:08.189569Z 1 [Note] InnoDB: Trx id counter is 2560
2017-05-09T09:23:08.566912Z 1 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2017-05-09T09:23:08.566953Z 1 [Note] InnoDB: Creating shared tablespace for temporary tables
2017-05-09T09:23:08.567087Z 1 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2017-05-09T09:23:08.584078Z 1 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2017-05-09T09:23:08.585004Z 1 [Note] InnoDB: 32 rollback segment(s) are active in the temporary tablespace.
2017-05-09T09:23:08.587310Z 1 [Note] InnoDB: 8.0.1 started; log sequence number 2474076984
2017-05-09T09:23:08.587383Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4839ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
2017-05-09T09:23:08.591928Z 0 [Note] InnoDB: Starting in background the rollback of uncommitted transactions
2017-05-09T09:23:08.591988Z 0 [Note] InnoDB: Rolling back trx with id 2111, 18 rows to undo
2017-05-09T09:23:08.592121Z 1 [Note] InnoDB: Waiting for purge to start
2017-05-09T09:23:08.594763Z 0 [Note] InnoDB: Rollback of trx with id 2111 completed
2017-05-09T09:23:08.594792Z 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2017-05-09T09:23:08.642474Z 0 [Note] InnoDB: Loading buffer pool(s) from /export/umesh/server/binaries/Trunk/mysql-8.0.1/data/ib_buffer_pool
2017-05-09T09:23:08.647536Z 0 [Note] InnoDB: Buffer pool(s) load completed at 170509 11:23:08
2017-05-09T09:23:08.707188Z 1 [Note] Found data dictionary with version 1
2017-05-09T09:23:08.710422Z 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
2017-05-09T09:23:08.710865Z 0 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
2017-05-09T09:23:08.710896Z 0 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
2017-05-09T09:23:08.710956Z 0 [Note] Server socket created on IP: '127.0.0.1'.
2017-05-09T09:23:08.770757Z 0 [Note] bin/mysqld: ready for connections.
Version: '8.0.1-dmr'  socket: '/tmp/mysql_ushastry.sock'  port: 3306  MySQL Community Server (GPL)
[9 May 2017 9:34] MySQL Verification Team
Anything I'm missing? 3 times I have repeated the previous steps but each time no issues observed though.
[9 May 2017 10:08] MySQL Verification Team
This seems to be repeatable under this circumstances:

-- Start mysqld with default innodb_undo_tablespaces

-- kill -9 mysqld

-- set innodb_undo_tablespaces=77 and any attempt to restart will end up with

2017-05-09T10:03:20.198839Z 1 [Note] InnoDB: Log scan progressed past the checkpoint lsn 11820841
2017-05-09T10:03:20.198861Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 11820850
2017-05-09T10:03:20.200399Z 1 [Note] InnoDB: Doing recovery: scanned up to log sequence number 11820850
2017-05-09T10:03:20.200413Z 1 [Note] InnoDB: Database was not shutdown normally!
2017-05-09T10:03:20.200419Z 1 [Note] InnoDB: Starting crash recovery.
2017-05-09T10:03:20.303008Z 1 [ERROR] InnoDB: Expected to open 77 undo tablespaces but was able to find only 0 undo tablespaces. Set the innodb_undo_tablespaces parameter to the correct value and retry. Suggested value is 0
2017-05-09T10:03:20.303032Z 1 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2017-05-09T10:03:20.803565Z 1 [ERROR] Failed to initialize DD Storage Engine
2017-05-09T10:03:20.803761Z 0 [ERROR] Data Dictionary initialization failed.
2017-05-09T10:03:20.803773Z 0 [ERROR] Aborting

2017-05-09T10:03:20.803795Z 0 [Note] Binlog end
2017-05-09T10:03:20.803849Z 0 [Note] Shutting down plugin 'MyISAM'
2017-05-09T10:03:20.803861Z 0 [Note] Shutting down plugin 'CSV'
2017-05-09T10:03:20.803865Z 0 [Note] Shutting down plugin 'InnoDB'
2017-05-09T10:03:20.803875Z 0 [Note] Shutting down plugin 'keyring_file'
2017-05-09T10:03:20.804238Z 0 [Note] bin/mysqld: Shutdown complete

Imho, per documentation - "innodb_undo_tablespaces can only be configured prior to initializing the MySQL instance and cannot be changed afterward. If no value is specified, the instance is initialized using the default setting (0). Attempting to restart InnoDB with a greater number of undo tablespaces than specified when the MySQL instance was initialized results in a startup failure and an error stating that InnoDB did not find the expected number of undo tablespaces." - https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_undo_tablespa...

If this happened in your case then I would say this is not a bug but expected behavior.
[9 May 2017 13:05] Shahriyar Rzayev
Well reading the doc:

"innodb_undo_tablespaces can only be configured prior to initializing the MySQL instance and cannot be changed afterward. If no value is specified, the instance is initialized using the default setting (0). Attempting to restart InnoDB with a greater number of undo tablespaces than specified when the MySQL instance was initialized results in a startup failure and an error stating that InnoDB did not find the expected number of undo tablespaces."

But I could start MySQL with different innodb_undo_tablespaces value after first start with fresh server.
Described here:

2017-05-08T08:44:34.036513Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2017-05-08T08:44:34.084948Z 1 [Note] InnoDB: Creating UNDO Tablespace Data file .//undo066
2017-05-08T08:44:34.084962Z 1 [Note] InnoDB: Setting file .//undo066 size to 10 MB
2017-05-08T08:44:34.084965Z 1 [Note] InnoDB: Physically writing the file full
2017-05-08T08:44:34.234390Z 1 [Note] InnoDB: Undo log encryption is enabled.
2017-05-08T08:44:34.234488Z 1 [Note] InnoDB: Creating UNDO Tablespace Data file .//undo067
2017-05-08T08:44:34.234494Z 1 [Note] InnoDB: Setting file .//undo067 size to 10 MB
2017-05-08T08:44:34.234497Z 1 [Note] InnoDB: Physically writing the file full
2017-05-08T08:44:34.435166Z 1 [Note] InnoDB: Undo log encryption is enabled.
2017-05-08T08:44:34.435243Z 1 [Note] InnoDB: Creating UNDO Tablespace Data file .//undo068
2017-05-08T08:44:34.435250Z 1 [Note] InnoDB: Setting file .//undo068 size to 10 MB
2017-05-08T08:44:34.435253Z 1 [Note] InnoDB: Physically writing the file full
2017-05-08T08:44:34.618732Z 1 [Note] InnoDB: Undo log encryption is enabled.
2017-05-08T08:44:34.618821Z 1 [Note] InnoDB: Creating UNDO Tablespace Data file .//undo069
2017-05-08T08:44:34.618828Z 1 [Note] InnoDB: Setting file .//undo069 size to 10 MB
2017-05-08T08:44:34.618831Z 1 [Note] InnoDB: Physically writing the file full
2017-05-08T08:44:34.761399Z 1 [Note] InnoDB: Undo log encryption is enabled.
2017-05-08T08:44:34.761473Z 1 [Note] InnoDB: Creating UNDO Tablespace Data file .//undo070
2017-05-08T08:44:34.761479Z 1 [Note] InnoDB: Setting file .//undo070 size to 10 MB

The problem is that, after fresh MySQL install you could change innodb_undo_tablespaces say with value 77 as described above, but after receiving -9 it is not going to start.
So for me the overall steps:
1. Fresh initialized datadir with default values.
2. Stopping server
3. Changing config:
early-plugin-load=keyring_file.so
keyring_file_data=/home/shahriyar.rzaev/sandboxes/msb_8_0_1/tmp/keyring

innodb_redo_log_encrypt=ON
innodb_undo_tablespaces=77
innodb_undo_logs=77
innodb_undo_log_encrypt=ON
4. Starting server
5. Killing with -9
6. Starting server - Failed.

Conclusion/Question -> if it is prohibited why I could change the value of innodb_undo_tablespaces, but after killing -9 could not change?
[19 Oct 2017 12:50] MySQL Verification Team
I'm still not seeing after last provided steps(with data(and even alter.. encryption='Y'), without data etc), please could you confirm from your end?

(1) Start new instance - all defaults
rm -rf 85969
bin/mysqld --initialize-insecure --basedir=$PWD --datadir=$PWD/85969 
bin/mysqld --basedir=$PWD --datadir=$PWD/85969 --core-file --socket=/tmp/mysql_ushastry.sock --port=3306 --log-error=$PWD/85969/log.err 2>&1 &

[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: bin/mysql -uroot -S /tmp/mysql_ushastry.sock
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 8.0.3-rc-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

root@localhost [(none)]> show variables like 'innodb_undo_%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_undo_directory    | ./    |
| innodb_undo_log_encrypt  | OFF   |
| innodb_undo_log_truncate | ON    |
| innodb_undo_tablespaces  | 2     |
+--------------------------+-------+
4 rows in set (0.01 sec)

root@localhost [(none)]> \q
Bye

(2) Stop Server
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: bin/mysqladmin -uroot -S /tmp/mysql_ushastry.sock shutdown
[1]+  Done                    bin/mysqld --basedir=$PWD --datadir=$PWD/85969 --core-file --socket=/tmp/mysql_ushastry.sock --port=3306 --log-error=$PWD/85969/log.err 2>&1

(3) Change config
-- my.cnf change config, restart
[mysqld]
early-plugin-load=keyring_file.so
keyring_file_data=/tmp/keyring

innodb_redo_log_encrypt=ON
innodb_undo_tablespaces=77
#innodb_undo_logs=77 # removed since 5.7.19
innodb_undo_log_encrypt=ON

[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3:
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: vi my.cnf

(4) Start Server

bin/mysqld --defaults-file=./my.cnf --basedir=$PWD --datadir=$PWD/85969 --core-file --socket=/tmp/mysql_ushastry.sock --port=3306 --log-error=$PWD/85969/log.err 2>&1 &

--
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: bin/mysql -uroot -S /tmp/mysql_ushastry.sock
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 8.0.3-rc-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

root@localhost [(none)]> show variables like 'innodb_undo_%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_undo_directory    | ./    |
| innodb_undo_log_encrypt  | ON    |
| innodb_undo_log_truncate | ON    |
| innodb_undo_tablespaces  | 77    |
+--------------------------+-------+
4 rows in set (0.00 sec)

(5) kill -9 

[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: ps aux|grep mysqld

umshastr 12756  2.6  0.1 1535264 412300 pts/4  Sl   14:33   0:02 bin/mysqld --defaults-file=./my.cnf --basedir=/export/umesh/server/binaries/Trunk/mysql-8.0.3 --datadir=/export/umesh/server/binaries/Trunk/mysql-8.0.3/85969 --core-file --socket=/tmp/mysql_ushastry.sock --port=3306 --log-error=/export/umesh/server/binaries/Trunk/mysql-8.0.3/85969/log.err

[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: kill -9 12756
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3:
[1]+  Killed                  bin/mysqld --defaults-file=./my.cnf --basedir=$PWD --datadir=$PWD/85969 --core-file --socket=/tmp/mysql_ushastry.sock --port=3306 --log-error=$PWD/85969/log.err 2>&1

(6) Restart

[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3:
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: bin/mysqld --defaults-file=./my.cnf --basedir=$PWD --datadir=$PWD/85969 --core-file --socket=/tmp/mysql_ushastry.sock --port=3306 --log-error=$PWD/85969/log.err 2>&1 &
[1] 12855
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3:
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3:
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3:
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-8.0.3: bin/mysql -uroot -S /tmp/mysql_ushastry.sock
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 8.0.3-rc-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

root@localhost [(none)]>
[20 Nov 2017 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".