Skip to main content
Version: 4.8

MariaDB DB Stack

The MariaDB db stack is used to build and deploy MariaDB database in dataspaces and produce deployment-ready containers for the SCALE environment.

MariaDB is one of the most popular database servers in the world. It's made by the original developers of MySQL and guaranteed to stay open source. Notable users include Wikipedia, Facebook and Google.

MariaDB is developed as open source software and as a relational database it provides an SQL interface for accessing data. The latest versions of MariaDB also include GIS and JSON features.

The containers produced in this db stack share common requirements with other application and db stacks deployed to the SCALE environment. These shared requirements include:

  • Security scanning for any vulnerabilities
  • Staging of the db container in the appropriate Docker container repositories and tagged according to SCALE conventions
  • Completion of Unit Testing and User Acceptance Testing
  • Gated approvals before allowing deployments into pre-production and production environments
  • Audit trail and history of deployment within the SCALE CI/CD Pipeline

Because of the above-listed requirements, the MariaDB db stack is provided in order to support the build and deployment of MariaDB database in a manner that integrates with SCALE requirements and processes. The flow of deployment includes first a Continuous Integration stage of processing in a pipeline prior to deployment in the Continuous Deployment stages. The Continuous Integration stage focuses on building the application, running scans to security vulnerabilities, and staging the container in the appropriate Docker repository ready for deployment. Subsequent pipeline stages deploy the application to the appropriate target Kubernetes spaces.

For details on getting started, repository structure, CI/CD pipelines, and pipeline definition, see the Common Database Documentation.

Configuration and Customization of the MariaDB Pipeline

Global Variables

For details on global variables, see Global Variables.

Database-Specific Pipeline Configuration

The extends YAML object is a complex object consisting of additional YAML objects. This object is used to extend the v4.3 pipeline logic (referenced by the repository defined in the resources object) by (a) referencing the correct dbstack pipeline entry point (dbaas/devexp-mariadb.yml@spaces for the MariaDB pipeline) and (b) passing a set of YAML objects as parameters to influence the behavior of the pipeline to meet an application teams specific needs.

The extends YAML object consists of 2 objects beneath it:

  • template
  • parameters

The template YAML object is a single value set to the initial entry point for the V4 pipeline for the MariaDB dbstack, so it should always be defined as follows:

variables:
- { group: mariadb-<dataspace repo name>.props }
resources:
repositories:
- { repository: templates, type: git, name: devexp-engg/automation, ref: release/v4.7 }
- { repository: spaces, type: git, name: spaces, ref: dbaas/v1.5 }
extends:
template: dbaas/mariadb-<dataspace repo name>.yml@spaces

The parameters YAML object is defined immediately following the template object and at the same indentation level. This is the object that requires the most attention and definition to be set up.

Pipeline Modes

For details on pipeline modes, see Pipeline Modes.

MariaDB pipelines also support the restoreFromSgrid parameter:

  - { name: restoreFromSgrid, displayName: 'Restore from NPC Sgrid ?', type: 'string',values: ['yes','no'], default: 'no' }

Starting with Pipeline v4.7, backups will be stored in AWS S3. We have also provided the option to restore from NPC Sgrid in case you need to restore from old backups. Please refer to SCALE DBaaS: Backup and Restore From AWS S3.

Backup Schedule

For details on backup scheduling, see Backup Schedule.

Additional Configurations

Support for Kong

Support for Kong has been introduced since V4.7. Kong needs to be enabled in values.yaml and any override values files:

kong:
tls:
secret:
dbaas:
enabled: true
domain:

PLEASE NOTE: Ambassador and Kong both can not be enabled at once. You can select either but ONLY one at a time.

New file under helm template tcpingress.yaml is added to support Kong.

CPU Request Tuning

For details on CPU request tuning, see CPU Request Tuning.

MariaDB example:

extends:
parameters:
appVersion: <version>
mariadb:
podSpec:
cpuRequests: 200m

Database Configuration and Deployment

Database will be automatically configured with random password during provision. To modify the details of MariaDB passwords, you need to update <repo-name>.props variable group in pipeline library.

chartname

chartname

chartname

For general deployment configuration details, see Database Configuration and Deployment.

Helm Override Files

For details on helm override files, see Helm Override Files.

MariaDB example:

workspace:
helm:
overrideFiles: |
dbaas-mariadb1/values.workspace.yaml
dataspace:
helm:
overrideValues: |

How to enable database backup?

Backups using DBaaS self-service option is discontinued for version 4.3, please refer to backup and restore document.

Changing Database User Password

For details on changing database user password, see Changing Database User Password.

Click the below image to watch the video

change_password_logo

Exposing Databases Outside the Cluster

See our documention on SCALE Stunnel Client

Sysdig Monitoring

For details on Sysdig monitoring, see Sysdig Monitoring.

MariaDB probe update

If you manually upgraded older version mariadb pipeline to v4.7, please make sure to update the mariadb probe settings.

To update the probe edit the file standalone-deployment.yaml under templates folder and replace the following probe structure

        livenessProbe:
exec:
command:
- /bin/sh
- -c
- -i
- "MYSQL_PWD=$MYSQL_PASSWORD mysql -h $POD_IP -u $MYSQL_USER -D $MYSQL_DATABASE -e 'SELECT 1'"
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
successThreshold: {{ .Values.livenessProbe.successThreshold }}
failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
readinessProbe:
exec:
command:
- /bin/sh
- -c
- -i
- "MYSQL_PWD=$MYSQL_PASSWORD mysql -h $POD_IP -u $MYSQL_USER -D $MYSQL_DATABASE -e 'SELECT 1'"
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
successThreshold: {{ .Values.readinessProbe.successThreshold }}
failureThreshold: {{ .Values.readinessProbe.failureThreshold }}

replace with this new structure.

        livenessProbe:
exec:
command:
- /bin/sh
- -c
- MYSQL_PWD=$MYSQL_PASSWORD mysql -h $POD_IP -u $MYSQL_USER -D $MYSQL_DATABASE -e "SELECT 1"
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
successThreshold: {{ .Values.livenessProbe.successThreshold }}
failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
readinessProbe:
exec:
command:
- /bin/sh
- -c
- MYSQL_PWD=$MYSQL_PASSWORD mysql -h $POD_IP -u $MYSQL_USER -D $MYSQL_DATABASE -e "SELECT 1"
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
successThreshold: {{ .Values.readinessProbe.successThreshold }}
failureThreshold: {{ .Values.readinessProbe.failureThreshold }}

DR Changes

For details on DR changes, see DR Changes.

Detailed Pipeline Configuration

For details on pipeline configuration, see Detailed Pipeline Configuration.

Kubernetes Deployment Objects

For details on Kubernetes deployment objects, see Kubernetes Deployment Objects.

Troubleshooting

For troubleshooting information, see Troubleshooting.