The general description and the full background can be found in

https://docs.google.com/document/d/14TsnuBUZ_WCcwv3jJqBnF3TuBiU_OHBTzTP7Zx_Xxjc/edit#heading=h.gnlldgczly15

It appears the proposal can be implemented in 2 phases.

Phase 1 . This is likely to be satisfactory to the client in question. At this stage we will still rely on command history for both RETRY and session failover. What this ticket is requesting is:

a) Enable an additional directive to MaxScale requesting "rebalancing" of existing sessions. This operation would be requested when the XPAND cluster is enlarged.
The act of rebalancing can be of longer duration. Sessions which are currently "eligible" (have no outstanding transactions opened on them) can be "moved" right away.
If the desired distribution is not immediately achieved, additional "moves" can be delayed and performed when presently active transactions complete.

b)Enable additional directive to redistribute sessions presently located on a living server to other servers. This should be requested prior to terminating a node gracefully.
We will probably owe them a method of checking if such redistribution has been completed.

In Phase 2, if we ever go there, we can talk about enhancing the current mechanism of moving sessions which presently depends on command history.

Instead, "eligible" sessions get "moved" to a different server by
--Reading its current Session State (below), and
--Reconstructing that state on a target server

Some proposed alternatives and possible risks are outlined in the referenced paper.