ApsaraDB for MongoDB:Why do I need to upgrade my instance to a later MongoDB version?

Data inconsistency occurs during data migration due to the existence of orphaned documents in sharded cluster instances

• Affected versions and architecture: sharded cluster instances that run MongoDB 4.2 or later.

• Description: If you do not clean up orphaned documents in sharded cluster instances at the earliest opportunity, data inconsistency may occur during data migration.

• Recommended version: MongoDB 4.4 or later.

• Reason for recommendation:

  After a chunk is migrated from the source shard to a new shard, the chunk in the source shard is retained for a period of time before deletion. In most cases, orphaned documents are generated due to migration interruption. Orphaned documents do not affect requests on mongos nodes because the requests are checked by the routing data of ConfigServer nodes.

  MongoDB 4.4 or later supports self-recovery chunk migration and automatic orphaned document cleanup. If nodes fail, MongoDB automatically recovers the interrupted migration process. You do not need to run the cleanupOrphaned command to clean up orphaned documents. You can run this command to confirm whether backend threads are cleaned up orphaned documents in an instance.

  For more information, see cleanupOrphaned.

Compact operations block read and write requests

• Affected versions and architectures: instances of all architectures that run MongoDB 4.2 or earlier.

• Description: If you want to defragment a disk, read and write requests are blocked after you perform a compact operation on an instance that runs an earlier version. In this case, you can only restart the instance because the operation cannot be interrupted. This affects your business.

• Recommended version: MongoDB 4.4 or later.

• Reason for recommendation:

  Starting from MongoDB 4.4, the locking behavior of the compact command is optimized to ensure that read and write (CRUD) operations are not blocked except for some DDL operations such as createIndex and dropIndex. You can run the compact command in a period of time outside a specified maintenance window.

  For more information, see Defragment the disks of an instance to increase disk utilization and compact Blocking.

  Note

  To defragment a disk, we recommend that you use the storage analysis feature provided by ApsaraDB for MongoDB. For more information about the feature, see Storage analysis.

Compact operations cause nodes to enter the RECOVERING state

• Affected versions and architectures: instances of all architectures whose major version is MongoDB 4.2 or earlier and whose minor version is earlier than MongoDB 4.2.18.

• Description: If you want to defragment a disk, nodes in an instance that runs an earlier version enter the RECOVERING state after you perform a compact operation on the instance. If the nodes remain in the state for a long time, the nodes are considered unhealthy by the instance activation component of ApsaraDB for MongoDB. In this case, a re-build operation is triggered.

• Recommended version: MongoDB 4.4 or later.

• Reason for recommendation:

  Starting from MongoDB 4.2.18, mongos nodes do not enter the RECOVERING state after you run the compact command in the nodes. This prevents the existence of unavailable mongos nodes and unexpected re-build task flows.

  For more information, see Defragment the disks of an instance to increase disk utilization and compact RECOVERING.

  Note

  To defragment a disk, we recommend that you use the storage analysis feature provided by ApsaraDB for MongoDB. For more information about the feature, see Storage analysis.

Physical backups in hidden nodes consume a large amount of disk space

• Affected versions and architectures: Instances of all architectures that run MongoDB 4.2 or earlier and uses local disks.

• Description: The size of disk files keeps increasing during back uploads due to the physical backup mechanism. If a large number of disk files are accumulated, a large amount of disk space is consumed. If a node failure or switchover occurs, an incorrect alert related to disk usage is triggered.

• Recommended version: MongoDB 5.0 or later (cloud disks).

• Reason for recommendation:

  Full backup in instances that use cloud disks combines physical backup with disk snapshots. Full backup reduces the time required to maintain backup checkpoints in WiredTiger (WT) and resolves disk space bloats due to backups on hidden nodes in an efficient manner.

  Snapshot backup and data restoration based on snapshot backup provided by instances that use cloud disks deliver improved performance. If the amount of data in a replica set instance exceeds 2 TB, we recommend that you use snapshot backup to back up data in the instance. This way, do not occur during backup. These issues include long physical backup time required for instances that use local disks, high backup failure rate, and failures to perform other O&M operations.

