Charmed MongoDB Tutorial (replica set) | 4. Scale your replicas

Charmed MongoDB Tutorials > Deploy a replica set > 4. Scale your replicas

Scale your replicas

A replica set in MongoDB is a group of processes that copy stored data in order to make a database highly available. Replication provides redundancy, which means the application can provide self-healing capabilities in case one replica fails.

Disclaimer: This tutorial hosts all replicas on the same machine. This should never be done in a production environment.

To enable high availability in a production environment, replicas should be hosted on different servers to maintain isolation.

Summary


Add replicas

You can add two replicas to your deployed MongoDB application with:

juju add-unit mongodb -n 2

It usually takes several minutes for the replicas to be added to the replica set. You’ll know that all three replicas are ready when juju status --watch 1s reports:

Model     Controller  Cloud/Region         Version  SLA          Timestamp
tutorial  overlord    localhost/localhost  3.1.6   unsupported  14:42:04Z

App      Version  Status  Scale  Charm    Channel   Rev  Exposed  Message
mongodb           active      3  mongodb  5/edge   96  no       Replica set primary

Unit        Workload  Agent  Machine  Public address  Ports      Message
mongodb/0*  active    idle   0        10.23.62.156    27017/tcp  Replica set primary
mongodb/1   active    idle   1        10.23.62.55     27017/tcp  Replica set secondary
mongodb/2   active    idle   2        10.23.62.243    27017/tcp  Replica set secondary

Machine  State    Address       Inst id        Series  AZ  Message
0        started  10.23.62.156  juju-d35d30-0  jammy       Running
1        started  10.23.62.55   juju-d35d30-1  jammy       Running
2        started  10.23.62.243  juju-d35d30-2  jammy       Running

If you wanted to verify the replica set configuration, you could connect to MongoDB via charmed-mongodb.mongo. Since your replica set has 2 additional hosts, you will need to update the hosts in your URI. You can retrieve these host IPs with:

export HOST_IP_1=$(juju show-unit mongodb/1 | awk '/public-address:/{print $NF;exit}')
export HOST_IP_2=$(juju show-unit mongodb/2 | awk '/public-address:/{print $NF;exit}')

Then recreate the URI using your new hosts and reuse the username, password, database name, and replica set name that you previously used when you first connected to MongoDB:

export URI=mongodb://$DB_USERNAME:$DB_PASSWORD@$HOST_IP,$HOST_IP_1,$HOST_IP_2/$DB_NAME?replicaSet=$REPL_SET_NAME

Now view and save the output of the URI:

echo $URI

Like earlier, we access mongo by sshing into one of the Charmed MongoDB hosts:

juju ssh mongodb/0

While sshd into mongodb/0, we can access mongo with charmed-mongodb.mongo, using our new URI that we saved above.

charmed-mongodb.mongosh <saved URI>

Now, run rs.status() and you should see your replica set configuration. The first few lines should look something like this:

