Changing database servers causes XF to timeout?

[BulbaTech]

We ran into a problem with our current database server and needed to make a new one, so I took the database backup, moved it over to the new one, and pointed the XF install at it. This caused Xenforo to fail to load due to timeouts, but when inspecting the transaction log, I can see that requests are indeed being made. Apache is also working correctly and showing relatively low load, so I suspect it has to be something with MySQL (MariaDB to be more exact). Our install does not support emojis via XF's native support (and we're fine with that), so it isn't the UTF8 problem. I've been stuck on this for awhile and I'm not sure what to check next to debug, as I'm not terribly familiar with Xenforo. I'm happy to provide any information that could help figure this out.

It's also worth noting that the load on the database is very low.

 

[TPerry]

Well, since you don't detail what the "problem" was with your old DB server, once could be left with a presumption that the issue was with MySQL itself.
Did you confirm that the data dump from the old server was valid? GIGO can come into play. If the old DB server was having an actual MySQL server application issue, it could have dumped garbage out.

And are you using any type of caching? If so, have you restarted it?

 

[ENF]

We ran into a problem with our current database server and needed to make a new one, so I took the database backup, moved it over to the new one, and pointed the XF install at it. This caused Xenforo to fail to load due to timeouts, but when inspecting the transaction log, I can see that requests are indeed being made. Apache is also working correctly and showing relatively low load, so I suspect it has to be something with MySQL (MariaDB to be more exact). Our install does not support emojis via XF's native support (and we're fine with that), so it isn't the UTF8 problem. I've been stuck on this for awhile and I'm not sure what to check next to debug, as I'm not terribly familiar with Xenforo. I'm happy to provide any information that could help figure this out.

It's also worth noting that the load on the database is very low.

When moved the database, you said 'current database server' and then you said 'new one' -- so when you restored the database did you:
A) Ensure the connection address of the new server/db, updated in XF config.php.
B) Ensure that the credentials were created and/or updated to your config.php file for XF.
C) Is MySQL/MariaDB actually running and open to receive requests? (especially if on different server, ports need to be opened if they haven't been already)

The way you explained it, led me to believe that you moved the DB to a wholly different server, which is why I bring up the points A, B, C above.

 

[TPerry]

The way you explained it, led me to believe that you moved the DB to a wholly different server, which is why I bring up the points A, B, C above.

Looks like he did do the A) portion because he indicated that he pointed the XF install at it.

B & C are valid concerns when using an outside DB server instance... usually those ports are blocked... and I'd LEAVE them blocked except for connections from the specific IP instance of the XF server.
I also assumed since he commented that he examined the transaction log and was seeing requests being made (I simply assumed they were from the XF install), that B & C also were answered.

 

[ENF]

Looks like he did do the A) portion because he indicated that he pointed the XF install at it.

B & C are valid concerns when using an outside DB server instance... usually those ports are blocked... and I'd LEAVE them blocked except for connections from the specific IP instance of the XF server.
I also assumed since he commented that he examined the transaction log and was seeing requests being made (I simply assumed they were from the XF install), that B & C also were answered.

I don't assume anything.
What I do assume is people make mistakes and don't realize it.
Good to have a checklist and step back through it with a fresh pair of eyes.

 

[TPerry]

I don't assume anything.
What I do assume is people make mistakes and don't realize it.
Good to have a checklist and step back through it with a fresh pair of eyes.

Yep, but when one mentions in the origianl post that they reset the XF config, the fact that they ARE getting connections in a transaction log (which a beginner would not think to look at) it's a pretty good indicator that he HAD done due diligence in performing the acts that would be required. The only question is double-checking them to confirm that the credentials are correct (but one assumes so as he checked the transaction logs for connections, which would lead one to believe to know enough to confirm that they are connections/transactions to the source he is expecting).
I am still more concerned with the "issue with the old server" was having may having caused a DB corruption and then the dumped data will be trashed.
I just went through this with an Ubuntu 20.04LTS install running TimeTrex... and currently am in the process of having to set up a new server and a new instance using an older version of the DB since psql seemed to have crapped all over itself... and it's easier to just restore from a known good backup that is a few days old than try to troubleshoot the current install.

 

[BulbaTech]

We solved the issue on our own by making a full image of the mysql server and recreating it, then setting that server as the database. We suspect UTF-8 encoding may actually have played a role but will not know until further investigation.