cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Petrov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14405) Transient Replication: Metadata refactor
Date Thu, 26 Jul 2018 17:19:00 GMT


Alex Petrov commented on CASSANDRA-14405:

First of all, awesome work Ariel and Blake. Patches look great and this whole project looks
extremely impressive, was a big pleasure to review it.

I've pushed reviewed branch with some changes and fixes [here|],
waiting for a CI run. 

I also have some more general remarks:
  * I'd propose to leave everything repair-related out of this patch for now, like changes
to [PendingRepairManager|]
for example. We'll need to do even more repair-related work, both on streaming and cleanup
side, and we'll be able to test it better if we concentrate at one thing at a time.
  * the way {{AbstractWriteResponseHandler}} is currently implemented and indirection in {{getInitialRecipients}}
that would actually initialise a speculation context that will later be used in {{maybeTryAdditionalReplicas}}
is difficult to see from the API. I understand that currently response handler is an abstract
class and this is most likely why it was not possible to implement it in a more direct way,
like in a wrapper class similar to how batches are done in storage proxy. I'd try to remove
hidden dependency between the two methods or abstract them into an independent entity.
  * we need more dtests for speculative execution on read path.
  * it seems that {{BlockingReadRepairs}} class might be redundant. Read/repair hierarchy
is already quite complex and having an extra class with similar name might make it harder
to find things.
  * we now have a mechanism of sending more data requests {{maybeSendAdditionalDataRequests}},
and later we can also send additional repairs in {{maybeSendAdditionalRepairs}}. In this case
we're taking more candidate replicas from the ones that we haven't yet seen and send updates
to them. Since this doesn't seem to be a transient replication-related. Why do we need this
mechanism and why can't we rely on previously existing repair paths?

> Transient Replication: Metadata refactor
> ----------------------------------------
>                 Key: CASSANDRA-14405
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core, Distributed Metadata, Documentation and Website
>            Reporter: Ariel Weisberg
>            Assignee: Blake Eggleston
>            Priority: Major
>             Fix For: 4.0
> Add support to CQL and NTS for configuring keyspaces to have transient replicas.
> Add syntax allowing a keyspace using NTS to declare some replicas in each DC as transient.
> Implement metadata internal to the DB so that it's possible to identify what replicas
are transient for a given token or range.
> Introduce Replica which is an InetAddressAndPort and a boolean indicating whether the
replica is transient. ReplicatedRange which is a wrapper around a Range that indicates if
the range is transient.
> Block altering of keyspaces to use transient replication if they already contain MVs
or 2i.
> Block the creation of MV or 2i in keyspaces using transient replication.
> Block the creation/alteration of keyspaces using transient replication if the experimental
flag is not set.
> Update web site, CQL spec, and any other documentation for the new syntax.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message