Product Description Managed Databases
Managed Databases is a service for deploying and managing high-performance and fault-tolerant clusters of supported databases in the cloud.
You can work with Managed Databases in the control panel, via the Managed Databases API or Terraform (except OpenSearch).
The product supports user types and roles, projects, and project limits and quotas.
Records of operations with Managed Databases are saved in audit logs.
Supported Managed Databases
How Managed Databases work
Managed databases are deployed in a cluster. A cluster is one or more database servers (nodes). Cluster nodes run on the cloud platform resources.
Managed databases support monitoring, backups, and cluster scaling. You can improve resiliency of the cluster and configure replication between nodes.
Database settings are set by default when creating a cluster and depend on the cluster configuration and the database version. You can change them if necessary.
Configuration of the Managed Database networks depends on the infrastructure in which the Managed Database is embedded.
Monitoring
In Managed Databases, you can track the cluster status in the control panel:
- view information about cluster node utilization and database load in the form of graphs in the control panel;
- check the cluster status;
- receive notifications about disk usage.
Cluster and database metrics can also be exported in Prometheus format.
Read more 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 support point-in-time recovery (Point-in-Time Recovery). The frequency of backup creation depends on the selected database.
Backups are stored isolated from backups of other users. Backups cannot be downloaded. Automatic backup creation cannot be disabled.
Read more about backups in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, and Redis.
Scaling
A Managed 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 disk type must match and the disk size must be larger.
Read more 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, a cluster consists of one primary node — the master node. When connected to the master node, all operations are available: reading (SELECT) and writing (INSERT, UPDATE, DELETE, etc.).
To provide cluster fault tolerance, add replicas — complete copies of the master node. They are only available for reading data (SELECT). If the master node is unavailable, replicas will assume its role, and the cluster will continue to operate normally. They can also be used to offload the master node during heavy read activity.
The cluster with replicas operates under an SLA — we guarantee 99.95% write availability and 99.99% read availability.
The node placement type in a cluster depends on whether the cluster has replicas, the type of pool in which the cluster is located, and the number of segments in the pool.
Read more about fault tolerance in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis.
OpenSearch
OpenSearch Managed Database cluster fault tolerance is affected by:
- index replication;
- the number of nodes in node groups;
- node placement type within node groups.
Find more information in the OpenSearch cluster fault tolerance instruction.
Managed database settings
Database settings affect the database cluster performance. When creating a database cluster, values for all settings are set automatically. These values are optimized for high cluster performance and vary depending on the cluster configuration and the database version.
If the default values are not suitable for your tasks, for all Managed Databases except Redis and OpenSearch, you can set your own values when creating a cluster or change the settings in an existing cluster.
Read more about Managed Database settings in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, and Kafka.
Networks
When creating a Managed Database cluster, it is necessary to consider the specifics of the infrastructure in which the Managed Database is embedded — whether the cluster nodes need to be accessed from the Internet and whether network connectivity with other Servercore services is required.
A cluster can be connected:
- to a private subnet — a subnet without Internet access;
- to a public subnet (except OpenSearch) — all addresses in the public subnet are accessible from the Internet.
Once the cluster is created, the subnet cannot be changed.
Read more about creating network connectivity between a Servercore dedicated server and a Managed Database cluster in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis, and Kafka.
Areas of responsibility
Servercore provides
- selection of hardware for high DBMS performance;
- operating system installation;
- DBMS installation and standard configuration, which is optimal for the selected configuration;
- updates and maintenance of the operating system and utility software;
- cluster reliability and fault tolerance — when you create 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;
- a cluster monitoring system in the control panel;
- secure data storage and protection against theft and leaks;
- availability of resources for cluster scaling, if you have initiated scaling;
- technical support.
The user provides
- correct connection to the database;
- optimality of database queries;
- database schema and structure;
- changing settings in accordance with their load profile and application specifics;
- initiating cluster scaling.