| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Ubuntu 22.04 |
| Webmin version | 2.402 |
| Virtualmin version | 7.30.8 |
| Webserver version | Apache2 |
| Related packages | SUGGESTED |
I try to transfer a domain between 2 Ubuntu 22.04 servers. After transfer I get a 500 error. The error say that one table in the db is missing. After check it turnes out true. I have tested to transfer 3 times and get the same error. Also when I backup and then restore the backup I get the same error. How can this happen
Not saying that this is the problem but are the 2 versions of mysql/mariadb the same ? If they are different you may find that the table structure is incompatible with the version of mysql that you are importing into, best thing to do is to check the logs. Maybe look at /var/webmin/miniserv.error and maybe /var/webmin/webmin.log where you might see some logs.
if you have mysql error reporting switched on there maybe some references in the mysql logs also.
if this looks a bit techie, and you have phpmyadmin installed try importing the dump via phpmyadmin and this will show the table error.
As it appears you are using the transfer option you may want to make a backup of the original source rather than using the transfer option so at least you have a physical copy of the mysql dump to test with.
I get the same error when using backup option instead. MariaDb is the same on both. I will now try to clone the old one to the new with rsync to see if that work
You need to check the logs just copying the data across will no difference at all if the data structure is invalid for the version of mysql running on the server that you are copying the data to.
I assume that you know the table that is apparently missing.
How do you know that the transfer restore failed? is it because the application (eg some PHP application/website) is failing?
it could be the reason (more likely) that the application is failing to correctly load the database/table(s) correctly - some cache/temporary tables perhaps. was the original closed down before the transfer and users logged out.
I have checked. The source db has 120 tables and the destination has 119 after transfer. The missing table is ps_shop_url
sounds like it is something important but also related to some app (“ps”)
so is that app trying to find it. and when it is run the error is observed?
is this the only app using that database / table. does the app have an install script that has to be run to put that table in the db?
sounds to me that the app is at fault
so how many tables are in the mysql dump file ?
119 the one I wrote is missing
So the old server is perhaps not exporting the table in the first place then ? Have you checked the mysql dump from a backup rather than just a transfer ? This means opening the backup archive on your pc finding the mysql dump opening it in a text editor and searching for the table name
If I backup the db the table is there
So therefore as i said in an earlier post it looks like that table stucture is incompatible with the version of the version of mysql you are trying to import into so you need to find the incompatibility in the table and fix it by editing the table in the dump file and imprting it manually, most errors are table or field corelation but as suggested before there are tools to pinpoint the actual error via logs or phpmyadmin
So, as I had presumed, it is the app that is at fault. So really one for the devs at Thirtybees. that code should first check for the existence of the table (and possibly create it and it’s indexes) before attempting to perform such a convoluted join. or something else is potentially deleting it further up the code. but only the devs will know what the purpose of this code is for (as so often with code it lacks documentation)
Or as it worked on the old server there is something different about that table .. don’t forget mysql tables will inherit coralition from the database unless you stipulate the corelation.. so you change the mysql rules i.e from one version of to anoher the import will fail and to be fair webmin fails silently.. so adding this advice may send the OP down a dead end
Well I dont know what to believe really. The 2 vps is identical setups. When I transferred I get this error. When I made a backup of all and restore it I get the same error.
I got tired of it and decided a different approach. I created the domains in the new server, downloaded a zipped public_html from the old server and unzipped it on the new. Then I dumped the database and installed it on the new db. And it worked flawless as soon as I changed ip in the dns. So I really dont know what happened
The table is in the backup but is being discarded during the import because there are restrictions/privileges/constraints that may block the import in 1 case and ignore the error in another. Check if the import setup/parameters are the same, a verbose import that shows any errors would help.
I will close this post as solved with this last post. The problem must have been a communication problem. When I transferred the server, its a webshop, the transferred database contained 119 tables of 351. I checked the dump. So when found out I dumped the db using commandline and restored it on the new server and everything immediately worked. Why this happened I have no clue about
