Questions about Mongo Sidecar, replica sets, and nodes requirements

Support
1

Hi Sebastian,

I’m planning on migrating from 1 mongodb instance to 3 instances (replica set) on a single node.

I was reading the docs and came across the following in the forums:

The cluster (aka replica set) is hosted in kubernetes. When I started with the replica set it was configured with a sidecar. This sidecar is a special container which scans kubernetes for MongoDB instances and connects them to a replica set. It was the way to go a few years ago, but is not recommended anymore, because during updates and down times the replica set gets reconfigured all the time, making updates much harder in some cases. The idea of this sidecar is to make scaling easier, as you can increase the number of nodes and everything will be configured automatically. But in practice this does almost never happens.

The sentence

It was the way to go a few years ago, but is not recommended anymore

caught my attention.

  1. What do I use today instead of the Sidecar (cvallance/mongo-k8s-sidecar)?

  2. When using a replica set do I have to use 3 nodes or can I use just 1 node? The reason I ask is because I don’t want to pay for more than 1 node at the moment. I don’t have that much traffic and it would be a waste of money paying for 3 nodes.

  3. How would I configure my connection string if I were to use only 1 node (if I were to use cvallance/mongo-k8s-sidecar)?

Currently I have it configured like this (I use 1 node and 1 StatefulSet replica):

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: mongo
spec:
  serviceName: "mongo"
  replicas: 1
.
.
.
.
        - name: ASSETSTORE__MONGODB__CONFIGURATION
          value: "mongodb://mongodb-sts-0.mongodb-svc:27017/"

        - name: EVENTSTORE__MONGODB__CONFIGURATION
          value: "mongodb://mongodb-sts-0.mongodb-svc:27017/"

        - name: STORE__MONGODB__CONFIGURATION
          value: "mongodb://mongodb-sts-0.mongodb-svc:27017/"
.
.
.

Would the following be the correct configuration for the replicas and connection strings?

    apiVersion: apps/v1beta1
    kind: StatefulSet
    metadata:
      name: mongo
    spec:
      serviceName: "mongo"
      replicas: 3
    .
    .
    .
    .
            - name: ASSETSTORE__MONGODB__CONFIGURATION
              value: "mongodb://mongodb-sts-0.mongodb-svc,mongodb-sts-1.mongodb-svc,mongodb-sts-2.mongodb-svc:27017/"

            - name: EVENTSTORE__MONGODB__CONFIGURATION
              value: "mongodb://mongodb-sts-0.mongodb-svc,mongodb-sts-1.mongodb-svc,mongodb-sts-2.mongodb-svc:27017/"

            - name: STORE__MONGODB__CONFIGURATION
              value: "mongodb://mongodb-sts-0.mongodb-svc,mongodb-sts-1.mongodb-svc,mongodb-sts-2.mongodb-svc:27017/"

Thanks!

2

  1. I have configured it manually as described in the MongoDB docs. You have to add a replica set name to the config and then rs.initiate() once: https://docs.mongodb.com/manual/tutorial/deploy-replica-set/

  2. Yes, you can, I also recommend it because it enables change streams which can be leveraged by Squidex for event pulling and is faster.

  3. Your configuration looks fine.

3

@Sebastian have you seen this? (Community Operator)

Do you think it could work with Squidex?

Just saw the video and it looks promising. Will be trying it out soon.

1 Like
4

Hi Sebastian,

Is it possible to use just ONE persistent volume instead THREE? Is this the setup you have in your own production environment on GKE?

According to https://github.com/Squidex/squidex-docker/blob/master/standalone/kubernetes/mongodb/README.md you can dynamically provision 3 separate PersistentVolumes with each bound to a unique PersistentVolumeClaim:

$ kubectl get pvc         
NAME                               STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
mongo-persistent-storage-mongo-0   Bound     pvc-af87f9d5-d3ab-11e6-8cf2-42010af0018d   100Gi      RWO           12m
mongo-persistent-storage-mongo-1   Bound     pvc-af8cef48-d3ab-11e6-8cf2-42010af0018d   100Gi      RWO           12m
mongo-persistent-storage-mongo-2   Bound     pvc-af8f1d24-d3ab-11e6-8cf2-42010af0018d   100Gi      RWO           12m

The problem I’m trying to solve is:

  1. I want to have just ONE PersistentVolume
  2. I want to be able to BACKUP that PersistentVolume in Azure using az snapshot create:

az snapshot create -g myResourceGroup -n theNameOfTheSnapshot --source /subscriptions/<guid>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/disks/my-squidex-data-disk

I am looking into a MongoDB Backup strategy as well, but that’s another topic.

5

No, this does not work. Neither kubernetes nor MongoDB supports it.

6

Thanks, did not know that.

Pasting relevant URL:s for reference:


7

Hi Sebastian,

Regarding whether to use 1 node, 3 nodes, or more. The following go me thinking:

Yes, you can, I also recommend it because it enables change streams which can be leveraged by Squidex for event pulling and is faster.

As I mentioned earlier I’m using 1 node at the moment which is fine for my workloads.

But in the future if the site grows significantly and I need to increase the number of nodes; will I need to consider configuring Squidex/Mongo in a different manner? If so, how?

Thanks!

8

For normal workloads event streams are not that important. They are only useful for the background processes but not for any queries. I would just keep it like it is for now. Mongo replicas are useful for failover but a lot of queries still have to go to the primary so far.

9

Okay. Not sure I understand the part about event streams but I’m keeping my config as it is for now. Thanks.

10

One final question.

Do you use the --oplog and --oplogReplay when you run mongodump and mongorestore?

11

No, I don’t. Fortunenatly I only need mongodump to reproduce bugs :wink: