Databases#

General information#

K2 Cloud databases are automated services which help you to quickly and easily create, configure, and manage popular DBMSs, using cloud platform tools. We currently support MongoDB, MySQL, PostgreSQL, and Redis.

MySQL is the most popular open-source relational DBMS. To learn more about MySQL DBMS capabilities, read the documentation.

PostgreSQL is a Postgres-based object-relational DBMS. It supports most of the SQL standard and offers many advanced features. To learn more about its capabilities, read the PostgreSQL documentation.

Redis is an open-source resident DBMS. It handles key-value data structures and can be used as a database, cache, message broker, or queue. To learn more about Redis capabilities, visit the official website.

MongoDB is a universal NoSQL database that stores data of any structure and supports indexing, sharding, and replication. To learn more about MongoDB features, see the MongoDB official website.

ClickHouse is an open-source column-oriented database management system designed for online analytical processing (OLAP). It ensures high-speed execution of complex queries on huge datasets. You can learn more about the DBMS capabilities in the ClickHouse documentation.

Billing#

The ClickHouse, MongoDB, MySQL, PostgreSQL, and Redis PaaS database services are free of charge. You pay for actually consumed billable resources: instances, volumes, Elastic IP addresses, and other resources.

Databases in K2 Cloud#

Using K2 Cloud automated databases is a powerful alternative to installing and configuring databases manually. The database service can be deployed on a single instance or multiple instances (3- or 6-node cluster).

The cluster service option ensures high availability for critical workloads by placing nodes in multiple availability zones. If any of these nodes fails, the cluster will continue to run on the remaining nodes. This prevents data loss, and there is no interruption in service, or it is reduced to a minimum delay required for failover.

In the Databases service web interface, you can perform the following actions:

Creating database service
Managing database resources
Database backup and recovery
Deleting database service

What is the Database service good for?

For quick creation of a ready-to-work database.
For simplifying database provisioning and maintenance.
For accelerating time-to-market.

Cluster with an arbitrator#

In K2 Cloud, you can launch a high-availability service in a multi-node cluster (3 or more nodes depending on the service). This solves the split-brain problem.

If you use a database cluster and connectivity between nodes is lost, the cluster gets partitioned. Each part of the cluster decides whether to continue processing data or stop. If each part of the cluster considers itself the only survivor and continues running and changing data, then there is the split-brain problem that can cause data corruption. To avoid this, clusters use a quorum rule stating that only one part of the cluster (the one with a larger number of nodes) continues operating. This is only possible if the total number of nodes in the cluster is odd.

However, running three full-fledged nodes is redundant in terms of the resources involved. Therefore, a configuration with two full-featured nodes and a cluster arbitrator is more cost-effective, because the arbitrator neither stores nor processes data and is launched with the minimum set of resources required to maintain cluster quorum.

Before you begin#

We advise to preliminarily read the recommendations on how to work with the service in the cloud.

Required privileges#

To be able to work with the database service, a user needs to have PaaSFullAccess project grants. For instance, such grants are available to administrators in the CloudAdministrators group. If necessary, you can create a separate user, add the user to the project, and either attach the PaaSFullAccess policy to the user or add the user to the group of cloud administrators in this project.

Note

If database backup is required, then the PaaSBackupPolicy policy should be attached to the user (see to learn more about IAM policies).

The PaaSFullAccess project grants provide the user with permissions to all PaaS services. To provide permissions to the database service only, create a policy with the following grants:

paas:CreateDatabase;
paas:CreateUser;
paas:ListUsers;
paas:ListDatabases;
paas:ModifyUser;
paas:ModifyDatabase;
paas:DescribeService;
paas:ListServices;
paas:ListBackupUsers;

and assign it to the user.

To allow a user only to work with database backups, but not delete them, create a policy with the following grants:

paas:DescribeBackup;
paas:ListBackupUsers;
paas:ListBackups;
paas:ModifyBackup;
paas:DescribeService;
paas:ListServices;
paas:ModifyService;

and assign it to the user.

For details, see the IAM documentation on how to create a policy and attach it to the user.

Required resources#

There should be the following resources in the project:

Creating database service#

The database service creation process can be divided into two parts:

infrastructure creation;
software installation and configuration.

Currently, the infrastructure creation consists of launching the required number of instances with the specified configuration from a given image and setting up security groups so that the databases can connect to each other.

After the successful launch of the instances, software installation inside VMs begins. Upon the successful installation, the database service enters the running status. Any other status means that the creation process is not completed. The database service in the running status is ready for operation.

Important

The database service can be launched only in subnets that have Internet access. For this purpose, the VPC must have an internet gateway and a NAT gateway attached, and a default route must be created in the route table. When creating the service, only VPCs with an attached internet gateway and NAT gateway are available for selection.

Note

Creating a high-availability service also automatically creates placement groups for every three nodes. For example, in case of a five-node cluster in one availability zone, two placement groups are created, containing three and two nodes, respectively. Should it be a five-node cluster across three availability zones, one placement group is created in each zone, with two groups containing two nodes each, and one group containing only one node. Instances from the same group are deployed on different physical servers, which improves the service availability.

To configure the service, select the DBMS in the Service store or Running services subsection, click Create and follow the steps below:

Set the required network parameters:

Note

To run the service in the selected VPC, you must first create a subnet in the preferred availability zone (in a configuration with one zone), or one subnet in each availability zone (in a configuration with three zones). In addition, the same volume types must be supported in the availability zones used.

Note

The ability to attach network interfaces may be useful, for example, when you need to recreate a database service. If you delete the service, do not delete attached network interfaces, you will be able to reuse them for connecting nodes of the new cluster to subnets, where the new cluster will be deployed. Thus, you can keep previous network settings, such as private IP addresses and security groups, rather than configure them again.
MySQL
- To configure a cluster, where the service will be deployed, you can select the following number of nodes:
  - one master node (the service without high availability);
  - two master nodes and one arbitrator node;
  - three master nodes.
- VPC where the database service will be deployed.
- Security groups to control traffic through interfaces of the instances on which the database service will run.
- Subnets to which instances with the running service will be attached, or network interfaces through which cluster nodes will be attached to subnets.
  
  Note
  
  When selecting subnets, you may specify either one or three subnets in different availability zones. In the former case, the service will be deployed in the same availability zone as the selected subnet.
  
  When selecting network interfaces for a multi-node configuration, you must specify one interface per availability zone.
- Internal and/or internet-facing load balancers (for details, see Load balancer management).
  
  In the DNS name field, you can specify an arbitrary subdomain name in the <lb-name>-<lb-id>.lb.<region>.k2.cloud DNS service zone for an Internet-facing load balancer and in the <lb-name>-<lb-id>.lb.vpc-xxxxxx.internal zone for an internal load balancer. The name may contain Latin letters, digits, and hyphens.
  
  If the DNS name field is left blank, the name will be specified automatically.
