Database Administration

Database status
[Link]() / [Link]({ serverStatus: 1 })
Returns a document that provides an overview of the database process's state.
This command provides a wrapper around the database command serverStatus.
Behavior
By default, [Link]() excludes in its output:
some content in the repl document.
mirroredReads document.
To include fields that are excluded by default, specify the toplevel field and set it to 1 in the command. To
exclude fields that are included by default, specify the field and set to 0. You can specify either toplevel or
embedded fields.
For example, the following operation suppresses the repl, metrics and locks information in the output.
[Link]( { repl: 0, metrics: 0, locks: 0 } )
The following example includes all repl information in the output:
[Link]( { repl: 1 } )
Initialization
The statistics reported by [Link]() are reset when the mongod server is restarted. The [Link]()
command does not report some statistics until they have been initialized by server events.
For example, after restarting the mongod server, [Link]() won't return any values for findAndModify.
[Link]().[Link]
// No results returned
After you run an update query, subsequent calls to [Link]() display the expected metrics.
{
"arrayFilters" : NumberLong(0),
"failed" : NumberLong(0),
"pipeline" : NumberLong(0),
"total" : NumberLong(1)
}
Include mirroredReads
By default, the mirroredReads information is not included in the output. To return mirroredReads information,
you must explicitly specify the inclusion:
[Link]( { mirroredReads: 1 } )
Include latchAnalysis
By default, the latchAnalysis information (available starting in version 4.4) is not included in the output. To
return latchAnalysis information, you must explicitly specify the inclusion:
[Link]( { latchAnalysis: 1 } )
Output
See serverStatus Output for complete documentation of the output of this function.
Check Database Statistics:
[Link]()
This command returns statistics about the current database, such as the number of collections, objects, storage
size, etc.
Check Collection Statistics:
[Link]()
Replace collectionName with the name of the collection you want to check. This will give you stats specific to
that collection.
Replica Set Status
If you're using a replica set, you can check its status using:
[Link]()
This command provides information about each member of the replica set, including their state (primary,
secondary, etc.), health, and any errors.
Troubleshooting issues
Troubleshooting issues in MongoDB involves a range of strategies, depending on the problem you're facing.
Here are some common issues and troubleshooting steps:
1. Connection Issues
Error Message: "Failed to connect to MongoDB server" or similar.
Check:
Ensure MongoDB server is running (`mongod` process).
Verify the connection string and credentials.
Check if the MongoDB server is accessible (network issues, firewall settings).
Confirm that you're connecting to the correct port (default is 27017).
2. Authentication Failures
Error Message: "Authentication failed" or "Unauthorized".
Check:
Verify username and password.
Ensure the user has the correct roles and permissions.
Check the authentication database (`admin` or custom).
3. Performance Issues
Symptoms: Slow queries, high CPU usage.
Check:
Use the `explain` method to analyze slow queries.
Create or optimize indexes for frequently queried fields.
Monitor resource usage with `mongostat` or `mongotop`.
Review the server logs for any errors or warnings.
4. Data Consistency Problems
Symptoms: Unexpected data or data corruption.
Check:
Ensure replica set members are in sync.
Review oplog for any issues with replication.
Use `validate` command to check data integrity.
5. Disk Space Issues
Symptoms: Database crashes or fails to start.
Check:
Ensure sufficient disk space is available.
Configure and monitor disk usage thresholds.
Consider enabling WiredTiger’s compression settings to save space.
6. Indexing Issues
Symptoms: Slow queries, high latency.
Check:
Ensure indexes are created for query patterns.
Use `[Link]()` to review existing indexes.
Use `[Link]()` to remove redundant indexes.
7. Configuration Problems
Symptoms: Server crashes or behaves unexpectedly.
Check:
Verify `mongod` configuration file settings.
Ensure proper values for settings like `bindIp`, `port`, and `dbPath`.
Review any changes to configuration and restart MongoDB if necessary.
8. Network Issues
Symptoms: Connection timeouts, network errors.
Check:
Verify network connectivity between client and server.
Ensure no firewalls or security groups are blocking traffic.
Use tools like `ping` and `telnet` to check network connectivity.
Current Operations
Returns a document that contains information on inprogress operations for the database instance. The
[Link]() method wraps the database command currentOp.
Use the $currentOp aggregation stage instead of the currentOp command and its mongosh helper method
[Link]().
Syntax
[Link]() has the following form:
[Link](<operations>)
[Link]() can take the following optional argument:
Behavior
[Link]() can accept a filter document or a boolean parameter.
If you pass a filter document to [Link](), the output returns information only for the current operations
that match the filter.
[Link](true)
[Link]( { "$all": true } )

Users and Roles

Users
Creating Users:
You can create users with specific roles that define their permissions. Users are typically created in the admin
database or in specific databases where they will have access.
Create User:
[Link]({
user: "myUser",
pwd: "myPassword",
roles: [ "readWrite", "dbAdmin" ]
});
Create User with Specific Roles:
[Link]( { user: "root", pwd: “root@123”, roles: [ { role: "root", db: "admin" } ] })
Listing Users:
You can list users in a specific database or in the admin database.
List Users in Current Database:
[Link]();

List Users in admin Database:

use admin;
[Link]();
Dropping Users:
You can drop users if they are no longer needed.
Drop User:
[Link]("myUser");

