[MDEV-22127] MariaDB 10.4 can't import database dump created before 10.4 Created: 2020-04-02 Updated: 2022-08-04 |
|
| Status: | Stalled |
| Project: | MariaDB Server |
| Component/s: | Server |
| Affects Version/s: | 10.4.12 |
| Fix Version/s: | 10.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Kristyna Streitova | Assignee: | Oleksandr Byelkin |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | mysqldump | ||
| Issue Links: |
|
||||||||
| Description |
|
MariaDB 10.4 can't import a database dump that was created by MariaDB < 10.4 and reports message: "ERROR 1050 (42S01) at line 804: Table 'user' already exists" The problem seems to be caused by changes in MariaDB 10.4 where mysql.global_priv table has replaced the mysql.user table, and mysql.user is now a view. So when you create a dump of the DB in 10.4, it drops both table and view before "CREATE TABLE `user`": MariaDB 10.4 dump
But when you create a dump e.g. on MariaDB 10.2 (tested with 10.2.31), only a table is dropped: MariaDB 10.2 dump:
When a user wants to restore 10.2 dump with MariaDB 10.4, the view is not dropped and MariaDB reports "Table 'user' already exists" error. If the "DROP VIEW IF EXISTS" statement is added to the dump, then it's restored without any problems. |
| Comments |
| Comment by Sergei Golubchik [ 2020-04-03 ] | ||
|
I don't see what kind of patch can help here. Perhaps the only solution is to edit the dump, adding at the beginning
| ||
| Comment by Elena Stepanova [ 2020-04-03 ] | ||
|
I tried the above for upgrade from 10.1/10.2/10.3 to 10.4, it appears to be working. An alternative, maybe somewhat more user-friendly, option could be running mysqldump with --add-drop-database option. It will drop the entire mysql database, including the view in question. I suppose if users restore the entire schemata, including system tables, it should be acceptable. | ||
| Comment by Kristyna Streitova [ 2020-04-07 ] | ||
|
What about to adjust mysqldump in next releases of MariaDB 10.2 and 10.3 so it automatically adds "DROP VIEW IF EXISTS `user`" statement? That would help users that will create a dump and migrate from MariaDB 10.2/3 to 10.4 in the future. The rest of them, who already created the dump, will have to add this line manually, obviously. Still, it can help a lot of users. Does this solution make a sense to you? | ||
| Comment by Sergei Golubchik [ 2020-04-07 ] | ||
|
Yes, it does. We can do that. But as elenst noted above, mysqldump --add-drop-database already works, it's existing documented and future-proof option. Wouldn't it be a preferred solution compared to adding drops just for the case a user might want to dump in 10.2 and load in 10.4? | ||
| Comment by Kristyna Streitova [ 2020-04-08 ] | ||
|
From my point of view, adding drops to mysqldump for 10.2 and 10.3 is a foolproof solution and it would prevent us from getting a lot of bug reports where the answer would be always "just use --add-drop-database option" or "alter your dump file please". I think it's easier and smoother to patch it than try to deliver this information to all migrating users. | ||
| Comment by Kristyna Streitova [ 2020-04-17 ] | ||
|
Can you please let me know if you decided to fix it? Thanks! | ||
| Comment by Sergei Golubchik [ 2020-04-30 ] | ||
|
okay, let's do it | ||
| Comment by Kristyna Streitova [ 2020-07-01 ] | ||
|
Hello Sergei, what's the status of this issue, please? | ||
| Comment by Sergei Golubchik [ 2020-07-02 ] | ||
|
it's assigned to a developer to be fixed. in 10.1, 10.2, 10.3 | ||
| Comment by VAROQUI Stephane [ 2020-09-18 ] | ||
|
--add-drop-database is affected by https://bugs.mysql.com/bug.php?id=69970 | ||
| Comment by Danilo Spinella [ 2021-07-20 ] | ||
|
Hi there, is there any update on this issue? | ||
| Comment by Sergei Golubchik [ 2021-07-29 ] | ||
|
| ||
| Comment by Danilo Spinella [ 2021-11-17 ] | ||
|
mysqldump --system=all does not work on an already initialized database so I think that's not really usable. A dump created with this option also create the user root@localhost that has already been added by mysql_install_db. |