Skip to main content

FAQ — MySQL

Why does Hikube use MariaDB for the MySQL service?​

The MySQL service on Hikube is based on MariaDB, deployed via the MariaDB Operator. MariaDB is an open-source fork of MySQL, fully compatible with the MySQL protocol and syntax. This choice guarantees:

  • Full compatibility with existing MySQL clients and applications
  • An active and transparent open-source development
  • Advanced features (column compression, Aria engine, etc.)

Your MySQL applications work without modification with the Hikube MySQL service.

What is the difference between resourcesPreset and resources?​

The resourcesPreset field lets you choose a predetermined resource profile for each MySQL replica. If the resources field (explicit CPU/memory) is defined, resourcesPreset is completely ignored.

PresetCPUMemory
nano250m128Mi
micro500m256Mi
small1512Mi
medium11Gi
large22Gi
xlarge44Gi
2xlarge88Gi
mysql.yaml
spec:
  # Using a preset
  resourcesPreset: small

  # OR explicit configuration (the preset is then ignored)
  resources:
    cpu: 2000m
    memory: 2Gi

How does MySQL replication work on Hikube?​

MySQL replication on Hikube uses binlog replication (binary log) managed by the MariaDB Operator:

  • One node is designated as the primary (read-write)
  • Other nodes are replicas (read-only)
  • Automatic failover (auto-failover) is managed by the operator in case of primary failure

With 3 replicas, you get 1 primary + 2 replicas, which ensures high availability.

How to configure backups with Restic?​

MySQL backups use Restic for encryption and compression. Configure the backup section with S3-compatible storage:

mysql.yaml
spec:
  backup:
    enabled: true
    s3Region: eu-central-1
    s3Bucket: s3.example.com/mysql-backups
    schedule: "0 3 * * *"
    cleanupStrategy: "--keep-last=7 --keep-daily=7 --keep-weekly=4"
    s3AccessKey: your-access-key
    s3SecretKey: your-secret-key
    resticPassword: your-restic-password
warning

Keep the resticPassword in a safe place. Without this password, backups cannot be decrypted.

How to perform a primary switchover?​

To switch the primary role to another replica, modify the spec.replication.primary.podIndex field in your manifest:

mysql.yaml
spec:
  replication:
    primary:
      podIndex: 1    # Index of the pod that will become the new primary

Then apply the change:

kubectl apply -f mysql.yaml
note

The switchover causes a brief interruption of writes during the failover. Reads remain available on replicas.

How to manage users and databases?​

Use the users and databases maps to define your users and databases. Each user can have a connection limit, and each database can have admin and readonly roles:

mysql.yaml
spec:
  users:
    appuser:
      password: SecurePassword123
      maxUserConnections: 100
    analyst:
      password: AnalystPassword456
      maxUserConnections: 20

  databases:
    production:
      roles:
        admin:
          - appuser
        readonly:
          - analyst
    analytics:
      roles:
        admin:
          - appuser
        readonly:
          - analyst