xDB Replication Server - Multi Master
Who needs multi-master replication?
Is your organization de-centralized into multiple units that are geographically dispersed? Does each unit manage similar or identical data? Are users in one unit finding they need quick access to data from other units within minutes and not hours or days? Are you struggling to maintain write availability for all your units?
A ‘yes’ to any one of these questions means you need to consider an xDB Replication Server Multi-Master configuration. With a multi-master configuration it’s easy for everyone to keep writing data they can all view in near real time and read more data than in single master configurations.
What can multi-master replication do?
When you have multiple master databases it is possible to achieve faster access to consolidated data, better uptime performance for round the clock updates, and read scalability, all using commodity hardware!
Continuous Data Integration
Say goodbye to scheduled batch jobs that temporarily synchronize data across locations from a central master. Continuous asynchronous master to master replication means one region’s data is available to all regions in near real time.
High Availability for Writes
If a master in one region fails, users won’t have long delays to enter / update data until a replacement is brought online. You can re-route the downed region’s database requests to another region’s database. When the replacement master re-joins the cluster, it will re-synchronize with the other masters automatically.
Automatic Conflict Resolution
If conflicting edits occur on the same row during replication (i.e. a uniqueness, update or delete conflict), you can choose from Earliest Timestamp, Latest Timestamp, Node Priority, custom algorithms, or manual options for determining a resolution. You can even have a standby resolution should your first choice not resolve the conflict.
Scalability for Reads
In addition to each of your local regions or users having faster access to integrated data, your systems will be able to handle more reads and queries. Each master will be available to handle queries from any region or any query needing consolidated data. To scale further you can build out Hot Standby replicas to each master that handle even more read loads providing you a very flexible and scalable architecture for the future.