Server Administration practice questions

The instance will use 7.5GB for the WiredTiger cache.

Why it fails: This value represents the default calculation (50% of 16GB minus 1GB) that MongoDB would use if the cacheSizeGB parameter was omitted. Since the configuration file explicitly defines a size of 2GB, the default calculation is ignored by the storage engine during the initialization of the WiredTiger process.

The total resident memory (RSS) will not exceed 2GB.

Why it fails: WiredTiger's cache size only accounts for the internal storage engine cache, not the total memory consumed by the mongod process. The process will also use memory for connections, aggregations, and the filesystem cache. Therefore, the total resident memory will almost always exceed the 2GB limit specified in the configuration.

The mongod process will fail to start due to a memory mismatch.

Why it fails: Setting a cache size lower than the default is a valid configuration and will not prevent the server from starting. MongoDB does not enforce a minimum cache size relative to system RAM, though performance may suffer if the cache is too small to hold the working set of the database.

Performing a daily mongodump with the --gzip flag.

Why it fails: While mongodump is useful for smaller datasets, it is inefficient for 2TB databases because it must read every document and rebuild all indexes upon restoration. This leads to extremely long recovery times that usually exceed production SLAs, making it an inferior choice for large-scale point-in-time recovery scenarios.

Scheduling a weekly mongorestore to a staging environment.

Why it fails: Restoring to a staging environment is a good practice for testing backups but is not a strategy for achieving point-in-time recovery in production. It does not address the need to capture and replay real-time changes, and the weekly frequency is insufficient for most modern recovery point objectives (RPO).

Running the repairDatabase command after every write operation.

Why it fails: The repairDatabase command is not a backup or recovery strategy; it is a tool used to recover data from a corrupted standalone mongod. Running it after every write would cause massive performance degradation and provide no benefit for point-in-time recovery, as it does not create a historical record of data states.

Upgrade the primary node first to ensure new features are available.

Why it fails: Upgrading the primary first is dangerous because if the primary fails after the upgrade, the secondaries (still on the old version) might not be able to elect a new primary or replicate data correctly. Standard procedure always dictates upgrading secondaries before stepping down the primary for its own upgrade.

Disable all indexes on the collection before starting the upgrade.

Why it fails: Disabling indexes is not required for a MongoDB version upgrade and would cause massive performance issues as all queries become collection scans. MongoDB is designed to handle index compatibility across consecutive major versions during a rolling upgrade without requiring any manual index intervention from the administrator.

Run 'db.upgrade()' from the admin database on each node.

Why it fails: There is no 'db.upgrade()' command in MongoDB. The upgrade process involves replacing the binaries and then updating the 'featureCompatibilityVersion' once all members are on the new version. The server handles internal data format changes automatically as part of the startup and reconciliation process.

Increase the 'wiredTiger.engineConfig.cacheSizeGB' value to consume all available system RAM.

Why it fails: Allocating all system RAM to the WiredTiger cache is dangerous because it leaves no memory for the operating system, network buffers, or other processes. This leads to heavy paging and system instability, potentially causing the OS to kill the MongoDB process via the OOM killer when memory requests fail.

Enable the 'net.compression.snappy' setting to reduce memory footprint.

Why it fails: Compression settings affect the data stored on disk and the network traffic, but they do not directly control the size of the WiredTiger cache. While compression reduces I/O pressure, it does not solve the underlying issue of the cache reaching its maximum allowed size within RAM limitations.

Set 'storage.journal.enabled' to false to free up cache space.

Why it fails: Disabling journaling removes the write-ahead log, which is essential for crash recovery and data durability. This does not impact the size of the WiredTiger cache and exposes the database to potential data loss in the event of a system crash, violating best practices for server administration.

Perform a manual copy of the data files while the server is running.

Why it fails: Simply copying data files while the server is running will result in an inconsistent backup. Because the server is continuously modifying data, the resulting files will be in an invalid state, making it impossible to restart a database from those files after a restore attempt.

Stop the mongod process and copy the contents of the 'dbPath'.

Why it fails: While this method creates a consistent backup, it fails the requirement to perform the backup 'without stopping the service'. Stopping the mongod process causes an outage, which is unacceptable in environments that require high availability and continuous access to the database throughout the entire backup procedure.

Use the 'mongorestore' utility to stream data to a remote server.

Why it fails: The 'mongorestore' utility is designed to import data into a MongoDB instance, not to perform backups. Using it for this purpose is logically incorrect and does not address the need to capture a consistent, point-in-time representation of the current state of a running production database.

Immediately delete the /var/lib/mongodb directory.

Why it fails: Deleting the data directory before ensuring the node is fully decommissioned and the data is archived is risky. It is better to verify the node is fully removed and the remaining set is healthy before permanently destroying the local data files on the decommissioned server instance.

