I run a dedicated web server (Plesk Obsidian 18.0.67 Web Host Edition) on CentOS 7.9. I'm going to be re-imaging it soon since RHEL 7 has been at EOL for a while now :D. Normally when I reimage a server I use the Plesk migrator to migrate a copy of my hosted sites to another server and change the DNS until the re-imaged server is ready to go and then migrate it all back over. Works pretty well most of the time.

Anyways, after doing this, I ran into a database error when I went to access my Invision Community.

Fatal error: Uncaught IPS\Db\Exception: No such file or directory in /var/www/vhosts/swrebellion.net/httpdocs/system/Db/Db.php:269 Stack trace: #0 /var/www/vhosts/swrebellion.net/httpdocs/system/Db/Db.php(356): IPS\_Db->_establishConnection() #1 /var/www/vhosts/swrebellion.net/httpdocs/system/Db/Db.php(487): IPS\_Db->checkConnection() #2 /var/www/vhosts/swrebellion.net/httpdocs/system/Db/Db.php(972): IPS\_Db->preparedQuery() #3 /var/www/vhosts/swrebellion.net/httpdocs/system/Session/Admin.php(103): IPS\_Db->replace() #4 [internal function]: IPS\Session\_Admin->write() #5 [internal function]: session_write_close() #6 {main} thrown in /var/www/vhosts/swrebellion.net/httpdocs/system/Db/Db.php on line 269

I didn't see any errors in the migration logs but I did notice the database size is quite different (~800mb on the destination server and ~950mb on the source server). Any time I try to dump the database - even making a copy of it on the source server it has this database size discrepancy. The number of tables are the same, but there is a hiccup happening somewhere.

This could be related, (though not sure what to do about it) - I saw a couple warnings on the Contact Support page in the ACP (from the working/source server):

1. Compact table type:

  Quote

You have one or more InnoDB tables that are using the Compact row format. This may limit the amount of data that can be stored within the table. We recommend changing it to 'Dynamic'. Please make sure that innodb_file_per_table is enabled. If you are not sure how to do this, you should contact your hosting provider or system administrator for assistance.

2. Non-InnoDB tables

  Quote

InnoDB database tables typically perform more efficiently and reliably than other database engines such as MyISAM on most modern hosts when configured correctly. It is strongly encouraged to ensure all of your database tables are using the InnoDB storage engine, and that your hosting provider has configured MySQL for InnoDB use.

I have a bit more info available. These are the tables that are showing as MyISAM (the rest are all InnoDB). Whenever I try to dump these tables, even as plaintext SQL (no compression), the output file ends up being far less than the original. The aforementioned migrated copy and copy on source server are showing the same number of rows for these tables but the size of the core_search_index table when I dump it is only 170.4 MiB.

Table	Rows	Type	Size in DB	Size on Copied DB	Size on Export to File
core_search_index	175,492	MyISAM	293.6 MiB w/ 65.9 MiB overhead	170.3 MiB / no overhead	96.0 MB
core_pfields_content	12,291	MyISAM	1.4 MiB	1.5 MiB	1.72 MB
core_message_topics	9,589	MyISAM	1.0 MiB	1.0 MiB	979 KB
core_message_posts	9,552	MyISAM	8.9 MiB	8.8 MiB	5.43 MB

  On 2/9/2025 at 11:22 AM, Ryan M said:

I have a bit more info available. These are the tables that are showing as MyISAM (the rest are all InnoDB).

It would be best that the database type is set to InnoDB for all tables imo.

  On 2/9/2025 at 6:58 AM, Ryan M said:

Fatal error: Uncaught IPS\Db\Exception: No such file or directory in

I came this across before for a client of mine. The move and configuration isn't done throughly/properly. Also make sure that the php version in the new setup meets the requirements of your forum version.

That message would indicate it cant connect to the database, so I would check the details provided in your conf_global.php file first of all

That's what I thought at first, but my conf_globals.php is solid. I even changed the sql user's password and matched it just to make sure :(

That DB error only shows up in the logs when I try to access /admin/ but if I just go to the domain root I get Error 500 with just very little info.

Edited February 11Feb 11 by Ryan M

If you are getting a 500 error, it should show up within your server error logs