From 67652e1825d83238f9e05445ecd4739de2477376 Mon Sep 17 00:00:00 2001 From: Anastasia Alexadrova Date: Wed, 28 Jun 2023 14:52:34 +0200 Subject: [PATCH] PBM-1118 Added support of custom shard names for remapping modified: docs/features/selective-backup.md modified: docs/usage/restore.md modified: styles/Vocab/Percona/accept.txt --- docs/features/selective-backup.md | 6 +++--- docs/usage/restore.md | 5 ++++- styles/Vocab/Percona/accept.txt | 2 +- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/docs/features/selective-backup.md b/docs/features/selective-backup.md index 42e6cc70..03642a1a 100644 --- a/docs/features/selective-backup.md +++ b/docs/features/selective-backup.md @@ -28,20 +28,20 @@ During the restore, the reverse process occurs: * A `pbm-agent` on each shard restores only the specified databases/collections and replays the oplog that relates only to the specified namespaces. The operations for other namespaces are ignored. * On the config server replica set, the `pbm-agent` restores the router configuration only for the specified sharded collections. The router configuration for other databases, collections and chunks remains intact. -The restore for sharded timeseries collections is not supported. +The restore for sharded time series collections is not supported. Note that selective backups and restores operate only with data and router configuration. The cluster configuration and topology-related settings are ignored. Therefore, we recommended to restore the databases/collections on the same environment. ### Implementation specifics -During the selective restore, the primary shard for a database is set to the state it had during the backup. For example, the primary shard for the database "Staff" during backup was A. After you restore the "Staff" database, the primary shard will be set to A even if you moved the primary from A to B before the restore. All non sharded collections will be restored on A; however, they will not be deleted from B. You must take needed actions (cleanup or move the primary back to B) to maintain them. +During the selective restore, the primary shard for a database is set to the state it had during the backup. For example, the primary shard for the database "Staff" during backup was A. After you restore the "Staff" database, the primary shard will be set to A even if you moved the primary from A to B before the restore. All non-sharded collections will be restored on A; however, they will not be deleted from B. You must take needed actions (cleanup or move the primary back to B) to maintain them. ## Known limitations of selective backups and restores 1. Only **logical** backups and restores are supported. 2. Selective backups and restores are supported in sharded clusters for non-sharded collections starting with version 2.0.3. Sharded collections are supported starting with version 2.1.0. -3. Sharded timeseries collections are not supported. +3. Sharded time series collections are not supported. 4. Multiple namespaces are not yet supported for selective backups. However, you can specify several namespaces for the restore (e.g., restore several collections of a database). 5. Multi-collection transactions are not yet supported for selective restore. 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. diff --git a/docs/usage/restore.md b/docs/usage/restore.md index 37b0a006..b274b7f3 100644 --- a/docs/usage/restore.md +++ b/docs/usage/restore.md @@ -265,6 +265,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re ``` This is expected behavior of periodic checks upon the database start. During the restore, the `config.system.sessions` collection is dropped but Percona Server for MongoDB recreates it eventually. It is a normal procedure. No action is required from your end. + 2. Resync the backup list from the storage. 3. Start the balancer and the `mongos` node. 4. As the general recommendation, make a new base backup to renew the starting point for subsequent incremental backups. @@ -281,7 +282,9 @@ Of course, make sure not to run **pbm backup** from the new environment whilst t ## Restoring into a cluster / replica set with a different name -Starting with version 1.8.0, you can restore **logical backups** into a new environment that has the same or more number of shards and these shards have different replica set names. +Starting with version 1.8.0, you can restore **logical backups** into a new environment that has the same or more number of shards and these shards have different replica set names. + +Starting with version 2.2.0, you can restore environments that have [custom shard names](https://www.mongodb.com/docs/manual/reference/command/addShard/#mongodb-dbcommand-dbcmd.addShard). To restore data to the environment with different replica set names, configure the name mapping between the source and target environments. You can either set the `PBM_REPLSET_REMAPPING` environment variable for `pbm` CLI or use the `--replset-remapping` flag for PBM commands. The mapping format is `=`. diff --git a/styles/Vocab/Percona/accept.txt b/styles/Vocab/Percona/accept.txt index f7ff6d95..0c4adf9c 100644 --- a/styles/Vocab/Percona/accept.txt +++ b/styles/Vocab/Percona/accept.txt @@ -14,7 +14,7 @@ Percona XtraDB Cluster Percona XtraBackup Percona Toolkit Sysbench -Ooplog +[Oo]plog PITR pitr namespace