So you want to set up Master-Master Replication. Clustrix Xpand supports all types of MySQL Replication topologies, including Master-Master. However, the database is just one part of what needs to be considered for setting up Replication.
- How will data be segregated?
- How might you expect the peak times to vary?
- What happens if ownership of some data transfers between masters? How is the transition handled? Example: For an application segregated by user location, what happens if a user moves between location masters?
- Are there any requirements for referential integrity between masters?
- How will shared metadata be managed?
- How will you prevent Key Collision on INSERT? Do you use auto-increment now? A master-master setup needs a key generation topology that guarantees uniqueness.
- How will your application handle MVCC errors, where multiple transactions try to modify the same row? Is there retry logic currently in place?
- What about online DDL like TRUNCATE, ALTER, etc? Do those need to be replicated?
- How will the deployment of application upgrades look where schema changes are also required?
- How will timestamps be handled?
- Do you plan to use a tool such as Tungsten to manage this configuration?
- Do you have a documented failover plan?
- Can this plan be used to quiesce load onto a single cluster in order to resolve data discrepancies in case of some replication error?
- How will you validate your approach and check for data consistency?
- What type of application testing will there be before you start the Master-Master replication? ClustrixDB Xpand on AWS may be a good candidate for validating that two will not encounter data inconsistencies.
Once you are confident you understand the above use cases, see steps for configuration on Using Xpand as a Replication Master.
Feel free to contact Clustrix Xpand Support with any other questions you may have about Replication.