Is there any plan to support physical backup from MongoDB's Operator?

MongoDB Percona Operator for MongoDB
1

Since PBM v1.7.0 have already support physical backup for MongoDB with specified version, does the operator for MongoDB have plan to support this feature? It seems to me that latest implementation of operator does not support this feature. Thank you

2 Likes
2

Hello @Xiaolu - yeah, we have it in our roadmap.
As of now physical backups are not GA in PBM, but we will start working on its implementation shortly.

Could you tell me what is the use case for you? Usually physical backups are used for big data sets to speed up recovery. How big is the database that you run with the Operator?

1 Like
3

Hello @Sergey_Pronin, Thank you for your prompt response.
We have verified current logical backup for about 50G+ mongodb will take hours, so it is better to have physical backup as another option.
Also I found some historical discuss about supporting physical backup vs partial backup (say only backup some collections or DB). Is there some conflict or special thoughts for those two features on implementation?

2 Likes
4

Hey @Xiaolu , understood, thank you.

As for partial backup - we don’t have it yet in PBM and it is in our roadmap. I would say that first we need to go GA with physical and focus next on partial (which would be obviously logical).

1 Like
5

Hi, @Sergey_Pronin, do you have some potential date for GA of physical backup? Is it possibility that I came up with PR for you guys to review so that speed this process up?

1 Like
6

I would expect to have physical backups as GA in PBM by mid Q3.

And definitely PRs are always welcome :slight_smile:
I would suggest to come up with the design first and we can have a quick session to discuss it with our engineering team. This is a significant feature and they might provide more context and inputs before writing any code.

1 Like
7

Hello, @Sergey_Pronin
I would like to submit my design about physical backup/restore function based on pbm v1.8.0 for your guys to review. Is there any guide/formats on submitting this and where should I put the design doc? Thank you

1 Like
8

Hey @Xiaolu ,

we have the following folder which is intended to store architecture and tech details: percona-server-mongodb-operator/docs/architecture/decisions at main · percona/percona-server-mongodb-operator · GitHub

You can use the following template to create the new doc:

Couple of comments:

  1. do not overcomplicate this
  2. diagram sometimes can say much more than text

Please do not hesitate and let me know if there are any questions.

1 Like
9

Thank you @Sergey_Pronin , got it

1 Like
10

Hi, @Sergey_Pronin

I have issued a jira (K8SPSMDB-713) and tried to submit a PR with architecture decision into above repo but failed with “ERROR: Permission to percona/percona-server-mongodb-operator.git denied”. It seems I do not have permission to do that. So I put content as below for your guys to review. Please comment, thank you.

Context

PBM tool can support physical backup from v1.7.0 while current Mongo operator can not. Considering the efficiency of physical backup for large size db, should enable this feature via Mongo operator.

Brief procedure

  • Add a type field (logical or physical) in CR PSMDB (spec.backup.type) and PSMDB-Backup to indicate backup type.
  • Let pbm tool recognize and check Mongo server’s encryption/compression setting so that it can handle db data correctly during restoration. If pbm found different setting of encryption/compression, it will failed with error. PBM tool can not transfer db data files from one format to another for now.
  • Let pbm tool hide Mongo server’s K8S entrypoint file (/data/db/ps-entry.sh) during restoration and recover entrypoint file before restoration succesful return. In this way, mongod container will stay in unready state and will not be restarted to jump in and interrupt restoration process.
  • Mount Mongo server’s data volume into pbm container as well.
  • Mount encryption keyfile into pbm container as well if encryption enabled.
  • Add mongod binary into pbm tool’s image as well because pbm will exec mongod temporarily.

Considered Options: How to make mongod container stay DOWN during restoration

  • Option A: Hide mongod container’s entrypoint file and after shutdown mongo server, mongod container will stay DOWN until entryfile been restored.
  • Option B: Design a mechanism for pbm tool to inform psmdb operator to delete mongod container from statfulset.

Decision

Chosen option: “option A”, because it is quite straightforward. Option B will add a lot of complexity into current architecture and there is no other such requirement for pbm notifying psmdb operator. Also considering pbm tool is not intended be used in K8S only, it is not good to let pbm tool handle K8S resource directly.

Consequences

User can trigger a physical backup or physical restore (pretty the same way with logical restore) from K8S CR (psmdb or psmdb-backup)

Negative Consequences

  • Hide container’s entrypoint file seems a little hack.
1 Like
11

Hi @Xiaolu ,

It is interesting. Please have a look at contribution guide and try to do it once again.

  • Option A: Hide mongod container’s entrypoint file and after shutdown mongo server, mongod container will stay DOWN until entryfile been restored.

I need to see it more detailed but maybe it is better not to ‘hide’ any entrypoints but add the logic to this entrypoint. E.g. entrypoint can understand that this is physical recovery case and do not start mongod.

1 Like
12

Hi, @Slava_Sarzhan

PR submitted. (Physical backup support proposal by sinbadonline · Pull Request #983 · percona/percona-server-mongodb-operator · GitHub)

I will look into this possibility of add some logic to enhance entrypoint. Keep you posted.

1 Like