Routing data exists in a sharded cluster instance when you recreate a database that has the same name as a deleted database

• Affected versions and architectures: sharded cluster instances that run MongoDB 4.4 or earlier.

• Description: When you run the dropDatabase command in a sharded cluster instance and then recreate a database that has the same name as a deleted database, read and write operations in the instance cannot be performed as expected because routing data exists in the ConfigServer node of the instance.

• Recommended version: MongoDB 5.0 or later.

• Reason for recommendation:

  MongoDB 5.0 or later optimizes the routing data processing of the dropDatabase command. This way, routing data does not exist in a sharded cluster instance that runs MongoDB 5.0 or later. In MongoDB 4.2 or earlier, you must repeatedly run the dropDatabase command. You must also run the flushRouterConfig command on all mongos nodes to refresh routing data. Otherwise, residual routing data degrades database performance.

  For more information, see dropDatabase and flushRouterConfig.

Data synchronization between the primary and secondary nodes is abnormal due to the default writeConcern settings of {w:1}

• Affected versions and architectures: instances of all architectures that run a version earlier than MongoDB 5.0.

• Description: If data is quickly written to the primary node of an instance, secondary nodes in the instance may receive only parts of the data and then enter the RECOVERING state. This degrades the availability of the instance. The secondary nodes may fail to read expected data, which compromises business that requires read/write splitting. In this case, incremental backup cannot be performed as expected. and data cannot be restored to a previous point in time.

• Recommended version: MongoDB 5.0 or later.

• Reason for recommendation:

  Starting from MongoDB 5.0, the default value of writeConcern is changed from {w:1} to {w:"majority"}, indicating that data to be written can be queried only after the data is confirmed by most nodes in a replica set instance. This improves data reliability at a slight performance loss. This also resolves data loss caused by slow query responses or the primary node in the ROLLBACK state due to parts of data received by secondary nodes and flow control triggered on the primary node.

  You can set writeConcern to {w:1} in scenarios that require high write performance.

  For more information, see Default Write Concern and setDefaultRWConcern.

Balancer evenly distributes data at a slow speed, provides poor scaling performance, and fails to perform scale-out activities during peak hours

• Affected versions and architectures: instances of all architectures that run a version earlier than MongoDB 5.0.

• Description: The balancer cannot migrate data at a higher speed. Consequently, data cannot be evenly distributed at a fast speed in scenarios that require scale-out activities. This degrades database performance.

• Recommended version: MongoDB 5.0 or later.

• Reason for recommendation:

  Starting from MongoDB 5.0, the chunkMigrationConcurrency and balancerMigrationsThrottlingMs parameters are added to adjust the migration concurrency and performance of the balancer.

  For more information, see chunkMigrationConcurrency and balancerMigrationsThrottlingMs.

  Note

  If your instance runs MongoDB 5.0 and does not support the two parameters, update the minor version of the instance. For more information, see Update the minor version of an instance.

Load in a sharded cluster instance is unevenly distributed due to data unbalance

• Affected versions and architectures: instances of all architectures whose major version is MongoDB 5.0 or earlier and whose minor version is earlier than MongoDB 6.0.3.

• Description: The balancer checks whether data is evenly distributed based on the number of chunks among shards. If Jumbo and empty chunks exist and portions of data is frequently accessed, data and load unbalance occurs among shards.

• Recommended version: MongoDB 6.0 or later.

• Reason for recommendation:

  Starting from MongoDB 6.0.3, the balancer evenly distributes data based on the difference in data volume among shards instead of that in the number of chunks among shards. This resolves data and load unbalance due to the existence of Jumbo and empty chunks and frequently accessed data in earlier versions.

  For more information, see Changes to the balancer in MongoDB 6.0.3.

Other kernel issues