Ryan19929 opened a new pull request, #65321:
URL: https://github.com/apache/doris/pull/65321
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
### Historical Context
Backup metadata has stored the full `Table` object since the original
backup/restore implementation was introduced in #224. As a result, Replica
objects were included implicitly through the catalog object hierarchy:
`OlapTable -> Partition -> MaterializedIndex -> Tablet -> Replica`
They were not added as a dedicated backup metadata object.
A later restore enhancement, #11942, introduced the `reserve_replica`
property. That feature preserves the original replication allocation when
requested, but it does not require preserving individual serialized Replica
objects. During restore, Doris still recreates tablets and replicas with new
ids and selected backend ids.
### Background
Large BACKUP jobs can generate very large backup metadata because Doris
currently persists all Replica objects for every backed up tablet. For tables
with many tablets and replicas, this increases both backup metadata size and FE
memory usage.
### Root Cause
Backup metadata currently stores a detached copy of the full table metadata.
Since Tablet metadata contains Replica objects, all replicas are serialized
into backup metadata as part of the table object graph.
This is unnecessary for restore. Restore only needs the table structure,
partition/index/tablet topology, version information, and replica allocation.
The actual Replica objects are recreated during restore with new replica ids
and selected backend ids.
### Changes
This PR strips replica information from the detached table copy used for
backup metadata.
A mutable FE config `backup_meta_reserve_replica_info` is added as a
fallback. The default value is `false`, which omits unused replica information
from backup metadata. Setting it to `true` preserves the old behavior.
### Follow-up Work
This PR only addresses replica-info amplification in backup metadata.
Follow-up PRs will handle larger serialization optimizations:
- Reduce RestoreJob JSON serialization/deserialization memory usage by
streaming large RestoreJob fields such as `snapshotInfos` and
`restoredVersionInfo`.
- Further reduce BACKUP job memory usage by introducing streaming JSON
write/read paths for large backup metadata.
### Compatibility
Restore compatibility is kept because RESTORE does not depend on serialized
Replica objects. The previous behavior can still be restored with
`backup_meta_reserve_replica_info`.
### Release note
None
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] Regression test
- [ ] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
- [ ] Previous test can cover this change.
- [ ] No code files have been changed.
- [ ] Other reason <!-- Add your reason? -->
- Behavior changed:
- [ ] No.
- [ ] Yes. <!-- Explain the behavior change -->
- Does this need documentation?
- [ ] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR should
merge into -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
