We are excited to announce the release of Percona Operator for MongoDB v.1.15.0. This release consists of various enhancements and bug fixes. In this blog post, we will look into some of the most interesting features.

  1. Reduce Recovery Point Objective (RPO) with Point-in-Time Recovery for physical backups
  2. Encrypt your backups with Server-Side Encryption (SSE) to meet compliance and security requirements
  3. Long awaited split horizon functionality that enables users to create various topologies

Point-in-time recovery for physical backups (Tech preview)

In the previous 1.14.0 release, we added support for physical backups and restores to significantly reduce Recovery Time Objective (RTO), especially for big data sets. However, the problem of losing data between backups – in other words, Recovery Point Objective (RPO) – for physical backups was not solved. With this release, users can greatly reduce RPO by leveraging the Point-in-time Recovery feature in the Operators. Under the hood, we store logical oplogs along with physical backups into the object storage.

Percona Operator for MongoDB

As a prerequisite, you would need to have physical backups enabled. It can be done either through setting tasks.[].type in the schedule configuration or when taking a backup manually.

Now, you can enable PITR. The trick is to use the oplogOnly flag, which would instruct Percona Backup for MongoDB to upload oplogs to the object storage without waiting for the logical backup.

Restoration is performed as usual via specifying needed parameters in restore.yaml. See more details in the documentation.

Backups server-side encryption (SSE)

Whether it is compliance or security requirements, there is often a need to encrypt database backups. With data-at-rest encryption enabled and physical backups, you don’t have to worry about it. But what about logical backups, where data from your databases is copied as is to the object storage? This is where server-side encryption comes into play. With our Operator, users can leverage integration with AWS KMS or just encrypt/decrypt backups with AES-256 encryption algorithm with any S3-compatible storage.

To configure SSE, we add a backup.storages.[].s3.serverSideEncryption  section. There, you can either integrate with AWS KMS or use AES-256 key. For example, to use the AES-256 key, your custom resource manifest will look as follows:

This functionality has taken our Operator to new heights, all thanks to our incredible community! A huge shoutout to Mert Gönül, whose exceptional pull request made it all happen. We are immensely grateful for your valuable contribution!

Split horizon

The implementation of this feature is a result of an interesting and multi-layered problem. This functionality will be interesting for those who use a single replica set without sharding or who deploy MongoDB across multiple Kubernetes clusters (cross-site replication).

The story of a problem

Before version 1.14, we were configuring exposed replica set primary and secondary nodes with IP-addresses. For example, if you had the following in your custom resource manifest:

We would configure the replica set using the IP-addresses and rs.status()  command shows the following:

This is suboptimal, leads to multiple issues (K8SPSMDB-860, K8SPSMDB-841, K8SPSMDB-854), and is against best practices.

As a result of it, we made a decision to configure replica sets with Fully Qualified Domain Names (FQDNs) only (K8SPSMDB-867). We understood, though, that it might be a breaking change and allowed users to keep the old behavior with the clusterServiceDNSMode flag.

So in 1.14, whenever you expose a replica set, nodes will always use an internal FQDN:

But the obvious issue with this setup is that replica set nodes are not aware if they are exposed or not, and MongoDB will just deny the connection (see more in K8SPSMDB-929):

Introducing split horizon

Split horizon is an industry term. In the case of Percona Operator for MongoDB, it allows us to configure replica set nodes according to best practices but still expose them with different external domain names. And still, MongoDB accepts the connections.

To configure split horizon, we add the section spec.replsets.[].splitHorizons. To expose the nodes with additional FQDNs, just add something like this:

Now, you will be able to connect to the new domain names, and the MongoDB replica set is still configured according to the best practices.

Limitations

There are two important limitations that you should take into account when using split horizon.

  1. If you plan to scale your replica set horizontally by adding more nodes, make sure that you have a corresponding entry in your splitHorizons section. You can add them beforehand, even for non-existing nodes.
  2. TLS certificates must be properly generated for the new domain names so that your connection is accepted. Read more about how to do it in our documentation. We might create certificate generation in future releases.

Conclusion

We continue our journey of constantly improving the user experience and functionality of our Operators. This release comes with multiple awesome features, improvements, and important bug fixes. Read more in our release notes.

If you are new to databases on Kubernetes, try out our quick start guides here.

If you are an experienced user – see how to Upgrade to a new version here.

You can get early access to new product features, invite-only ”ask me anything” sessions with Percona Kubernetes experts, and monthly swag raffles. Interested? Fill in the form at percona.com/k8s.

 

Learn More About Percona Kubernetes Operators

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments