Trying to migrate from one machine to another, no luck with database restore, help?

[arretx]

I have little knowledge about what I'm doing. Here's the scenario.

I'm moving ZM from a Truenas Jail to an Unraid Docker container. The new ZM is up and running on the Unraid box as a docker container and has no data or events.

The event path for the new instance is `/var/cache/zoneminder/events`.

I've stopped ZM on both Truenas and Unraid from the ZM console. I've rsync'd the entire events folder from the truenas jail to the new events location. Now I need to restore the database.

On the Truenas box, I ran `mysqldump -p zm > zm-dbbackup.sql' then copied that file to the new events folder so the new ZM shell can see it.

When I run `mysql -p zm < zm-dbbackup.sql` I get an error:

ERROR 1146 (42502) at line 331: Table 'zm.Events' doesn't exist

If I `use zm;` and then `show tables;` I see the following:

+-----------------+
| Tables_in_zm |
+-----------------+
| config |
| controlpresets |
| controls |
| devices |
| event_summaries |
| events |
+-----------------+

The only thing I see in this is that "zm.Events" is capitalized and the table that's being created is not, but who am I to know what the heck is going on?

Anyone know how I can get this new ZM up and running with the old data and events in tact? I've had both instances off for a few days now so I'm not writing new information to the database, but I need to get this back online. Thanks in advance.

[Magic919]

Howe do you have a DB with tables before importing the DB? Just clear it out and start again.

[Andyrh]

Maybe this will help, this is the command I use to restore the DB to my test server.

mysql -u root -p password < zmdb.sql

[arretx]

Howe do you have a DB with tables before importing the DB? Just clear it out and start again.

Well, the first time this was the case because I had a fresh install of ZM on the unraid docker. When I ran the restore, it got stuck with a trigger error. So, I dropped the ZM database and recreated a new, blank ZM database and ran the restore, and that's when I started having a bunch of case mismatch errors on the table names.

For some reason, the dump created statements like zm.Events and zm.Events_Day, etc.

At this point, I had to edit the sql file manually, changing all of the upper case to lower case wherever it threw an error.

After running the restore one more time, it made it through to the end where there's a statement about GTID, and that threw an error, but I'm not sure if it's consequential or not.

I'm not sure at this point if it worked.

[arretx]

Hmm...here's something.

When I run `mysql --version` on the Truenas box (source) I get Ver 14.14 Distrib 5.7.36, for FreeBSD12.2
When I run it on the Unraid docker container, I get Ver 15.1 Distrib 10.3.32-MariaDB, for debian-linux-gnu

Clearly these are two different versions...

How much does this matter?

[Magic919]

I run with MariaDB having moved it from MySQL and it’s fine. That part in itself won’t cause problems.

[reelbusy]

lower_case_table_names, it's looking for 'E' events,

https://mariadb.com/docs/reference/mdb/ ... ble_names/
https://dev.mysql.com/doc/refman/8.0/en ... ivity.html

You had a different setting between your past and this enviro