Migration to a new server

[sfpx]

What is the typical procedure when you have to move your filemaker server to a new server with a new ip address ?

Are there instructions or a tutorial for a smooth transition ?

I understand that we can't install a license of mirrorsync on 2 computers.

Let's suppose the current Mirrorsync license has 50 users.

Let's say we buy a new license for the new server that syncs data from the old server and the new database and 50 users.

Can we merge the 2 licenses together and have 100 users on the new installation after we delete the previous installation ?

I'm quite intimidated by the task ahead.

Edited July 12, 2018 by sfpx

[sfpx]

I guess that an easier transition would be done in a few steps 

1.We change our mirrorsync config to point to our domain name instead of the ip address

2.We have an app update system that imports all the tables(including mirrosync) from a previous app to the new one.

So a user that was syncing to the ip address now syncs to the domain name but keeps using his device sync data on the current server.

3.Once everyone has the new version then we can stop mirrorsync .Copy it on the new server.Copy the new database.

4.Change the domain name ip address. 

5. Restart mirrorsync

 

something along those lines.

Would it work ?

[sean360Works]

Hello!

Before I can answer your question, I want to verify exactly what you're trying to do. You have a server with 50 users syncing to an old IP. You want to transition the database and all users on that server to a new server with a new address, and eventually discontinue the old server. Is this correct?

I'm assuming you do not have anything setup on the new server for the database in question.

By smooth transition, do you mean you would like to allow users to continue to sync throughout the transition instead of doing a hard stop on syncs while the new server is getting set up? Specifically, do you want two servers hosting their own instance of the same database, and have the host files sync with each other until all users set up their machines to sync with the new server?

Also, do you want to increase the total number of users allowed to sync with the database, as well? To clarify, in your example, there are two separate groups of users syncing. 50 users are currently syncing on the old server, and 50 new users will be syncing on the new server once the database is hosted. When the transition is complete, the 50 users who were syncing on the old server will join with the 50 others on the new server, making 100 users in total syncing with the new server. You didn't mean 50 users syncing on the new server as just available license space for the original 50 to occupy. Is this correct?

[sfpx]

Quote

Hello!

Before I can answer your question, I want to verify exactly what you're trying to do. You have a server with 50 users syncing to an old IP. You want to transition the database and all users on that server to a new server with a new address, and eventually discontinue the old server. Is this correct?

That is correct.

 

Quote

I'm assuming you do not have anything setup on the new server for the database in question.

The new server is not set up yet.

 

Quote

By smooth transition, do you mean you would like to allow users to continue to sync throughout the transition instead of doing a hard stop on syncs while the new server is getting set up? Specifically, do you want two servers hosting their own instance of the same database, and have the host files sync with each other until all users set up their machines to sync with the new server?

Ideally users would still continue to sync to the old server and gradually , when they update to the newest version would sync to the new server. But I understand that it's probably more complicated because of the licensing issues , would necessitate a server to server sync and would also probably necessitate an initial sync on the new server. I would not mind if I had to hard stop all the syncs for an hour or 2 if it means that I can import de device sync data on the new server and they can continue to sync normally once I started mirrorsync on the new server (after I changed the ip associated with the domain name...not sure how long it takes to propagate). Of course with this 2nd method I would need to make sure all the users have the version that syncs on the domain name before stopping mirrorsync and start the migration.

 

Quote

Also, do you want to increase the total number of users allowed to sync with the database, as well? To clarify, in your example, there are two separate groups of users syncing. 50 users are currently syncing on the old server, and 50 new users will be syncing on the new server once the database is hosted. When the transition is complete, the 50 users who were syncing on the old server will join with the 50 others on the new server, making 100 users in total syncing with the new server. You didn't mean 50 users syncing on the new server as just available license space for the original 50 to occupy. Is this correct?

I do not really want to increase the number of users.

It's just that I understood that I can not install the same mirrorsync license on 2 servers (at least that's what I read somewhere)  so I would actually need to buy a new license with the same amount of users if I want both servers to sync at the same time. Maybe I got that wrong.

Thanks for your help.

 

Edited July 12, 2018 by sfpx

[sean360Works]

Conducting a hard stop on syncing to move the database to a new server would be the simplest and least risky method, and it would not require any new license/configuration purchases. I would recommend doing the following:

To reduce server downtime, you can set up your new server with a 1 sync device configuration at no cost. Do this to test your new configuration so integrating the database over to the new server goes more smoothly. Once you have a successful configuration on your new server, have all users perform a final sync to update the database, and then close out of their files. When all users have done so, copy the up-to-date database file to the new server. Step the file through the MirrorSync configuration client you already created on the new server to make sure there are no discrepancies. Copy the scripts into your database file, then you should probably test a sync to make sure everything is working properly, and distribute new offline copies to all of your users.

I hope this information helps, and let me know if you have more questions!

[sfpx]

11 minutes ago, seankuhn said:

Conducting a hard stop on syncing to move the database to a new server would be the simplest and least risky method, and it would not require any new license/configuration purchases. I would recommend doing the following:

To reduce server downtime, you can set up your new server with a 1 sync device configuration at no cost. Do this to test your new configuration so integrating the database over to the new server goes more smoothly. Once you have a successful configuration on your new server, have all users perform a final sync to update the database, and then close out of their files. When all users have done so, copy the up-to-date database file to the new server. Step the file through the MirrorSync configuration client you already created on the new server to make sure there are no discrepancies. Copy the scripts into your database file, then you should probably test a sync to make sure everything is working properly, and distribute new offline copies to all of your users.

I hope this information helps, and let me know if you have more questions!

Thanks for help.

The thing is that I would like to avoid having to do initial syncs.

We currently have in place an update system that works. It installs an empty version of the database on the device and imports all the data from the previous version (including the mirrorsync table). This way, users still can sync normally after an update.

My idea :

1.Change my current mirrorsync config to point to the domain name instead of  the ip address

2.Wait until everyone has the new version that syncs to the domain name

3.Stop mirrorsync on the current server

4.Install mirrorsync on the new server

5.Copy everything related to mirrorsync on the new server (device sync data , logs etc)

6.Change the ip associated with the domain name

7. Wait for propagation

8.Users sync to new server

Could that work ?

Edited July 13, 2018 by sfpx

[sean360Works]

That could possibly work. You probably already know this, but just in case, you'll want to decrease the TTL when you make the address change to a domain name so the propagation step doesn't cause a lot of downtime. Another step I forgot to mention is, while you make the change to the domain name in your MirrorSync configuration, you'll need to delete the database's MirrorSync external data sources before you copy the new MirrorSync scripts into the file.

Edited July 16, 2018 by seankuhn

[sfpx]

I have some problems importing the Mirrorsync data onto the new server

1.Installed Mirrorsync on the new server

2.Imported the configuration

3.Copied the SyncData4_MirrorSync folder from the old server to new one

When I try to sync I get the following error

Quote

Could not open connection to HSQL: java.sql.SQLException: problem with log file:  - file check mismatch - 1

 

Solution ?

Edited February 22, 2019 by sfpx