Force a primary election before removal.

Why it fails: Forcing an election is not a standard decommissioning step and can cause unnecessary downtime for the application. If the node to be removed is a secondary, it can be removed without affecting the primary. If it is a primary, it will step down automatically upon removal, ensuring smooth transitions.

The write operation will be faster than with 'w: 1'.

Why it fails: Majority write concern is slower than 'w: 1' because it requires multiple nodes to acknowledge the write before the client proceeds. The additional network round-trips and disk I/O required for secondary nodes to process the write naturally increase the latency compared to waiting only for the primary's acknowledgement.

It forces the data to be written directly to the disk cache.

Why it fails: The 'w' parameter in write concern relates to replication acknowledgment, not disk-level caching. The 'j' (journaling) parameter controls whether the write is flushed to disk. A majority write concern ensures consensus among nodes, but it does not dictate the low-level behavior of the storage engine's write cache.

It automatically enables read-your-writes consistency for all reads.

Why it fails: Majority write concern alone does not guarantee read-your-writes consistency. For that, you also need to use an appropriate read concern, such as 'majority' or 'snapshot', to ensure the client reads the data that was written. Write concern only governs the acknowledgement of the write operation itself by the cluster.

mongodump

Why it fails: The 'mongodump' utility is used for creating logical backups of data. It performs a query-based export and does not check the physical integrity of the underlying data files on the disk. It is not an administrative tool for validating the health of the WiredTiger storage engine or data files.

mongofiles

Why it fails: The 'mongofiles' utility is used to interact with GridFS, a specification for storing and retrieving large files in MongoDB. It is unrelated to database engine integrity, storage file verification, or the health of the WiredTiger engine, and cannot be used to diagnose or repair corruption in the data files.

mongostat

Why it fails: The 'mongostat' utility is a performance monitoring tool that shows real-time metrics such as operation counts, cache usage, and memory pressure. It is not designed to inspect data files or perform any form of integrity verification. It cannot identify corruption, check metadata, or perform any repair-related administrative tasks.

Restart the mongod service.

Why it fails: Restarting the service will rotate logs but also causes a brief outage for the application. In a production environment, this is highly disruptive and unnecessary, as there are methods like sending a POSIX signal to trigger rotation that achieve the same result without interrupting the availability of the database service.

Manually delete the current log file while the service is running.

Why it fails: Manually deleting the log file while the process is running is a bad practice. The operating system will hold the file descriptor, and the disk space will not be freed until the process is restarted. Additionally, the process might stop logging altogether if it loses track of the handle.

Update the 'systemLog.path' in the config file.

Why it fails: Changing the configuration path does not automatically rotate logs. The process will continue writing to the old file until it is restarted. This approach is not a valid administrative way to manage log rotation, as it requires a restart to take effect, which contradicts the goal of non-disruptive management.

The write concern 'majority' is calculated based on the number of data-bearing members, which excludes arbiters.

Why it fails: While it's true that majority is based on voting members and arbiters do not store data, this is not the cause of increased latency. The scenario does not mention arbiters. The latency is due to the network delay to a secondary that may be needed to achieve the majority.

The primary must wait for all secondaries to acknowledge before returning.

Why it fails: Majority write concern does not require all members to acknowledge; it requires a majority of voting members. In a three-member set, that is two members. Waiting for all would be write concern 'all' (or {w: 3}). The primary does not wait for all secondaries, only for enough to satisfy the majority.

Secondary2 is the only member that can satisfy the majority write concern.

Why it fails: Any secondary can contribute to the majority. The primary itself counts toward the majority. The write concern is satisfied when the primary and at least one secondary have acknowledged. There is no restriction that only a specific secondary can satisfy the majority.

rs.freeze(120)

Why it fails: rs.freeze() prevents a member from becoming primary for a specified period. It is typically run on a secondary to keep it from being elected. Running it on the primary does not step down the primary; it would prevent that member from becoming primary again if it steps down, but it does not initiate a step down.

Restart mongod with --shutdown

Why it fails: --shutdown is not a valid mongod startup option. To shut down mongod, you use db.shutdownServer() or send a SIGTERM signal. Restarting with an invalid option will cause mongod to fail to start. This is not a method to step down a primary.

db.shutdownServer()

Why it fails: db.shutdownServer() shuts down the mongod process. While this will cause the primary to become unavailable and trigger an election, it is not a graceful step down. It abruptly stops the server, which may cause an unclean shutdown and is not recommended for maintenance if you want to avoid downtime.

mongod --dbpath /data/db --wiredTigerCacheSizeGB 1 --auth