PostgreSQL
Important

It is not recommended to create a four-node cluster as otherwise any connectivity loss may lead to quorum loss due to split brain.
- To configure a cluster, where the service will be deployed, you can select the following number of nodes:
  - one master node (the service without high availability);
  - two master nodes and one arbitrator node;
  - three to six master nodes 1.
  1
  
  We recommend selecting this configuration if the cluster scalability may be required in the future.
- VPC where the database service will be deployed.
- Security groups to control traffic through interfaces of the instances on which the database service will run.
- Subnets to which instances with the running service will be attached, or network interfaces through which cluster nodes will be attached to subnets.
  
  Note
  
  When selecting subnets, you may specify either one or three subnets in different availability zones. In the former case, the service will be deployed in the same availability zone as the selected subnet.
  
  When selecting network interfaces for a multi-node configuration, you must specify as many interfaces as there are nodes in the cluster.
  
  Network interfaces should be evenly distributed across all availability zones where the service will be deployed, if possible. For example, if you plan to create a cluster with five master nodes across three availability zones, you should specify two interfaces in each of two availability zones and one interface in the remaining zone.
- Internal and/or internet-facing load balancers (for details, see Load balancer management).
  
  In the DNS name field, you can specify an arbitrary subdomain name in the <lb-name>-<lb-id>.lb.<region>.k2.cloud DNS service zone for an Internet-facing load balancer and in the <lb-name>-<lb-id>.lb.vpc-xxxxxx.internal zone for an internal load balancer. The name may contain Latin letters, digits, and hyphens.
  
  If the DNS name field is left blank, the name will be specified automatically.
Redis
- To configure a cluster, where the service will be deployed, you can select the following number of nodes:
  - one master node (the service without high availability);
  - three master nodes;
  - six master nodes.
- VPC where the database service will be deployed.
- Security groups to control traffic through interfaces of the instances on which the database service will run.
- Subnets to which instances with the running service will be attached, or network interfaces through which cluster nodes will be attached to subnets.
  
  Note
  
  When selecting subnets, you may specify either one or three subnets in different availability zones. In the former case, the service will be deployed in the same availability zone as the selected subnet.
  
  When selecting network interfaces for a multi-node configuration, you must specify as many interfaces as there are nodes in the cluster.
  
  Network interfaces should be evenly distributed across all availability zones where the service will be deployed.
- Internal and/or internet-facing load balancers (for details, see Load balancer management).
  
  In the DNS name field, you can specify an arbitrary subdomain name in the <lb-name>-<lb-id>.lb.<region>.k2.cloud DNS service zone for an Internet-facing load balancer and in the <lb-name>-<lb-id>.lb.vpc-xxxxxx.internal zone for an internal load balancer. The name may contain Latin letters, digits, and hyphens.
  
  If the DNS name field is left blank, the name will be specified automatically.
MongoDB
Important

It is not recommended to create a four-node cluster as otherwise any connectivity loss may lead to quorum loss due to split brain.
- To configure a cluster, where the service will be deployed, you can select the following number of nodes:
  - one master node (the service without high availability);
  - two master nodes and one arbitrator node;
  - three to six master nodes. 2
  2
  
  We recommend selecting this configuration if the cluster scalability may be required in the future.
- VPC where the database service will be deployed.
- Security groups to control traffic through interfaces of the instances on which the database service will run.
- Subnets to which instances with the running service will be attached, or network interfaces through which cluster nodes will be attached to subnets.
ClickHouse
- To configure a cluster, where the service will be deployed, you can select the following number of nodes:
  - single node (service without high availability);
  - three combined nodes and up to twelve servers;
  - three coordinators and three to twelve servers.
- VPC where the database service will be deployed.
- Security groups to control traffic through interfaces of the instances on which the database service will run.
- Subnets to which instances with the running service will be attached, or network interfaces through which cluster nodes will be attached to subnets.
  
  Note
  
  When selecting subnets, you may specify either one or three subnets in different availability zones. In the former case, the service will be deployed in the same availability zone as the selected subnet.
  
  When selecting network interfaces for a multi-node configuration, you must specify as many interfaces as there are nodes in the cluster.
  
  Network interfaces should be evenly distributed across all availability zones where the service will be deployed, if possible. For example, if you plan to create a cluster with five master nodes across three availability zones, you should specify two interfaces in each of two availability zones and one interface in the remaining zone.
- Internal and/or internet-facing load balancers (for details, see Load balancer management).
  
  In the DNS name field, you can specify an arbitrary subdomain name in the <lb-name>-<lb-id>.lb.<region>.k2.cloud DNS service zone for an Internet-facing load balancer and in the <lb-name>-<lb-id>.lb.vpc-xxxxxx.internal zone for an internal load balancer. The name may contain Latin letters, digits, and hyphens.
  
  If the DNS name field is left blank, the name will be specified automatically.
Click Next to proceed to the next step.
Set the service instance parameters:

MySQL

If the configuration with a cluster arbitrator was selected for the MySQL service, then in the Master node block, configure the instance to be used as the master node. Select the instance type and data volume parameters: type, size, and IOPS (if available for this type).

The configuration of the instance to be used as the arbitrator is set automatically and cannot be changed.

PostgreSQL

If the three to six master nodes cluster configuration was selected in the previous step, you can set the number of master nodes in the cluster. However, if network interfaces were specified, the number of instances is fixed and equal to the number of selected network interfaces.

If the configuration with a cluster arbitrator was selected, then in the Master node block, configure the instance to be used as the master node. Select the instance type and data volume parameters: type, size, and IOPS (if available for this type). The configuration of the instance to be used as the arbitrator is set automatically and cannot be changed.

MongoDB

If the configuration with a cluster arbitrator was selected for the MongoDB service, then in the Master node block, configure the instance to be used as the master node. Select the instance type and data volume parameters: type, size, and IOPS (if available for this type).

The configuration of the instance to be used as the arbitrator is set automatically and cannot be changed.

ClickHouse

If a high-availability configuration was selected for the ClickHouse service in the previous step, you can set the number of instances with the Server role in the cluster. Configure the instances in the Server, Combined node, or Coordinator blocks for nodes with the corresponding roles. For nodes with the Server or Combined node role, you can set the instance type and data volume parameters: type, size, and IOPS (if available for this volume type). In the three combined nodes and up to twelve servers configuration, all nodes will use the same parameters. For nodes with the Coordinator role, you can set only the instance type. In the three coordinators and three to twelve servers configuration, you need to set the parameters of nodes with the Coordinator and Server roles separately.

Note

Database performance depends on the selection of node components. We recommend using high performance volumes gp2: Universal (SSD) or io2: Maximum (SSD).

You can enable automatic expansion of the data volume.

