From 1a6f2761b976f739ae9bc020d2926211f7219b14 Mon Sep 17 00:00:00 2001 From: Anastasia Alexadrova Date: Wed, 25 Sep 2024 20:17:43 +0200 Subject: [PATCH 1/2] 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 | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/features/point-in-time-recovery.md b/docs/features/point-in-time-recovery.md index 392ad5e..0752a64 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** + + Oplog slicing is not supported during the [unshardCollection :octicons-link-external-16:](https://www.mongodb.com/docs/v8.0/reference/command/unshardCollection/) operation. + 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..4e0049c 100644 --- a/docs/usage/start-backup.md +++ b/docs/usage/start-backup.md @@ -155,6 +155,8 @@ The following diagram illustrates the backup flow. If you reshard a collection in MongoDB 5.0 and higher versions, make a fresh backup to prevent data inconsistency and restore failure. + Note that oplog slices are not saved when you unshard a collection. + ### Adjust node priority for backups In Percona Backup for MongoDB prior to version 1.5.0, the `pbm-agent` to do a backup is elected randomly among secondary nodes in a replica set. In sharded cluster deployments, the `pbm-agent` is elected among the secondary nodes in every shard and the config server replica sets. If no secondary node responds in a defined period, then the `pbm-agent` on the primary node is elected to do a backup. From c2d833fd7c61dc8b7e8245790d3ca7f687d2b3a5 Mon Sep 17 00:00:00 2001 From: Anastasia Alexadrova Date: Tue, 1 Oct 2024 09:13:15 +0200 Subject: [PATCH 2/2] Changed wording for unsharding a collection --- docs/features/point-in-time-recovery.md | 4 ++-- docs/usage/start-backup.md | 5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/features/point-in-time-recovery.md b/docs/features/point-in-time-recovery.md index 0752a64..2712220 100644 --- a/docs/features/point-in-time-recovery.md +++ b/docs/features/point-in-time-recovery.md @@ -54,9 +54,9 @@ 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** + **For MongoDB 8.0 and higher versions** - Oplog slicing is not supported during the [unshardCollection :octicons-link-external-16:](https://www.mongodb.com/docs/v8.0/reference/command/unshardCollection/) operation. + 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: diff --git a/docs/usage/start-backup.md b/docs/usage/start-backup.md index 4e0049c..645338e 100644 --- a/docs/usage/start-backup.md +++ b/docs/usage/start-backup.md @@ -153,9 +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. - - Note that oplog slices are not saved when you unshard a collection. + 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