summaryrefslogtreecommitdiff
path: root/mysql-test/suite/encryption/t/innodb-encryption-alter.test
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.3 into 10.4Marko Mäkelä2019-07-021-0/+2
|\
| * MDEV-19914 Server startup fails while dropping garbage encrypted tablespace ↵Thirunarayanan Balathandayuthapani2019-07-011-0/+1
|/ | | | | | | if innodb_encryption_threads > 0 - Avoiding accessing encryption thread mutex before initiating the encryption threads
* Merge 10.1 into 10.2Marko Mäkelä2019-03-041-4/+9
|\
| * MDEV-18601 Can't create table with ENCRYPTED=DEFAULT when ↵Marko Mäkelä2019-02-281-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | innodb_default_encryption_key_id!=1 The problem with the InnoDB table attribute encryption_key_id is that it is not being persisted anywhere in InnoDB except if the table attribute encryption is specified and is something else than encryption=default. MDEV-17320 made it a hard error if encryption_key_id is specified to be anything else than 1 in that case. Ideally, we would always persist encryption_key_id in InnoDB. But, then we would have to be prepared for the case that when encryption is being enabled for a table whose encryption_key_id attribute refers to a non-existing key. In MariaDB Server 10.1, our best option remains to not store anything inside InnoDB. But, instead of returning the error that MDEV-17320 introduced, we should merely issue a warning that the specified encryption_key_id is going to be ignored if encryption=default. To improve the situation a little more, we will issue a warning if SET [GLOBAL|SESSION] innodb_default_encryption_key_id is being set to something that does not refer to an available encryption key. Starting with MariaDB Server 10.2, thanks to MDEV-5800, we could open the table definition from InnoDB side when the encryption is being enabled, and actually fix the root cause of what was reported in MDEV-17320.
* | cleanup: don't ---replace_regex /#sql-.*/#sql-temporary/Sergei Golubchik2019-02-051-2/+0
| | | | | | | | no longer needed
* | Merge 10.1 into 10.2Marko Mäkelä2019-01-171-9/+29
|\ \ | |/
* | Merge 10.1 into 10.2Marko Mäkelä2018-11-071-0/+24
|\ \ | |/
| * MDEV-17230: encryption_key_id from alter is ignored by encryption threadsJan Lindström2018-11-061-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Background: Used encryption key_id is stored to encryption metadata i.e. crypt_data that is stored on page 0 of the tablespace of the table. crypt_data is created only if implicit encryption/not encryption is requested i.e. ENCRYPTED=[YES|NO] table option is used fil_create_new_single_table_tablespace on fil0fil.cc. Later if encryption is enabled all tables that use default encryption mode (i.e. no encryption table option is set) are encrypted with default encryption key_id that is 1. See fil_crypt_start_encrypting_space on fil0crypt.cc. ha_innobase::check_table_options() If default encryption is used and encryption is disabled, you may not use nondefault encryption_key_id as it is not stored anywhere.
* | Merge 10.1 into 10.2Marko Mäkelä2017-11-011-3/+1
|\ \ | |/
| * MDEV-14219 Allow online table rebuild when encryption or compression ↵Marko Mäkelä2017-10-311-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parameters change When MariaDB 10.1.0 introduced table options for encryption and compression, it unnecessarily changed ha_innobase::check_if_supported_inplace_alter() so that ALGORITHM=COPY is forced when these parameters differ. A better solution is to move the check to innobase_need_rebuild(). In that way, the ALGORITHM=INPLACE interface (yes, the syntax is very misleading) can be used for rebuilding the table much more efficiently, with merge sort, with no undo logging, and allowing concurrent DML operations.
* | Remove references to innodb_file_format.Marko Mäkelä2017-01-181-8/+0
|/ | | | | | | | | | innodb_file_format=Barracuda is the default in MariaDB 10.2. Do not set it, because the option will be removed in MariaDB 10.3. Also, do not set innodb_file_per_table=1 because it is the default. Note that MDEV-11828 should fix the test innodb.innodb-64k already in 10.1.
* MDEV-8817: Failing assertion: new_state->key_version != ↵Jan Lindström2015-09-231-5/+18
| | | | | | | | | | ENCRYPTION_KEY_VERSION_INVALID Folloup: Made encryption rules too strict (and incorrect). Allow creating table with ENCRYPTED=OFF with all values of ENCRYPTION_KEY_ID but create warning that nondefault values are ignored. Allow creating table with ENCRYPTED=DEFAULT if used key_id is found from key file (there was bug on this) and give error if key_id is not found.
* MDEV-8817: Failing assertion: new_state->key_version != ↵Jan Lindström2015-09-221-0/+85
ENCRYPTION_KEY_VERSION_INVALID Analysis: Problem sees to be the fact that we allow creating or altering table to use encryption_key_id that does not exists in case where original table is not encrypted currently. Secondly we should not do key rotation to tables that are not encrypted or tablespaces that can't be found from tablespace cache. Fix: Do not allow creating unencrypted table with nondefault encryption key and do not rotate tablespaces that are not encrypted (FIL_SPACE_ENCRYPTION_OFF) or can't be found from tablespace cache.
View Lorry Controller Status