Thanks Jeff. How do I determine that bootstrap is finished? Haven't seen that anywhere so far.
Reads via storage would be ok as every query would be checked by another node too. I was only seeing inconsistencies since clients went directly to the node with Consistency ONE Greetings Jeff Jirsa <jji...@gmail.com> schrieb am Mi. 2. Aug. 2017 um 16:01: > By the time bootstrap is complete it should be as consistent as the source > node - you can change start_native_transport to false to avoid serving > clients directly (tcp/9042), but it'll still serve reads via the storage > service (tcp/7000), but the guarantee is that data should be consistent by > the time bootstrap finishes > > > > > -- > Jeff Jirsa > > > > On Aug 2, 2017, at 1:53 AM, Daniel Hölbling-Inzko < > daniel.hoelbling-in...@bitmovin.com> wrote: > > > > Hi, > > It's probably a strange question but I have a heavily read-optimized > payload where data integrity is not a big deal. So to keep latencies low I > am reading with Consistency ONE from my Multi-DC Cluster. > > > > Now the issue I saw is that I needed to add another Cassandra node (for > redundancy reasons). > > Since I want this for renduncancy I booted the node and then changed the > Replication of my Keyspace to include the new node (all nodes have 100% of > the data). > > > > The issue I was seeing is that clients that connected to the new Node > afterwards were seeing incomplete data - so the Key would already be > present, but the columns would all be null values. > > I expect this to die down once the node is fully replicated, but in the > meantime a lot of my connected clients were in trouble. (The application > can handle seeing old data - incomplete is another matter all together) > > > > The total data in question is a negligible 500kb (so nothing that should > really take any amount of time in my opinion but it took a few minutes for > the data to replicate over and I am still not sure everything is replicated > correctly). > > > > Increasing the RF to something higher won't really help as the setup is > dc1: 3; dc2: 2 (I added the second node in dc2). So a LOCAL_QUORUM in dc2 > would still be 2 nodes which means I just can't loose either of them. > Adding a third node is not really cost effective for the current workloads > these nodes need to handle. > > > > Any advice on how to avoid this in the future? Is there a way to start > up a node that does not serve client requests but does replicate data? > > > > greetings Daniel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