Why it fails: This command sets the storage engine cache size and authentication but does not specify the port, so it would default to 27017. However, it also does not include `--fork`, and the scenario requires ensuring the port is 27017. The explicit port setting is missing, making this option incomplete for the stated requirements.

mongod --dbpath /data/db --port 27017 --auth

Why it fails: While this command sets the correct port and authentication, it omits the `--fork` flag. Without `--fork`, mongod runs in the foreground, which may not be suitable for a production restart where the process should run as a daemon. The requirement does not explicitly mention daemon mode, but in typical administrative restarts, background execution is expected.

mongod --config /etc/mongod.conf --fork

Why it fails: Using `--config` assumes a configuration file exists, but the scenario states the configuration file is unavailable. This command would fail if the file is missing, and it does not explicitly set the required parameters like `--auth` or `--port`. It relies on the file for settings, which is not an option here.

Add an arbiter to the replica set to break ties faster.

Why it fails: Adding an arbiter can allow elections in even-numbered sets, but it does not speed up failure detection. The election timeout still governs how long members wait before starting an election. Also, the scenario says you should not change the topology, so adding an arbiter violates that constraint and does not directly reduce the failover window.

Set the writeConcern majority on all application writes.

Why it fails: Increasing write concern to majority improves durability and consistency, but it does not make the election happen faster. In fact, writes may wait longer because they must be acknowledged by a majority of voting members. It does not address the delay in detecting primary failure, so it would not reduce the duration of 'not primary' errors during failover.

Increase the oplog size on all replica set members.

Why it fails: Oplog size affects how far a secondary can fall behind before requiring a full resync. It has no effect on how quickly an election is triggered after a primary becomes unavailable. Increasing the oplog might help avoid resync in some scenarios, but it does not reduce client write errors during a failover event.

Run the compact command on all collections to release unused space.

Why it fails: The compact command defragments collection data and releases disk space, but it does not directly reduce process memory usage. It can temporarily increase memory usage during operation. While compaction can improve disk I/O, it is not the primary tool for addressing excessive resident memory in a running mongod process.

Set the tcmallocReleaseRate parameter to 0 to force immediate memory release.

Why it fails: tcmallocReleaseRate controls how aggressively the allocator returns memory to the OS. Setting it to 0 disables release, which would make memory usage worse, not better. Even a higher release rate may not fully solve fragmentation issues. This parameter is not a direct solution for an already unresponsive server and is not the recommended first action.

Restart mongod with a smaller --wiredTigerCacheSizeGB value.

Why it fails: Reducing the WiredTiger cache size can actually increase I/O pressure because more data must be read from disk. The scenario describes high resident memory that exceeds the cache size, which often indicates memory fragmentation or other allocations outside the cache. Simply shrinking the cache does not address the root cause and may degrade performance further by causing more evictions.

Set `arbiterOnly` to true for one member.

Why it fails: An arbiter is a member that participates in elections but does not store data. While an arbiter can help maintain a majority in a two-member set, it does not provide data redundancy. In a three-member set, adding an arbiter instead of a full data-bearing member reduces fault tolerance for data. The requirement is to tolerate one member failure without losing election capability, but an arbiter does not contribute to data durability.

Set `hidden` to true for one member.

Why it fails: A hidden member is not visible to clients and cannot become primary, but it still can vote. Hiding a member does not affect the replica set's ability to elect a primary after a failure; it only changes visibility and eligibility for reads. This setting is unrelated to fault tolerance for elections.

Set `priority` to 1 for all members.

Why it fails: Priority determines the likelihood of a member being elected primary but does not affect the replica set's ability to elect a primary after a failure. With three members, as long as a majority (two) are available, an election can occur regardless of priority. Setting priority to 1 for all members does not guarantee fault tolerance; it only equalizes election chances.

rs.add({ host: 'newhost:27017', hidden: true, priority: 0, secondaryDelaySecs: 3600 })

Why it fails: This command uses secondaryDelaySecs instead of slaveDelay. In MongoDB, the correct field for delayed members is slaveDelay (in MongoDB 3.4 and later, it is still slaveDelay; in MongoDB 5.0, it was renamed to secondaryDelaySecs). However, for the C100DBA exam, which may be based on an older version, slaveDelay is the expected field. But the exam could be on a newer version. To be safe, I will assume the exam uses slaveDelay as the standard. Therefore, secondaryDelaySecs is incorrect for this exam. The correct field is slaveDelay. (Explanation length: 68 words)

rs.add({ host: 'newhost:27017', hidden: true, priority: 0, delay: 3600 })

Why it fails: This command uses delay instead of slaveDelay. The correct field name for specifying a delayed secondary is slaveDelay (or secondaryDelaySecs in newer versions). The field delay is not recognized by MongoDB and will be ignored or cause an error. Therefore, the member would not be configured with a delay, failing the requirement. The DBA must use the correct field name to achieve the delayed backup functionality. (Explanation length: 58 words)

