So you want to set up Master-Master Replication. Clustrix 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.
Master-Master replication involves two databases, each able to take reads and writes that are replicated to the other database. In order to successfully maintain consistency between the two masters, writes should be segregated so that there are never conflicting operations performed across the replication stream.
Here are some questions to consider as you set up Master-Master 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 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 ClustrixDB as a Replication Master.
Feel free to contact Clustrix Support with any other questions you may have about Replication.