Details
-
New Feature
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
-
MXS-SPRINT-220, MXS-SPRINT-221, MXS-SPRINT-222
Description
The output of maxctrl list servers has now two columns related to the server state; State and State Info. The former shows the state and the latter the reason for the state. The output in the case of a typical primary/replica cluster might look like:
┌─────────┬─────────────────┬──────┬─────────────┬───────┬────────────┬─────────┬─────────┐
|
│ Server │ Address │ Port │ Connections │ State │ State Info │ GTID │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────┼─────────┼─────────┤
|
│ Server1 │ 192.168.121.103 │ 3306 │ 0 │ Write │ Primary │ 0-1-618 │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────┼─────────┼─────────┤
|
│ Server2 │ 192.168.121.134 │ 3306 │ 0 │ Read │ Replica │ 0-1-618 │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────┼─────────┼─────────┤
|
│ Server3 │ 192.168.121.92 │ 3306 │ 0 │ Read │ Replica │ 0-1-618 │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────┼─────────┼─────────┤
|
│ Server4 │ 192.168.121.136 │ 3306 │ 0 │ Read │ Replica │ 0-1-618 │ Monitor │
|
└─────────┴─────────────────┴──────┴─────────────┴───────┴────────────┴─────────┴─────────┘
|
The state of Server1 is Write, indicating that is the server used for writing and the reason is that the server happens to be the Primary. The state of the other servers is Read since they are Replica s.
If the variable read_only is now set to 1 on Server1, the output will be:
┌─────────┬─────────────────┬──────┬─────────────┬───────┬────────────────────┬─────────┬─────────┐
|
│ Server │ Address │ Port │ Connections │ State │ State Info │ GTID │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────────────┼─────────┼─────────┤
|
│ Server1 │ 192.168.121.103 │ 3306 │ 0 │ Read │ Primary, read_only │ 0-1-618 │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────────────┼─────────┼─────────┤
|
│ Server2 │ 192.168.121.134 │ 3306 │ 0 │ Read │ Replica │ 0-1-618 │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────────────┼─────────┼─────────┤
|
│ Server3 │ 192.168.121.92 │ 3306 │ 0 │ Read │ Replica │ 0-1-618 │ Monitor │
|
├─────────┼─────────────────┼──────┼─────────────┼───────┼────────────────────┼─────────┼─────────┤
|
│ Server4 │ 192.168.121.136 │ 3306 │ 0 │ Read │ Replica │ 0-1-618 │ Monitor │
|
└─────────┴─────────────────┴──────┴─────────────┴───────┴────────────────────┴─────────┴─────────┘
|
The state of Server1 becomes Read and the reason that although it still is the Primary, since it has read_only turned on, it cannot be used for writing.
Original Description
Currently the meaning of master and slave are overloaded; on the one hand they are used for denoting whether a particular server is used (or can be used) in a read-write or read-only manner, on the other hand they are used for describing the roles of servers in a master/slave replication topology. This is confusing.
- In Xpand, every node was marked as Master, to cause it to be used in a read-write fashion, although it was nonsensical to call it master, as there is no replication topology. An entire Xpand cluster can be used in the role of a master with respect to another cluster, but that's a different thing.
- In Galera, one node is denoted as Master, to cause all writes to go to one node (as otherwise you would encounter conflicts), and the rest as Slave, which is nonsensical as there is no master/slave topology in a Galera cluster.
Even in a true master/slave replication cluster there is room for confusion, because e.g. disk_space_ok of master_conditions will cause the master in a replication topology to be marked as being a slave, if it is low on disk space. That means something like "the master in a master/slave replication topology will be marked as master, except if it is low on disk-space in which case it will be marked as slave, even though it is still the master." I.e. extremely confusing.
The situation can be clarified by using Read-Write, instead of Master, to denote a server that is used in a read-write fashion and Read-Only, instead of Slave, to denote a server that is used in a read-only fashion. That would mean that concepts could be explained clearly without ambiguity.
- In an Xpand cluster every node is Read-Write.
- In a Galera cluster, one node is deterministically marked as Read-Write, the rest as Read-Only.
- In a master/slave replication cluster, the master is typically marked as Read-Write and all slaves as Read-Only. However, if e.g. disk space checking is enabled and the master runs low on disk-space, it will also be marked as Read-Only. In this case, writes will fail.
That is, from the perspective of MaxScale routers, a server is either Read-Write or Read-Only. The reason for a server being read-write or read-only then varies according to the type and circumstances of the backend cluster.
For the end-user this would appear as the state and reason being separated. Currently maxctrl list servers looks like:
┌─────────┬───────────┬──────┬─────────────┬────────┬──────┬──────────┐
|
│ Server │ Address │ Port │ Connections │ State │ GTID │ Monitor │
|
├─────────┼───────────┼──────┼─────────────┼────────┼──────┼──────────┤
|
│ Server1 │ 127.0.0.1 │ 5000 │ 6 │ Master │ │ Monitor1 │
|
├─────────┼───────────┼──────┼─────────────┼────────┼──────┼──────────┤
|
│ Server2 │ 127.0.0.1 │ 5001 │ 6 │ Slave │ │ Monitor1 │
|
└─────────┴───────────┴──────┴─────────────┴────────┴──────┴──────────┘
|
After this change, it would look something like:
┌─────────┬───────────┬──────┬─────────────┬────────────┬────────┬──────┬──────────┐
|
│ Server │ Address │ Port │ Connections │ State │ Reason │ GTID │ Monitor │
|
├─────────┼───────────┼──────┼─────────────┼────────────┼────────┼──────┼──────────┤
|
│ Server1 │ 127.0.0.1 │ 5000 │ 6 │ Read-Write │ Master │ │ Monitor1 │
|
├─────────┼───────────┼──────┼─────────────┼────────────┼────────┼──────┼──────────┤
|
│ Server2 │ 127.0.0.1 │ 5001 │ 6 │ Read-Only │ Slave │ │ Monitor1 │
|
└─────────┴───────────┴──────┴─────────────┴────────────┴────────┴──────┴──────────┘
|
If the master would be made read-only due to being low an disk-space, it would appear like:
┌─────────┬───────────┬──────┬─────────────┬────────────┬────────────────────┬──────┬──────────┐
|
│ Server │ Address │ Port │ Connections │ State │ Reason │ GTID │ Monitor │
|
├─────────┼───────────┼──────┼─────────────┼────────────┼────────────────────┼──────┼──────────┤
|
│ Server1 │ 127.0.0.1 │ 5000 │ 6 │ Read-Only │ Master, Disk-space │ │ Monitor1 │
|
├─────────┼───────────┼──────┼─────────────┼────────────┼────────────────────┼──────┼──────────┤
|
│ Server2 │ 127.0.0.1 │ 5001 │ 6 │ Read-Only │ Slave │ │ Monitor1 │
|
└─────────┴───────────┴──────┴─────────────┴────────────┴────────────────────┴──────┴──────────┘
|
Attachments
Issue Links
- is duplicated by
-
MXS-5116 maxctrl list servers | State | Enhancement
-
- Closed
-