Hi folks,
It appears that we have multiple ways to disable/enable bucket sync. Either from "bucket sync disable/enable", which can run without bucket-specific sync policy. Or from "sync group create/modify" with --status=allowed/enabled/forbidden. What is the relationship between the two?
I notice that after I did "bucket sync disable" on a bucket and then enabling it with "sync group create --status=enabled", "bucket sync status" shows the status of all related pipes and it claims all 11 shards are behind, which is a bit strange since my bucket only has 4 objects. The sync status looks the same in both zones that are involved in the newly create sync policy. It appears to be bogus since both cannot be behind to the other.
Then I run "bucket sync init" in both zones and that changes the sync status as "init: bucket sync has not started". "bucket sync run" that follows this step changes the sync status again to be "stopped: bucket sync is disabled".
It seems to be some disconnect between the effect of "bucket sync disable" and sync policy. The latter wonders around and eventually figures out that the bucket sync has been disabled. The plus side is that sync never happens so it is truly disabled. After I use "bucket sync enable" to enable it, eventually the bucket is synced up between the two zones without explicit run of "bucket sync run" again.
So, what is the relationship between these two ways and what is recommended practice of using them together?
Thanks,
Yixin
Hi folks,
What is the purpose of this command? It is always stuck and its debug log shows that it couldn't get locks on mdlog.sync-status* objects, which are constantly locked by the running radosgw process (every 60 seconds, it will ensure it gets the lock). It appears that RGWMetaSyncShardCR::incremental_sync() never gets out of the do-while loop until can_adjust_marker is false, which is only set as such when one of its children returns an error. So, it seems that during normal operation, this loop never ends. Thus, it always holds sync status object locks, thus renders this command useless. Or did I use it wrong?
Thanks,
Yixin
On Wed, Apr 12, 2023 at 12:32 PM Marc <Marc(a)f1-outsourcing.eu> wrote:
> >
> > We are excited to share with you the latest statistics from our Ceph
> > public telemetry dashboards <https://telemetry-public.ceph.com/> .
>
> :)
>
> > One of the things telemetry helps us to understand is version adoption
> > rate. See, for example, the trend of Quincy <https://telemetry-
> > public.ceph.com/d/ZFYuv1qWz/telemetry?viewPanel=28&orgId=1&var-
> > display=Minor&var-major=17&var-minor=All&var-daemons=All> deployments
> > in the community.
> >
>
> What is the 'weird' drop at the 5th of February?
>
> It is due to issues we had with the lab, the service was a bit unstable.
> > Ceph telemetry is on an opt-in basis. You can opt-in with:
> > `ceph telemetry on`
> > Learn more here
> > <https://docs.ceph.com/en/latest/mgr/telemetry/#enabling-telemetry> .
> >
> > Help us cross the exabyte mark by opting-in today!
> > Learn more about the latest developments around Telemetry
> > <https://sched.co/1JKZ2> at the upcoming Cephalocon.
> >
>
> :)
> _______________________________________________
> ceph-users mailing list -- ceph-users(a)ceph.io
> To unsubscribe send an email to ceph-users-leave(a)ceph.io
>
>