To do this, tick the Enable auto-expansion checkbox and specify:
- maximum volume size — its value cannot exceed the quota for the maximum volume size in the project;
- utilization threshold — the range of possible values is from 70% to 90%.
Click Next to proceed to the next step.
Set the main parameters of the service (the specific set of options depends on the selected service).
MySQL
- Name tag — Optional arbitrary description of the service.
- Service name — An arbitrary unique name of the database service.
- Vendor — MySQL DBMS engine. Valid values: mariadb, percona, mysql.
- Version — The DBMS engine version. Depending on the engine vendor, the following versions are supported:
  
  Vendor
  
  Version
  
  mariadb
  
  10.4
  10.5
  10.6
  10.11
  
  percona
  
  5.7
  8.0
  
  mysql
  
  8.0
- Enable monitoring – For centralized monitoring of a database service, first deploy the Prometheus-based monitoring service.
  - Monitoring service – The selection of a monitoring service is only available when the Enable monitoring checkbox is checked.
  - Monitoring labels — Optionally, you can set monitoring labels, which the installed monitoring agents will assign to the collected metrics (for details, see Using labels). Labels can only be set when the Enable monitoring checkbox is selected.
- Enable logging – For centralized PaaS service logging, first create a logging service. Once a PaaS service is created, you will be able to install logging agents manually only.
  - Logging service – The selection of a logging service is only available when the Enable logging checkbox is checked.
  - Logging tags – Tags are assigned to logs when the latter are imported by the logging service. They simplify search for the required logs. Tags can only be set when the Enable logging checkbox is selected.
PostgreSQL
- Name tag — Optional arbitrary description of the service.
- Service name — An arbitrary unique name of the database service.
- Vendor — PostgreSQL DBMS storage subsystem engine. Valid values: pgsql, pgsql1c.
  
  Note
  
  If you select the pgsql1c vendor, the following PostgreSQL extensions are installed automatically: fasttrun, fulleq, mchar, and plantuner.
- Version — The DBMS engine version. Depending on the engine vendor, the following versions are supported:
  
  Vendor
  
  Version
  
  pgsql
  
  14
  15
  16
  17
  18
  
  pgsql1c
  
  16
  17
- Replication option — The replication mode in the Patroni cluster. Available only when the High-availability service option is selected.
  
  Valid values: asynchronous, synchronous, synchronous_strict.
- Enable monitoring – For centralized monitoring of a database service, first deploy the Prometheus-based monitoring service.
  - Monitoring service – The selection of a monitoring service is only available when the Enable monitoring checkbox is checked.
  - Monitoring labels — Optionally, you can set monitoring labels, which the installed monitoring agents will assign to the collected metrics (for details, see Using labels). Labels can only be set when the Enable monitoring checkbox is selected.
- Enable logging – For centralized PaaS service logging, first create a logging service. Once a PaaS service is created, you will be able to install logging agents manually only.
  - Logging service – The selection of a logging service is only available when the Enable logging checkbox is checked.
  - Logging tags – Tags are assigned to logs when the latter are imported by the logging service. They simplify search for the required logs. Tags can only be set when the Enable logging checkbox is selected.
Redis
- Name tag — Optional arbitrary description of the service.
- Service name — An arbitrary unique name of the database service.
- Version — The supported DBMS versions are 7.0, 7.2, 8.0, 8.2, 8.4.
- Clustering option. Valid values: native, sentinel. Available only when a three node cluster configuration is selected. For a six node cluster configuration, only the native option is supported.
- RDB Persistence — The RDB storage mode.
- AOF Persistence — The AOF storage mode.
- Enable monitoring – For centralized monitoring of a database service, first deploy the Prometheus-based monitoring service.
  - Monitoring service – The selection of a monitoring service is only available when the Enable monitoring checkbox is checked.
  - Monitoring labels — Optionally, you can set monitoring labels, which the installed monitoring agents will assign to the collected metrics (for details, see Using labels). Labels can only be set when the Enable monitoring checkbox is selected.
- Enable logging – For centralized PaaS service logging, first create a logging service. Once a PaaS service is created, you will be able to install logging agents manually only.
  - Logging service – The selection of a logging service is only available when the Enable logging checkbox is checked.
  - Logging tags – Tags are assigned to logs when the latter are imported by the logging service. They simplify search for the required logs. Tags can only be set when the Enable logging checkbox is selected.
- Password — User password 8 - 128 characters long. It can be set manually or generated automatically.
MongoDB
- Name tag — Optional arbitrary description of the service.
- Service name — An arbitrary unique name of the database service.
- Version — The up-to-date list of supported versions is available in the web interface.
- Enable monitoring – For centralized monitoring of a database service, first deploy the Prometheus-based monitoring service.
  - Monitoring service – The selection of a monitoring service is only available when the Enable monitoring checkbox is checked.
  - Monitoring labels — Optionally, you can set monitoring labels, which the installed monitoring agents will assign to the collected metrics (for details, see Using labels). Labels can only be set when the Enable monitoring checkbox is selected.
- Enable logging – For centralized PaaS service logging, first create a logging service. Once a PaaS service is created, you will be able to install logging agents manually only.
  - Logging service – The selection of a logging service is only available when the Enable logging checkbox is checked.
  - Logging tags – Tags are assigned to logs when the latter are imported by the logging service. They simplify search for the required logs. Tags can only be set when the Enable logging checkbox is selected.
ClickHouse
- Service name — An arbitrary unique name of the database service.
- ClickHouse version — The up-to-date list of supported versions is available in the web interface. The following LTS versions are supported: 24.8, 25.3.
- Enable logging – For centralized PaaS service logging, first create a logging service. Once a PaaS service is created, you will be able to install logging agents manually only.
  - Logging service – The selection of a logging service is only available when the Enable logging checkbox is checked.
  - Logging tags – Tags are assigned to logs when the latter are imported by the logging service. They simplify search for the required logs. Tags can only be set when the Enable logging checkbox is selected.
- Enable monitoring – For centralized monitoring of a database service, first deploy the Prometheus-based monitoring service.
  - Monitoring service – The selection of a monitoring service is only available when the Enable monitoring checkbox is checked.
  - Monitoring labels — Optionally, you can set monitoring labels, which the installed monitoring agents will assign to the collected metrics (for details, see Using labels). Labels can only be set when the Enable monitoring checkbox is selected.
Click Next to proceed to the next step.
Configure backup.

Note

This step is currently available for MongoDB, MySQL and PostgreSQL.

