Cooperative Transaction Replay

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.