Complete test plan for transaction replay against XPAND Direct

Prologue
There are multiple dimensions in the process, with lots of possible permutations of events which may occur at different times. Group Change may be very fast or rather slow. Sessions may be idle, or have transactions. Transactions may be quiet or running a statement. Group change can be initiated by flex-down or flex-up; or by node crash. Crashed node can return into the cluster without causing group change (10 minutes), or be considered dead (>10 min). There may be more.

It is safe to assume that by now MaxScale has these algorithms fully debugged for normal read-write splits. The new and unusual thing about XPAND is that Group Change makes entire cluster inaccessible in a special way. It is worth validating the behaviors empirically.

Given that the number of possible permutations is close to infinite, In this project we will select only a number of scenarios, trying to achieve the highest likelihood of overall success.

Plan
We concentrate on long group changes only.

Part 1. Actions on the departing node

Part 2. Actions on the nodes not affected by group change

Note Later on we would try to observe what happens to idle and active sessions and transactions living on a node which crashed and is not coming back when the 10 minutes interval is about to expire (i.e. when an activity is attempted while XPAND is still hoping for the node to come back, and then went into group change). But this is in due time. Let's get the fundamentals verified first.