When you select Enable backup, the following settings are available:
MySQL
- Bucket — The bucket where backups will be stored.
- User — A user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket.
- Start time — The time when the daily backup starts.
- Retention period — How long a backup is kept.
- Email — (Optional) The email address to which notifications are sent if a backup fails. If no email address is set, notifications are sent to the address of the user you specified when configuring backup.
PostgreSQL
- Name — The backup plan name.
- Type — The backup plan type, Incremental or Full (see how the plans differ).
- Databases — (Full plan only) By default, all new databases are backed up. You can change this setting after the service is created.
- Frequency — Backup can run daily or weekly. If you select the Incremental plan and daily backup, full backups are created once a week on Sunday, and incremental backups once a day. Otherwise, full backups are created at the selected frequency.
- Day — (Weekly backup only) The day of the week when the full backup runs.
- Start time — The time when the daily and/or weekly backup starts.
- Retention period — (Full plan only) How long a backup is kept.
- Storage — Where backups are stored. If there is no storage, or you want to create a new one, click Create storage and set the following parameters:
  - the storage name;
  - the bucket where backups will be stored;
  - a user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket;
  - the encryption option, if the backups must be encrypted.
- Email — (Optional) The email address to which notifications are sent if a backup fails.
MongoDB
- Bucket — The bucket where backups will be stored.
- User — A user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket.
- Start time — The time when the daily backup starts.
- Retention period — How long a backup is kept.
- Email — (Optional) The email address to which notifications are sent if a backup fails. If no email address is set, notifications are sent to the address of the user you specified when configuring backup.
Click Next to proceed to the next step.
Set the maintenance window (see Configuring the maintenance window). If scheduled maintenance can be performed at any time, leave the Maintenance window option set to Custom. If there are time restrictions when maintenance can be performed, select the interval that is convenient for you. To do so, specify the following parameters:
- the Scheduled value for the Maintenance window option;
- a day of the week for the maintenance to take place;
- hour interval for the maintenance window.
To set additional parameters or tags for the service, click the respective button to move to the required step — Additional parameters or Add tags. If neither need to be set, click Create to launch the service.
Specify additional parameters, that will become part of the DBMS configuration (optional). The supported parameters depend on the type of database service you launch. You can read more about supported parameters in the recommendations for a particular database.

You can also specify advanced settings of your choice at this step. To do this, click advanced settings and specify the desired settings and their values.

Important

The specified parameters and settings will be part of the DBMS configuration and, therefore, will affect its operation. Add only the parameters you really need.

To set tags for the service, click Add tags to go to the next step. If no tags are required, click Create to launch the service.
To add a tag, click Add tag and enter tag key and value.

Note

If no tags have been set yet, you can add the Name tag by clicking Add Name tag and specifying its value.

When done, click Create to launch the service.

Vendor	Version
mariadb	10.4 10.5 10.6 10.11
percona	5.7 8.0
mysql	8.0

Vendor	Version
pgsql	14 15 16 17 18
pgsql1c	16 17

Important

The database service creation process usually takes 5 to 15 minutes. Single-node installations are deployed faster than multi-node ones.

To ensure the correct operation of a database service, a new security group is automatically created together with the cluster. It includes the following rules:

the rule to permit inbound traffic from interfaces that are in the same security group;
the rule to enable all outbound IPv4 traffic.

If the database service is deleted, the security group will also be deleted.

Modifying service node options#

Make the service highly available#

If you selected the one master node cluster configuration when creating a MongoDB or PostgreSQL service, you can convert that service into a high-availability one. Conversion is possible only when the service is in the Running state.

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Instances tab and click Make highly available.
Specify the parameters of the high-availability service:
- Cluster configuration — Select a high-availability cluster configuration. The available configurations depend on the service type.
- Subnets or Network interfaces — Specify the subnets to which the instances running the service will be attached, or the network interfaces through which the cluster nodes will connect to the subnets.
  
  Note
  
  Which resources you specify (subnets or network interfaces) depends on the original service configuration. When converting the service, you can place the nodes in the same zone or in different availability zones by selecting subnets or network interfaces located in that zone or in other zones, respectively.
- Replication mode — (PostgreSQL services only) Specify the replication mode in the Patroni cluster. Possible values: asynchronous, synchronous, and synchronous_strict.
Click Convert.

When a service is converted to high availability, two nodes are added regardless of the selected configuration. If the selected configuration supports scaling, you can add more nodes after the conversion.

Note

If any additional parameters were specified when the PostgreSQL service was created, those parameters and their values are carried over to the high-availability cluster.

Add nodes for the service#

If the three to six master nodes cluster configuration was selected when creating a PostgreSQL or MongoDB service and the cluster has fewer than six nodes, you can scale it by adding nodes. Scaling is possible only when the service is in the Running state.

Important

For the databases service created before 30.01.2026, cluster scaling is not supported.

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
On the Instances tab, click Add instances.
In the window that opens, specify the number of instances to be added. If network interfaces were specified at the service creation, you can either create interfaces automatically by pushing Create automatically or specifying the existing ones by pushing Select manually and selecting the interfaces in the specified availability zones.
Click Add to complete the operation.

Delete service nodes#

If the three to six master nodes cluster configuration was selected when creating a PostgreSQL or MongoDB service and the cluster has more than three nodes, you can reduce the number of master nodes when the load decreases. Nodes can be deleted only when the service is in the Running state.

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Instances tab.
In the resource table, select the instances to be deleted that host master nodes and click Delete.

Important

After deletion, the number of nodes must not be less than the minimum allowed number of nodes in the cluster.
Click Delete to complete the operation.

Modify the instance type for the node#

You can modify the instance type for cluster nodes running the databases service. You can do it only when the service is in the Ready state.

Important

Instance type cannot be modified for nodes with the arbitrator role.

To modify the instance type:

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
In the Information tab, edit the Instance type field in the configuration section of master node. To do this, click the edit icon and selecting the instance type.
Click to save changes.

Modify data volume parameters#

You can only change the data volume parameters when the service is in the Ready state.

You can configure the data volume size and its performance in IOPS right from the cloud web interface.

Important

You can change IOPS only for a data volume of the type io2.

To change the volume parameters, follow these steps:

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
In the Information tab, edit the required fields (Data volume size and/or Data volume IOPS) by clicking the edit icon .

Important

The new data volume size must exceed the current one.
Click to save changes.

Configuring automatic volume expansion#

Note

This feature is not available if the service uses nv1 volumes (non-replicated NVMe volumes).

When automatic expansion is enabled, the volume size will increase every time the utilization of the data volume on at least one node equals or exceeds the threshold value within 10 minutes.

During expansion, ~20% is added to the volume (the resulting volume size is rounded up to a multiple of 8 GiB). The volume size increases immediately, without waiting for the nearest maintenance window. The service remains available to users during expansion.

Important

The fee for volume usage is proportional to its size. Expansion is irreversible — the volume size cannot be reduced.

After each automatic volume expansion, a cooldown period is provided — a pause of 30 minutes, during which the next utilization check is not performed.

Once the preset maximum size is reached, automatic expansion is disabled.

