node: Evacuate objects without setting mode to MAINTENANCE
#1349
No reviewers
TrueCloudLab/storage-core-developers
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#1349
Loading…
Reference in a new issue
No description provided.
Delete branch "acid-ant/frostfs-node:feature/evac-without-mm"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Signed-off-by: Anton Nikiforov an.nikiforov@yadro.com
MAINTENANCE
d2c27341a9
to280c981cb2
acid-ant referenced this pull request2024-09-03 12:49:58 +00:00
REP 1
only #1350@ -366,6 +366,7 @@ func (e *StorageEngine) evacuateShardObjects(ctx context.Context, shardID string
listPrm.WithCount(defaultEvacuateBatchSize)
sh := shardsToEvacuate[shardID]
sh.SetEvacInProgress(true)
When is this disabled? What if we get error in
ListWithCursor
below?When we move shard to
DISABLED
mode. Think this should be the one-way trip. Otherwise, it is possible to lose the data.But for evacuation shard mode
READ_ONLY
is only required...@ -70,6 +72,11 @@ func (s *Shard) Head(ctx context.Context, prm HeadPrm) (HeadRes, error) {
res, err = s.Get(ctx, getPrm)
obj = res.Object()
} else {
s.m.RLock()
On an unrelated note: we should take mode for the whole operation duration.
I am surprised it wasn't the case before.
Not for this PR
That was done in a such way because we take the same lock here
res, err = s.Get(ctx, getPrm)
. Maybe that was the reason why we don't take lock for the whole operation.@ -17,2 +17,4 @@
Mode mode.Mode
// True when evacuation is in progress.
EvacInProgress bool
EvacuationInProgress
?Renamed.
@ -580,2 +580,4 @@
}
}
func (s *Shard) SetEvacInProgress(val bool) {
Evacuation is done on the engine level, but we have a flag on the shard level and because of this we have
SkipEvacCheck
parameter to the operation.Was having
evacuationInProgress
flag considered to be present somewhere in the engine structure?It looks more complex and slower. Once it will be on an
engine
level, we should check for each request is evacuation for shard in progress, and go to internal map for checking shard and exclude it from iteration. If this overhead is ok for us, we can do that in a such way.280c981cb2
to785403affd
785403affd
to659c5989ce
Propagate evacuation status into metrics:
Now evacuation status resetting by request
StopShardEvacuationRequest
.659c5989ce
to5717d86173
Please, adjust the documentation https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/docs/evacuation.md (need to mention new flag and the behaviour)
5717d86173
tofb01817d3d
New commits pushed, approval review dismissed automatically according to repository settings
fb01817d3d
to108e4e07be
Updated
evacuation.md
.