Hi Petr,
If data corruption means accidental data deletions via Cassandra commands, you
have to restore entire cluster with latest snapshots. This may lead to data
loss as there may be valid updates after the snapshot was taken but before the
data deletion. Restoring single node with snapshot
This isn't about using the same UUID though. It's about the timestamp bits
in the UUID.
What the use case is for generating multiple UUIDs in a single row? Why do
you need to extract the timestamp out of both?
On Fri, Dec 2, 2016 at 10:24 AM Edward Capriolo
wrote:
>
> On
On Thu, Dec 1, 2016 at 11:09 AM, Sylvain Lebresne
wrote:
> On Thu, Dec 1, 2016 at 4:44 PM, Edward Capriolo
> wrote:
>
>>
>> I am not sure you saw my reply on thread but I believe everyone's needs
>> can be met I will copy that here:
>>
>
> I saw it,
These issues exist since the very first implementation of MVs in *ALL* CS
versions.
If you want to use MVs, you may want to wait until these issues are
officially resolved. For testing or pre-prod, you could checkout
https://github.com/Jaumo/cassandra/commits/CASSANDRA-12905. I have fixed
these
All,
Many thanks for this enlightening thread.
We're about to go live with a client for a pre-production environment, and
must decide on which 3.x version to use. We will probably need to perform
regular repairs, so we are obviously worried about both CASSANDRA-12905 and
CASSANDRA-12888 that
No worries.
I added some patches to these tickets after having tested them yesterday
with our production cluster.
I think this will be a huge step for MV stability.
Anybody welcome to post comments on them or give me a review:
CASSANDRA-12888, CASSANDRA-12905, CASSANDRA-12984
Thanks folks!