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

Upgrade MariaDB backend server(s)

    XMLWordPrintable

Details

    • New Feature
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Won't Do
    • None
    • N/A
    • N/A
    • None

    Description

      It would be nice if customers could interact with MaxScale (via GUI, CLI, and API) to schedule and/or initiate upgrade(s) of attached MariaDB backend(s).

      In all cases, the goal would be to ensure the upgrade occurs using best-practice (ex- https://mariadb.com/docs/service-management/upgrades/enterprise-server/release-series/) and leverages benefits of MaxScale's extra understanding/visibility of topology.

      In a very basic case, a user could select a specific MariaDB backend to upgrade. The customer would be shown the backend's current MariaDB version and would be given one or more newer MariaDB versions the user could select from to upgrade the backend to. cPanel has an example interface for something like this which might give an idea of useful GUI feedback to a user for this process. Once the user selects the new version and initiates the upgrade, MaxScale would connect to the backend and take all, necessary steps to upgrade the backend to the new version.

      In a more advanced case, a user could select a MariaDB Monitor object and tell MaxScale to initiate a rolling upgrade for all backends attached to that MariaDB Monitor object to a target MariaDB version. In this case, MaxScale would leverage MariaDB Monitor's understanding of primaries and replicas to select one (perhaps more- could let user configure how many replicas can be done in parallel) replica to upgrade at a time, taking not only the necessary steps to update the replica, but to also perform appropriate cluster management within MaxScale for the node to safely drain connections and enable maintenance mode until the replica successfully completes its upgrade. Upon getting to the primary node, MaxScale would need to perform a primary switchover to the best-fit, healthy replica that is already on the new version, and to upgrade the old primary and then rejoin it as a replica (it would also be nice to have an option such that the old primary, post-upgrade, can be setup as a replica only long enough to catch-up to the new primary and to perform another switchover to restore the old primary as primary again).

      The kind of complex upgrade operation above is something which right now requires significant coordination from customer DBAs to achieve in a properly HA, safe fashion, but which MariaDB has all the tools to enable MaxScale to achieve with one click, one CLI command, or one API request. This would go a long way to improve customer confidence in MariaDB's HA upgrade process and would make customers more likely to upgrade to newer MariaDB versions more frequently.

      Another benefit of such an approach from MaxScale would be enabling hands-off/scheduled upgrades. Particularly for customers who have more daytime-specific database needs and smaller DBA/IT teams, letting them schedule MaxScale to perform upgrades overnight (or even on a regular, "automatic upgrade" cadence at a scheduled time) would make it easier to get upgrades done in a timely manner.

      Attachments

        Activity

          People

            toddstoffel Todd Stoffel (Inactive)
            rob.schwyzer@mariadb.com Rob Schwyzer
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

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