Skip to content
logo
Percona Operator for MongoDB
Frequently asked questions
Initializing search
    percona/k8spsmdb-docs
    percona/k8spsmdb-docs
    • Welcome
      • System requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Generic Kubernetes installation
      • Install on OpenShift
      • Application and system users
      • Changing MongoDB options
      • Anti-affinity and tolerations
      • Labels and annotations
      • Exposing the cluster
      • Local storage support
      • Arbiter and non-voting nodes
      • MongoDB sharding
      • Transport encryption (TLS/SSL)
      • Data at rest encryption
      • Telemetry
        • About backups
        • Configure storage for backups
        • Making scheduled backups
        • Making on-demand backup
        • Storing operations logs for point-in-time recovery
        • Restore from a previously saved backup
        • Delete the unneeded backup
      • Upgrade MongoDB and the Operator
      • Horizontal and vertical scaling
      • Multi-cluster and multi-region deployment
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
      • Restart or pause the cluster
      • Debug and troubleshoot
      • OpenLDAP integration
      • How to use private registry
      • Creating a private S3-compatible cloud for backups
      • Restore backup to a new Kubernetes-based environment
      • How to use backups to move the external database to Kubernetes
      • Install Percona Server for MongoDB in multi-namespace (cluster-wide) mode
      • Upgrading Percona Server for MongoDB manually
      • Custom Resource options
      • Percona certified images
      • Operator API
      • Frequently asked questions
        • Why do we need to follow “the Kubernetes way” when Kubernetes was never intended to run databases?
        • How can I contact the developers?
        • What is the difference between the Operator quickstart and advanced installation ways?
        • Which versions of MongoDB the Operator supports?
        • How can I add custom sidecar containers to my cluster?
        • How to provoke the initial sync of a Pod
      • Old releases (documentation archive)
      • Release notes index
      • Percona Operator for MongoDB 1.14.0 (2023-03-13)
      • Percona Operator for MongoDB 1.13.0 (2022-09-15)
      • Percona Operator for MongoDB 1.12.0 (2022-05-05)
      • Percona Distribution for MongoDB Operator 1.11.0 (2021-12-21)
      • Percona Distribution for MongoDB Operator 1.10.0 (2021-09-30)
      • Percona Distribution for MongoDB Operator 1.9.0 (2021-07-29)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.8.0 (2021-05-06)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.7.0 (2021-03-08)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.6.0 (2020-12-22)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.5.0 (2020-09-07)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.4.0 (2020-03-31)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.3.0 (2019-12-11)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.0.0 (2019-05-29)

    • Why do we need to follow “the Kubernetes way” when Kubernetes was never intended to run databases?
    • How can I contact the developers?
    • What is the difference between the Operator quickstart and advanced installation ways?
    • Which versions of MongoDB the Operator supports?
    • How can I add custom sidecar containers to my cluster?
    • How to provoke the initial sync of a Pod

    Frequently Asked Questions¶

    Why do we need to follow “the Kubernetes way” when Kubernetes was never intended to run databases?¶

    As it is well known, the Kubernetes approach is targeted at stateless applications but provides ways to store state (in Persistent Volumes, etc.) if the application needs it. Generally, a stateless mode of operation is supposed to provide better safety, sustainability, and scalability, it makes the already-deployed components interchangeable. You can find more about substantial benefits brought by Kubernetes to databases in this blog post.

    The architecture of state-centric applications (like databases) should be composed in a right way to avoid crashes, data loss, or data inconsistencies during hardware failure. Percona Operator for MongoDB provides out-of-the-box functionality to automate provisioning and management of highly available MongoDB database clusters on Kubernetes.

    How can I contact the developers?¶

    The best place to discuss Percona Operator for MongoDB with developers and other community members is the community forum.

    If you would like to report a bug, use the Percona Operator for MongoDB project in JIRA.

    What is the difference between the Operator quickstart and advanced installation ways?¶

    As you have noticed, the installation section of docs contains both quickstart and advanced installation guides.

    The quickstart guide is simpler. It has fewer installation steps in favor of predefined default choices. Particularly, in advanced installation guides, you separately apply the Custom Resource Definition and Role-based Access Control configuration files with possible edits in them. At the same time, quickstart guides rely on the all-inclusive bundle configuration.

    At another point, quickstart guides are related to specific platforms you are going to use (Minikube, Google Kubernetes Engine, etc.) and therefore include some additional steps needed for these platforms.

    Generally, rely on the quickstart guide if you are a beginner user of the specific platform and/or you are new to the Percona Operator for MongoDB as a whole.

    Which versions of MongoDB the Operator supports?¶

    Percona Operator for MongoDB provides a ready-to-use installation of the MongoDB-based database cluster inside your Kubernetes installation. It works with Percona Server for MongoDB 4.2, and 4.4, and the exact version is determined by the Docker image in use.

    Percona-certified Docker images used by the Operator are listed here. For example, Percona Server for MongoDB 4.4 is supported with the following recommended version: 4.4.18-18. More details on the exact Percona Server for MongoDB version can be found in the release notes (5.0, 4.4, and 4.2).

    How can I add custom sidecar containers to my cluster?¶

    The Operator allows you to deploy additional (so-called sidecar) containers to the Pod. You can use this feature to run debugging tools, some specific monitoring solutions, etc. Add such sidecar container to the deploy/cr.yaml configuration file, specifying its name and image, and possibly a command to run:

    spec:
      replsets:
      - name: rs0
        ....
        sidecars:
        - image: busybox
          command: ["/bin/sh"]
          args: ["-c", "while true; do echo echo $(date -u) 'test' >> /dev/null; sleep 5; done"]
          name: rs-sidecar-1
        ....
    

    You can add sidecars subsection to replsets, sharding.configsvrReplSet, and sharding.mongos sections.

    Note

    Custom sidecar containers can easily access other components of your cluster. Therefore they should be used carefully and by experienced users only.

    Find more information on sidecar containers in the appropriate documentation page.

    How to provoke the initial sync of a Pod¶

    There are certain situations where it might be necessary to delete all MongoDB instance data to force the resync. For example, there may be the following reasons:

    • rebuilding the node to defragment the database,
    • recreating the member failing to sync due to some bug.

    In the case of a “regular” MongoDB, wiping the dbpath would trigger such resync. In the case of a MongoDB cluster controlled by the Operator, you will need to do the following steps:

    1. Find out the names of the Persistent Volume Claim and Pod you are going to delete (use kubectl get pvc command for PVC and kubectl get pod one for Pods).
    2. Delete the appropriate PVC and Pod. For example, wiping out the my-cluster-name-rs0-2 Pod should look as follows:

      $ kubectl delete pod/my-cluster-name-rs0-2 pvc/mongod-data-my-cluster-name-rs0-2
      

    The Operator will automatically recreate the needed Pod and PVC after deletion.

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-03-14
    Percona LLC and/or its affiliates, © 2009 - 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.