1. Home
  2. Docs
  3. Knowledgebase and Tutorials
  4. ClusterControl
  5. Terraform provider for ClusterControl
  6. ClusterControl Provider Examples

ClusterControl Provider Examples

ClusterControl Provider Examples

The GitHub repository contains concrete examples of deploying database clusters of various types (MySQL/MariaDB replication or galera with ProxySQL, PostgreSQL replication, MongoDB replica set and/or sharded, Redis sentinel, Microsoft SQL server, and Elasticsearch)

Navigate to the repository docs folder for generated documentation on the terraform provider plugin for ClusterControl.

The sub-folders contain examples of the following:

Database type Description
MySQL / MariaDB MySQL and/or MariaDB database (both Master/Slave and Galera multi-master
ProxySQL ProxySQL load balancer with MySQL/MariaDB database clusters
PostgreSQL Postgres (Primary with Hot-Standby clusters
MongoDB Both sharded clusters and single Replicaset clusters
Redis Redis sentinel clusters
Microsoft SQL Server Both standalone and hot-standby cluster with one hot-standby (async)
Elasticsearch Elasticsearch clusters

Provider Configuration

Use the following to configure the Terraform provider for ClusterControl:
terraform {
  required_providers {
    clustercontrol = {
      source = "severalnines/clustercontrol"
      version = "0.2.15"
    }
  }
}

provider "clustercontrol" {
  # Configuration options:
  # cc_api_url = ""
  # cc_api_user = "" 
  # cc_api_user_password = ""
}

Common fields in the resource definition

db_host

The db_host block inside the clsutercontrol_db_cluster resource specifies the hosts that make up the cluster. Each host that makes up the DB cluster should have one of these blocks. The mandatory attribute for each db_host block is the hostname.

Example:

resource "clustercontrol_db_cluster" "this" {
    ...
    db_host {
        hostname = "host-1"
    }
    db_host {
        hostname = "host-2"
    }
    ...

}

Scheduling Backups using the – clustercontrol_db_cluster_backup_schedule resource

The backup schedule resource allows you to create a backup schedule for a cluster in ClusterControl through the terraform provider. Here’s an example of a daily full backup schedule using xtrabackup. As can be seen the clustercontrol_db_cluster_backup_scheduleresource depends on the clustercontrol_db_cluster resource.

 resource "clustercontrol_db_cluster_backup_schedule" "full-1" {
   depends_on                   = [clustercontrol_db_cluster.this]
   db_backup_sched_title        = "Daily full"
   db_backup_sched_time         = "TZ=UTC 0 0 * * *"
   db_cluster_id                = clustercontrol_db_cluster.this.id
   db_backup_method             = "xtrabackupfull"
   db_backup_dir                = var.db_backup_dir
   db_backup_subdir             = var.db_backup_subdir
   db_backup_encrypt            = var.db_backup_encrypt
   db_backup_host               = var.db_backup_host
   db_backup_storage_controller = var.db_backup_storage_controller
   db_backup_compression        = var.db_backup_compression
   db_backup_compression_level  = var.db_backup_compression_level
   db_backup_retention          = var.db_backup_retention
 }

Taking adhoc backups using the – clustercontrol_db_cluster_backup resource

You can a maintenance window for a cluster using the clustercontrol_db_cluster_backup resource. Here’s an example of a full backup using xtrabackup.

 resource "clustercontrol_db_cluster_backup" "full-1" {
   depends_on                   = [clustercontrol_db_cluster.this]
   db_cluster_id                = clustercontrol_db_cluster.this.id
   db_backup_method             = "xtrabackupfull"
   db_backup_dir                = var.db_backup_dir
   db_backup_subdir             = var.db_backup_subdir
   db_backup_encrypt            = var.db_backup_encrypt
   db_backup_host               = var.db_backup_host
   db_backup_storage_controller = var.db_backup_storage_controller
   db_backup_compression        = var.db_backup_compression
   db_backup_compression_level  = var.db_backup_compression_level
   db_backup_retention          = var.db_backup_retention
 }

Setting a maintenance window using the – clustercontrol_db_cluster_maintenance resource

You can take adhoc backups (full or incremental) of a cluster using the clustercontrol_db_cluster_backup resource. Here’s an example of a full backup using xtrabackup.

 resource "clustercontrol_db_cluster_maintenance" "server-upgrade-03312024" {
   depends_on = [clustercontrol_db_cluster.this]
   db_cluster_id       = clustercontrol_db_cluster.this.id
   db_maint_start_time = "Mar-31-2024T00:00"
   db_maint_stop_time  = "Mar-31-2024T23:30"
   db_maint_reason     = "Hardware refresh March 31, 2024"
 }
Note

The db_maint_start_time and db_maint_stop_time should be specified in local time (without the timezone).

Supported backup methods for the respective database types (and vendors)

The following types are supported:

Database type Vendor Backup method
MySQL Oracle, Percona xtrabackupfull, xtrabackupincr, mysqldump
MariaDB MariaDB mariabackupfull, mariabackupincr, mysqldump
PostgreSQL Community pg_basebackup, pgdumpall, pgbackrest(full,incr,diff)
MongoDB MongoDB mongodump, percona-backup-mongodb
Redis Redis Use the value "" to indicate (aof – default redis)
SQL Server Microsoft mssql_full
Elasticsearch Elastic TBD – default snapshot

Toggling cluster auto-recovery option

You can toggle the cluster-auto-recovery feature in ClusterControl using the db_auto_recovery field of the clustercontrol_db_clusterresource.

resource "clustercontrol_db_cluster" "this" {
...
  db_auto_recovery         = true
...
}
Was this article helpful to you? Yes No