rs.add('newhost:27017'); rs.reconfig({ _id: 'rs0', members: [ { _id: 0, host: 'existing1:27017' }, { _id: 1, host: 'existing2:27017' }, { _id: 2, host: 'existing3:27017' }, { _id: 3, host: 'newhost:27017', hidden: true, priority: 0, slaveDelay: 3600 } ] })

Why it fails: This sequence first adds the member without the desired properties, then attempts to reconfigure the entire replica set with a manually specified configuration. This approach is error-prone because the DBA must include all existing members exactly as they are, and any mistake could break the replica set. Additionally, the initial rs.add would add the member as a regular secondary, and then the reconfig would change it. It works but is not the recommended single-step method. The rs.add command can accept the full configuration directly, making this two-step process unnecessary and risky. (Explanation length: 78 words)

Each shard must have at least one secondary with zero replication lag.

Why it fails: While replication lag should be minimal for a smooth upgrade, there is no strict requirement that a secondary must have zero lag. The upgrade process involves taking members down one at a time, and as long as the replica set can maintain a majority, it can proceed. Zero replication lag is ideal but not a mandatory prerequisite.

All clients must be upgraded to the MongoDB 5.0 drivers.

Why it fails: Client drivers do not need to be upgraded before the server upgrade. MongoDB maintains backward compatibility with older drivers for a period. While it is good practice to upgrade drivers eventually, it is not a prerequisite for the server upgrade itself. Clients can continue to connect using older drivers during and after the upgrade.

The balancer must be stopped before upgrading any shard.

Why it fails: While it is recommended to stop the balancer during certain maintenance operations, it is not a strict prerequisite for a version upgrade. The MongoDB documentation advises that the balancer can remain running during a rolling upgrade, but it may be paused to avoid unnecessary chunk migrations. However, it is not a mandatory requirement for the upgrade to proceed.

security.authorization set to enabled

Why it fails: security.authorization enables role-based access control for clients. While important for security, it is not directly related to TLS or internal x.509 authentication. The scenario focuses on transport encryption and member authentication, not on client authorization. Enabling authorization is good practice but does not fulfill the specific requirements described.

net.tls.CAFile set to the CA certificate path

Why it fails: net.tls.CAFile specifies the certificate authority file used to validate certificates presented by clients and members. While necessary for TLS to function, it is not the option that enables TLS or x.509 authentication; it is a supporting parameter. The question asks for options that enable the features, not the supporting files. Also, it alone does not force TLS or set the authentication mode.

security.ldap.authz.queryTemplate set to a valid template

Why it fails: This option configures LDAP authorization, which is unrelated to TLS or x.509 internal authentication. The scenario does not mention LDAP. Using this would not enable TLS for clients or x.509 for members, and it would introduce an unnecessary external dependency. It is a distractor based on other authentication mechanisms.

{ w: 0 }

Why it fails: This write concern disables acknowledgment entirely. It does not wait for any acknowledgment from any member, including the primary. Therefore, it does not require a majority of voting members. This is the lowest latency and least durable write concern. It is incorrect for this scenario. (Explanation length: 45 words)

{ w: 1 }

Why it fails: This write concern requires acknowledgment only from the primary member. It does not wait for any secondary members. Therefore, it does not require a majority of voting members. This write concern typically provides the lowest latency but the least durability. Since the requirement is for majority acknowledgment, this option is incorrect. (Explanation length: 50 words)

{ w: 'all' }

Why it fails: This write concern is not valid in MongoDB. The valid values for w are a number, 'majority', or a custom write concern name. 'all' is not a recognized value. If used, it would likely cause an error. Therefore, it does not meet the requirement. (Explanation length: 45 words)

Send a SIGHUP signal to the mongod PID.

Why it fails: The SIGHUP signal is traditionally used in many Unix daemons to reload configuration files, but MongoDB does not use it for log rotation. Relying on SIGHUP would result in no action or potentially unexpected behavior, depending on the OS version, rather than the intended archival and rollover of system logs.

Run the 'rotateLogs' command from the admin database.

Why it fails: This setting is incorrect because the 'logRotate' command must be issued from within the mongo shell to have an effect. While it achieves the same result as a signal, the question specifically asks for the mechanism used in automated Linux scripts, where signals are often the preferred external interface.

Update the 'systemLog.path' in the YAML config and run 'mongod --reconfig'.

Why it fails: MongoDB does not support a '--reconfig' flag for the mongod binary to update log paths dynamically. Changing the configuration file requires a full process restart to take effect, which violates the requirement of maintaining uptime. This method is inefficient for routine administrative tasks like log management in production.