Yandex Managed Databases: where database operations break
A database lives peacefully as long as only application queries touch it. As soon as maintenance passes to a person with a checklist, users begin to notice delays, not the monitoring system.
Manual database operations stretch out any task: role switching, applying a schema migration, restoring from a backup are done by hand, at a time convenient for the on-call engineer, and with varying degrees of care each time.
The most common failure is replica desynchronization.
The read node lags behind the primary, the application serves stale data, and no one has configured the lag threshold because "the replica catches up on its own." Alongside that is the lack of alerts for connection exhaustion, write queue growth, and free space: the database doesn't fail immediately—it degrades—first responding more slowly, then starting to reject connections.
The cost of such a failure is downtime due to a database failure at the worst possible moment.
Updating a version or parameters without a tested rollback plan turns planned maintenance into an incident, and restoring from the latest backup rolls data back—everything written between backups is lost irreversibly.
The bottleneck in database maintenance is not disk or memory, but the person who holds the whole picture in their head and remains the single point of failure.
We break down how this is addressed in Yandex Managed Databases: declarative cluster descriptions, replication with lag control, alerts based on real metrics, and reproducible rollback to the previous version.
What managed database operations change for the team
Cluster fault tolerance is not a "replica just in case" but a different class of availability.
Nodes are placed in different zones, on failure the role switches automatically, and recovery time after an incident is measured in minutes, not hours of nighttime investigation.
In most scenarios, the user does not notice the event: the connection is re-established, the application retries the query.
The reduction in manual operations is visible in the on-call checklist. Automatic scheduled backups with restore verification, log rotation, node maintenance, and minor-version updates all cease to be a separate task and become a configuration parameter.
In Yandex Managed Databases, cluster state is described declaratively, and the same configuration is applied to a second environment in full.
Monitoring and alerts cover what used to be found through complaints. Node state, replica lag, free space, number of connections, and query duration are tracked; thresholds are set so the signal arrives before degradation.
Failure classes that stop reaching users: log overflow, lagging replica, connection pool exhaustion, single-node failure.
The team retains what requires engineering decisions: data schema, indexes, access rights, query parameters. Hence a measurable shift—the share of manual operations and the number of nighttime calls fall, and recovery becomes a predictable process with a known maximum time.
Deployment modes and cluster fault tolerance
The deployment mode determines what happens to the database when an availability zone fails or during planned maintenance. A single node cannot survive such a situation: the cluster is raised from a backup, and the service remains idle until the site comes back online.
A read replica in a neighboring zone removes part of the load from the primary node and provides automatic switching on failure. The price for this is replication lag: queries that require strict data consistency still go to the primary node.
| Contour option | When it fits | Limitations |
|---|---|---|
| Single node | Internal services, test and pre-production environments where downtime is acceptable | No automatic switching; recovery only from backup |
| Primary node and read replica in a neighboring zone | Production services with a read-heavy workload, reporting and analytics on a separate node | Replication lag; the application must be able to switch to the replica |
| Distributed contour across three zones | Fault-tolerant cluster where downtime is unacceptable: node quorum and automatic write switching | More expensive in resources; some parameters require coordinated configuration across all nodes |
A distributed contour is more expensive and harder to maintain, so it is chosen where downtime is unacceptable.
We design the standby contour in advance: cluster parameters and switching rules are described in code so that recovery in another zone is reproducible rather than a manual operation from memory.
We assemble Yandex Managed Databases clusters in one of these configurations—according to the load profile and availability requirements.
Implementation order: from audit to handover to support
We work in stages, and each ends with an artifact that can be verified, not a verbal "done." The order is not accidental: until the current contour is described, design turns into guesswork, and data migration without a rollback plan becomes a risk of losing production.
- Infrastructure audit. We capture the actual picture: DBMS versions, database sizes and growth, read and write load, replication, backups, and access schemes. The output is a map of bottlenecks and a list of what is blocking migration.
- Cluster design. We determine the topology: number of hosts, roles, availability zones, disk class, fault-tolerance parameters, and connection pooler. We fix target response-time and recovery-point objectives.
- Infrastructure as code. We describe cluster, network, and access rights configuration in a repository (Terraform), and changes go through review. Environments are reproduced from the description, manual console edits are excluded—no more discrepancies between stands.
- Database migration. We move to replication with minimal lag, then switch traffic in a short window. We bring the schema and rights to the target form in advance so switching does not drag rework along with it.
- Failure testing. We deliberately take a node down, break a replica, and restore a backup to a separate contour. We observe how the application behaves and how long recovery takes.
- Documentation. We describe the architecture, growth points, standard operation procedures, and incident investigation. The on-call engineer acts according to instructions, not the author's memory.
- Handover to support. We transfer access, configure alerts, and walk through them together with your team using live scenarios.
After the seventh stage, changes to the cluster go through the repository, and infrastructure state is visible in monitoring.
What remains with the team: configurations, schemas, regulations
Handing over a working contour is not "we gave access and said goodbye." A Yandex Cloud managed database cluster without a description of how it was assembled and why it is configured this way becomes a black box within six months: changes are made at random.
Therefore, along with the infrastructure, we hand over artifacts that the team uses to run it independently.
- Cluster schema — nodes and roles, networks, application connection points, dependencies between components; the topology is clear from the document, without back-and-forth messages.
- Access policies and roles — who is allowed to read and change what. Rights are granted by groups rather than individually: changing an employee does not break access.
- Configurations in the repository — settings live in code, not in the control panel: a change goes through review and remains in history.
- Backup regulations — what is backed up, how often, where it is stored, how long a backup is retained, and how restoration is verified.
- Infrastructure documentation — service connections, environment variables, stand deployment procedure, standard operations.
- Change log — what changed, when, and why, and who approved it: during incident investigation, it is clear after which change the behavior broke.
- Alerts and on-call procedure — which signals are critical, who receives them, and what to do for each.
Artifacts are updated during the work, not written on the last night. At the end, we go through them together with the team and answer questions while we are in touch.
Case study: reduced database recovery time after failure
The project was an order service with a single-node database: the replica was raised manually according to regulations, and fault tolerance rested on the on-call engineer.
Incident investigation took 3–4 hours: while node state was captured, logs were compared, and data was raised from backup, order intake was down. Over a quarter, 5–6 incidents accumulated, and nearly every second one ended with manual data edits.
What we changed
The contour was moved to Yandex Cloud with managed databases: a primary with a hot replica, automatic switching on node failure, and backups with restore verification in a separate contour.
The cluster, fault-tolerance rules, and backup schedule were described declaratively—infrastructure state lives in code, not in the on-call engineer's memory.
Separately, we configured a monitoring dashboard: replication lag, query queue, response time, and remaining space with notifications before failure occurs.
What resulted
Recovery time decreased from 3–4 hours to 5–10 minutes: switching is done by the platform, and the engineer only confirms the result and investigates the cause.
The number of incidents over the same period fell from 5–6 to one or two, and the share of manual actions during an incident went from about 100% to 15%, and this is no longer recovery but verification.
Operational metrics are visible over time, so we catch degradation before failure and plan capacity based on facts, not feelings.
Managed cluster or self-managed: what to choose
A direct answer: a managed contour is advantageous as long as database tasks are typical. The provider handles backup, fault tolerance, updates, and monitoring—the team does not keep an on-call engineer for patches. The boundary begins where non-standard extensions, superuser rights, or kernel tuning are needed.
Control over configuration is the second dividing line. In a managed Yandex Cloud contour, some parameters are closed: predictability matters more than freedom.
A self-managed cluster gives full access, but in return requires an update policy, backup verification through restoration, and incident investigation—database administration takes up part of the engineer's time.
Data requirements decide more often than convenience: placement, retention periods, encryption with customer keys. Some are covered by a managed contour, some only by a self-managed one.
Hence the working hybrid scheme: typical databases in a managed contour, non-standard ones separately.
| Option | When it fits | Limitations |
|---|---|---|
| Managed cluster | Typical workload, needs backups and fault tolerance without in-house operations | Some parameters are closed, non-standard extensions are unavailable |
| Self-managed cluster | Specific extensions, kernel tuning, special placement requirements | Updates, backups, on-call duty, and recovery are on the team |
| Hybrid | Main workload is typical, individual databases require full control | Two operational schemes, unified monitoring and access accounting are needed |
The selection criterion is the share of non-standard tasks. While it is less than one-fifth, a managed cluster provides a lower failure class. When the database grows its own storage logic, we calculate a self-managed contour.
Technical concerns: backups, access, rollbacks
Before starting, four things are usually checked: how backups are taken, who gets access to the production database, what happens during an unsuccessful release, and whether the application will have to be rewritten. Below are short answers on each point.
Managed Yandex Cloud databases provide automatic backup with configurable retention depth and restoration to an arbitrary point within the window.
We do not rely only on the built-in mechanism: in the configuration we describe the backup schedule and retention period, and once a quarter we deploy a backup in an isolated contour and compare table checksums.
How quickly can you roll back to a restore point?
The backup is deployed to a new cluster, and the application switches by changing the connection string. The time depends on the data volume—on large databases it is tens of minutes, not hours. Before returning traffic, we verify integrity.
How are access rights separated?
The application gets only read and write access to its schemas, analytics gets read-only access to the replica, and engineers get temporary access by request with logging. Direct connection to the primary node is an emergency scenario, and it is visible in the log.
What is included in the rollback plan?
The plan is written before release and tested on a stand. First, the application rolls back to the previous build, and only if the schema is incompatible—database restoration to the point before the update.
We do migrations in two steps so that application rollback does not drag schema rollback along with it.
Will the application need to be changed for the managed database?
Usually not: the engine is the same, drivers and access logic remain, and only connection parameters change. If the engine version differs from the current one, we first raise an intermediate stand, update on it, and only then switch the production contour.
What to discuss at the start: how we arrive at a work plan
To come back with an estimate of the scope of work and an implementation plan rather than general wording, a short list of inputs is needed at the start.
We collect some of them, some come from the customer: without any item, the estimate turns into a guess, and stage deadlines have to be revised during the process.
Access and inputs needed from you:
- access to the cloud account with read-only rights—it shows current clusters, number of replicas, backup settings, and maintenance windows;
- current infrastructure diagram: which services access the databases, how test and production environments are separated, and where responsibility boundaries between teams lie;
- application inventory—what is already described by configuration and what is configured manually and will require transfer into infrastructure descriptions;
- constraints: allowed maintenance windows, fault-tolerance requirements, backup retention periods, and who receives incident notifications;
- responsible parties on the operations side and the procedure for approving changes in the production contour.
On our side, we fix the target managed database scheme on Yandex Managed Databases, the list of metrics and thresholds for alerts, a draft of infrastructure descriptions, and a breakdown by stages with timelines: preparation, migration, verification, and commissioning. This way the plan relies on facts about your contour, not a standard template.