Skip to main content

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

PostgreSQL

An open-source database. Focused on performance and extensibility — you can connect any external data sources, create new data types, and functions

PostgreSQL for 1C

A version of PostgreSQL with necessary extensions for efficient work with 1C:Enterprise

PostgreSQL TimescaleDB

A version of PostgreSQL with the TimescaleDB extension, which can be used for storing time-series data

MySQL semi-sync

An open-source relational database management system that is easy to manage and scale. Suitable for most data-related tasks

MySQL sync

An open-source MySQL solution. Runs on Percona Server for MySQL with the XtraDB storage engine

Redis

NoSQL in-memory database management system. Can be used as a database, message queue, message broker, and for data caching. Works with key-value data

Kafka

A distributed open-source system for message delivery, storage, and processing. Can act as a data bus for Cloud Native applications

OpenSearch

A scalable open-source search and analytics system

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.