Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-3284

Multi-DC conflict resolution



    • New Feature
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Won't Do
    • None
    • N/A
    • binlogrouter
    • None


      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.




            toddstoffel Todd Stoffel (Inactive)
            shane.johnson@mariadb.com Shane Johnson (Inactive)
            0 Vote for this issue
            2 Start watching this issue



              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.