Managed Cloud Databases

Managed Databases is a cloud service provided by Servercore. It offers a turnkey solution that enables fast and simple deployment of database clusters in the cloud. A cluster can consist of one or multiple servers configured for data replication to ensure high availability and have automatic failover to protect against failures.

Cloud databases also include automated backups that allow data to be restored to a specific point in time (Point-in-Time recovery). This ensures data safety and preservation in unforeseen circumstances.

On-premises cloud databases are hosted on your own hardware or rented servers. As a customer, you are responsible for managing all aspects of the infrastructure: choosing and purchasing hardware, installing operating systems and databases, testing, ensuring security, configuration, and updates.

Servercore’s Managed Databases are fully managed database management systems (DBMS) hosted in the cloud. Their main advantage is that Servercore, as a cloud service provider, takes on any administration tasks.

Servercore’s area of responsibility includes:

— Commissioning, fine-tuning, and optimizing server hardware.
— Managing the Infrastructure Layer (IaaS).
— Setting up OS and databases.
— Ensuring uninterrupted access and backup.
— Scaling resources.
— Monitoring database performance.

A cloud database cluster includes:

— Database servers: physical or virtual systems that store and manage data.
— Master: the central node of the cluster responsible for processing writes, updates, and reads.
— Replicas: copies of the master that provide its fault tolerance. Replicas are used solely for reading data.

If the master fails, one of the replicas automatically assumes its role, ensuring continuous data access (failover). Once the master is restored, it becomes a replica again.

For existing databases, use the same virtual machine configuration on which the database was previously running. To save costs, you can initially rent a virtual machine with fewer vCPUs and RAM and scale its resources as needed.

For new databases, start with a virtual machine with minimal resources. Scale up the server size if the load increases.

Choose disk capacity with some buffer to avoid frequent scaling, especially if you do not have a fault-tolerant database cluster.

The disk size of a created cluster cannot be reduced.

If you need advice on choosing a server configuration for cloud databases, you can contact our experts at hello@servercore.com.

You can explore all available configurations for cloud database servers on our website under the Calculator section or within the control panel.

The rental price for any server includes an internet connection with a data transfer speed of 100 Mbps.

The cloud platform employs a predictable and transparent pricing model — pay-as-you-go. Every hour, your account is charged for the resources used in the previous hour and for outgoing traffic.

You will be billed for all resources you create, even if they are not in use.

For example, if you create a cloud database cluster with resources such as vCPU, RAM, and local disk. If you stop the cluster, you will still be charged hourly for these resources.

For more detailed information about costs and pricing plans, please refer to the documentation.

— PostgreSQL 12, 13, 14, 15, 16
— TimescaleDB based on PostgreSQL
— MySQL semi-sync 8.0
— MySQL sync 8.0
— Redis 6
— Kafka 3.5

Leave the complexities of database maintenance to us. Servercore’s responsibilities include:

— Providing access to resources, creating virtual machines, and installing and configuring the operating system and DBMS.
Once the client has created the DBMS, databases, and users, Servercore is responsible for:
— Automatic creation and storage of backups.
— Horizontal and vertical scaling (upon user request).
— Ensuring fault tolerance and failover in user-created fault-tolerant clusters.
Users of the service are responsible for monitoring the correctness of database connections, data schemas and structures, as well as the queries executed.

Yes, there is such an option. You can alter certain settings of your Servercore database cluster quickly in the control panel:

— Name.
— Number of replicas in the cluster (increase or reduce).
— Server configuration: number of vCPUs, amount of RAM, and number of SSDs (increase or reduce).
— DBMS parameters (e.g., MySQL, PostgreSQL, or Redis), which are initially set by default depending on the chosen server configuration.

Note that you cannot change the subnet to which the cluster is connected. However, you can always recreate the DBMS cluster in a new subnet using a backup.

Backups of Servercore cloud databases are performed according to the following schedule:

— Full weekly backups.
— Incremental (delta) daily backups.
— For WAL files (PostgreSQL) or binlog files (MySQL): every 10 minutes or when a certain volume of changes accumulates.
Backups are stored for seven days, after which they are deleted. However, backups of deleted clusters are available for seven days post-deletion.

Once deleted, a cluster can be restored from its backups.

Servercore cloud databases are highly scalable. The service supports two types of scaling:

— Vertical scaling. This involves altering the configuration of the virtual machines hosting the database cluster. This includes increasing or reducing the number of virtual CPUs (vCPUs) and RAM. Vertical scaling occurs without downtime if you have a fault-tolerant cluster. However, note that NVMe SSD storage can only be increased but not reduced.
— Horizontal scaling. This involves altering the number of replicas in the database cluster. This entails adding or removing database instances that replicate the primary database. Horizontal scaling also occurs without downtime.

To learn more about scaling clusters for various DBMS, please refer to the relevant documentation sections: PostgreSQL, MySQL, Redis, Kafka, TimescaleDB.

To enhance the fault tolerance of your database cluster and ensure automatic failover to a standby database in case of failure, you need to add replicas to the cluster.

If the master node fails, one of the replicas automatically takes over its role, ensuring uninterrupted application functionality. The failed master node will automatically be recreated and join the cluster as a replica.

Connecting to Servercore databases can be done in two ways:

— By connecting to a specific node using its IP address.
— Connecting using a domain name, which allows requests to be automatically redirected to an active node even during failures or scaling events.
It is recommended to use domain names for connection to ensure seamless database access under all circumstances.

For detailed information on connecting to PostgreSQL, MySQL, TimescaleDB, and Redis clusters, please refer to the corresponding sections in the documentation via the provided links.

If the cluster is operating correctly, both the cluster and all virtual machines within it will display an ACTIVE status in the Servercore control panel. If this status is different, it means that there are some errors in the cluster operation.

Possible issues and their indicators include:
— In a fault-tolerant cluster: If the master becomes unavailable and does not report an ACTIVE status for 30 seconds. This triggers a failover from the master to a replica.
— In a single-master cluster: If the master becomes unavailable, the entire cluster will be temporarily inaccessible until a new server is created to replace the master. The databases are not lost but remain inaccessible during this period.

In the event of cluster errors, you can:
— Restore the cluster from a backup yourself.
— Contact our technical support by submitting a ticket through the Servercore control panel. Our specialists will remove the faulty virtual machine, replace it, and analyze the cause of the incident.

— You can create up to 10,000 databases and up to 1,000 users within a single cluster.

— Resource limits. These are the limits on the number of databases, vCPUs, RAM, and local disk depend on resource quotas.

To increase project quotas, navigate to «Cloud Platform» -> «Quotas.» Select the region where you need to modify quotas and modify the quota limit. If a «Limit Reached» icon appears for a resource, the limit is exhausted. In such cases, create a ticket in the panel to request an increase in your account’s limit. Additional information on quotas and limits can be found in the documentation.

— Network Restrictions: Clusters can only be created in private and public subnets; floating IP addresses are not supported.

You can integrate various Servercore cloud computing services with cloud databases for your projects:

— Cloud servers.
— Dedicated servers.
— Managed Kubernetes.
— Object S3 storage.
— Global router.

You can also order a cloud database administration service on our website in order to completely delegate to us the tasks of ensuring the smooth operation of the database and focus on higher priority product tasks.

Yes. For example, you can use Redis to cache, which can significantly improve the speed of your apps.