Today Starcounter provides an async replication facility as part of distribution. You can setup replication for an arbitrary tree of Starcounter instances. This facility can be used:
A) as a classical full-data master-slave,
B) as a partial master-master (for disjoint sets of data when one part of the database tables is master data to the replica but the other part is a mirror of the data that is being changed on a replica) or partial master-slave, with arbitrary filtering on data entries,
C) as a master-master active-passive (standby instance for failover). You can also put a load balancer in front of Starcounter (usually a separate machine, HAProxy or nginx) to track failover events.
Please note that you unlikely will use replication to increase (scale-out) read performance. Starcounter is good enough to provide a desirable performance on a single instance (http://starcounter.com/resources-activities-articles-and-knowledge/starcounter- performance/).
The two major use cases for replication are:
1) Support failover scenario;
2) Support high data availability and low latency, when you want to have a read/write replica at hand, e.g.:
2.1) when point of sales operates disconnected from the mother machine (e.g. store is located in the mountains and the connection quality is poor or connection is missing);
2.2) when a vessel travels in the seas, connects to the ground machine via satellite with disturbances and disconnections;
2.3) Geo-distributed applications, when you want to have replicas of data physically close to users to decrease the connection latency (e.g. run a dedicated replica in China for Chinese users, while having the core business and its servers in Germany).
In the replication facility Starcounter utilises a module called log streamer, which resolves stable replication even over poor network having connection drop-offs and other quality of service degradations. The log streamer aims to efficiently utilise the connection channel and sync data between two parities appropriately on the connection being re-established.
Note that simply letting an async replica take over the failed master isn’t generally enough for failover, since some data might have been reported committed on the master not having reached the replica (due to network loss, master machine network card dead and so on). However, providing a synchronous replication (when the replica acknowledge master to have the data received and master reports transaction committed based on this replica’s feedback) is not a practical choice: master becomes dependant on replica, and the overall throughput of the master system is now bound to the network and to the death of replica. Hence, the active-passive master-passive setup (when one machine is a master, but when the master dies the async replica becomes the master) is a practical choise today (not only for Starcounter installations).
However, a question for small data portions being potentially lost still prevails. In order to support full-consistent failover without sacrificing performance (by sync replication), we will support the following failover setup in Starcounter in one of the future version updates.
1) On a master machine transactional log is written to the fault-tolerant storage (like RAID-1 with multiplexing). When master dies, we expect the fault-tolerant storage to tolerate the fault and redundantly preserve the data. Lower write performance of fault- tolerant stores isn’t an issue for Starcounter, since it is an in-memory database technology, hence it persists data to disk in a sequential manner (rather than writing to arbitrary locations on a disk), enabling to stream gigabytes of writes per seconds to persistent stores.
2) On master death the load balancer / watchdog (usually run on a separate machine close to master machine) tracks a need to pass processing to the standby replica machine (by loosing heartbeat from the master or alike).
3) Standby replica machine takes over. Replica already has all or almost all data from the master. To ensure all data is presented (and fetch the small missing bits if needed) the replica machine reads up from the fault-tolerant storage of the master and syncs replica’s data. Since the diff between master and replica is usually no more than seconds (either because of network data loss, or for the big distance between two machines), it will take a fraction of second or seconds to read up the needed bits (since there is no need to load the whole database into memory from disk, which might take 3-5 minutes for 30-50 Gb database).
4) After the sync is completed, replica becomes a master available for the users.