[MXS-3284] Multi-DC conflict resolution Created: 2020-11-05 Updated: 2022-09-08 Resolved: 2022-09-08 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | binlogrouter |
| Affects Version/s: | None |
| Fix Version/s: | N/A |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Shane Johnson (Inactive) | Assignee: | Todd Stoffel (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Given the use of multiple data centers, and active/active deployments, it would be great if MaxScale could perform conflict detection, and optionally conflict resolution strategies as well. In this scenario, MaxScale is both a binlog router for a local cluster as well as a replica of a binlog router in a remote cluster. The idea is to compare incoming binlog events from the remote cluster (as a replica) against outgoing binlog events from the local cluster (as a binlog router). One idea is for MaxScale to maintain a sliding window of outing binlog events (from the binlog router) and to check if an incoming event (as a replica) conflicts with one. If MaxScale could get the primary keys of tables in Server, then perhaps it can use them to identify multiple binlog events (in a defined window) whose rows have the same one. At the very minimum, MaxScale should log the conflict to a file. Optionally, simply conflict resolution would help as well. It may also need to implement a delay so binlog events are buffered before being sent (outgoing)/applied (incoming). This could allow MaxScale to implement a deterministic algorithm for universally accepting, rejecting or modifying binlog events such that if there were a conflict, multiple MaxScale instances (one in each DC) would all make the same choice, data would be consistent and the conflicts/resolutions logged. However, detection alone would be a nice addition. |