[MXS-4357] Document how master_reconnection works, with examples Created: 2022-10-20  Updated: 2023-02-13  Resolved: 2022-11-15

Status: Closed
Project: MariaDB MaxScale
Component/s: Documentation, readwritesplit
Affects Version/s: 2.5
Fix Version/s: 2.5.23

Type: Task Priority: Major
Reporter: Valerii Kravchuk Assignee: markus makela
Resolution: Fixed Votes: 1
Labels: missing_manual

Sprint: MXS-SPRINT-170

 Description   

We have master_reconnect setting since 2.3.x, but current documentation:

https://mariadb.com/kb/en/mariadb-maxscale-25-readwritesplit/#master_reconnection

does not include any example on how the connection will work (what client side will get) when it's enabled. There are many preconditions listed, and one may assume (without reading that KB page) that connection to current master will be transparently re-routed to a new master, while this may not be true and the feature is more about changing read only status for the connections to promoted slave (correct me if I am wrong).

Please, elaborate and show some use cases for this feature with examples (in KB and/or Enterprise Documentation).



 Comments   
Comment by Valerii Kravchuk [ 2022-11-15 ]

This part:

"With master_failure_mode=fail_instantly, the master server is only allowed to change to another server. This change must happen without a loss of the master server."

is not clear to me. That's why I asked to provide examples. Some session started, connected to a master and did something, now master fails (let's say crashes) and a new master is picked up by MaxScale. We need to know what will happen to a session upon the next SELECT or next data change attempt for each reasonable set of related settings.

Maybe a table is needed, showing the outcome for each set of related parameters (columns) for a given kind of operation (row), including open transaction etc. Specific error returned, what data we get, what else influence the outcome. Or maybe a flow chart to follow to find out the outcome. Something easy to understand without doubts and misinterpretations.

Generated at Thu Feb 08 04:28:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.