DOCSEARCHbyAlgolia
Submit Docs

cnmsql Documentation

website·Indexed 30 days ago

https://cnmsql.co

Documentation for cnmsql, a Kubernetes operator for managing MySQL and MariaDB clusters. Covers cluster lifecycle, Group Replication, point-in-time recovery (PITR), automated backups, autoscaling, and the mysql.cnmsql.co/v1alpha1 API reference. Includes guides on storage configuration, multi-tenancy models, and security trust boundaries for versions 0.5 through 0.7.

Tokens
329.2K
Snippets
1.3K
Records
2.3K
Agent score
42%

What's inside cnmsql

  1. Overview of cnmsql instance images

    cnmsql uses custom instance images based on Percona Server for MySQL (not Oracle MySQL). These images are designed similarly to the CloudNativePG model, where the operator controls an image containing the database, Percona XtraBackup, and the cnmsql manager binary, rather than relying on upstream database images. The images are rootless, running as UID 1001.

  2. Overview of CNMSQL for Percona Server for MySQL

    CNMSQL is a Kubernetes operator designed for Percona Server for MySQL. It allows developers to manage MySQL clusters declaratively by defining a Cluster resource. The operator automates the provisioning of Pods, PVCs, credentials, TLS, and role-routed Services, while handling replication, failover, backups, and point-in-time recovery (PITR).

  3. Overview of MySQL account management mechanisms in cnmsql

    cnmsql provides three ways to declare MySQL accounts depending on ownership and scope:

    1. spec.managed.roles (Cluster): Used for cluster-level accounts owned by the platform team. Editing these requires editing the shared Cluster object.
    2. Database.spec.users[] (Database): Used for accounts tied to a single schema; grants default to that schema.
    3. DatabaseUser (Custom Resource): Used for application-team accounts that span several schemas (or none), managed independently of the Cluster object.

  4. Overview of CloudNative MySQL

    CloudNative MySQL is a Kubernetes operator for Percona Server for MySQL. It allows developers to manage MySQL clusters declaratively using Kubernetes custom resources. The operator automates the provisioning of Pods, PVCs, credentials, TLS, and role-routed Services, while handling replication, failover, backups, and point-in-time recovery (PITR).

  5. Overview of CNMSQL for Percona Server for MySQL

    CNMSQL is a Kubernetes operator designed for Percona Server for MySQL. It allows developers to manage MySQL clusters declaratively using Kubernetes custom resources. The operator automates the provisioning of Pods, PVCs, credentials, TLS, and role-routed Services, while handling replication, failover, backups, and point-in-time recovery (PITR).

  6. Overview of CloudNative MySQL

    CloudNative MySQL is a Kubernetes operator for Percona Server for MySQL. It allows developers to manage MySQL clusters declaratively using Kubernetes custom resources. The operator automates the provisioning of Pods, PVCs, credentials, TLS, and role-routed Services, while handling replication, failover, backups, and point-in-time recovery (PITR).

  7. Overview of cnmsql instance images

    cnmsql uses custom rootless instance images (running as UID 1001) that contain Percona Server, Percona XtraBackup, and essential runtime tools. Unlike standard database images, the cnmsql instance manager binary is not baked into the image; instead, the operator copies it into each Pod at startup. The images are designed to be minimal, stripping documentation and non-runtime payloads.

  8. Overview of CNMSQL Kubernetes Operator

    CNMSQL is a Kubernetes operator for Percona Server for MySQL (and MariaDB) that allows developers to manage database clusters declaratively. By defining a Cluster resource, the operator automatically provisions Pods, PVCs, credentials, TLS, and role-routed Services. It handles critical database operations including replication, failover, backups, and point-in-time recovery (PITR).

  9. Overview of Point-In-Time Recovery (PITR) in cnmsql

    cnmsql implements PITR by combining a physical base backup (created via XtraBackup) with continuously archived MySQL binary logs. To recover, cnmsql restores the base backup and replays archived logs up to a specified recovery target. The system is GTID-first, meaning recovery correctness is measured by whether the archived GTID set covers the target. For MariaDB clusters, targetGTID uses the domain-server-seq format (e.g., 0-1-16) and is supported for a single replication domain.

  10. Overview of ScheduledBackup

    ScheduledBackup is a scheduling layer for physical backups. It does not move data itself; instead, it creates Backup objects on a cron cadence. The existing Backup controller then handles the XtraBackup-to-object-store data path. For one-off on-demand backups, use the CLI instead of a YAML manifest.
    kubectl cnmysql backup <cluster>

  11. Overview of CNMSQL for Kubernetes

    CNMSQL is a Kubernetes operator for Percona Server for MySQL (and MariaDB) that allows developers to manage database clusters declaratively. By defining a Cluster resource, the operator automates the provisioning of Pods, PVCs, credentials, TLS, and role-routed Services. It handles complex database operations including replication, failover, physical backups via XtraBackup to S3, and point-in-time recovery (PITR).

  12. Overview of Logical Backups in cnmsql

    Logical backups in cnmsql are SQL dumps of application schemas stored in an object store. They are primarily used for partial restores (single database), moving data across different server versions (e.g., 8.0 to 9.x), or exporting schemas for development.

    Unlike physical backups (xtrabackup), logical backups:

    • Are slower to take and restore on large datasets.
    • Do not support point-in-time recovery (PITR).
    • Do not include users or grants (these must be declared as Custom Resources).
    • Are not used as a base for binlog replay.
    • Use --single-transaction to ensure a consistent snapshot for InnoDB tables.