Conversation
There was a problem hiding this comment.
Pull request overview
Updates the PITR-from-physical-backup documentation to reflect a change in how oplog entries are applied during physical PITR restores.
Changes:
- Document that PITR oplog entries are applied to all nodes in a replica set during physical restore, allowing any start order.
- Add a “Version added” note for the behavior change and reframe the previous primary-first requirement.
- Rework the sharded-cluster PITR limitations section into bullets.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| During a physical restore with point-in-time recovery (PITR), PBM applies oplog entries to all nodes in each replica set. As a result, all nodes contain the same restored data files when the restore completes, allowing replica set members to be started in any order. | ||
|
|
There was a problem hiding this comment.
This paragraph says PBM applies PITR oplog entries to all nodes in each replica set, but later in this section the sharded-cluster bullet states oplog events are replayed only on the primary node of each shard. Please reconcile these statements (update/remove the bullet, or qualify this paragraph) so the documented behavior is consistent.
There was a problem hiding this comment.
@copilot apply changes based on this feedback
There was a problem hiding this comment.
Updated the sharded-cluster bullet in commit d415a85 to say oplog events are replayed on all nodes of every shard, removing the "primary only" language and the "remaining nodes receive data during initial sync" note. This aligns the bullet with the paragraph above it that describes the 2.14.0 behavior.
…ct all-nodes behavior Agent-Logs-Url: https://github.com/percona/pbm-docs/sessions/5cf9e396-42d9-49db-8902-91496dd3e247 Co-authored-by: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com>
… of https://github.com/percona/pbm-docs into PBM-1167-PITR-with-physical-backup-doesnt-recover-data
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
rasika-chivate
temporarily deployed
to
PBM-1167-PITR-with-physical-backup-doesnt-recover-data - pbm-release-branch-docs PR #359
Render
Destroyed
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 2. When doing point-in-time recovery for deployments with sharded collections, PBM only writes data to existing ones and doesn’t support creating new collections. Therefore, whenever you create a new sharded collection, make a new backup for it to be included there. | ||
| During a physical restore with point-in-time recovery (PITR), PBM applies oplog entries to all nodes in each replica set. As a result, all nodes contain the same restored data files when the restore completes, allowing replica set members to be started in any order. | ||
|
|
||
| !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)" |
There was a problem hiding this comment.
The new “Version added: 2.14.0” admonition links to ../release-notes/2.14.0.md, but that release-notes file doesn’t exist in the repo, so this will render as a broken link. Either add the docs/release-notes/2.14.0.md page, or remove/adjust the link (e.g., keep the version text without a link) to match the existing documentation pattern.
| !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)" | |
| !!! admonition "Version added: 2.14.0" |
radoslawszulgo
deleted the
PBM-1167-PITR-with-physical-backup-doesnt-recover-data
branch
No description provided.