Roles
Builtin Roles:
MongoDB comes with several builtin roles with predefined permissions. Some of the common roles include:
Database Roles:
read: Grants read access to a database.
readWrite: Grants read and write access to a database.
dbAdmin: Grants administrative access to a database.
Cluster Roles:
clusterAdmin: Grants administrative access to the entire cluster.
clusterMonitor: Allows monitoring of the cluster state.
backup: Allows backup operations.
Creating Custom Roles:
You can create custom roles with specific privileges tailored to your needs.
Create Custom Role:
[Link]({
role: "customRole",
privileges: [
{
resource: { db: "myDatabase", collection: "" },
actions: [ "find", "update" ]
}
],
roles: []
});

Assigning Roles:
When creating or updating a user, you can assign roles to define what the user can do.
Assign Roles to User:
[Link]("myUser", {
roles: [ "read", "customRole" ]
});

Listing Roles:
You can list roles within a database or cluster.
List Roles in a Database:
[Link]();

List All Roles in the Cluster:

use admin;
[Link]({ showBuiltinRoles: true });

Dropping Roles:
You can drop custom roles if they are no longer needed.
Drop Custom Role:
[Link]("customRole");

Explain Plan
In MongoDB, the Explain Plan is equally important as it provides insights into how queries are executed. This
is crucial for optimizing queries and understanding how MongoDB processes them, which can help improve
performance.
Why Explain Plan is Required
➢ Understanding Query Execution
➢ Performance Optimization
➢ Index Usage Analysis
➢ Identifying Scans and Joins
➢ Resource Utilization Insights
➢ Guidance for Schema Design
➢ Many More
[Link]("executionStats") methods provide statistics about the performance of a query. These
statistics can be useful in measuring if and how a query uses an index.
explain() returns the following results:
1. Query Planner Section:
Winning Plan: The winning Plan shows that the query is using an index or collection. This indicates that
MongoDB is using an index to find results instead of performing a full collection scan.
Stages: The stages show that the query is first using an IXSCAN (Index Scan) or COLLSCAN (collection
scan) to find the matching entries based on the index or collection, followed by a FETCH stage to retrieve the
full documents.
2. Execution Stats Section:
nReturned: The number of documents returned by the query (5).
executionTimeMillis: The time taken to execute the query (0 ms),
totalKeysExamined: The number of index keys examined (10), which indicates that only a small number of
keys were checked.
totalDocsExamined: The number of documents that were examined in the collection (5). Since this number
matches nReturned, it suggests that the query is efficient.

Profiler
MongoDB profiling helps you monitor and analyze database operations to identify performance bottlenecks and
inefficient queries. Profiling captures details about query execution times and the operations being performed,
which is useful for diagnosing performance issues.
Types of Profiling in MongoDB
MongoDB provides two types of profiling:
1. Database Profiling: Captures detailed information about operations at the database level.
2. Application Profiling: Provides insights into how the application interacts with MongoDB, though this is
generally done through logging and applicationlevel instrumentation.
Enabling and Configuring Profiling
# 1. Database Profiling Levels
You can set the profiling level at the database level to capture different levels of detail:
`0`: Profiling is off. No profiling data is collected.
`1`: Captures slow operations only (defined by a threshold).
`2`: Captures all operations.
To set the profiling level, use the `[Link]()` command:
[Link](level, slowms)

`level`: The profiling level (`0`, `1`, or `2`).

`slowms`: For level `1`, the minimum execution time (in milliseconds) for an operation to be logged. For level
`2`, this parameter is ignored.

Example: Set profiling to capture operations slower than 100 milliseconds:

[Link](1, 100)

Example: Enable full profiling (capture all operations):

[Link](2)

# 2. Viewing Profiling Data

MongoDB stores profiling data in the `[Link]` collection within each database. You can query this
collection to view profiling information.

[Link]().pretty()

Querying Slow Operations:

[Link]({ "millis": { "$gt": 100 } }).sort({ "ts": 1 }).pretty()

Example Fields in `[Link]`:

`op`: The type of operation (e.g., `query`, `insert`, `update`, `delete`).
`ns`: Namespace (database and collection).
`millis`: Time taken to execute the operation (in milliseconds).
`query`: The query object (for `query` operations).
`command`: The command object (for commands).

Profiling Commands
# 1. View Current Profiling Level
[Link]()

# 2. Get Profiling Data with Filter

You can use the following commands to get profiling data filtered by time ranges, operation types, etc.
Get operations taking longer than 200 ms:
[Link]({ millis: { $gt: 200 } }).sort({ ts: 1 })
Get operations from the last 1 hour:
var oneHourAgo = new Date([Link]() 60*60*1000);
[Link]({ ts: { $gte: oneHourAgo } }).sort({ ts: 1 })

Profiling and Indexing

Profiling can help identify queries that are not using indexes effectively. For example, if you see a lot of
collection scans in the profiling data, it may indicate that indexes are missing or not used efficiently.
Performance Considerations
Impact on Performance: Enabling full profiling (level `2`) can impact database performance due to the
overhead of recording detailed information. Use it selectively and consider disabling it once profiling is
complete.
Retention: Profiling data can grow quickly. Monitor the size of the `[Link]` collection and set up
processes to archive or clean up old profiling data if needed.

Using Profiling Data

Profiling data can be used to:
Identify Slow Queries: Look for operations with high execution times and optimize them.
Analyze Query Patterns: Understand how different queries are performing.
Improve Indexes: Determine if certain queries could benefit from additional indexes.