To enable, configure, or disable automatic expansion:

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
In the Information tab, click the editing icon next to the Auto-expansion field.
To disable auto-expansion, clear the Enable auto-expansion checkbox. To enable auto-expansion, tick the checkbox and configure the auto-expansion parameters:
- maximum volume size — its value cannot exceed the quota for the maximum volume size in the project;
- utilization threshold — the range of possible values is from 70% to 90%.
Once you have made all the required modifications, click Save.

Database backup and recovery#

Scheduled backups can be enabled for a database service so that full backups of the specified databases are created daily at the specified time. If necessary, you can quickly restore the desired database as of a specific date from the saved backup.

Note

Backup is available for PostgreSQL, MySQL, and MongoDB database services.

To enable backup for MySQL and MongoDB services, configure a schedule for the database service as a whole and enable the corresponding option for each database to be backed up.

To enable backup for a PostgreSQL service, create a backup plan. Whether individual databases can be backed up depends on the selected plan type (see how the plans differ).

Backups are created only for running services and are written to object storage. To keep old unwanted backups from taking up space, limit their retention period or delete them from time to time. Individual backups can be protected from automatic deletion.

Along with the backup, a log is created to store information about the backup utility operation. If the backup has failed, you can use the log to find out why. We recommend checking the log for warnings on successful backups also to make sure that there were no problems during the backup process.

Attention

To avoid backup problems caused by lack of space for temporary files, we recommend that you leave 20 MB of free space in the root partitions on cluster instance volumes.

You can view information about database services that have backups in PaaS Storages and backups.

Important

Before configuring backup, make sure that the project has both a bucket for storing backups and a user with PaaSBackupPolicy privileges. This is a special user, and only this policy should be assigned to him/her.

PiTR#

General information#

Point-in-time Recovery (PITR) lets you restore a PostgreSQL database to any point in time within the backup retention period.

A regular backup restores data only as of the moment the backup was created. PiTR can restore it to the exact second. This matters most as protection against logical errors, such as accidental data deletion or an incorrect record update, when the database copy is intact but the data is logically inconsistent.

PiTR use cases:

Accidental data deletion or an incorrect SQL statement (for example, DELETE or UPDATE without a condition in the WHERE clause).
A software logic failure that corrupted data or changed it incorrectly.
Minimizing data loss during an incident by returning the database to the state immediately before the failure.

Terms#

Backup retention period — the time during which backups and change logs are available. Restoring to a point in time outside this period is not possible.
Restore point (Recovery target time ) — the specific date and time to which the service should restore the database.

How it works#

Restore proceeds in several steps:

You specify the restore point (date and time) to which the data should be returned.
A suitable full backup created before that time is deployed automatically.

How the backup is chosen:
- it is the most recent backup made before the specified time;
- it is intact and can be read.
All committed changes from the backup creation time up to the specified restore point are applied, in order, to the databases deployed from that backup.

As a result, the databases of the PostgreSQL PaaS service are restored to the specified point in time.

Differences between PostgreSQL backup plans#

A PostgreSQL PaaS database service has two backup plan types:

Full.
With this plan type, only full database backups are made. You can set the backup frequency, the date and time when the process starts, the backup retention period, and other parameters.
Incremental.
With this plan type, full database backups are made once a week, and incremental backups are made every day. You can set the backup frequency, the time when the process starts, and other parameters.

Usage specifics#

How long the procedure takes depends on the total size of the databases and on the volume of changes to apply from the latest full backup to the point in time you selected.
The restore finishes when the last transaction committed in the transaction log at the specified time has been applied.
You cannot choose a particular database to restore. For example, if the service contains five databases, restoring to a specific point in time brings all five to the target state.

Comparing restore methods: a backup and PiTR#
Characteristic	Restore from a backup	Point-in-Time Recovery (PiTR)
The point in time to which restore is possible	As of the time the selected backup was created	To a selected point in time within the retention period
How it works	The database is restored from a backup	The database is restored from a backup, then transaction logs are applied up to the specified time
Use cases	You need to return the database to the state captured in a particular backup	You need to return the database to the state immediately before an error or a failure
Example	Restore the state as of 02:00	Restore the state as of 14:37:12

Setup service backup#

Backup can be enabled when you create a database service. If you have not done this and want to enable it, or if you need to change the settings for an already enabled backup, then:

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
In the Information tab, click Backup settings.

Note

For a PostgreSQL service, you can also configure backup on the Backup plans tab.
Set or change backup settings:
MySQL
- Enable backup — Turns backup on or off.
- Bucket — The bucket where backups will be stored.
- User — A user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket.
- Start time — The time when the daily backup starts.
- Retention period — How long a backup is kept.
- Email — (Optional) The email address to which notifications are sent if a backup fails. If no email address is set, notifications are sent to the address of the user you specified when configuring backup.
PostgreSQL
- Name — The backup plan name.
- Type — The backup plan type (Incremental or Full). With an Incremental plan, backups are created for the whole service. With a Full plan, you can select individual databases to back up. See how the plans differ.
- Databases — (Full plan only) The databases to back up. If no database is specified, backups are created for all databases.
- Frequency — Backup can run daily or weekly. If you select the Incremental plan and daily backup, full backups are created once a week and incremental backups once a day. Otherwise, full backups are created at the selected frequency.
- Day — (Weekly backup only) The day of the week when the full backup runs.
- Start time — The time when the daily and/or weekly backup starts.
- Retention period — (Full plan only) How long a backup is kept.
- Storage — Where backups are stored. If there is no storage, or you want to create a new one, click Create storage and set the following parameters:
  - the storage name;
  - the bucket where backups will be stored;
  - a user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket;
  - the encryption option, if the backups must be encrypted.
- Email — (Optional) The email address to which notifications are sent if a backup fails.
MongoDB
- Enable backup — Turns backup on or off.
- Bucket — The bucket where backups will be stored.
- User — A user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket.
- Start time — The time when the daily backup starts.
- Retention period — How long a backup is kept.
- Email — (Optional) The email address to which notifications are sent if a backup fails. If no email address is set, notifications are sent to the address of the user you specified when configuring backup.
To apply the settings, click Create.

Note

To back up specific MySQL and MongoDB databases, enable the corresponding option for each of them.

Enable database backup#

Important

MySQL and MongoDB database backups are created only if backup is enabled for the service. Backup of individual PostgreSQL databases can be configured only for a Full backup plan.

If you want to enable backup for a specific database:

MySQL

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Databases tab and select the database in the resource table.
Click Set up and select the Enable backup checkbox.
Click Save.

PostgreSQL

Note

