Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.1.26, 10.2.7
-
None
-
Red Hat Enterprise Linux Server 7.3
Server version: 10.2.7-MariaDB-log MariaDB Server
Description
After upgrading from an older 5.5 release and implementing Data At Rest Encryption, then proceeding to convert a lot of myisam tables over to innodb, the following errors are now reported when starting the mariadb service.
[ERROR] InnoDB: The page [page id: space=0, page number=7] in file './ibdata1' cannot be decrypted.
[Note] InnoDB: However key management plugin or used key_version 1 is not found or used encryption algorithm or method does not match.
[ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page.
(See attached error_output.txt for full startup log detail)
The entire upgrade process did work smoothly, until the point I restarted the mariadb service.
The upgrade process went through the following stages.
1: Update mariadb via yum using the mariadb repo.
2: Rework config files due to path changes and start mariadb
3: Stop database, add in encryption configuration and start again.
4: Run sql query to convert tables from myisam to innodb.
# mysql dev_cms -e "show table status where Engine='MyISAM';" | awk 'NR>1
{print "ALTER TABLE `"$1"` ENGINE = InnoDB;"}' |mysql dev_cms
5: Test and verify that encryption is working.
6: Stop and restart mariadb - Fault occurs on startup.
I've referenced two other issues which appear to be the same problem, however they're both listed and fixed in the 10.1 branch not 10.2
I don't have, but can probably generate more data if required.
Attachments
Issue Links
- causes
-
-
- Closed
-
- duplicates
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
I wrote some comments to the 10.1 patch. It seems to me that this could also fix
MDEV-13488 InnoDB writes CRYPT_INFO even though encryption is not enabled
If that is the case, please mark this bug report as a duplicate of that one.
commit 352d27ce36bc807f0c3c803e192ad1851f7f86a0
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Tue Aug 29 14:23:34 2017 +0300
MDEV-13557: Startup failure, unable to decrypt ibdata1
Fixes also MDEV-13488: InnoDB writes CRYPT_INFO even though
encryption is not enabled.
Problem was that we created encryption metadata (crypt_data) for
system tablespace even when no encryption was enabled and too early.
System tablespace can be encrypted only using key rotation.
Test innodb-key-rotation-disable, innodb_encryption, innodb_lotoftables
require adjustment because INFORMATION_SCHEMA INNODB_TABLESPACES_ENCRYPTION
contain row only if tablespace really has encryption metadata.
fil_crypt_set_thread_cnt: Send message to background encryption threads
if they exits when they are ready. This is required to find tablespaces
requiring key rotation if no other changes happen.
fil_crypt_find_space_to_rotate: Decrease the amount of time waiting
when nothing happens to better enable key rotation on startup.
fsp_header_init: Write encryption metadata to page 0 only if tablespace is
encrypted or encryption is disabled by table option.
i_s_dict_fill_tablespaces_encryption : Skip tablespaces that do not
contain encryption metadata. This is required to avoid too early
wait condition trigger in encrypted -> unencrypted state transfer.
open_or_create_data_files: Do not create encryption metadata
by default to system tablespace.
10.2 version requesting new review as this is somewhat different compared to 10.1.
https://github.com/MariaDB/server/commit/fc3708c2aebddbdd49948160024b8765c47768d9
Hi dcorp, thank you for your feedback. Because our QA engineer elenst repeated the problem with a freshly created 5.5 database, we can conclude that the impact is much higher than I initially thought. We can proceed without any copy of your data.
SQL dump and import into MySQL 5.5 or later would properly initialize all InnoDB data pages. If all previous upgrades were made in place, using original binary files potentially dating back as far as MySQL 3.23.49, then there could be problems due to previously unused but written-as-garbage bytes that have been repurposed in later versions of InnoDB. I think that we can rule it out in this case. InnoDB stopped writing uninitialized data to files in some version of the InnoDB Plugin for MySQL 5.1. All 5.5 versions should be safe in this respect.