Memstate is a complete redesign of OrigoDB with major improvements in key areas such as performance, availability, licensing, cross-platform, docker and cloud support.
Please visit Memstate on Github for more information!
OrigoDB supports multi-server replication using a single primary node and zero or more replicas in either standby or readonly mode. Commands are handled by the primary and synced with each replica over a tcp connection, either synchronously (default) or asynchronously. Read-only replicas handle queries while commands are rejected with a redirect message pointing at the current primary.
Replication can be used to
Switchover is when the primary and one of the replicas exchange roles. Switchover is performed manually using the web ui of either the primary or the replica. The transition is completed within milliseconds. Switchover allows system maintenance without downtime.
Failover is the same as switchover except it being due to a failure at the at the primary. Promoting a replica to primary is performed manually using the web ui.
The native client has information about the current cluster configuration. In the event of a switchover, clients will be automatically redirected to the new primary. If a client loses connection with the primary it will attempt to reconnect to a replica.
A readonly replica will respond to queries and commands on the native interface. This is useful for distributing heavy read load across multiple servers. In standby mode the replicas native interface not active. Use standby mode to have a hot replica ready to instantly take on the role of primary. Standby mode requires no additional license.
Each replica can be configured with either synchronous or asynchronous replication. In sync mode the primary will wait for each replica to acknowledge each transaction. Sync mode provides 100% consistency and protection against data loss but adds latency to each transaction.
In async mode, the primary puts commands in an internal queue and commits immediately, eliminating extra latency. The internal queue is processed by a background thread. Under load, async replicas will lag behind. If the primary were to crash the queued commands will never reach the replica. Promoting a replica to primary under this condition will result in lost transactions.
There is no limit to the number of possible replicas. By using different configurations it’s possible to achieve a number different goals. Here are some example use cases.
This is the normal high availability configuration. A primary and a single replica in standby sync mode both connected via gigabit LAN.
A primary and one or more replicas in read only async mode for reads and one replica in read only sync mode for HA. The async replicas may lag behind under heavy load. How far they lag behind will depend on both the write load and the read load at each replica.
A search engine would be a good fit for this configuration. The eventual consistency won’t be a problem, it means some users will be served slightly dated results. The crawler(s) might need a 100% consistent view. This can be achieved by directing their queries to the primary.
This is similar to the async read load scaling scenario but all the replicas are in sync. It won’t scale as well because write throughput will diminish with increasing read load and for each replica added. Use this configuration when eventual consistency is unacceptable.
A replica in async read only mode connected over WAN/VPN can be used for analytics/reporting or to bring data closer to the user. Client applications can be configured to send commands to the primary and read from the local replica.
A replica in async standby mode connected over LAN/WAN/VPN is a useful backup strategy.
ORIGO