This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-17. For the latest, interactive version please visit https://mariadb.com/kb/.

Changing location of database

Using 5.5.31 on Linux Mint. By default datadir is /var/lib/mysql. Like most users I do not want my data on my boot drive so I moved it to a different physical drive which is always mounted. I then stopped server, reset the basedir in my.cnf and restarted. No problem. After a reboot the log shows multiple errors "Table xxx doesn't exist" although it does. In Mysql workbench the tables are listed in the schema tree but any attempt to access causes workbench to abort.

I also tried deleting all data, recreate the schema folders and then the scripts to create the tables and routines and data. Again ok until a reboot. The only thing I haven't tried is dropping the schemas and recreating them in workbench.

Relevant data: The new data drive is NTFS. The error messages include:

[ERROR] Cannot find or open table pword/pword from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.

Would appreciate any suggestions.

Answer Answered by Sergei Golubchik in this comment.

I mean "incorrect path inside innodb". it would not affect logging in or SHOW DATABASES.

I cannot know whether MariaDB starts before or after your drives are mounted, it depends on how your startup scripts are configured. If needed, you can force the correct order, by adding dependencies to your startups scripts.

Still, if you'll be able to create a test case — please submit a bug report.

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.