Architecture

MariaDB on STACKIT offers a fully managed, self-service deployment of MariaDB with flexible sizing, high availability, automated backups, and instance cloning. Here’s how it’s implemented:

An instance is defined by its type, number of vCPUs, RAM, underlying storage and networking. You can learn more about them in Create and manage instances for MariaDB.

Instance level

On the instance level, you define on how many nodes your instance runs. The type property defines whether an instance is a single instance or a replica set. A replica set consists of 3 nodes for production resilience and is implemented as a Galera Cluster. So, all three nodes are a full mirror of each other and act as Active-Active. Go to Cluster setup to learn the details of STACKIT’s implementation of high availability. STACKIT calls scaling on this level horizontal scaling.

You cannot change the type after creating your instance.

Node level

On the node level, you control how every node in the instance and its storage is sized. A node is characterized by its number of vCPUs, its RAM and the storage connected to it. STACKIT calls scaling on this level vertical scaling.

On STACKIT’s MariaDB the number of vCPUs, the size of RAM and disk is determined by a plan. Go to Service plans to see all available plans.

Your instance will have a downtime after changing any parameter except ACL and disk threshold.

Network

Each instance has its own hostname and IPv4 address. By default, it only can be reached from predefined STACKIT address ranges. With the ACL parameter, you can add custom IPv4 single addresses and ranges from which the instance can be reached.

Backup

You manage your backups at the instance level. The system creates a backup every 4 hours. Independently, you can also schedule manual backups at any time. All backups are stored for 14 days.

Monitoring and Observability

Each MariaDB instance has its own Prometheus proxy, which you can access over a metrics-endpoint. If you use STACKIT’s Observability solution, you can scrape MariaDB’s telemetry (metrics, logs and traces) and thus import it into your Observability instance.

Management

You manage instances with the STACKIT Portal, the STACKIT CLI, the STACKIT APIs, Terraform or Cloud Foundry:

• Provisioning new instances
• Modifying instances
• Monitoring performance metrics and logs
• Restoring backups

Deployment separation

MariaDB services created through Cloud Foundry and those created via STACKIT Portal/CLI are completely separated. Services created in one environment must be managed and deleted in the same environment - cross-environment management is not supported for technical reasons.

Services must always be managed in the environment they were created in.

• Services created in the STACKIT Portal/CLI must also be managed/deleted in the STACKIT Portal/CLI. In the STACKIT Portal, some (not all) services may be displayed that were created using Cloud Foundry (esp. the Flex databases).
• Services created using Cloud Foundry must be managed/deleted using Cloud Foundry.

Services displayed in Cloud Foundry as part of an organization prefixed by stackit_portal_prod_ have been created using the STACKIT Portal/CLI and must be managed from there, even if management options are displayed in Cloud Foundry. For technical reasons it is not possible to create a service in Cloud Foundry and delete it using the STACKIT Portal/CLI, or vice versa.