Makes sense, just wondering if the behavior should only be enabled when 
config.isSchemaLedgerForceRecovery() == true (PIP-327)?

-Lari

On 2024/10/09 04:51:23 Rajan Dhabalia wrote:
> >> When the schemas of a topic are lost, all of the messages in the topic
> can not be consumed successfully, and producers can not publish messages
> anymore.
> 
> Well, there are already many issues created related to the lost schema
> ledgers so, it is a very well known issue that the topic becomes
> unavailable and producers are not able to publish messages anymore just
> because of server issues which is extremely critical for mission critical
> usecases and not acceptable as well. Because of that brokers must be fault
> tolerant to recover in case of missing ledgers. Broker already handles such
> issues during manged-ledger or managed-cursor legers but it should also
> handle in case of schema ledger as well and make sure that broker won't
> impact topic's unavailability. It is also very important to just not rely
> on operational effort to fix such unavailability issues manually but broker
> should have a mechanism to recover by itself,
> Therefore, this PR is important to make sure tenants don't face topic
> unavailability due to well known issues of missing schema ledgers.
> 
> Thanks,
> Rajan
> 
> On Tue, Oct 8, 2024 at 8:29 PM Yubiao Feng
> <yubiao.f...@streamnative.io.invalid> wrote:
> 
> > Hi all
> >
> > Background: When the schemas of a topic are lost, all of the messages in
> > the topic can not be consumed successfully, and producers can not publish
> > messages anymore. This mechanism alerts users to try to recover their
> > schemas or recreate their topics.
> >
> > https://github.com/apache/pulsar/pull/23395 added a patch: producers will
> > rebuild schemas if the original schemas were lost, which will mix the old
> > schema and new schema as the same schema ID. For example:
> > - send M1 with schema `Int32`, get schema id: `1`
> > - send M2 with schema `String`, get schema id: `2`
> > - schemas are lost
> > - send M3 with schema `String`, get schema id `1`
> >
> > The messages `M1` and `M3` use different schemas, but have the same schema
> > id, but users assume all things are fine, which is dangerous. So I want to
> > revert this PR.
> >
> > Thanks
> > Yubiao Feng
> >
> 

Reply via email to