Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-5015

Separate read-write/read-only and master/slave

    XMLWordPrintable

Details

    • New Feature
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    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

        Activity

          People

            JoeCotellese Joe Cotellese
            johan.wikman Johan Wikman
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.