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

Add lightweight witness/arbiter node support to MaxScale for 2-node quorum

    XMLWordPrintable

Details

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

    Description

      Today, achieving safe automatic failover with mariadbmon cooperative locking requires a 3rd voting participant — but the only mechanism available is registering a full MariaDB server (real mariadbd, storage, replication stream) as a non-promotable monitored server.

      MaxScale should support a native, dataless witness/arbiter/observer role that:

      • Runs as a lightweight client process ( no storage, no replication, no mariadbd maybe?) — reports reachability of registered DB nodes to MaxScale for quorum calculation.
      • Participates in cooperative_monitoring_locks majority math
      • easy to configure: avoid using servers_no_promotion workarounds ?, since it's structurally never promotable. unless we want a dedicated new variable tracking these witnesses potentially
      • Supports being deployed almost anywhere?, including on maxscale itself, including application-tier servers, so customers can achieve quorum without provisioning dedicated infrastructure
      • Degrades gracefully if witnesses are unreachable, using that information as needed for calculations

      Note:
      critical for true AZ fault tolerance in 2-AZ deployments (a witness inside either existing AZ doesn't actually protect against that AZ failing outright).

      Current Design

      Implement a router for MaxScale that supports:

      Additionally, support for SET statements must be partially supported so that wait_timeout is parsed and respected. The behavior should be exactly as in MariaDB.

      Design Considerations for MaxScale Implementation

      The implementation in MaxScale does not need to strictly follow MariaDB. The primary purpose is for this to be usable with mariadbmon. This means that the timeout for GET_LOCK does not need to be implemented as mariadbmon never uses it which simplifies the implementation. The processing of wait_timeout is also not needed as MXS-6867 can be made a blocker for this.

      The implementation must support multi-statement parsing as mariadbmon uses SQL that sets the wait_timeout and does the GET_LOCK call in one multi-statement SQL query.

      Attachments

        Issue Links

          Activity

            People

              markus makela markus makela
              allen.herrera Allen Herrera
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - 5d
                  5d
                  Remaining:
                  Remaining Estimate - 5d
                  5d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                  Git Integration

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