Supported Failover and Scaling Strategies


The TeamDrive Client application has no auto detection to check if a server is available or not. You have to make sure that all published domain names can be reached by the TeamDrive Client.

The Registration Server can be scaled very well horizontally. There are 6 scaling and failover strategies possible which are based on the “MySQL Reference Architectures for Massively Scalable Web Infrastructure”:

For the following scaling strategies 2 and 3 the Registration Server and the TeamDrive Client offer a functionality where you can offer multiple URLs to a client. The client will then distribute requests using a round robin mechanism to all Registration Server instances.

Tiny architecture

No fail over, no scaling

Run all process on one machine. We recommend using a local mysql replication and storing the replicated database on a second disc or network volume in order to have some data redundancy.

Small architecture

Two MySQL server basic failover

Run two machines which mirror each other. Machine 1 will run the MySQL master and will replicate the database to machine 2, the MySQL slave. Both servers are running an apache which will connect to the MySQL master. In case of an error with the MySQL master, the MySQL slave will become the master and the apache connections must be switched to the new MySQL master. If one machine dies completely, all processes must be executed on the other machine. Switching the processes will not automatically handled by the teamdrive components and must be setup manually or automatically by a failover script which might also take care of moving domain names to the other server.

Medium architecture

Divide the apache front end server from the database instance

Run one database server and several apache server in front of the database server. Additional apache front end server can be added later on. Use the round robin mechanism of the TeamDrive Client application to distribute the requests over the different machines.

Automatic availability and scalability architecture

Load balancer configuration with single database instance


This requires the ability to launch more front end instances on demand

Use configuration 3 and put a load balancer in front of the apache server, so that the requests will be automatically distributed over all apache servers without using the round robin mechanism of the TeamDrive Client application. The load balancer will take care to distribute the requests over all front end servers.

Keep in mind that you might need 2 load balancers to be safe in case of a hardware failure.

Large architecture

Load balancer configuration with scalable & failsafe MySQL configuration

Use configuration 3 and / or 4 and make the MySQL instance scalable and failsafe. There are different mechanisms and strategies available to make MySQL failsafe. This also depends on your hardware infrastructure. The best solution for your environment must be checked together with TeamDrive Systems. Additional modification might be necessary to optimize the Registration Server software to fit your requirements.

Extra large architecture

Use TDNS to distribute users over more than one Registration Server system Use configuration from “Tiny architecture” to “Large architecture” in combination with the TDNS. to distribute users over more than one Registration Server system (API usage or different client installers necessary)