{
  set: 'mongodb',
  date: ISODate("2022-12-02T14:39:52.732Z"),
  myState: 1,
  term: Long("1"),
  syncSourceHost: '',
  syncSourceId: -1,
  heartbeatIntervalMillis: Long("2000"),
  majorityVoteCount: 2,
  writeMajorityCount: 2,
  votingMembersCount: 3,
  writableVotingMembersCount: 3,
  optimes: {
    lastCommittedOpTime: { ts: Timestamp({ t: 1669991990, i: 1 }), t: Long("1") },
    lastCommittedWallTime: ISODate("2022-12-02T14:39:50.020Z"),
    readConcernMajorityOpTime: { ts: Timestamp({ t: 1669991990, i: 1 }), t: Long("1") },
    appliedOpTime: { ts: Timestamp({ t: 1669991990, i: 1 }), t: Long("1") },
    durableOpTime: { ts: Timestamp({ t: 1669991990, i: 1 }), t: Long("1") },
    lastAppliedWallTime: ISODate("2022-12-02T14:39:50.020Z"),
    lastDurableWallTime: ISODate("2022-12-02T14:39:50.020Z")
  },

  ...

Return to original shell

Leave the MongoDB shell by typing exit.

You will be back in the host of Charmed MongoDB (mongodb/0). Exit this host by typing exit again.

You should now be at the original shell where you can interact with Juju and LXD.

Remove replicas

Removing a unit from the application scales the replicas down. Before we scale down the replicas, list all the units with juju status, here you will see three units mongodb/0, mongodb/1, and mongodb/2. Each of these units hosts a MongoDB replica.

To remove the replica hosted on the unit mongodb/2 enter:

juju remove-unit mongodb/2

You’ll know that the replica was successfully removed when juju status --watch 1s reports:

Model     Controller  Cloud/Region         Version  SLA          Timestamp
tutorial  overlord    localhost/localhost  3.1.6   unsupported  14:44:25Z

App      Version  Status  Scale  Charm    Channel   Rev  Exposed  Message
mongodb           active      2  mongodb  5/edge   96  no       Replica set primary

Unit        Workload  Agent  Machine  Public address  Ports      Message
mongodb/0*  active    idle   0        10.23.62.156    27017/tcp  Replica set primary
mongodb/1   active    idle   1        10.23.62.55     27017/tcp  Replica set secondary

Machine  State    Address       Inst id        Series  AZ  Message
0        started  10.23.62.156  juju-d35d30-0  jammy       Running
1        started  10.23.62.55   juju-d35d30-1  jammy       Running

You can also see that the replica was successfully removed by using the new URI (where the removed host has been excluded).

Next step: 5. Manage passwords

Hello Nick,

Thank you for this tutorial! I successfully set up the Charmed MongoDB cluster using it and can log in to the cluster with charmed-mongodb.mongosh using the URI mongodb://operator:<password>@<HOST_IP>,<HOST_IP1>,<HOST_IP2>/admin?replicaSet=mongodb.

Could you please provide guidance or a link to documentation that can help me connect to this cluster from outside the network, e.g. using MongoDB Compass?

Thank you!

Thanks!

1 Like

Hi @sanjay-l! It’s great that you are using Charmed MongoDB successfully, I hope you are finding it easy to find the information you need. An external connection should be also possible, but I’d like to tag in @avgomes who has more current experience with this charm

@evilnick I was able to find the necessary information without much trouble. I’ll wait for further guidance from @avgomes.

Thanks.

Hi @sanjay-l , thank you for your comment - it’s really helpful to hear about use cases that aren’t entirely covered by the documentation. Now we know a good way to improve it :slight_smile:

Unfortunately I can’t answer your question myself, but I’ve been in touch with the team and one of our engineers will get back to you soon with more details about using external IPs.

1 Like

Hi @sanjay-l thanks for your interest in Charmed MongoDB clients in external network should connect only via exposed mongos

To connect with an exposed mongos you will need to deploy a sharded Charmed MongoDB cluster with a Charmed mongos application.

Please follow steps 1-6 of the sharded cluster tutorial to achieve this set up :slight_smile:

2 Likes

@sanjay-l As Mia pointed out, the main way to do so is to deploy a sharded cluster and use mongos along with the data integrator charm (if you don’t already have a juju client app) and expose mongos publicly (through security groups in AWS for ex).

Another way if Charmed MongoDB is deployed within a private / internal network, you could first connect to your VPN (if any, in case of corporate networks for ex), then open an ssh tunnel connection to the MongoDB cluster. This would allow you to directly consume mongodb using the private IPs from your local MongoDB compass client.

2 Likes

Thanks @medib. I will check this out and get back, in case of any queries.

Thank you for adding this additional context to the answer Mehdi :pray: Greatly appreciate this context.

One last thing, is that when the mongos charm is not integrated to the data-integrator charm, it communicates via the unix domain socket, which I do not think will be reachable from outside. You can read about why we went with this design in this explaination

However, when you integrate the mongos charm with the data-integrator charm it communicates via a port and should be reachable outside of a cluster (once exposed public via security groups). Step 6 of the tutorial I linked uses mongos with the data-integrator charm.