Merge XF2 database after host change

[Frode789]

I have moved to a new host and it was migrated with a complete cpanel backup. However while waiting for some stuff being changed and set up (and before the domain pointed to the new host), some posts and stuff were posted on the "old" host after the complete backup.

Ideally this would be moved over. I did a sql backup of it now, is there a way to just merge the changes over? It comparing the two and just copying in the table(s) that have more/new information.

 

[duderuud]

I wouldn't try it, sounds really tricky!

I moved hosts serveral times and for that exact reason I closed the forum so no data would get lost...

 

[Frode789]

Understood, I will just manually create the few users and posts that were lost.

 

[Forsaken]

Whenever you do any maintenance (installing add-ons, server migration, server config changes) you should turn off your forum and take a backup, and then do whatever you need to do.

 

[Miri]

If it can help you, there is an addon that allows you to edit the author name and date of the author. In this way, you can speed up your work. You publish the posts under your own name, and then with this addon, you assign the date, time, and author to the messages you've published. https://xenforo.com/community/resources/change-content-owner-or-date.6124/

 

[rogerl]

Whenever you do any maintenance (installing add-ons, server migration, server config changes) you should turn off your forum and take a backup, and then do whatever you need to do.

I would add that during a server move this on its own would be insufficient as there is always a window when some users have the old DNS record and some the new one (assuming that it is a new IP address).

You need to ensure that only one of your database copies is ever accessed at any one time and that would typically be done by forwarding the SQL database requests from one server to the other via an SSH tunnel for a few days. (ie both servers running the front end, but both accessing the same database)

None of this of course helps the OP, and I would suggest for @Frode789 that the best thing is to forget about synching them and just remember what went wrong next time you do a move so you don't make the same mistake again.

 

[Frode789]

Yeah thank you for the input.

 

[Forsaken]

I would add that during a server move this on its own would be insufficient as there is always a window when some users have the old DNS record and some the new one (assuming that it is a new IP address).

You need to ensure that only one of your database copies is ever accessed at any one time and that would typically be done by forwarding the SQL database requests from one server to the other via an SSH tunnel for a few days. (ie both servers running the front end, but both accessing the same database)

None of this of course helps the OP, and I would suggest for @Frode789 that the best thing is to forget about synching them and just remember what went wrong next time you do a move so you don't make the same mistake again.

If your forum is off on the old server, they cannot register or post until their DNS updates for the new server regardless, so it is plenty sufficient in so far as those edge cases.

If you turn off the forum, change the DNS to the new server, and then begin migration by the time you've finished the migration the majority of users should be accessing the new DNS, especially if it is a larger migration.

 

[Paul B]

A good tip is to change the TTL to the lowest possible value before you start the move.
At least as far in advance as the TTL is currently set to.

That will ensure the DNS propagates much faster and in most cases it will be a matter of minutes, an hour or 2 at the most.

 

[TPerry]

I would add that during a server move this on its own would be insufficient as there is always a window when some users have the old DNS record and some the new one (assuming that it is a new IP address).

No, it should be entirely sufficient..... as if the old site is left in a closed mode and still online (until removed by the hosting provider or deleted if the admin if the old hosting account still has time on the clock)... those whose DNS hasn't updated will NOT be able to post anything anyway.... and if one has updated their notice that the site is being moved, the users should understand why. You can even suggest that the users change their DNS from their ISP provider (which are usually slow to update) to use one of the many free main DNS providers (Google, CloudFlare, OpenDNS and such).



Once the DNS propagates fully, then on the new site, which would be open, you would no longer see this message since the new site is not in an inactive mode.

Your comment of "running both off the same database via an SSH tunnel" is not the best recommendation unless you KNOW what you are doing to allow multiple sites access to the same database for read/write.

Whenever I change to a new hosting provider (VPS) I simply mark the site as inactive (and give a similar notice as above), make the move over to the new VPS, then go into CloudFlare, change to the new IP and reduce the TTL for the domain entries to the minimum possible. I've found that the BIG DNS providers tend to have the newly propagated IP address fairly quickly. Those small ISP's may take upwards of 48 hours (ergo the notice of such in the inactive board message). I do recommend making a move with at least a few days left on your old hosting account... that way the old site will stay online until most DNS providers will have gotten the new IP address.

By the way you detail... you may have users hitting a dead site or the site be showing errors, depending on what part of the restore you may be in. The way outlined above pretty much bypasses that issue.

 

[rogerl]

A good tip is to change the TTL to the lowest possible value before you start the move.
At least as far in advance as the TTL is currently set to.

That will ensure the DNS propagates much faster and in most cases it will be a matter of minutes, an hour or 2 at the most.

I agree and it certainly helps, but so many providers cache and ignore the setting whatever you put it to. I always lower it several days before doing a move, but you still see people hitting the old site 7-10 days after changing whatever you set it too!

 

[rogerl]

By the way you detail... you may have users hitting a dead site or the site be showing errors, depending on what part of the restore you may be in. The way outlined above pretty much bypasses that issue.

Nobody should ever hit a dead site or get errors if this is done properly.

There is a brief time with the board unavailable and a notice up whilst you move and restore the database, but this is entirely under your own control, unlike DNS propagation.

 

[TPerry]

Nobody should ever hit a dead site or get errors if this is done properly.

There is a brief time with the board unavailable and a notice up whilst you move and restore the database, but this is entirely under your own control, unlike DNS propagation.

Once more.... for users that use a major DNS provider... one won't. Those issues typically occur when someone uses their ISP provider DNS service.

And sorry... still not a fan of telling someone to run to sites off the same database located in a different datacenter, when a LARGE number of folks won't know what/how to do it, how to secure it, and many shared hosting providers will block outside attempts to connect to the local DB from outside.

 

[Black Tiger]

On a server move, I lower TTL and do the move at night time, most users are a sleep. As Tracy Perry said in post #10. Just close the old forum with a notice. Little people will mind as you normally don't move server 10 times a year.

Move it and restore on the new server. And if you can access the new forums, open the forums there on the new server only.
This way users know when they are on the new server, as stated.

and many shared hosting providers will block outside attempts to connect to the local DB from outside.

Exactly! Maybe even most shared hosting providers block this. And with good reason.