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	A NoSQL in-memory database management system. It can be used as a database, an errand queue, a message broker, and for data caching. It 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
ClickHouse®	An SQL-based column-oriented DBMS for real-time analytical data processing (Online Analytical Processing, OLAP)

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 scaling of the cluster. 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.

The configuration of networks for a managed database depends on the specifics of the infrastructure in which the managed database is embedded.

Monitoring

In managed databases, you can track the status of the cluster in the control panel:

view information about cluster node utilization and database load in the form of charts in the control panel;
view cluster status;
receive notifications about disk space usage.

Cluster node and database metrics can also be exported in Prometheus format.

Learn 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. 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.

Learn more about backups in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis.

Scaling

A managed database cluster can be scaled — for example, you can increase vCPU and RAM to improve cluster performance. You can select a configuration from a different plan line, but the disk type used must match and the disk size must be larger.

Learn more about scaling in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis, Kafka and OpenSearch.

Resiliency and replication

PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis

By default, the cluster consists of one primary node, or master node. When connected to the master node, all operations are available: reading (SELECT) and writing (INSERT, UPDATE, DELETE, and others).

To ensure cluster resiliency, add replicas — full copies of the master node. They are available for read-only access (SELECT). If the master node is unavailable, replicas will take over its role, and the cluster will continue to operate normally. They can also be used to reduce the load on the master node during intensive read operations.

An SLA applies to the cluster with replicas — 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.

Learn more about resiliency in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis.

OpenSearch

OpenSearch managed database cluster resiliency is affected by:

index replication;
the number of nodes in node groups;
the node placement type in node groups.

Learn more in the OpenSearch cluster resiliency instruction.

Managed database settings

Database settings affect 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 do not meet your requirements, you can set your own values for all managed databases except Redis and OpenSearch when creating a cluster, or you can change the settings in an existing cluster.

Learn 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, you need to consider the specifics of the infrastructure the database is embedded in — whether you need to access cluster nodes 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;
a public subnet (except for OpenSearch) — all addresses in the public subnet are accessible from the Internet.

You cannot change the subnet after the cluster has been created.

Learn 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;
installation of the operating system;
installation of the DBMS and standard configuration, which is optimal for the selected setup;
updates and maintenance of the operating system and utility software;
cluster reliability and resiliency — when you create a resilient cluster, we provide failover in the event of a failure;
configuration and maintenance of the service network for cluster replicas;
backup — automatic creation and storage of backups;
a cluster status monitoring system in the control panel;
secure data storage and protection against theft and leaks;
availability of resources for cluster scaling, if you initiate scaling;
technical support.

The user provides

correct connection to the database;
writing optimal database queries;
database schema and structure;
changing settings in accordance with their workload profile and application specifics;
initiating cluster scaling.

ClickHouse® is a registered trademark of ClickHouse, Inc. https://clickhouse.com.