To add a database to an existing backup plan, use Modify on the Backup plans tab.

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Databases tab and click Configure backup.
In the window that opens, enter the name of the new backup plan, select the databases to be backed up according to this plan, and set the plan parameters:
- Frequency — Backup can run daily or weekly.
- Start time — The time when the daily backup starts.
- Retention period — How long a backup is kept.
- Storage — Where backups are stored. If there is no storage, or you want to create a new one, click Create storage and set the following parameters:
  - the storage name;
  - the bucket where backups will be stored;
  - a user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket;
  - the encryption option, if the backups must be encrypted.
- Email — (Optional) The email address to which notifications are sent if a backup fails.
Click Save.

MongoDB

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Databases tab and select the database in the resource table.
Click Set up and select the Enable backup checkbox.
Click Save.

Configure a backup storage for PostgreSQL#

For a PostgreSQL service, you can configure the storage where backups are kept. To protect the stored backups further, you can enable SSE-C encryption. An encryption key is generated automatically and separately for each service.

Important

You can create up to 10 storages in each project.

Create a storage#

Go to PaaS Storages and backups.
On the Storages tab, click Create.
In the window that opens, set the following parameters:
- the storage name;
- the bucket where backups will be stored;
- a user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket;
- the encryption option, if you need to enable backup encryption.
To finish, click Create.

Modify a storage#

Go to PaaS Storages and backups.
On the Storages tab, select the storage in the resource table and click Modify.
In the window that opens, you can change the following parameters:
- the bucket where backups will be stored;
- a user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket;
- the encryption option, if you need to enable or disable backup encryption.
To apply the changes, click Save.

Delete a storage#

Important

You can delete a storage only if it contains no backups and is not used by any backup plan.

Go to PaaS Storages and backups.
On the Storages tab, select the storage to delete in the resource table and click Delete.
To confirm the deletion, click Delete in the window that opens.

Configure a backup plan for PostgreSQL#

Important

You can create up to 10 backup plans for each service. All plans for a given service must use the same storage.

Create a plan#

Important

You can create only one Incremental plan for each service.

Go to the PaaS section Running services and open the Databases tab.
Find the PostgreSQL service in the resource table and click its ID to open the service page.
On the Backup tab, click Create plan.

Note

You can create a backup plan from an existing one. Select the plan in the resource table and change the parameters you need.
- Name — The backup plan name.
- Type — The backup plan type, Incremental or Full (see how the plans differ).
- Databases — (Full plan only) The databases for which backups will be created according to the plan. If you leave the field empty, all databases are backed up.
- Frequency — Backup can run daily or weekly. If you select the Incremental plan and daily backup, full backups are created once a week and incremental backups once a day. Otherwise, full backups are created at the selected frequency.
- Day — (Weekly backup only) The day of the week when the full backup runs.
- Start time — The time when the daily and/or weekly backup starts.
- Retention period — (Full plan only) How long a backup is kept.
- Storage — Where backups are stored. If there is no storage, or you want to create a new one, click Create storage and set the following parameters:
  - the storage name;
  - the bucket where backups will be stored;
  - a user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket;
  - the encryption option, if the backups must be encrypted.
- Email — (Optional) The email address to which notifications are sent if a backup fails.
To save the plan changes, click Save.

Modify a plan#

Go to the PaaS section Running services and open the Databases tab.
Find the PostgreSQL service in the resource table and click its ID to open the service page.
On the Backup tab, select the plan in the resource table and click Modify.
Change the backup plan settings (the available settings depend on the plan type):
- Databases — (Full plan only) The databases for which backups will be created according to the plan. If you leave the field empty, all databases are backed up.
- Frequency — Backup can run daily or weekly. If you select the Incremental plan and daily backup, full backups are created once a week and incremental backups once a day. Otherwise, full backups are created at the selected frequency.
- Day — (Weekly backup only) The day of the week when the full backup runs.
- Start time — The time when the daily and/or weekly backup starts.
- Retention period — (Full plan only) How long a backup is kept.
- Storage — Where backups are stored. If there is no storage, or you want to create a new one, click Create storage and set the following parameters:
  - the storage name;
  - the bucket where backups will be stored;
  - a user with PaaSBackupPolicy privileges, on whose behalf backups are written to the bucket;
  - the encryption option, if the backups must be encrypted.
- Email — (Optional) The email address to which notifications are sent if a backup fails.
To save the plan changes, click Save.

Delete a plan#

Go to the PaaS section Running services and open the Databases tab.
Find the PostgreSQL service in the resource table and click its ID to open the service page.
On the Backup tab, select the plan you no longer need in the resource table and click Delete.
To confirm the deletion, click Delete.

Recover a database from a backup#

Important

To avoid problems when recovering the database, we recommend that you recover it to a service with the same DBMS version as that used to create the database.

To recover a database:

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Databases tab and click Create from backup.
In the database creation wizard that opens, select the required backup from the list. To make the search easier, you can select the service where the database whose backup you are looking for was created. Click Select to go to the next step.
Select the database you want to restore. Click Select to proceed to the next step.
Specify the database parameters and, if necessary, add users. These steps are the same as steps 4–6 of database creation and are described in more detail in the database creation instructions.

Attention

If parameters other than default ones were specified when creating the database, such as PostgreSQL locale, we recommend that you enter the same parameters for the correct recovery.

Restore a PostgreSQL service to a specified point in time#

Important

Restoring a PostgreSQL service to an arbitrary point in time (Point-in-Time Recovery, PiTR) is supported only for the Incremental plan type. You can restore only the whole service, not individual databases.

Go to the PaaS section Running services and open the Databases tab.
Find the PostgreSQL service in the resource table and click its ID to open the service page.
On the Information tab, select Restore to a point in time. If this button is not shown, open the additional action menu (More).
In the window that opens, you can select any point in time within the available period (the available period is shown under the Restore point field). The nearest available backup is used to restore to the selected point in time.

Attention

The service is stopped while the restore is in progress. All data created after the selected restore point will be lost.

Confirm that you accept the data loss by selecting the corresponding checkbox.
Click Restore.

Disable backup#

To disable backup for a specific database:

MySQL

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Databases tab and select the database in the resource table.
Click Edit.
Uncheck the Enable backup checkbox, while leaving all other parameters unchanged.
Click Save.

PostgreSQL

Note

Backup of individual databases can be turned off only for the Full plan type. If a database is included in several plans, remove it from all of them to turn its backup off completely.

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
On the Backup tab, select the plan that backs up this database and click Modify.
In the Databases field, remove the database from the plan by clicking next to its name.

Important

If the plan has no databases left, backups are created for all databases by default. If you do not want to use this plan for other databases, delete it.
Repeat steps 3-4 if you need to remove the database from other plans.
Click Save without changing the other settings.

MongoDB

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Databases tab and select the database in the resource table.
Click Edit.
Uncheck the Enable backup checkbox, while leaving all other parameters unchanged.
Click Save.

