linux, commodity pc server.

Linux storm0 2.6.32.43-tlinux-1.0.10-default #1 SMP Fri Jan 30 11:15:12 CST 2015 x86_64 x86_64 x86_64 GNU/Linux

gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-4)

Linux TENCENT64.site 3.10.0-1-tlinux2-0014.tl2 #1 SMP Wed Mar 11 11:43:03 CST 2015 x86_64 x86_64 x86_64 GNU/Linux

DZW,
Thanks for the report and the patch.

This is basically duplicate of https://mariadb.atlassian.net/browse/MDEV-9362 and your solution while correct does not solve the migration from 10.1.10 to version where these flags are corrected.

Hi Jan Lindström,

Thanks for your comment.
In which version are the flags corrected? I saw the code of mariadb-10.1.11 and they are not yet corrected in it.

And are you saying that there are further issues around the migration and my patch doesn't solve all of them? Because I'm concerned about whether I can use my patch in production environment now, or do I have to wait for mariadb's official solution(and when will the version with the solution be released?).

What I found is that the patch solves the problem and mysqld can start up with old data files after the patch is applied.

Regards,
David

There is similar problem on dictionary flags. Furthermore, if you just move the placement of the individual flags, your existing databases created using 10.1 using these new flags would not work. I'm currently working on patch and I hope it will be released on 10.1.12, this patch I plan to make so that you do not need to export all tables and import them back, but no promises yet as fix is not 100% ready (currently I would say 90% for xtradb). Furthermore, as you fixed only xtradb, similar fix is needed for innodb plugin.

Thanks for the quick reply. My further questions:

1. Is it possible for me to see your unreleased fix? Is it in some development branch somewhere? or could you please send me a patch of it?
2. I want it because I want to know: whether the PAGE_COMPRESSION,PAGE_COMPRESSION_LEVEL, and ATOMIC_WRITES tablespace flags in future mariadb release will be placed the same way as in my patched version? I hope they will be the same otherwise I would face data format inconsistency when I have to upgrade to some future mariadb version. So if I can't see your code yet, could you describe the format of the tablespace flag integer here?

and btw, in my above patch I did fix both innodb and xtradb, actually I am using innodb rather than xtradb.

Hi,

(1) I have not yet committed the patch anywhere as it does not yet work fully.

(2) There is following problem: We (MariaDB) and Oracle have done independent development, this means that we and Oracle have used same tablespace flags bits (fsp->flags) and dictionary flags bits (sys_tables.flags). This will become even worse with MySQL 5.7. Thus, I wanted solution that works for 10.1 as well as our 10.2 under development (I'm merging 5.7 InnoDB). My solution is simple, I remove our extended flags PAGE_COMPRESSION,PAGE_COMPRESSION_LEVEL, and ATOMIC_WRITES from both fsp flags and dictionary flags and use new system table SYS_TABLE_OPTIONS instead where this information is stored. This means your patch is not compatible with my solution. I'm in process adding a methods that will migrate existing 10.1 databases using those flags to our new solution.

Created with 10.0.25 debian version, upgraded with 10.1.14 of mariadb.org for debian jessie.

InnoDB: Error: Current page size 8192 !=  page size on page 16384

2016-06-28 11:31:57 140588507318208 [Note] InnoDB: Restoring page 0 of tablespace 0

2016-06-28 11:31:57 140588507318208 [Warning] InnoDB: Doublewrite does not have page_no=0 of space: 0

2016-06-28 11:31:57 140588507318208 [ERROR] InnoDB: innodb-page-size mismatch in data file ./ibdata1

2016-06-28 11:31:57 140588507318208 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!

2016-06-28 11:31:57 140588507318208 [ERROR] Plugin 'InnoDB' init function returned error.

2016-06-28 11:31:57 140588507318208 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

2016-06-28 11:31:57 140588507318208 [Note] Plugin 'FEEDBACK' is disabled.

2016-06-28 11:31:57 140588507318208 [ERROR] Unknown/unsupported storage engine: InnoDB

2016-06-28 11:31:57 140588507318208 [ERROR] Aborting

Hi, can you provide your database, I will try to investigate ?

This issue has been fixed on https://jira.mariadb.org/browse/MDEV-11623, thus closing this.