reshard stale-instances
Hi Everyone, We've just completed undoing multisite to bring us back down to a single zone/site. Now I'm working through cleaning things up. Heads up, I'll probably have a few more questions over the next couple of weeks :) Firstly though, regarding "radosgw-admin reshard stale-instances list". This brings back a decent list mostly of some test buckets that were being deleted and recreated by an automated system. This has left over 150k stale instances for each of three buckets. I know these ones will be fine to delete as even if it messes up the bucket I can delete and re-create them. So my question is, how do I clean these up without using the big hammer "radosgw-admin reshard stale-instances delete" to remove all of them which would include some production buckets that I'm not quite sure how to verify are stale? Another thought that I had is maybe if I were to reshard all the buckets up to the next prime now that we're on single zone would that guarantee that all the stale instances are actually stale? Any thoughts and tips would be much appreciated. Thanks, Rich
Hi Everyone, I've found through a bit of digging that if I use the reshard stale-instances list I get entries of this form (bucket name is "bstor08") bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 I know that this particular bucket is junk left over from an automated system as per above so I'd like to clean them up. I can do a metadata get on this: radosgw-admin metadata get bucket.instance:bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 and therefore also a metadata rm: radosgw-admin metadata rm bucket.instance:bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 After doing this I re-run the stale-instances list and that instance is gone from the list so that looks promising. Checking the code, it looks like the stale-instance delete/rm also does an instance purge before the metadata remove, so above is possibly half right: int ret = bucket->purge_instance(dpp, y); if (ret == 0){ auto md_key = "bucket.instance:" + binfo.bucket.get_key(); ret = driver->meta_remove(dpp, md_key, y); } Is anyone able to tell me if there's a radosgw-admin command to do the instance purge part? I couldn't see anything when I was digging around but I've probably missed something obvious. Thanks, Rich On Mon, 17 Mar 2025 at 17:49, Richard Bade <hitrich@gmail.com> wrote:
Hi Everyone, We've just completed undoing multisite to bring us back down to a single zone/site. Now I'm working through cleaning things up. Heads up, I'll probably have a few more questions over the next couple of weeks :) Firstly though, regarding "radosgw-admin reshard stale-instances list". This brings back a decent list mostly of some test buckets that were being deleted and recreated by an automated system. This has left over 150k stale instances for each of three buckets. I know these ones will be fine to delete as even if it messes up the bucket I can delete and re-create them. So my question is, how do I clean these up without using the big hammer "radosgw-admin reshard stale-instances delete" to remove all of them which would include some production buckets that I'm not quite sure how to verify are stale? Another thought that I had is maybe if I were to reshard all the buckets up to the next prime now that we're on single zone would that guarantee that all the stale instances are actually stale? Any thoughts and tips would be much appreciated.
Thanks, Rich
On Sun, Mar 30, 2025 at 7:21 PM Richard Bade <hitrich@gmail.com> wrote:
Hi Everyone, I've found through a bit of digging that if I use the reshard stale-instances list I get entries of this form (bucket name is "bstor08") bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 I know that this particular bucket is junk left over from an automated system as per above so I'd like to clean them up. I can do a metadata get on this: radosgw-admin metadata get bucket.instance:bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 and therefore also a metadata rm: radosgw-admin metadata rm bucket.instance:bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 After doing this I re-run the stale-instances list and that instance is gone from the list so that looks promising.
Checking the code, it looks like the stale-instance delete/rm also does an instance purge before the metadata remove, so above is possibly half right:
int ret = bucket->purge_instance(dpp, y); if (ret == 0){ auto md_key = "bucket.instance:" + binfo.bucket.get_key(); ret = driver->meta_remove(dpp, md_key, y); }
Is anyone able to tell me if there's a radosgw-admin command to do the instance purge part? I couldn't see anything when I was digging around but I've probably missed something obvious.
'radosgw-admin bi purge' is probably what you're looking for. it deletes the bucket's index shard objects, but needs that bucket instance metadata to know how many shards there are and where they live
Thanks, Rich
On Mon, 17 Mar 2025 at 17:49, Richard Bade <hitrich@gmail.com> wrote:
Hi Everyone, We've just completed undoing multisite to bring us back down to a single zone/site. Now I'm working through cleaning things up. Heads up, I'll probably have a few more questions over the next couple of weeks :) Firstly though, regarding "radosgw-admin reshard stale-instances list". This brings back a decent list mostly of some test buckets that were being deleted and recreated by an automated system. This has left over 150k stale instances for each of three buckets. I know these ones will be fine to delete as even if it messes up the bucket I can delete and re-create them. So my question is, how do I clean these up without using the big hammer "radosgw-admin reshard stale-instances delete" to remove all of them which would include some production buckets that I'm not quite sure how to verify are stale? Another thought that I had is maybe if I were to reshard all the buckets up to the next prime now that we're on single zone would that guarantee that all the stale instances are actually stale? Any thoughts and tips would be much appreciated.
Thanks, Rich
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Thanks for that Casey. The docs are a bit sparse on these commands and it just told me "ERROR: bucket name not specified" when I ran it without anything. After a bit of googling I was able to find a mailing list response with this information from J. Eric Ivancich from a couple of years ago:
When the admin runs “bi purge” they have the option of supplying a bucket_id with the “--bucket-id” command-line argument. This was useful back when resharding did not automatically remove the older bucket index shards (which it now does), which had a different bucket_id from the current bucket index shards.
This looks to be exactly what I needed. So I'm going to try the following using my previous example "bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772" from my stale instance list where bucket_name=bstor08 and bucket_id=2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 - radosgw-admin bi purge --bucket-id="{bucket_id}" - radosgw-admin metadata rm bucket.instance:{bucket_name}:{bucket_id} That seems to cover what the code is doing. So hopefully this gets me all cleaned up. Thanks, Rich On Tue, 1 Apr 2025 at 02:16, Casey Bodley <cbodley@redhat.com> wrote:
On Sun, Mar 30, 2025 at 7:21 PM Richard Bade <hitrich@gmail.com> wrote:
Hi Everyone, I've found through a bit of digging that if I use the reshard stale-instances list I get entries of this form (bucket name is "bstor08") bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 I know that this particular bucket is junk left over from an automated system as per above so I'd like to clean them up. I can do a metadata get on this: radosgw-admin metadata get bucket.instance:bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 and therefore also a metadata rm: radosgw-admin metadata rm bucket.instance:bstor08:2efbe9f5-7b36-4290-a370-52f57c6353c7.2708501101.618772 After doing this I re-run the stale-instances list and that instance is gone from the list so that looks promising.
Checking the code, it looks like the stale-instance delete/rm also does an instance purge before the metadata remove, so above is possibly half right:
int ret = bucket->purge_instance(dpp, y); if (ret == 0){ auto md_key = "bucket.instance:" + binfo.bucket.get_key(); ret = driver->meta_remove(dpp, md_key, y); }
Is anyone able to tell me if there's a radosgw-admin command to do the instance purge part? I couldn't see anything when I was digging around but I've probably missed something obvious.
'radosgw-admin bi purge' is probably what you're looking for. it deletes the bucket's index shard objects, but needs that bucket instance metadata to know how many shards there are and where they live
Thanks, Rich
On Mon, 17 Mar 2025 at 17:49, Richard Bade <hitrich@gmail.com> wrote:
Hi Everyone, We've just completed undoing multisite to bring us back down to a single zone/site. Now I'm working through cleaning things up. Heads up, I'll probably have a few more questions over the next couple of weeks :) Firstly though, regarding "radosgw-admin reshard stale-instances list". This brings back a decent list mostly of some test buckets that were being deleted and recreated by an automated system. This has left over 150k stale instances for each of three buckets. I know these ones will be fine to delete as even if it messes up the bucket I can delete and re-create them. So my question is, how do I clean these up without using the big hammer "radosgw-admin reshard stale-instances delete" to remove all of them which would include some production buckets that I'm not quite sure how to verify are stale? Another thought that I had is maybe if I were to reshard all the buckets up to the next prime now that we're on single zone would that guarantee that all the stale instances are actually stale? Any thoughts and tips would be much appreciated.
Thanks, Rich
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
participants (2)
-
Casey Bodley
-
Richard Bade