Nuno Costa

Team Lead, Technical Services

## Introduction

Hello, everyone. My name is Nuno and I have been working with MongoDB databases for almost eight years now as a sysadmin and as a Technical Services Engineer.

One of the most common challenges in MongoDB environments is when a replica set member requires a resync and the [Initial Sync](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/core/replica-set-sync/#replica-set-initial-sync) process is interrupted for some reason.

Interruptions like network partitions between the sync source and the node doing the initial sync causes the process to fail forcing it to restart from scratch to ensure database consistency.

This began to be particularly problematic when faced with a large dataset sizes which can take up to several days when they are in terms of terabytes.

You may have already noticed that I am talking in the past tense as this is no longer a problem you need to face. I am very happy to share with you one of the latest enhancements introduced by MongoDB in v4.4: [Resumable Initial Sync](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/master/release-notes/4.4/#resumable-initial-sync).

Resumable Initial Sync now enables nodes doing initial sync to survive events like transient network errors or a sync source restart when fetching data from the sync source node.

## Resumable Initial Sync

The time spent when recovering replica set members with [Initial Sync](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/core/replica-set-sync/#replica-set-initial-sync) procedures on large data environments has two common challenges:

-   Falling off the oplog
-   Transient network failures

MongoDB became more resilient to these types of failures with [MongoDB v3.4](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/v3.4/core/replica-set-sync/#initial-sync) by adding the ability to pull newly added oplog records during the data copy phase, and more recently with [MongoDB v4.4](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/master/release-notes/4.4/#resumable-initial-sync) and the ability to resume the initial sync where it left off.

## Behavioral Description

The initial sync process will restart the interrupted or failed command and keep retrying until the command succeeds a non-resumable error occurs, or a period specified by the parameter [initialSyncTransientErrorRetryPeriodSeconds](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/upcoming/reference/parameters/#mongodb-parameter-param.initialSyncTransientErrorRetryPeriodSeconds) passes (default: 24 hours). These restarts are constrained to use the same sync source, and are not tolerant to rollbacks on the sync source. That is if the  sync source experiences a rollback, the entire initial sync attempt will fail.

Resumable errors include retriable errors when `ErrorCodes::isRetriableError` return `true` which includes all network errors as well as some other transient errors.

The `ErrorCodes::NamespaceNotFound`, `ErrorCodes::OperationFailed`, `ErrorCodes::CursorNotFound`, or `ErrorCodes::QueryPlanKilled` mean the collection may have been dropped, renamed, or modified in a way which caused the cursor to be killed. These errors will cause `ErrorCodes::InitialSyncFailure` and will be treated the same as transient retriable errors (except for not killing the cursor), mark `ErrorCodes::isRetriableError` as `true`, and will allow the initial sync to resume where it left off.

On `ErrorCodes::NamespaceNotFound`, it will skip this entire collection and return success. Even if the collection has been renamed, simply resuming the query is sufficient since we are querying by `UUID`; the name change will be handled during `oplog` application.

All other errors are `non-resumable`.

## Configuring Custom Retry Period

The default retry period is 24 hours (86,400 seconds). A database administrator can choose to increase this period with the following command:

``` javascript
// Default is 86400
db.adminCommand({
    setParameter: 1,
    initialSyncTransientErrorRetryPeriodSeconds: 86400
})
```

>Note: The 24-hour value is the default period estimated for a database administrator to detect any ongoing failure and be able to act on restarting the sync source node.

## Upgrade/Downgrade Requirements and Behaviors

The full resumable behavior will always be available between 4.4 nodes regardless of [FCV - Feature Compatibility Version](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/setFeatureCompatibilityVersion/#view-fcv). Between 4.2 and 4.4 nodes, the initial sync will not be resumable during the query phase of the `CollectionCloner` (where we are actually reading data from collections), nor will it be resumable after collection rename, regardless of which node is 4.4. Resuming after transient failures in other commands will be possible when the syncing node is 4.4 and the sync source is 4.2.

## Diagnosis/Debuggability

During initial sync, the sync source node can become unavailable (either due to a network failure or process restart) and still, be able to resume and complete.

Here are examples of what messages to expect in the logs.

Initial Sync attempt successfully started:

``` none
{"t":{"$date":"2020-11-10T19:49:21.826+00:00"},"s":"I",  "c":"INITSYNC", "id":21164,   "ctx":"ReplCoordExtern-0","msg":"Starting initial sync attempt","attr":{"initialSyncAttempt":1,"initialSyncMaxAttempts":10}}
{"t":{"$date":"2020-11-10T19:49:22.905+00:00"},"s":"I",  "c":"INITSYNC", "id":21173,   "ctx":"ReplCoordExtern-1","msg":"Initial syncer oplog truncation finished","attr":{"durationMillis":0}}
```

Messages caused by network failures (or sync source node restart):

``` none
{"t":{"$date":"2020-11-10T19:50:04.822+00:00"},"s":"D1", "c":"INITSYNC", "id":21078,   "ctx":"ReplCoordExtern-0","msg":"Transient error occurred during cloner stage","attr":{"cloner":"CollectionCloner","stage":"query","error":{"code":6,"codeName":"HostUnreachable","errmsg":"recv failed while exhausting cursor :: caused by :: Connection closed by peer"}}}
{"t":{"$date":"2020-11-10T19:50:04.823+00:00"},"s":"I",  "c":"INITSYNC", "id":21075,   "ctx":"ReplCoordExtern-0","msg":"Initial Sync retrying cloner stage due to error","attr":{"cloner":"CollectionCloner","stage":"query","error":{"code":6,"codeName":"HostUnreachable","errmsg":"recv failed while exhausting cursor :: caused by :: Connection closed by peer"}}}
```

Initial Sync is resumed after being interrupted:

``` none
{"t":{"$date":"2020-11-10T19:51:43.996+00:00"},"s":"D1", "c":"INITSYNC", "id":21139,   "ctx":"ReplCoordExtern-0","msg":"Attempting to kill old remote cursor with id: {id}","attr":{"id":118250522569195472}}
{"t":{"$date":"2020-11-10T19:51:43.997+00:00"},"s":"D1", "c":"INITSYNC", "id":21133,   "ctx":"ReplCoordExtern-0","msg":"Collection cloner will resume the last successful query"}
```

Data cloners resume:

``` none
{"t":{"$date":"2020-11-10T19:53:27.345+00:00"},"s":"D1", "c":"INITSYNC", "id":21072,   "ctx":"ReplCoordExtern-0","msg":"Cloner finished running stage","attr":{"cloner":"CollectionCloner","stage":"query"}}
{"t":{"$date":"2020-11-10T19:53:27.347+00:00"},"s":"D1", "c":"INITSYNC", "id":21069,   "ctx":"ReplCoordExtern-0","msg":"Cloner running stage","attr":{"cloner":"CollectionCloner","stage":"setupIndexBuildersForUnfinishedIndexes"}}
{"t":{"$date":"2020-11-10T19:53:27.349+00:00"},"s":"D1", "c":"INITSYNC", "id":21072,   "ctx":"ReplCoordExtern-0","msg":"Cloner finished running stage","attr":{"cloner":"CollectionCloner","stage":"setupIndexBuildersForUnfinishedIndexes"}}
{"t":{"$date":"2020-11-10T19:53:27.350+00:00"},"s":"D1", "c":"INITSYNC", "id":21148,   "ctx":"ReplCoordExtern-0","msg":"Collection clone finished","attr":{"namespace":"test.data"}}
{"t":{"$date":"2020-11-10T19:53:27.351+00:00"},"s":"D1", "c":"INITSYNC", "id":21057,   "ctx":"ReplCoordExtern-0","msg":"Database clone finished","attr":{"dbName":"test","status":{"code":0,"codeName":"OK"}}}
```

Data cloning phase completes successfully. Oplog cloning phase starts:

``` none
{"t":{"$date":"2020-11-10T19:53:27.352+00:00"},"s":"I",  "c":"INITSYNC", "id":21183,   "ctx":"ReplCoordExtern-0","msg":"Finished cloning data. Beginning oplog replay","attr":{"databaseClonerFinishStatus":"OK"}}
{"t":{"$date":"2020-11-10T19:53:27.353+00:00"},"s":"I",  "c":"INITSYNC", "id":21195,   "ctx":"ReplCoordExtern-3","msg":"Writing to the oplog and applying operations until stopTimestamp before initial sync can complete","attr":{"stopTimestamp":{"":{"$timestamp":{"t":1605038002,"i":1}}},"beginFetchingTimestamp":{"":{"$timestamp":{"t":1605037760,"i":1}}},"beginApplyingTimestamp":{"":{"$timestamp":{"t":1605037760,"i":1}}}}}
{"t":{"$date":"2020-11-10T19:53:27.359+00:00"},"s":"I",  "c":"INITSYNC", "id":21181,   "ctx":"ReplCoordExtern-1","msg":"Finished fetching oplog during initial sync","attr":{"oplogFetcherFinishStatus":"CallbackCanceled: oplog fetcher shutting down","lastFetched":"{ ts: Timestamp(1605038002, 1), t: 296 }"}}
```

Initial Sync completes successfully and statistics are provided:

``` none
{"t":{"$date":"2020-11-10T19:53:27.360+00:00"},"s":"I",  "c":"INITSYNC", "id":21191,   "ctx":"ReplCoordExtern-1","msg":"Initial sync attempt finishing up"}
{"t":{"$date":"2020-11-10T19:53:27.360+00:00"},"s":"I",  "c":"INITSYNC", "id":21192,   "ctx":"ReplCoordExtern-1","msg":"Initial Sync Attempt Statistics","attr":{"statistics":{"failedInitialSyncAttempts":0,"maxFailedInitialSyncAttempts":10,"initialSyncStart":{"$date":"2020-11-10T19:49:21.826Z"},"initialSyncAttempts":[],"appliedOps":25,"initialSyncOplogStart":{"$timestamp":{"t":1605037760,"i":1}},"initialSyncOplogEnd":{"$timestamp":{"t":1605038002,"i":1}},"totalTimeUnreachableMillis":203681,"databases":{"databasesCloned":3,"admin":{"collections":2,"clonedCollections":2,"start":{"$date":"2020-11-10T19:49:23.150Z"},"end":{"$date":"2020-11-10T19:49:23.452Z"},"elapsedMillis":302,"admin.system.keys":{"documentsToCopy":2,"documentsCopied":2,"indexes":1,"fetchedBatches":1,"start":{"$date":"2020-11-10T19:49:23.150Z"},"end":{"$date":"2020-11-10T19:49:23.291Z"},"elapsedMillis":141,"receivedBatches":1},"admin.system.version":{"documentsToCopy":1,"documentsCopied":1,"indexes":1,"fetchedBatches":1,"start":{"$date":"2020-11-10T19:49:23.291Z"},"end":{"$date":"2020-11-10T19:49:23.452Z"},"elapsedMillis":161,"receivedBatches":1}},"config":{"collections":3,"clonedCollections":3,"start":{"$date":"2020-11-10T19:49:23.452Z"},"end":{"$date":"2020-11-10T19:49:23.976Z"},"elapsedMillis":524,"config.system.indexBuilds":{"documentsToCopy":0,"documentsCopied":0,"indexes":1,"fetchedBatches":0,"start":{"$date":"2020-11-10T19:49:23.452Z"},"end":{"$date":"2020-11-10T19:49:23.591Z"},"elapsedMillis":139,"receivedBatches":0},"config.system.sessions":{"documentsToCopy":1,"documentsCopied":1,"indexes":2,"fetchedBatches":1,"start":{"$date":"2020-11-10T19:49:23.591Z"},"end":{"$date":"2020-11-10T19:49:23.801Z"},"elapsedMillis":210,"receivedBatches":1},"config.transactions":{"documentsToCopy":0,"documentsCopied":0,"indexes":1,"fetchedBatches":0,"start":{"$date":"2020-11-10T19:49:23.801Z"},"end":{"$date":"2020-11-10T19:49:23.976Z"},"elapsedMillis":175,"receivedBatches":0}},"test":{"collections":1,"clonedCollections":1,"start":{"$date":"2020-11-10T19:49:23.976Z"},"end":{"$date":"2020-11-10T19:53:27.350Z"},"elapsedMillis":243374,"test.data":{"documentsToCopy":29000000,"documentsCopied":29000000,"indexes":1,"fetchedBatches":246,"start":{"$date":"2020-11-10T19:49:23.976Z"},"end":{"$date":"2020-11-10T19:53:27.349Z"},"elapsedMillis":243373,"receivedBatches":246}}}}}}
{"t":{"$date":"2020-11-10T19:53:27.451+00:00"},"s":"I",  "c":"INITSYNC", "id":21163,   "ctx":"ReplCoordExtern-3","msg":"Initial sync done","attr":{"durationSeconds":245}}
```

The new InitialSync statistics from [replSetGetStatus.initialSyncStatus](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/index.html) can be useful to review the initial sync progress status.

Starting in MongoDB 4.2.1, [replSetGetStatus.initialSyncStatus](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/index.html#replSetGetStatus.initialSyncStatus) metrics are only available when run on a member during its initial sync (i.e., [STARTUP2](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/replica-states/#mongodb-replstate-replstate.STARTUP2) state).

The metrics are:

-   [syncSourceUnreachableSince](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.initialSyncStatus.syncSourceUnreachableSince) - The date and time at which the sync source became unreachable.
-   [currentOutageDurationMillis](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.initialSyncStatus.currentOutageDurationMillis) - The time in milliseconds that the sync source has been unavailable.
-   [totalTimeUnreachableMillis](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.initialSyncStatus.totalTimeUnreachableMillis) - The total time in milliseconds that the member has been unavailable during the current initial sync.

For each Initial Sync attempt from [replSetGetStatus.initialSyncStatus.initialSyncAttempts](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.initialSyncStatus.initialSyncAttempts):

-   [totalTimeUnreachableMillis](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.initialSyncStatus.totalTimeUnreachableMillis) - The total time in milliseconds that the member has been unavailable during the current initial sync.
-   [operationsRetried](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.initialSyncStatus.initialSyncAttempts) - Total number of all operation retry attempts.
-   [rollBackId](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.initialSyncStatus.initialSyncAttempts) - The sync source's rollback identifier at the start of the initial sync attempt.

An example of this output is:

``` none
replset:STARTUP2> db.adminCommand( { replSetGetStatus: 1 } ).initialSyncStatus
{
  "failedInitialSyncAttempts" : 0,
  "maxFailedInitialSyncAttempts" : 10,
  "initialSyncStart" : ISODate("2020-11-06T20:16:21.649Z"),
  "initialSyncAttempts" : [ ],
  "appliedOps" : 0,
  "initialSyncOplogStart" : Timestamp(1604693779, 1),
  "syncSourceUnreachableSince" : ISODate("2020-11-06T20:16:32.950Z"),
  "currentOutageDurationMillis" : NumberLong(56514),
  "totalTimeUnreachableMillis" : NumberLong(56514),
  "databases" : {
      "databasesCloned" : 2,
      "admin" : {
          "collections" : 2,
          "clonedCollections" : 2,
          "start" : ISODate("2020-11-06T20:16:22.948Z"),
          "end" : ISODate("2020-11-06T20:16:23.219Z"),
          "elapsedMillis" : 271,
          "admin.system.keys" : {
              "documentsToCopy" : 2,
              "documentsCopied" : 2,
              "indexes" : 1,
              "fetchedBatches" : 1,
              "start" : ISODate("2020-11-06T20:16:22.948Z"),
              "end" : ISODate("2020-11-06T20:16:23.085Z"),
              "elapsedMillis" : 137,
              "receivedBatches" : 1
          },
          "admin.system.version" : {
              "documentsToCopy" : 1,
              "documentsCopied" : 1,
              "indexes" : 1,
              "fetchedBatches" : 1,
              "start" : ISODate("2020-11-06T20:16:23.085Z"),
              "end" : ISODate("2020-11-06T20:16:23.219Z"),
              "elapsedMillis" : 134,
              "receivedBatches" : 1
          }
      },
      "config" : {
          "collections" : 3,
          "clonedCollections" : 3,
          "start" : ISODate("2020-11-06T20:16:23.219Z"),
          "end" : ISODate("2020-11-06T20:16:23.666Z"),
          "elapsedMillis" : 447,
          "config.system.indexBuilds" : {
              "documentsToCopy" : 0,
              "documentsCopied" : 0,
              "indexes" : 1,
              "fetchedBatches" : 0,
              "start" : ISODate("2020-11-06T20:16:23.219Z"),
              "end" : ISODate("2020-11-06T20:16:23.348Z"),
              "elapsedMillis" : 129,
              "receivedBatches" : 0
          },
          "config.system.sessions" : {
              "documentsToCopy" : 1,
              "documentsCopied" : 1,
              "indexes" : 2,
              "fetchedBatches" : 1,
              "start" : ISODate("2020-11-06T20:16:23.348Z"),
              "end" : ISODate("2020-11-06T20:16:23.538Z"),
              "elapsedMillis" : 190,
              "receivedBatches" : 1
          },
          "config.transactions" : {
              "documentsToCopy" : 0,
              "documentsCopied" : 0,
              "indexes" : 1,
              "fetchedBatches" : 0,
              "start" : ISODate("2020-11-06T20:16:23.538Z"),
              "end" : ISODate("2020-11-06T20:16:23.666Z"),
              "elapsedMillis" : 128,
              "receivedBatches" : 0
          }
      },
      "test" : {
          "collections" : 1,
          "clonedCollections" : 0,
          "start" : ISODate("2020-11-06T20:16:23.666Z"),
          "test.data" : {
              "documentsToCopy" : 29000000,
              "documentsCopied" : 714706,
              "indexes" : 1,
              "fetchedBatches" : 7,
              "start" : ISODate("2020-11-06T20:16:23.666Z"),
              "receivedBatches" : 7
          }
      }
  }
}
replset:STARTUP2>
```

## Wrap Up

Upgrade your MongoDB database to the new v4.4 and take advantage of the new Resumable Initial Sync feature. Your deployment will now survive transient network errors or a sync source restarts.

> If you have questions, please head to our [developer community website](https://mongodb.prakticum-team.ru/proxy/community.mongodb.com/?_ga=2.120529611.27043229.1639402367-1887056074.1627244583) where the MongoDB engineers and the MongoDB community will help you build your next big idea with MongoDB.

Discover the new Resumable Initial Sync feature in MongoDB v4.4. It enables nodes doing initial sync to survive events like transient network errors.

Resumable Initial Sync in MongoDB 4.4

Ella Shurhavetsky

Solution Architect



<div class="introduction">

## Introduction

Systems' security plays a fundamental role in today's modern
applications. It is very important to restrict non-authorized users'
access to root capabilities. With this blog post, we intend to document
how to avoid jeopardizing root system resources, but allow authorized,
non-root users, to perform administrative operations on `mongod`
processes such as starting or stopping the daemon.

The methodology is easily extensible to other administrative operations
such as preventing non-authorized users from modifying `mongod` audit
logs.

Use this procedure for Linux based systems to allow users with
restricted permissions to stop/start/restart `mongod` processes. These
users are set up under a non-root Linux group. Further, the Linux group
of these users is different from the Linux user group under which the
`mongod` process runs.

</div>

<div class="prerequisites">

## Considerations

>
>
>WARNING: The procedure requires root access for the setup. Incorrect
>settings can lead to an unresponsive system, so always test on a
>development environment before implementing in production. Ensure you
>have a current backup of your data.
>
>

It's recommended to perform this procedure while setting up a new
system. If it is not possible, perform the procedure during the
maintenance window.

The settings will impact only one local system, thus in case of replica
set or a sharded cluster perform the procedure in a rolling matter and
never change all nodes at once.

## Tested Linux flavors

-   CentOS 6\|7
-   RHEL 6\|7
-   Ubuntu 18.04
-   Amazon Linux 2

>
>
>Disclaimer: For other Linux distributions the procedure should work in a
>similar way however, only the above versions were tested while writing
>this article.
>
>

</div>

<div class="content">

## Procedure

-   Add the user with limited permissions (replace testuser with your
    user):

``` bash
$ adduser testuser
$ groupadd testgroup
```

-   Install [MongoDB
    Community](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/administration/install-on-linux/)
    \|
    [Enterprise](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/administration/install-enterprise/)
    following our recommended procedures.
-   Edit the MongoDB configuration file `/etc/mongod.conf` permissions:

``` none
$ sudo chown mongod:mongod /etc/mongod.conf
$ sudo chmod 600 /etc/mongod.conf
$ ls -l /etc/mongod.conf
-rw-------. 1 mongod mongod 330 Feb 27 18:43 /etc/mongod.conf
```

With this configuration, only the mongod user (and root) will have
permissions to access and edit the `mongod.conf` file. No other user
will be allowed to read/write and have access to its content.

### Systems running with systemd

This procedure works for CentOS 7 and RHEL 7.

-   Add the following configuration lines to the
    [sudoers](https://www.sudo.ws/man/1.8.17/sudoers.man.html) file with
    [visudo](https://www.sudo.ws/man/1.8.13/visudo.man.html):

``` bash
%mongod ALL =(ALL) NOPASSWD: /bin/systemctl start mongod.service, /bin/systemctl stop mongod.service, /bin/systemctl restart mongod.service
%testuser ALL =(ALL) NOPASSWD: /bin/systemctl start mongod.service, /bin/systemctl stop mongod.service, /bin/systemctl restart mongod.service
```

>
>
>Note: The root user account may become non-functional if a syntax error
>is introduced in the sudoers file.
>
>

### Systems running with System V Init

This procedure works for CentOS 6, RHEL 6, Amazon Linux 2 and Ubuntu
18.04.

-   MongoDB init.d-mongod script is available on our repository
    [here](https://github.com/mongodb/mongo/blob/master/rpm/init.d-mongod)
    in case manual download is required (make sure you save it in the
    /etc/init.d/ directory with permissions set to 755).
-   Add the following configuration lines to the
    [sudoers](https://www.sudo.ws/man/1.8.17/sudoers.man.html) file with
    [visudo](https://www.sudo.ws/man/1.8.13/visudo.man.html):

For CentOS 6, RHEL 6 and Amazon Linux 2:

``` bash
%mongod ALL =(ALL) NOPASSWD: /sbin/service mongod start, /sbin/service mongod stop, /sbin/service mongod restart
%testuser ALL =(ALL) NOPASSWD: /sbin/service mongod start, /sbin/service mongod stop, /sbin/service mongod restart
```

For Ubuntu 18.04:

``` bash
%mongod ALL =(ALL) NOPASSWD: /usr/sbin/service mongod start, /usr/sbin/service mongod stop, /usr/sbin/service mongod restart
%testuser ALL =(ALL) NOPASSWD: /usr/sbin/service mongod start, /usr/sbin/service mongod stop, /usr/sbin/service mongod restart
```

>
>
>Note: The root may become non-functional if a syntax error is introduced
>in the sudoers file.
>
>

## Testing procedure

### Systems running with systemd (systemctl service)

So with these settings testuser has no permissions to read
/etc/mongod.conf but can start and stop the mongod service:

``` none
[testuser@localhost ~]$ sudo /bin/systemctl start mongod.service
[testuser@localhost ~]$ sudo /bin/systemctl stop mongod.service
[testuser@localhost ~]$ vi /etc/mongod.conf
"/etc/mongod.conf" [Permission Denied]
[testuser@localhost ~]$ sudo vi /etc/mongod.conf
"/etc/mongod.conf" [Permission Denied]
```

>
>
>Note: The authorization is given when using the `/bin/systemctl`
>command. With this procedure, the `sudo systemctl start mongod` will
>prompt the sudo password for the testuser.
>
>

### Systems running with System V Init

Use sudo service mongod \[start|stop|restart\]:

``` none
[testuser@localhost ~]$ sudo service mongod start
Starting mongod:                                           [  OK  ]
[testuser@localhost ~]$ sudo service mongod stop
Stopping mongod:                                           [  OK  ]
[testuser@localhost ~]$ vi /etc/mongod.conf
"/etc/mongod.conf" [Permission Denied]
[testuser@localhost ~]$ sudo vi /etc/mongod.conf
[sudo] password for testuser:
Sorry, user testuser is not allowed to execute '/bin/vi /etc/mongod.conf' as root on localhost.
```

>
>
>Note: Additionally, test restarting other services with the testuser
>with (and without) the required permissions.
>
>

</div>

<div class="summary">

## Wrap Up

It is one of the critical security requirements, not to give
unauthorized users full root privileges. With that requirement in mind,
it is important for system administrators to know that it is possible to
give access to actions like restart/stop/start for a `mongod` process
(or any other process) without giving root privileges, using Linux
systems capabilities.

>
>
>If you have questions, please head to our [developer community
>website](https://mongodb.prakticum-team.ru/proxy/community.mongodb.com/) where the MongoDB engineers and
>the MongoDB community will help you build your next big idea with
>MongoDB.
>
>

</div>


Secure your MongoDB installation by allowing non-root users to stop/start/restart your mongod process.

Nuno Costa

Content by Nuno Costa

Resumable Initial Sync in MongoDB 4.4

Procedure to Allow Non-Root Users to Stop/Start/Restart "mongod" Process