Hi,
One of the most important operational features of Cassandra is how easy it
is (or should be) to do an in-place upgrade. The in-place upgrade procedure
essentially consists of rolling-restarting the cluster while updating the
jar to the new version, while following additional upgrade instructio
Was drafting up a VOTE thread and have one thing I want to add - anyone think
of any major issues w/this I'm missing?
• All supported branches are *built on the oldest JDK they support*. Our
support model is: build on single JDK, run on oldest up to current LTS
On Sat, Jun 7, 2025, at 10:53 AM,
This makes sense to me. The release scripts confirm the JDK being used
now, and this was the impetus to add that.
Kind Regards,
Brandon
On Tue, Jun 10, 2025 at 8:09 AM Josh McKenzie wrote:
>
> Was drafting up a VOTE thread and have one thing I want to add - anyone think
> of any major issues w/
> Extra row in MV (assuming the tombstone is gone in the base table) — how
> should we fix this?
>
>
>
This would mean that the base table had either updated or deleted a row and the
view didn't receive the corresponding delete.
In the case of a missed update, we'll have a new value and we
Okay, let’s put the efficiency discussion on hold for now. I want to make
sure the actual repair process after detecting inconsistencies will work
with the index-based solution.
When a mismatch is detected, the MV replica will need to stream its index
file to the base table replica. The base table
