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

Resolve cooperative monitoring deadlocks

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Icebox
    • Component/s: mariadbmon
    • Labels:
      None

      Description

      MaxScale 2.5 introduced cooperative monitoring as a way for two MaxScale instances to decide on their own which is the active and which is the passive instance. In the KB this is now left as the sole option (articles on keepalived, Lsyncd etc. have been removed). Unfortunately, cooperative monitoring does not work well when the system has (or, depending on the monitoring mode, ends up having) an even number of (active) nodes; this may easily lead to the situation when both MaxScale instances become passive and here is none to perform the HA function of a failover, should such be needed.

      Example: One primary, three slaves; MaxScales running with "majority of all"; each MaxScale obtains two locks and remains passive due to lack of quorum. Similar scenarios can be created for "majority of running" mode also.

      We see at least two ways of resolving such deadlocks:

      • With MaxScale-to-MaxScale communication: a strategy like "lowest IP address wins" may help a MaxScale become active when no MaxScale holds a majority of the necessary locks.
      • Without MaxScale-to-MaxScale communication: assigning a weight to each locked node and using these weights to form the quorum. Following the above example, if one of the nodes is given a weight of 2, sum of all will not be 4 but 5, so one of the MaxScale instances will have 3/5 of the lock's weights and will thus stay active even though it will only have locks of 1/2 of the nodes (the other MaxScale will also have locks for 1/2 of the nodes, but will only have 2/5 of the sum of all weights).

        Attachments

          Activity

            People

            Assignee:
            toddstoffel Todd Stoffel
            Reporter:
            assen.totin Assen Totin
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: