Product Description Managed databases
Managed databases — a service for deploying and managing high-performance and fault-tolerant clusters supported databases in the cloud.
You can work with Managed databases in control panel through Cloud Database API or Terraform (except for OpenSearch).
The product supports user types and roles, projects and project limits and quotas.
Supported Managed databases
How Managed databases work
Managed databases are deployed in a cluster. A cluster is one or more database servers (nodes). The nodes of a cluster run on the basis of cloud platform resources.
Managed databases support monitoring, backups and scaling cluster. It is possible to increase fault tolerance cluster and configure replication between nodes.
Database settings when creating the cluster are selected by default and depend on the cluster configuration and database version. You can change them if necessary.
Customization networks cloud database depends on the specifics of the infrastructure in which the cloud database is embedded.
Monitoring
In Managed databases, you can monitor the status of the cluster in the dashboard:
- View information about cluster node utilization and database load in the form of graphs in the control panel;
- watch the status of the cluster;
- receive notifications when the disk is full.
Cluster and database node metrics can also be exported in Prometheus format.
More information about monitoring in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis and Kafka.
Backups
In Managed databases, cluster backups are created automatically using WAL-G. All databases except Redis are Point-in-Time Recovery. The frequency of backups depends on the selected database.
The backups are stored isolated from other users' backups. Backups cannot be unloaded. Automatic creation of backups cannot be disabled.
More information about backups in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis.
Scaling
A cloud database cluster can be scaled — for example, increase vCPU and RAM to improve cluster performance. You can select a configuration from a different line of configurations, but the type of disk used must match and the disk size must be larger.
More information about scaling in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis, Kafka and OpenSearch.
Fault tolerance and replication
PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, My SQL semi-sync, Redis
By default, the cluster consists of one main node — the master node. When connected to the master node, all operations are available: read (SELECT) and write (INSERT, UPDATE, DELETE and others).
To provide cluster fault tolerance, add replicas — full copies of the master node. They are read-only (SELECT) copies of the master node. If the master node is unavailable, the replicas will take over and the cluster will operate normally. They can also be used to reduce the load on the master node during active reads.
For a replica cluster, the following applies SLA — we guarantee 99.95% write availability and 99.99% read availability.
The type of node placement in a cloud database cluster depends on the availability of replicas in the cluster and the number of segments in the pool where the cluster is located:
- Single-AZ — in one segment of the pool. Applicable for clusters without replicas and for clusters with replicas that are in pools with a single segment;
- Multi-AZ — in different segments of the pool. Applicable for replica clusters that are in pools with multiple segments. Nodes are allocated to segments sequentially.
Read more about fault tolerance in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis.
OpenSearch
The cluster uses the standard mechanism of index replication — for each primary shard, the number of replica shards you specified when creating the index is created. Writing to the index is done only through primary shards, reading can be done simultaneously from primary and replica shards.
Cloud database settings
Database settings affect the performance of the database cluster. When you create a database cluster, the values for all settings are set automatically. The values are selected to ensure high cluster performance and vary depending on the cluster configuration and database version.
If the automatic values are not suitable for your tasks, for all Managed databases except Redis and OpenSearch, you can set your values when creating a cluster or change the settings in an already created cluster.
For more information on setting up Managed databases, see the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync and Kafka.
Networks
When creating a cloud database cluster, it is necessary to consider the specifics of the infrastructure in which the cloud database is embedded — whether the cluster nodes need to be accessed from the Internet and whether network connectivity with other Servercore services is required.
The cluster can be connected:
- to a private subnet — a subnet with no access from the Internet;
- public subnet (except OpenSearch) — all public subnet addresses are accessible from the Internet.
Once a cluster is created, the subnet cannot be changed.
For more information on establishing network connectivity between a Servercore dedicated server and a cloud database cluster, see the instructions for the PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis and Kafka.
Areas of responsibility
Servercore provides
- hardware selection for high DBMS performance;
- installing an operating system;
- installation and optimal configuration of the DBMS;
- updating and maintenance of the operating system and service software;
- Cluster reliability and fault tolerance — when you build a fault-tolerant cluster, we provide failover in the event of a failure;
- Configuring and maintaining the service network for cluster replicas;
- Backup — automatic creation and storage of backups;
- cluster status monitoring system in the control panel;
- secure data storage and protection against theft and leakage;
- Availability of resources to scale the cluster if you initiate scaling;
- technical support.
The user provides
- correct connection to the database;
- optimality of writing database queries;
- the schema and structure of the data in the database;
- initiating cluster scaling.