Second Traccar platform driven from same GPS

I'll mention some points for possible development and improvement.

To have a backup system instantly ready to switch to in case of server failure. :

1. Host the Traccar's database on a different server but within the Cloud account (or LAN) and not externally Internet-facing. Have a regular backup.
2. (Cloud) Have an inactive VM ready which is a clone of the active VM. Just needs the external IP address and ready to go.

This "master/slave" primary/secondary scheme this thread started with:

1. Development of the {query string} in the Osmand protocol emulation so all needed live data is transmitted, not just the position data
2. If a redundant (secondary) database is used, a way of synchronising it with configuration changes to the primary such as geofence etc. This could be through a PHP script runing on apache, or a Java app.

Yes many roads lead to rome as they say :)

Yes many roads lead to rome as they say :)

Yes and knowing which is the best route to take :)

This scheme has worked much better than I'd expected. I've now successfully reduced to zero all effects of breaks in service after migrating to a replacement server. No break in service had affected me at all and live data was continuously available during system outages. I used it to fully test a replacement server with real live data and real users.

I can now also clarify these queries

I dont get the purpose of the idear..
Answer: To fully test a replacement server with real live data and real users so problems in service have zero impact.

What can the main (primary) Traccar server do which the secondary can't
A: Users can instantly revert back to this 'old server' (= main, primary) when the new server breaks.

On the main server you can already see all incoming data on the map, logfile, etc and see the device on the map.
A: No. Users are not looking at this 'main server'. They are using the 'new server' (until it breaks, THEN then it's "yes").

Why would you need to see that on a secondary traccar server ?
A: Because this is exactly how you test it, with real devices and real users. You can't test the new server if you're looking at the old one.

About my specific case. A Traccar platform migration from a physical server over to a Cloud-based virtual machine. The physical server has worked flawlessly for years, so turning off this service is not an option. Shutdown will only happen when cloud VM has enough attained runtime hours with real data/ users, at the moment nowhere near reliable enough.

The cloud VM is unreliable and problematic. Although the VM "specification" exceeds the physical server, there are still problems with 'resources', 'memory' etc. , the OS is too top-heavy with the cloud provider's services, the OS keeps killing services, and constant 'update-itis' and lot of other problems due to it being remote located. It makes cloud VM more trouble than it's worth over a physical server. I have even seen Traccar platform run fine running on a 10 year old laptop portable computer collecting dust leaning against a wall in the back of a store room.

Ok, interesting to read about your idears. Im running traccar on virtualbox. So i just clone the whole system and store it on an NAS. And can restore it in less then a minute on any server. But actually i never had to restore it because of a server crash or hardware problem. Internet is stable here. Meaby one hour maintenance downtime overnight in a year.

I wonder, how may devices do you have running on your traccar server ?

To restore in less than a minute is OK but you have to be available to do that 24/7. With this scheme of mine the user can instantly revert back to the primary server, no need to alert anyone and wait for a response. Just open the other icon and it's there. They would likely not even bother to report it.

I have never had any problem with physical servers in any shape or form they in but I'm not impressed at all so far with cloud computing.

I can't say how many other than few in number but "mission-critical" and watched like a hawk.

i think you should add a failover ip then and send the data to that ip:port, instead relaying data from server1 to second.

if server 1 fails, then your data never will arrive server2, or get an anycast ip with 2 locations, same setup and devices added.

or! rsync your database from server1 to server2 so all updates are there on real time.

something interesting but not for GPS is aishub, you send data to them, and then relay to many places.

@Alejandro M Some good ideas you mention.

It's been three months since I made the orginal posting, I should update on what happened.

The start of this was a planned migration from a physical server over to a remote cloud server. There couldn't be any service interruptions so there had to be two systems running in parallel. Went through a few stages:
0. Original (physical) system + devices & users

1. Original system + devices & users > copy of data to second (cloud) system + evaluators
2. Original system + devices & users > copy of data to offline second system is broken
3. Original system + devices > copy of data to second system + users tryout and debugging
4. Original system + devices & users reverted back > copy of data to offline second system broken again
5. Original system + devices > copy of data to second system + users migrated, with stress testing + reliabilty test
6. devices migrated to second system + users
7. original (physical) system mothballed

The cloud computing problems were mainly down to the cloud services vendor wanting you solve problems by upgrade to higher specification and by throwing money at the problem. For instance they want you to purchase more physical RAM memory instead of you using their hard drives as virtual memory (more than adequate). Of course they'll prefer customer paid-for RAM used instead of their own hard drive's cache RAM. Setting up a persistent swapfile makes all the difference.

So now I don't have a secondary platform at the moment but now I know there's more than one way of doing it.