[SOLVED] MySQL 8.1 to MariaDB 10.1 failing engine

[juliorollan]

Hello to everyone!
I had recently made a fresh install of Debian 9.6 which uses MariaDB 10.1. Previously I was using 8.5 with MySQL 8.1 (which I still have on another partition).
I found several issues with the usage of my databases. But there is one specific error which is annoying:

Code: Select all

MariaDB [<db>]> select * from <table>;
ERROR 1932 (42S02): Table '<db>.<table>' doesn't exist in engine

I have been searching around but found nothing useful to me and I really need to get those databases up because I make use of them on a daily basis.

Thanks for your time!
Best regards!

[llivv]

Code: Select all

# journalctl -xe

https://medium.com/@mcloide/moving-from ... cb042ed8d8

[juliorollan]

Ok, so this is the relevant entry:

Code: Select all

ene 17 08:06:38 <machine> mysqld[1546]: 2019-01-17  8:06:38 140578977008384 [Warning] InnoDB: Cannot open table <db>/<table> from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

I get this error for every table on the DB. There are no other errors related to MySQL or MariaDB engine.

I have read the reference URL. Permissions are fine for /var/lib/mysql. No disk quota enabled. Plenty of space left on disk.Reading the correct my.cnf file.

/var/log/mysql/error.log is empty.

Thank you!

[llivv]

I read the post below just a few days before your OP here.
I thought there was a reference to maria in the article -
Reading again I can't find maria, so here it is with reference to mysql transactions
from the developer of Gnocchi
https://julien.danjou.info/why-you-shou ... sactional/

The operator have to determine where the upgrade script stopped, roll back the upgrade by itself, fix the failure, and rerun the upgrade procedure.
The developer must anticipate every case of potential upgrade failure, write a roll back procedure for each of this case by and test every one of those cases.
Use a database system that handles transactional DDL.

https://julien.danjou.info/gnocchi-4-3-0-released/
It probably wouldn't give an answer to your immediate needs with mariaDB
although may still give some clues to the types of errors like the one you show.

[juliorollan]

I do not see any relation with my issue. And the fact that you may have read maria does not either make it related as that article talks about transactions.

I read the post below just a few days before your OP here.
I thought there was a reference to maria in the article -
Reading again I can't find maria, so here it is with reference to mysql transactions
from the developer of Gnocchi
https://julien.danjou.info/why-you-shou ... sactional/

The operator have to determine where the upgrade script stopped, roll back the upgrade by itself, fix the failure, and rerun the upgrade procedure.
The developer must anticipate every case of potential upgrade failure, write a roll back procedure for each of this case by and test every one of those cases.
Use a database system that handles transactional DDL.

https://julien.danjou.info/gnocchi-4-3-0-released/
It probably wouldn't give an answer to your immediate needs with mariaDB
although may still give some clues to the types of errors like the one you show.

[juliorollan]

Well, so finally I had to drop the databases and users, and import then again.