Update backup storage redundancy information#10359
Open
ZaeemKhaliq wants to merge 1 commit into
Open
Conversation
Clarified backup storage redundancy behavior for geo-secondary databases in General Purpose and Business Critical service tiers.
prmerger-automator
Bot
requested review from
MashaMSFT,
WilliamDAssafMSFT and
rajeshsetlem
Contributor
|
@ZaeemKhaliq : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
Contributor
|
Learn Build status updates of commit 158b5d2:
|
| File | Status | Preview URL | Details |
|---|---|---|---|
| azure-sql/database/active-geo-replication-overview.md | Details |
azure-sql/database/active-geo-replication-overview.md
- Line 119, Column 324: [Warning: hard-coded-locale - See documentation]
Link 'https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview?view=azuresql#automatic-backups-on-secondary-replicas' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites. - Line 119, Column 324: [Suggestion: docs-link-absolute - See documentation]
Absolute link 'https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview?view=azuresql#automatic-backups-on-secondary-replicas' will be broken in isolated environments. Replace with a relative link. - Line 119, Column 324: [Suggestion: preserve-view-not-set - See documentation]
You've pinned this link to a specific version of content with the view parameter. It's recommended not to pin a version unless that version is A) not the default view and B) the context is about that version specifically. To proceed with pinning a version add the &preserve-view=true to the URL. Otherwise, remove the view parameter. URL: https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview?view=azuresql#automatic-backups-on-secondary-replicas
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Active Geo-Replication documentation to clarify where automated backups are taken, aligning the “always on primary” statement with current behavior for Business Critical databases.
Changes:
- уточ Clarifies that backups are taken on the primary in General Purpose, while Business Critical uses secondary replicas (with a supporting reference link).
| > - Throttling can also occur for reasons unrelated to compute size, for example in heavy workloads for bulk insert, `SELECT INTO`, and index builds. For more information on wait types for different kinds of log I/O throttling, see [Transaction log rate governance](resource-limits-logical-server.md#transaction-log-rate-governance). | ||
|
|
||
| By default, backup storage redundancy of the geo-secondary is same as for the primary database. You can choose to configure a geo-secondary with a different backup storage redundancy. Backups are always taken on the primary database. If the secondary is configured with a different backup storage redundancy, then after a geo-failover, when the geo-secondary is promoted to the primary, new backups will be stored and billed according to the type of storage (RA-GRS, ZRS, LRS) selected on the new primary (previous secondary). | ||
| By default, backup storage redundancy of the geo-secondary is same as for the primary database. You can choose to configure a geo-secondary with a different backup storage redundancy. Backups are always taken on the primary database in **General Purpose** service tier (In **Business Critical** tier, they are now taken on [secondary replicas](https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview?view=azuresql#automatic-backups-on-secondary-replicas)). If the secondary is configured with a different backup storage redundancy, then after a geo-failover, when the geo-secondary is promoted to the primary, new backups will be stored and billed according to the type of storage (RA-GRS, ZRS, LRS) selected on the new primary (previous secondary). |
Contributor
|
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
Bot
added
the
aq-pr-triaged
Contributor
|
@ZaeemKhaliq : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This specific statement seems to be outdated (link):
Because in other place, it says that backups are now taken on secondary replicas in Business Critical service tier (link). So "always taken on the primary database" no longer holds true.