Thanks for your explanation. The users should upgrade the client to ensure the subscription will be replicated when the namespace or topic level is set, this is the best practice.
Thanks, Zixuan PengHui Li <peng...@apache.org> 于2024年12月24日周二 13:03写道： > > This depends on the consumer's `replicateSubscriptionState` value, when > the > consumer restarts with true or false, this subscription replication > configuration will be reverted, and when there are multiple tenants, > namespace, topic, and subscription, this workload is tedious. > > So I mentioned before, the `replicateSubscriptionState` from consumer API > should > only take effect on the auto-created subscription. If should not change the > configuration > of existing subscriptions. > > > For the new client, `replicateSubscriptionState` defaults to `null`, > while > the old client defaults to `false`, please see > https://github.com/apache/pulsar/pull/23757. > > Yes, I checked this PR before and it looks good to me. > > > The old client cannot use namespace and topic levels configurations, as > it > always sets `replicateSubscriptionState` to `false`. This is the reason we > propose ignoring the consumer configuration, ensuring that replication is > controlled by the namespace or topic-level settings instead. > > User should upgrade their client, and we can also discuss to cherry-pick > https://github.com/apache/pulsar/pull/23757 to the LTS version. > But for long-term consideration, we should make the Admin API > easy to understand and simple. We should not let users check many > places to understand why the replicateSubscriptionState is enabled or not. > > Regards, > Penghui > > > > On Mon, Dec 23, 2024 at 8:06 PM Zixuan Liu <node...@gmail.com> wrote: > > > > The reason is we don't have consumer-level control of the replicate > > subscription state, it's subscription-level control. > > > > Correct. > > > > > With this solution, you can enable or disable the replicate > subscription > > state with Admin API for the existing topics/subscriptions. > > > > This depends on the consumer's `replicateSubscriptionState` value, when > the > > consumer restarts with true or false, this subscription replication > > configuration will be reverted, and when there are multiple tenants, > > namespace, topic, and subscription, this workload is tedious. > > > > For the new client, `replicateSubscriptionState` defaults to `null`, > while > > the old client defaults to `false`, please see > > https://github.com/apache/pulsar/pull/23757. > > > > The old client cannot use namespace and topic levels configurations, as > it > > always sets `replicateSubscriptionState` to `false`. This is the reason > we > > propose ignoring the consumer configuration, ensuring that replication is > > controlled by the namespace or topic-level settings instead. > > > > Thanks, > > Zixuan > > > > PengHui Li <peng...@apache.org> 于2024年12月24日周二 09:01写道： > > > > > Hi Zixuan, > > > > > > Thanks for bringing the discussion here. After going through the > context > > > and discussions > > > from https://github.com/apache/pulsar/pull/23770 and > > > https://github.com/apache/pulsar/pull/23769. > > > It looks like we can improve the option "replicateSubscriptionState" to > > > make it only work for the newly created subscription. > > > The reason is we don't have consumer-level control of the replicate > > > subscription state, it's subscription-level control. > > > > > > With this solution, you can enable or disable the replicate > subscription > > > state with Admin API for the existing topics/subscriptions. > > > And we also don't need to introduce another Admin API mode to replicate > > the > > > subscription state on the cluster level which ignores > > > the configurations from the consumer. > > > > > > Regards, > > > Penghui > > > > > > On Mon, Dec 23, 2024 at 12:20 AM Lari Hotari <lhot...@apache.org> > wrote: > > > > > > > This PIP is very useful. > > > > > > > > One weakness of this PIP is that it would require client upgrades > > before > > > it > > > > would be effective. > > > > To achieve the desired outcome, I think it would be useful to have a > > way > > > to > > > > override the consumer-side setting and enable subscription > replication > > > for > > > > all topics in a namespace, regardless of the consumer-side setting. > > > > > > > > There's a separate recent PR about enabling subscription replication > > > > globally at the broker level, > > > https://github.com/apache/pulsar/pull/23769. > > > > I wonder if there's a need for a global broker-level configuration? > > > Zixuan, > > > > would you mind reviewing that PR? > > > > Since this recent PR #23769 is in the same area, I think it would > make > > > > sense to combine the work in a single PIP to ensure that we achieve > > > > consistency across the changes. > > > > > > > > -Lari > > > > > > > > On Mon, 23 Dec 2024 at 10:08, Zixuan Liu <zix...@apache.org> wrote: > > > > > > > > > Hi, Pulsar community, > > > > > > > > > > Subscription replication is an important feature in the failover > > > > scenario, > > > > > I made a PIP to add the subscription replication feature on the > > > namespace > > > > > and topic levels. > > > > > > > > > > PIP: https://github.com/apache/pulsar/pull/23770 > > > > > > > > > > Thanks, > > > > > Zixuan > > > > > > > > > > > > > > >
