From cdca18cf29e404568000d061c54e11e18f03775d Mon Sep 17 00:00:00 2001 From: Anastasia Alexandrova Date: Wed, 9 Oct 2024 12:05:50 +0200 Subject: [PATCH] PBM-1389 Documented limitations for ops for MongoDB 8.0 (#211) PBM-1359 Documented limitations for ops for MongoDB 8.0 modified: docs/features/point-in-time-recovery.md modified: docs/features/selective-backup.md modified: docs/usage/start-backup.md --- docs/features/point-in-time-recovery.md | 6 +++++- docs/features/selective-backup.md | 1 + docs/usage/start-backup.md | 3 ++- 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/features/point-in-time-recovery.md b/docs/features/point-in-time-recovery.md index 392ad5e..2712220 100644 --- a/docs/features/point-in-time-recovery.md +++ b/docs/features/point-in-time-recovery.md @@ -54,11 +54,15 @@ If you just enabled point-in-time recovery, it requires 10 minutes for the first If you [reshard :octicons-link-external-16:](https://www.mongodb.com/docs/manual/core/sharding-reshard-a-collection/) a collection, make a fresh backup and re-enable point-in-time recovery oplog slicing to prevent data inconsistency and restore failure. + **For MongoDB 8.0 and higher versions** + + If you [unshard a collection :octicons-link-external-16:](https://www.mongodb.com/docs/v8.0/reference/command/unshardCollection/), make a fresh backup and re-enable point-in-time recovery oplog slicing to prevent data inconsistency and restore failure. + Starting with version [2.4.0](../release-notes/2.4.0.md), oplog slicing runs as follows: * **Logical backups** - Before backup starts, the point-in-time recovery routine is automatically disabled. A backup routine creates oplog slices during the backup creation. After the backup is complete, the point-in-time recovery routine is re-enabled automatically. It copies the slices taken during the backup and continues oplog slicing from the latest timestamp. + Before backup starts, the point-in-time recovery routine is automatically disabled. A backup routine creates oplog slices during the backup creation. After the backup is complete, the point-in-time recovery routine is re-enabled automatically. It copies the slices taken during the backup and continues oplog slicing from the latest timestamp. * **Physical backups** diff --git a/docs/features/selective-backup.md b/docs/features/selective-backup.md index 5b31b1e..7ef0406 100644 --- a/docs/features/selective-backup.md +++ b/docs/features/selective-backup.md @@ -25,6 +25,7 @@ With the selective backup and restore functionality, you have the following opti 6. System collections in ``admin``, ``config``, and ``local`` databases cannot be backed up and restored selectively. You must make a full backup and restore to include them. 7. Selective point-in-time recovery is not supported for sharded clusters. +8. Selective backups are not supported for deployments with [config shards :octicons-link-external-16:](https://www.mongodb.com/docs/v8.0/core/sharded-cluster-config-servers/#std-label-sharded-cluster-config-server-config-shards) - config server replica sets that also store application data. ## Sharded collections diff --git a/docs/usage/start-backup.md b/docs/usage/start-backup.md index 9760554..645338e 100644 --- a/docs/usage/start-backup.md +++ b/docs/usage/start-backup.md @@ -153,7 +153,8 @@ The following diagram illustrates the backup flow. !!! important - If you reshard a collection in MongoDB 5.0 and higher versions, make a fresh backup to prevent data inconsistency and restore failure. + If you reshard a collection in MongoDB 5.0 and higher versions or unshard a collection in MongoDB 8.0 and higher versions, make a fresh backup to prevent data inconsistency and restore failure. + ### Adjust node priority for backups