ApsaraDB for MongoDB:Why upgrade to a later MongoDB version

Orphaned documents cause data inconsistency during migration

• Affected versions: Sharded cluster instances running MongoDB 4.2 or later

• Fix version: MongoDB 4.4 or later

After a chunk migrates from a source shard to a destination shard, the source shard retains the chunk temporarily before deletion. Migration interruptions leave behind orphaned documents. Orphaned documents do not affect requests on mongos nodes because the requests are checked by the routing data of ConfigServer nodes. However, orphaned documents accumulate and cause data inconsistency during subsequent migrations.

MongoDB 4.4 introduced self-recovery chunk migration and automatic orphaned document cleanup. If nodes fail mid-migration, MongoDB resumes the process automatically — no need to run cleanupOrphaned manually. Run the command only to confirm that background cleanup threads are active.

For details, see cleanupOrphaned.

The compact command blocks reads and writes

• Affected versions: All architectures running MongoDB 4.2 or earlier

• Fix version: MongoDB 4.4 or later

Running compact to defragment a disk on MongoDB 4.2 or earlier blocks all read and write operations for the duration. The operation cannot be interrupted, so the only recovery option is to restart the instance, which affects business continuity.

MongoDB 4.4 optimized the locking behavior of compact so that CRUD operations are not blocked. Only some DDL operations — createIndex and dropIndex — are briefly affected. Schedule compact runs outside your maintenance window.

For details, see Defragment the disks of an instance and compact blocking.

The compact command causes nodes to enter the RECOVERING state

• Affected versions: All architectures with major version MongoDB 4.2 or earlier and minor version earlier than 4.2.18

• Fix version: MongoDB 4.4 or later

On affected versions, running compact causes mongos nodes to enter the RECOVERING state. If nodes remain in this state long enough, the ApsaraDB for MongoDB activation component treats them as unhealthy and triggers a rebuild, causing unplanned downtime.

Starting from MongoDB 4.2.18, mongos nodes no longer enter the RECOVERING state after compact runs, preventing both unavailable nodes and unexpected rebuild flows.

For details, see Defragment the disks of an instance and compact RECOVERING.

Physical backups on hidden nodes consume excessive disk space

• Affected versions: All architectures running MongoDB 4.2 or earlier that use local disks

• Fix version: MongoDB 5.0 or later (cloud disks)

The physical backup mechanism on local-disk instances causes disk file sizes to grow continuously during backup uploads. Large accumulated files consume significant disk space and trigger incorrect disk usage alerts during node failures or switchovers.

Cloud-disk instances combine physical backup with disk snapshots, reducing the time required to maintain WiredTiger (WT) backup checkpoints and resolving disk space bloat on hidden nodes. For replica set instances with more than 2 TB of data, use snapshot backup to avoid the long backup times, high failure rates, and O&M operation conflicts that occur with local-disk physical backups.

Residual routing data breaks databases recreated with the same name

• Affected versions: Sharded cluster instances running MongoDB 4.4 or earlier

• Fix version: MongoDB 5.0 or later

When you drop a database with dropDatabase in a sharded cluster and then recreate a database with the same name, residual routing data in the ConfigServer node causes read and write operations to fail.

On MongoDB 4.2 or earlier, you must run dropDatabase repeatedly and then run flushRouterConfig on all mongos nodes to flush routing data — otherwise residual data degrades performance.

MongoDB 5.0 optimized dropDatabase routing data handling so that routing data is automatically cleared, eliminating this manual cleanup requirement.

For details, see dropDatabase and flushRouterConfig.

Default write concern {w:1} causes data sync failures on secondary nodes

• Affected versions: All architectures running versions earlier than MongoDB 5.0

• Fix version: MongoDB 5.0 or later

With the default write concern of {w:1}, data written rapidly to the primary node may only partially reach secondary nodes, causing them to enter the RECOVERING state. This degrades instance availability, breaks read/write splitting workloads, and prevents incremental backups and point-in-time recovery.

MongoDB 5.0 changed the default write concern from {w:1} to {w:"majority"}. Data is queryable only after the majority of replica set members confirm the write, improving data reliability at a slight performance loss. For high-write-throughput scenarios where you can accept the previous behavior, set write concern back to {w:1}.

For details, see Default write concern and setDefaultRWConcern.

The balancer rebalances data too slowly to support scale-out

• Affected versions: All architectures running versions earlier than MongoDB 5.0

• Fix version: MongoDB 5.0 or later

The balancer cannot migrate chunks fast enough to rebalance data during scale-out events, which degrades performance as data remains unevenly distributed across shards.

MongoDB 5.0 added chunkMigrationConcurrency and balancerMigrationsThrottlingMs parameters so you can tune balancer migration concurrency and throughput to match your workload.

For details, see chunkMigrationConcurrency and balancerMigrationsThrottlingMs.

Chunk-count-based balancing causes load imbalance in sharded clusters

• Affected versions: All architectures with major version MongoDB 5.0 or earlier and minor version earlier than 6.0.3

• Fix version: MongoDB 6.0 or later

The balancer distributes data based on chunk count rather than data volume. When jumbo chunks or empty chunks exist — or when a subset of data receives disproportionately high traffic — chunks appear balanced by count but shards carry unequal load.

MongoDB 6.0.3 changed the balancer to distribute data based on the difference in data volume across shards rather than chunk count. This resolves load imbalance caused by jumbo chunks, empty chunks, and hot data patterns.

For details, see Changes to the balancer in MongoDB 6.0.3.

Other kernel issues

The following table lists additional kernel issues in earlier MongoDB versions identified by the ApsaraDB for MongoDB team.