void-ptr974 commented on PR #25774: URL: https://github.com/apache/pulsar/pull/25774#issuecomment-4543717548
Thanks, the rationale for keeping cursor/schema migration symmetric makes sense. One related question: should preserving the exact same ledgerId on the target BK cluster be a hard requirement of the design, or mainly an implementation simplification? If the target BK cluster is not empty, or is already serving other topics/tenants, the source ledgerId may already exist there. Since different BK clusters normally have independent ledgerId allocation spaces, a same-ledgerId copy seems to require an additional invariant: the target cluster must either reserve/import those ledgerIds safely, or guarantee that they cannot collide with existing/future ledgerIds. An alternative would be to allow the copied ledger to get a new target ledgerId and explicitly persist a source-ledger/source-position → target-ledger/target-position mapping. That would make PROMOTE/ROLLBACK and schema/cursor lookup more complex, but it may make the feature applicable to a wider set of real deployments where the target BK cluster is not dedicated or empty. I’m not saying the PIP must choose this approach, but it may be worth documenting why the design intentionally requires same-ledgerId copy, and what assumptions are required for it to be safe. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