To disable backup for all MySQL and MongoDB databases:

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
In the Information tab, click Backup settings.
Uncheck the Enable backup checkbox.
To confirm, click Change.

To disable backup for all PostgreSQL databases, delete all backup plans.

Delete backups#

You can delete either specific or all unnecessary backups.

To delete specific backups:

Method 1

Go to PaaS Storages and backups.
On the Backups tab, select the service whose database backups you want to delete in the resource table. To make the search easier, you can select the service category or use the table search.
Click the service ID.
Open the Backups tab and select the backups for deletion in the resource table.
Click Delete and confirm the action in the dialog window.

Method 2

Go to PaaS Running services.
In the resource table, select the service whose database backups you want to delete. To make the search easier, you can select the service category or use table search.
Go to the service page and open the Backups tab.
In the resource table, select the backups to be deleted.
Click Delete and confirm the action in the dialog window.

To delete all backups:

Method 1

Go to PaaS Storages and backups.
In the resource table, select the service whose database backups you want to delete. To make the search easier, you can select the service category or use table search.
Click Delete and confirm the action in the dialog window.

Method 2

Go to the section PaaS Running services and open the Databases tab.
In the resource table, select the service whose database backups you want to delete. To make the search easier, you can select the service category or use table search.
Go to the service page and open the Backups tab.
Click Delete all backups and confirm the action in the window that opens.

Method 3

Go to PaaS Storages and backups and open the Databases tab.
On the Backups tab, select the service whose database backups you want to delete in the resource table. To make the search easier, you can select the service category or use the table search.
Click the service ID.
Open the Backups tab.
Click Delete all backups and confirm the action in the window that opens.

Note

When you delete all the backups of the service, the folder that was automatically created in the bucket to store them is also deleted.

Automatic backup deletion#

In the backup settings, you can set the backup retention period for the service. By default, backups are retained permanently. You can specify the number of days, weeks, months or even years for how long the created backups should be retained.

Individual backups can be protected from automatic deletion. To do this, find the required backup in the list of backups and turn on the Deletion protection switch.

Note

When you delete a database service, automatic deletion of backups will no longer be performed. Backups of the deleted service will be retained permanently. In this case, no-longer-needed backups will have to be deleted manually.

Load balancer management#

For MySQL, PostgreSQL and Redis services, you can create an internal and/or internet-facing load balancer (for details, see load balancers). They automatically distribute incoming requests among fully functional cluster nodes (requests are not sent to the arbitrator if there is one).

Load balancers are created automatically; their parameters and associated resources cannot be modified. To modify the DNS name of an existing load balancer, delete it first and then create a new one. For information about the created load balancers and, in particular, the service addresses, open the Load balancers tab on the service page.

Attention

A load balancer running together with a PaaS service can be deleted only on the page of this service.

Important

To run the internet-facing load balancer, give external access to HAProxy ports, which is denied by default. Add enabling rule for tcp/5000 port to the security group that was specified when creating the service.

Depending on the service, you may also need to open access to other ports. You can see the ports listened to by the service in the Information tab on its page.

Create a load balancer#

A load balancer for a database service can only be created when the service is in Running status. You can create one internal and one internet-facing load balancer per service.

Important

You can create an internal load balancer only if route propagation is enabled in VPC.

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Load balancers tab and click Create.
In the window that opens, select a balancer you want to create. If none has been created yet, you can create both internal and internet-facing balancers at once.

In the DNS name field, you can specify an arbitrary subdomain name in the <lb-name>-<lb-id>.lb.<region>.k2.cloud DNS service zone for an Internet-facing load balancer and in the <lb-name>-<lb-id>.lb.vpc-xxxxxx.internal zone for an internal load balancer. The name may contain Latin letters, digits, and hyphens.

If the DNS name field is left blank, the name will be specified automatically.
Click Create to complete the action.

Delete load balancer#

Load balancer associated with the service can only be deleted when the service is in Running status.

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Load balancers tab and click Delete.
In the window that opens, select a load balancer you want to delete. If two load balancers have been created for the service, you can delete both at the same time.
Click Delete to confirm the action.

Database service configuration#

If you have not enabled monitoring and/or logging when creating the database service, or you want to disable them, you can do it when the service is in the Ready state. You can also change Redis and MongoDB additional parameters.

Note

To enable monitoring and logging, first deploy Prometheus-based monitoring service and ELK-based logging service.

Important

If an attempt to modify some settings fails, then the service will be reset to default ones.

To set up the database service:

Go to the PaaS section Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Parameters tab and click Modify.
In the window that opens, you can configure monitoring and logging (or disable them if they are already enabled). You can also change RDB Persistence and AOF Persistence parameters for the Redis service.
To set up other parameters for Redis and MongoDB services, click Additional parameters.

You can also change advanced settings at this step. To do this, click advanced settings and specify the desired settings and their values.
To save new settings, click Modify.

Assigning tags#

Important

Tags are only supported for PaaS services with an fm-cluster-xxxxxxxxxxx ID. If you want to add tag support for the installed services with a UUID as an ID, please contact the support service.

Tags allow you to classify PaaS services by various attributes, such as purpose, owner, etc. Their usage simplifies the management of many similar resources.

To add, modify or delete tag for the databases service:

Go to PaaS Running services and open the Databases tab.
In the resource table, find the service for which you want to assign tags, and click on its ID to go to the service page.
Open the Tags tab.
To add a tag, click Add tag and specify the Key and Value fields.

To modify a tag, edit the required fields (Value and/or Key) of the respective tag.

To delete a tag, click the icon next to the tag you no longer need.

Note

If no tags have been set earlier, you can add the Name tag by clicking Add Name tag.
Click Apply to save the changes.

Managing security groups#

Note

Security groups can be changed only for a service in the Running status.

If you want to change security groups for a service:

Go to PaaS Running services and open the Databases tab.
In the resource table, find the service whose security groups you want to change and click the service ID to go to its page.
Open the Information tab.
To change the security groups assigned to the service, click next to the Security groups field.
Select one or more security groups from the drop-down list.

To cancel the selection or remove a group from the list, click next to the security group.

Note

If a security group is created automatically with the service, it cannot be deleted.
To save changes, click .

Note

The list of security groups cannot be empty.

Service start and stop#

You can stop the databases service, if you don’t need it, and start it when necessary, thus saving money on computing resources, because only attached volumes (and database backups, if any) are billed when the service is stopped.

You can also restart the service in case of an error, and synchronize the service status with those of the instances where it is installed.

Stop service#

The service can be stopped when it is in the Running or Error state.

Go to PaaS Running services and open the Databases tab.
In the resource table, find the service you want to stop and click the shutdown icon in the Actions field. Alternatively, click the service ID to go to its page and then click Stop in the Information tab.
In the dialog window, confirm the action.

Restart the service#

Note

