Bug #39551
closedmultisite: RGWListBucketIndexesCR for data full sync needs pagination
0%
Description
When a new peer zone is added, rgw starts in 'full sync'. This starts by listing all of that zone's bucket instances, in order to build a list of all of the bucket index shards we need to sync.
from RGWListBucketIndexesCR::operate():
/* FIXME: need a better scaling solution here, requires streaming output */
call(new RGWReadRESTResourceCR<list<string> >(store->ctx(), sync_env->conn, sync_env->http_manager,
entrypoint, NULL, &result));
This attempts to read the entire list of bucket instance ids from the remote zone's "/admin/metadata/bucket.instance" admin api. RGWOp_Metadata_List is the op for this admin api, and it will return a maximum of 1000 entries - so if there are more bucket instances than that, data sync won't see them. RGWOp_Metadata_List accepts a "marker" parameter that allows you to resume a listing from where the last request left off. RGWListBucketIndexesCR should use this marker in order to continue listing keys until the end (where truncated = false).
Updated by Casey Bodley almost 5 years ago
- Status changed from New to In Progress
- Assignee set to Shilpa MJ
Updated by Casey Bodley almost 5 years ago
- Status changed from In Progress to Fix Under Review
- Backport set to luminous mimic nautilus
- Pull request ID set to 28146
Updated by Casey Bodley almost 5 years ago
- Status changed from Fix Under Review to Pending Backport
Updated by Nathan Cutler almost 5 years ago
- Copied to Backport #40352: nautilus: multisite: RGWListBucketIndexesCR for data full sync needs pagination added
Updated by Nathan Cutler almost 5 years ago
- Copied to Backport #40353: luminous: multisite: RGWListBucketIndexesCR for data full sync needs pagination added
Updated by Nathan Cutler almost 5 years ago
- Copied to Backport #40354: mimic: multisite: RGWListBucketIndexesCR for data full sync needs pagination added
Updated by Nathan Cutler about 3 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".