Re: Guidance to downgrade the stateful Kafka stream application?

2020-12-17 Thread Sophie Blee-Goldman
Hey Ming,

There should not be any issues in downgrading from 2.5 to 2.2, and if
you stayed on the eager protocol then you can do the downgrade in a
single rolling bounce.

It sounds like your main concern here is with the RocksDB version bump,
and whether there would be any problems reading/opening a newer version
of rocksdb using an older version? AFAICT this should not be the case,
especially if you haven't made any config changes or tried to leverage new
features that are only present in the newer version of rocksdb. We also
only bumped the rocksdb version by a small amount. There was no major
version change or any compatibility-breakage that we are aware of.

If you're paranoid, or if you do happen to run into an issue after
downgrading,
you can always just wipe out the local state stores. Streams will rebuild
all
local rocksdb instances from scratch from the changelog topic.

Best,
Sophie

On Thu, Dec 17, 2020 at 11:59 AM Ming Liu  wrote:

> Hi Team,
> I can't find any documentation or guidance on the expectation of the
> downgrade of stateful Kafka stream application (which has different rocksdb
> versions embedded).
> For example, if we upgrade from 2.2 to 2.5 (with binary upgrade only
> and using the same eager protocol) and somehow found some problem and
> downgrade to 2.2. What is the expectation?
>
> Thanks!
> Ming
>


Guidance to downgrade the stateful Kafka stream application?

2020-12-17 Thread Ming Liu
Hi Team,
I can't find any documentation or guidance on the expectation of the
downgrade of stateful Kafka stream application (which has different rocksdb
versions embedded).
For example, if we upgrade from 2.2 to 2.5 (with binary upgrade only
and using the same eager protocol) and somehow found some problem and
downgrade to 2.2. What is the expectation?

Thanks!
Ming