Uploaded image for project: 'MariaDB Foundation Development'
  1. MariaDB Foundation Development
  2. MDBF-299

Minimum Viable Product - MariaDB Kubernetes Operator for traditional replication

    XMLWordPrintable

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • N/A
    • Kubernetes
    • None

    Description

      About K8s operator

      A Kubernetes Operator is a controller that encodes human operational knowledge: how do I run and manage a specific piece of complex software.

      Operator is an custom resources in K8s involving specific knowledge of application (in our case MariaDB) in order to automate lifecycle.
      This task should create MariaDB operator used to create the MariaDB statefull application in a cluster.

      Project scope

      The goal of this project is to create a Kubernetes Operator. As a Minimum Viable Product (MVP), the operator needs to know how to:

      1. Start a MariaDB Server
      2. Set up the initial database (mariadb_install_db, authentication methods, networking ports)
        1. Set up a complete and secure networking configuration (service) between nodes.
        2. Configuration method for specifying which machines to be used as nodes.
        3. Configuration method for specifying data directory locations.
      3. Set up a replication topology - primary server (master) & at least 2 replicas (slaves) (Asynchronous replication)
      4. Provides HA.
        1. Monitor the status of all MariaDB nodes in the cluster and restart in case nodes go down.
      5. Easy management of cluster; Change the size parameter to add/remove members from cluster

      Things that are not part of MVP, but are to be considered as future development:

      1. Ability to take backups (on demand or scheduled backup - locally or to object storage -S3, restore DB from existing backup)
      2. Provisioning of slaves from backups.
      3. Ability to fine tune which machines get assigned to which nodes. (For example master node might need to have more CPUs).
      4. Detect master failure and automatically promote one of the slaves to become the new master.
      5. Proxying. Automatically route writes to Primary/ies and distribute reads between all members (example haproxy, proxysql).
      6. Encryption in transit and Data-At-Rest
      7. Usage of private docker registries
      8. Helm chart to deploy the MariaDB operator (instead of editing yaml file).
      9. Change from master-slave replication to Galera replication topology.

      Attachments

        Issue Links

          Activity

            People

              anel Anel Husakovic
              anel Anel Husakovic
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 84d
                  84d
                  Remaining:
                  Time Spent - 4d 0.5h Remaining Estimate - 55d 7.5h
                  55d 7.5h
                  Logged:
                  Time Spent - 4d 0.5h Remaining Estimate - 55d 7.5h Time Not Required
                  4d 0.5h