You can only restart services with the environment version 3.6 or higher. You can find out the current version of the environment in the Information tab on the service page.

The service can be restarted when it is in the Running or Error state.

Go to PaaS Running services and open the Databases tab.
In the resource table, find the service you want to restart and click the restart icon in the Actions field. Alternatively, click the service ID to go to its page and then click Restart in the Information tab.
In the dialog window, confirm the action.

Synchronize the service with instances#

Synchronization allows you to match the states of the service and the instances on which it is installed, when instances were manually started after the service was stopped. It can also be used to match the states if an error occurred when stopping, starting, or restarting the service and instances had to be manually stopped/started.

Attention

Synchronization is not possible if the error cannot be eliminated (the error status can be viewed, for example, using the DescribeService method).

Go to PaaS Running services and open the Databases tab.
In the resource table, find the service you want to synchronize and click the synchronization icon in the Actions field. Alternatively, click the service ID to go to its page and then click Synchronize with confirmation in the Information tab.
In the dialog window, confirm the action.

Start the service#

You can only start the service, when it is in the Stopped state.

Go to PaaS Running services and open the Databases tab.
In the resource table, find the service you want to start and click the start icon in the Actions field. Alternatively, click the service ID to go to its page and then click Start in the Information tab.
In the dialog window, confirm the action.

Configuring the maintenance window#

During scheduled maintenance, critical security patches and other important updates are installed.

Attention

During maintenance, operations with the service, including its deletion, are not available, but the service itself will continue to operate. In some cases, it may be necessary to stop and restart the cluster nodes.

Maintenance is carried out strictly during a preset time period (if a maintenance window is specified). All actions of K2 Cloud specialists during maintenance are logged.

Note

You can modify the maintenance window settings when the service is in the Running state only.

To modify the maintenance window settings:

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
In the Maintenance tab, click Set up.
In the window that opens, specify the maintenance interval that is convenient for you. To do so, select the following parameters:
- the Scheduled value for the Maintenance window option;
- a day of the week for the maintenance to take place;
- hour interval for the maintenance window.
Or select the Custom value for the Maintenance window option, if maintenance can be performed at any time.
Click Save to modify the maintenance window.

Viewing metrics#

Depending on the service type, you can view the following metrics:

MySQL

Metrics	Description
mysql_global_status_aborted_clients	Number of aborted client connections
mysql_global_status_aborted_connects	Number of failed connection attempts
mysql_global_status_innodb_row_lock_current_waits	Current number of expected row locks
mysql_global_status_slow_queries	Number of slow queries
mysql_global_status_threads_connected	Current number of connected threads
mysql_global_status_threads_running	Number of threads that are not sleeping
mysql_global_variables_max_connections	Maximum permitted number of connections
mysql_info_schema_innodb_metrics_buffer_pool_pages	Number of pages in InnoDB buffer pool
mysql_up	Indicates whether MySQL server is up

PostgreSQL

Metrics	Description
pgbouncer_pools_client_maxwait_seconds	Max wait time for client connections
pgbouncer_pools_client_waiting_connections	Number of client connections currently waiting for a free server connection in the pool
pgbouncer_pools_server_active_connections	Number of active server connections in the pool
pgbouncer_up	Indicates whether the PgBouncer server is up
pg_locks_count	Number of locks currently held in database
pg_replication_lag	Replication lag (in seconds) between primary and standby nodes
pg_up	Indicates whether the PostgreSQL server is up

MongoDB

Metrics	Description
mongodb_mongod_replset_my_state	Current node state in MongoDB replica set
mongodb_mongod_wiredtiger_cache_pages	Number of pages in WiredTiger cache by page type
mongodb_ss_connections	Number of current connections
mongodb_ss_mem_resident	Resident memory used by MongoDB
mongodb_ss_mem_virtual	Virtual memory usage
mongodb_up	Indicates whether the MongoDB server is up

Redis

Metrics	Description
redis_connected_clients	Number of connected clients
redis_evicted_keys_total	Total number of evicted keys due to the max memory size limit
redis_expired_keys_total	Total number of expired keys
redis_memory_max_bytes	Max memory available for Redis
redis_memory_used_bytes	Total memory used by Redis
redis_memory_used_rss_bytes	Resident memory used by Redis (RSS)
redis_replication_connected_slaves	Number of connected replicas
redis_up	Indicates whether the Redis server is up
redis_uptime_in_seconds	Uptime of Redis server

To view the metrics of a specific service:

Go to PaaS Running services and open the Databases tab.
Find the desired service in the table and click the service ID to go to its page.
Open the Monitoring tab and select:
- metrics,
- instance to collect metric from.
Note

Instances available for a particular metric depend on their role. For certain metrics, there can be additional selectors apart from instance choice.

Go to Display parameters to set the period the metric graph covers, statistics, and metric calculation interval. To automatically refresh the graph, enable Auto-refresh; to refresh it manually, click Refresh.

Deleting database service#

Deleting a database service consists in deleting all instances, volumes, and placement groups created together with it.

To delete a service, go to PaaS Running services, open the Databases tab and click the icon in the table or the Delete button on the service page. If you want to use network interfaces in the future, for example, to recreate a service with the same network parameters, then in the dialog window, clear Delete associated network interfaces checkbox.

Note

When a service is deleted, stored backups of its databases are retained.

Databases

In this article:

Databases#

General information#

Billing#

Databases in K2 Cloud#

Cluster with an arbitrator#

Before you begin#

Required privileges#

Required resources#

Creating database service#

Modifying service node options#

Make the service highly available#

Add nodes for the service#

Delete service nodes#

Modify the instance type for the node#

Modify data volume parameters#

Configuring automatic volume expansion#

Managing database resources#

Users#

Create user#

Change user settings#

Delete user#

Databases#

Create a database#

Change database settings#

Delete database#

Shards#

Create a shard#

Modify a shard#

Delete a shard#

Profiles#

Create a profile#

Modify a profile#

Delete a profile#

Quotas#

Create a quota#

Modify a quota#

Delete a quota#

Database backup and recovery#

PiTR#

General information#

Terms#

How it works#

Differences between PostgreSQL backup plans#

Usage specifics#

Setup service backup#

Enable database backup#

Configure a backup storage for PostgreSQL#

Create a storage#

Modify a storage#

Delete a storage#

Configure a backup plan for PostgreSQL#

Create a plan#

Modify a plan#

Delete a plan#

Recover a database from a backup#

Restore a PostgreSQL service to a specified point in time#

Disable backup#

Delete backups#

Automatic backup deletion#

Load balancer management#

Create a load balancer#

Delete load balancer#

Database service configuration#

Assigning tags#

Managing security groups#

Service start and stop#

Stop service#

Restart the service#

Synchronize the service with instances#

Start the service#

Configuring the maintenance window#

Viewing metrics#

Deleting database service#