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

Cooperative Transaction Replay



    • New Feature
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • Icebox
    • None
    • None


      Many customers run MaxScale in container environments where unique memory leaks and other stability issues can affect individual instances and require them to be restarted.

      Although we currently have good HA architecture patterns, as well as client-side java connector failover capability, and cooperative monitoring makes multiple MaxScale instances able to work together effectively in managing back-end topologies, destroying an instance because it's leaking, for example, is still an incident with adverse consequences because whatever transactions are in-flight in current connections handled by the given MaxScale instance are lost.

      Transaction_replay manages this problem beautifully in the event of a lost back-end server. Having a similar mechanism to cache the client connection, recognize it from a second MaxScale in an HA configuration, and deliver back to that client whatever results might not have successfully made it from a destroyed MaxScale.

      Although replicating the transaction replay queue on every MaxScale is one way this could be accomplished, now that some MaxScale state information is already stored server-side, specifically who the controlling MaxScale in a cooperative group is controlling, it, replay & session information could also be stored on the database servers themselves.


        Issue Links



              Unassigned Unassigned
              juan.vera Juan
              1 Vote for this issue
              7 Start watching this issue



                Git Integration

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