RE: Question about replica and replication factor
Great explanation! For the single partition read, it makes sense to read data from only one replica. Thank you so much Ben! Jun From: ben.sla...@instaclustr.com Date: Tue, 20 Sep 2016 05:30:43 + Subject: Re: Question about replica and replication factor To: wuxiaomi...@hotmail.com CC: user@cassandra.apache.org “replica” here means “a node that has a copy of the data for a given partition”. The scenario being discussed hear is CL > 1. In this case, rather than using up network and processing capacity sending all the data from all the nodes required to meet the consistency level, Cassandra gets the full data from one replica and checksums from the others. Only if the checksums don’t match the full data does Cassandra need to get full data from all the relevant replicas. I think the other point here is, conceptually, you should think of the coordinator as splitting up any query that hits multiple partitions into a set of queries, one per partition (there might be some optimisations that make this not quite physically correct but conceptually it’s about right). Discussion such as the one you quote above tend to be considering a single partition read (which is the most common kind of read in most uses of Cassandra). CheersBen On Tue, 20 Sep 2016 at 15:18 Jun Wu <wuxiaomi...@hotmail.com> wrote: Yes, I think for my case, at least two nodes need to be contacted to get the full set of data. But another thing comes up about dynamic snitch. It's the wrapped snitch and enabled by default and it'll choose the fastest/closest node to read data from. Another post is about this.http://www.datastax.com/dev/blog/dynamic-snitching-in-cassandra-past-present-and-future The thing is why it's still emphasis only one replica to read data from. Below is from the post: To begin, let’s first answer the most obvious question: what is dynamic snitching? To understand this, we’ll first recall what a snitch does. A snitch’s function is to determine which datacenters and racks are both written to and read from. So, why would that be ‘dynamic?’ This comes into play on the read side only (there’s nothing to be done for writes since we send them all and then block to until the consistency level is achieved.) When doing reads however, Cassandra only asks one node for the actual data, and, depending on consistency level and read repair chance, it asks the remaining replicas for checksums only. This means that it has a choice of however many replicas exist to ask for the actual data, and this is where the dynamic snitch goes to work.Since only one replica is sending the full data we need, we need to chose the best possible replica to ask, since if all we get back is checksums we have nothing useful to return to the user. The dynamic snitch handles this task by monitoring the performance of reads from the various replicas and choosing the best one based on this history. Sent from my iPadOn Sep 20, 2016, at 00:03, Ben Slater <ben.sla...@instaclustr.com> wrote: If your read operation requires data from multiple partitions and the partitions are spread across multiple nodes then the coordinator has the job of contacting the multiple nodes to get the data and return to the client. So, in your scenario, if you did a select * from table (with no where clause) the coordinator would need to contact and execute a read on at least one other node to satisfy the query. CheersBen On Tue, 20 Sep 2016 at 14:50 Jun Wu <wuxiaomi...@hotmail.com> wrote: Hi Ben, Thanks for the quick response. It's clear about the example for single row/partition. However, normally data are not single row. Then for this case, I'm still confused. http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsRead_c.html The link above gives an example of 10 nodes cluster with RF = 3. But the figure and the words in the post shows that the coordinator only contact/read data from one replica, and operate read repair for the left replicas. Also, how could read accross all nodes in the cluster? Thanks! Jun From: ben.sla...@instaclustr.com Date: Tue, 20 Sep 2016 04:18:59 + Subject: Re: Question about replica and replication factor To: user@cassandra.apache.org Each individual read (where a read is a single row or single partition) will read from one node (ignoring read repairs) as each partition will be contained entirely on a single node. To read the full set of data, reads would hit at least two nodes (in practice, reads would likely end up being distributed across all the nodes in your cluster). CheersBen On Tue, 20 Sep 2016 at 14:09 Jun Wu <wuxiaomi...@hotmail.com> wrote: Hi there, I have a question about the replica and replication factor. For example, I have a cluster of 6 nodes in the same data center. Replication factor RF is set to 3 and the consistency level is default 1. According to this calculator http://www.ecyrd.com/
Re: Question about replica and replication factor
Yes, I think for my case, at least two nodes need to be contacted to get the full set of data. But another thing comes up about dynamic snitch. It's the wrapped snitch and enabled by default and it'll choose the fastest/closest node to read data from. Another post is about this. http://www.datastax.com/dev/blog/dynamic-snitching-in-cassandra-past-present-and-future The thing is why it's still emphasis only one replica to read data from. Below is from the post: To begin, let’s first answer the most obvious question: what is dynamic snitching? To understand this, we’ll first recall what a snitch does. A snitch’s function is to determine which datacenters and racks are both written to and read from. So, why would that be ‘dynamic?’ This comes into play on the read side only (there’s nothing to be done for writes since we send them all and then block to until the consistency level is achieved.) When doing reads however, Cassandra only asks one node for the actual data, and, depending on consistency level and read repair chance, it asks the remaining replicas for checksums only. This means that it has a choice of however many replicas exist to ask for the actual data, and this is where the dynamic snitch goes to work. Since only one replica is sending the full data we need, we need to chose the best possible replica to ask, since if all we get back is checksums we have nothing useful to return to the user. The dynamic snitch handles this task by monitoring the performance of reads from the various replicas and choosing the best one based on this history. Sent from my iPad > On Sep 20, 2016, at 00:03, Ben Slater <ben.sla...@instaclustr.com> wrote: > > If your read operation requires data from multiple partitions and the > partitions are spread across multiple nodes then the coordinator has the job > of contacting the multiple nodes to get the data and return to the client. > So, in your scenario, if you did a select * from table (with no where clause) > the coordinator would need to contact and execute a read on at least one > other node to satisfy the query. > > Cheers > Ben > >> On Tue, 20 Sep 2016 at 14:50 Jun Wu <wuxiaomi...@hotmail.com> wrote: >> Hi Ben, >> >> Thanks for the quick response. >> >> It's clear about the example for single row/partition. However, normally >> data are not single row. Then for this case, I'm still confused. >> http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsRead_c.html >> >> The link above gives an example of 10 nodes cluster with RF = 3. But the >> figure and the words in the post shows that the coordinator only >> contact/read data from one replica, and operate read repair for the left >> replicas. >> >> Also, how could read accross all nodes in the cluster? >> >> Thanks! >> >> Jun >> >> >> From: ben.sla...@instaclustr.com >> Date: Tue, 20 Sep 2016 04:18:59 + >> Subject: Re: Question about replica and replication factor >> To: user@cassandra.apache.org >> >> >> Each individual read (where a read is a single row or single partition) will >> read from one node (ignoring read repairs) as each partition will be >> contained entirely on a single node. To read the full set of data, reads >> would hit at least two nodes (in practice, reads would likely end up being >> distributed across all the nodes in your cluster). >> >> Cheers >> Ben >> >> On Tue, 20 Sep 2016 at 14:09 Jun Wu <wuxiaomi...@hotmail.com> wrote: >> Hi there, >> >> I have a question about the replica and replication factor. >> >> For example, I have a cluster of 6 nodes in the same data center. >> Replication factor RF is set to 3 and the consistency level is default 1. >> According to this calculator http://www.ecyrd.com/cassandracalculator/, >> every node will store 50% of the data. >> >> When I want to read all data from the cluster, how many nodes should I >> read from, 2 or 1? Is it 2, because each node has half data? But in the >> calculator it show 1: You are really reading from 1 node every time. >> >>Any suggestions? Thanks! >> >> Jun >> -- >> >> Ben Slater >> Chief Product Officer >> Instaclustr: Cassandra + Spark - Managed | Consulting | Support >> +61 437 929 798 > > -- > > Ben Slater > Chief Product Officer > Instaclustr: Cassandra + Spark - Managed | Consulting | Support > +61 437 929 798
RE: Question about replica and replication factor
Hi Ben, Thanks for the quick response. It's clear about the example for single row/partition. However, normally data are not single row. Then for this case, I'm still confused. http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsRead_c.html The link above gives an example of 10 nodes cluster with RF = 3. But the figure and the words in the post shows that the coordinator only contact/read data from one replica, and operate read repair for the left replicas. Also, how could read accross all nodes in the cluster? Thanks! Jun From: ben.sla...@instaclustr.com Date: Tue, 20 Sep 2016 04:18:59 + Subject: Re: Question about replica and replication factor To: user@cassandra.apache.org Each individual read (where a read is a single row or single partition) will read from one node (ignoring read repairs) as each partition will be contained entirely on a single node. To read the full set of data, reads would hit at least two nodes (in practice, reads would likely end up being distributed across all the nodes in your cluster). CheersBen On Tue, 20 Sep 2016 at 14:09 Jun Wu <wuxiaomi...@hotmail.com> wrote: Hi there, I have a question about the replica and replication factor. For example, I have a cluster of 6 nodes in the same data center. Replication factor RF is set to 3 and the consistency level is default 1. According to this calculator http://www.ecyrd.com/cassandracalculator/, every node will store 50% of the data. When I want to read all data from the cluster, how many nodes should I read from, 2 or 1? Is it 2, because each node has half data? But in the calculator it show 1: You are really reading from 1 node every time. Any suggestions? Thanks! Jun -- Ben SlaterChief Product OfficerInstaclustr: Cassandra + Spark - Managed | Consulting | Support+61 437 929 798
Question about replica and replication factor
Hi there, I have a question about the replica and replication factor. For example, I have a cluster of 6 nodes in the same data center. Replication factor RF is set to 3 and the consistency level is default 1. According to this calculator http://www.ecyrd.com/cassandracalculator/, every node will store 50% of the data. When I want to read all data from the cluster, how many nodes should I read from, 2 or 1? Is it 2, because each node has half data? But in the calculator it show 1: You are really reading from 1 node every time. Any suggestions? Thanks! Jun
RE: How to get information of each read/write request?
Hi Chris, Thank you so much for the reply. For the tracing on in cqlsh, it gives a very high-level information. I do need more other detailed information. For the ticket, that's exactly what I want: the waiting time for the thread pool queue. Actually I do want to the waiting time for each stage for each query. That could be awesome. Again, your information is quite useful. Thanks! Jun From: clohfin...@gmail.com Date: Tue, 30 Aug 2016 14:31:17 -0500 Subject: Re: How to get information of each read/write request? To: user@cassandra.apache.org Running a query with trace (`TRACING ON` in cqlsh) can give you a lot of the information for an individual request. There has been a ticket to track time in queue (https://issues.apache.org/jira/browse/CASSANDRA-8398) but no ones worked on it yet. Chris On Tue, Aug 30, 2016 at 12:20 PM, Jun Wu <wuxiaomi...@hotmail.com> wrote: Hi there, I'm very interested in the read/write path of Cassandra. Specifically, I'd like to know the whole process when a read/write request comes in. I noticed that for reach request it could go through multiple stages. For example, for read request, it could be in ReadStage, RequestResponseStage, ReadRepairStage. For each stage, actually it's a queue and thread pool to serve the request. First question is how to track each request in which stage.Also I'm very interested int the waiting time for each request to be in the queue, also the total queue in each stage. I noticed that in nodetool tpstats will have this information. However, I may want to get the real-time information of this, like print it out in the terminal. I'm wondering whether someone has hints on this. Thanks in advance! Jun
RE: How to get information of each read/write request?
Hi Matija, Thank you so much for the reply. The zipking seems to be a very useful tool and I'll take a close look at it. Meanwhile, I know how to use the Jconsole to get the information exposing to JMX. However, for the Jconsole, I need to click the refresh button to get the updated value for each metrics. I'm wondering whether there's a convenient way that I can print the time-series value out through the terminal of some metrics. Thanks! Jun From: matija0...@gmail.com Date: Tue, 30 Aug 2016 21:08:45 +0200 Subject: Re: How to get information of each read/write request? To: user@cassandra.apache.org Hi Jun, If you are looking to track each request zipking is your best bet. The last pickle has a blog about tracing using zipkin.Regarding the stats you see in nodetool did you check the metrics package in cassandra and what it exposes over JMX? Regards,Matija On Tue, Aug 30, 2016 at 7:20 PM, Jun Wu <wuxiaomi...@hotmail.com> wrote: Hi there, I'm very interested in the read/write path of Cassandra. Specifically, I'd like to know the whole process when a read/write request comes in. I noticed that for reach request it could go through multiple stages. For example, for read request, it could be in ReadStage, RequestResponseStage, ReadRepairStage. For each stage, actually it's a queue and thread pool to serve the request. First question is how to track each request in which stage.Also I'm very interested int the waiting time for each request to be in the queue, also the total queue in each stage. I noticed that in nodetool tpstats will have this information. However, I may want to get the real-time information of this, like print it out in the terminal. I'm wondering whether someone has hints on this. Thanks in advance! Jun
How to get information of each read/write request?
Hi there, I'm very interested in the read/write path of Cassandra. Specifically, I'd like to know the whole process when a read/write request comes in. I noticed that for reach request it could go through multiple stages. For example, for read request, it could be in ReadStage, RequestResponseStage, ReadRepairStage. For each stage, actually it's a queue and thread pool to serve the request. First question is how to track each request in which stage.Also I'm very interested int the waiting time for each request to be in the queue, also the total queue in each stage. I noticed that in nodetool tpstats will have this information. However, I may want to get the real-time information of this, like print it out in the terminal. I'm wondering whether someone has hints on this. Thanks in advance! Jun
How to understand of dynamic snitch update interval?
Hi there, I have a question for dynamic snitch, specifically in reading. For dynamic snitch, it is wrapped with other snitches. For reading, dynamic snitch plays a very important role, as mentioned in this article: http://www.datastax.com/dev/blog/dynamic-snitching-in-cassandra-past-present-and-future But I do feel confused by the update interval in it. The default dynamic update interval is 100 ms. Does it means every 100 ms it'll calculate the score based on the history latency. But we know that for each read request, the process/service time is much less than 100ms. So during this 100ms, there's tons of read requests being processed, where each request may have a latency record. So my questions are: 1. For the history latency, is it based on all latency information of the past 100 ms, or only a latest few samples? 2. After the score calculation, does it means for the lowest score/node, it will be choose as the replica to read from in the next 100ms. Then after next 100ms, the score will be recalculated and repeat the whole process? Any comment would be appreciated. Thanks in advance! Jun
RE: How to print out the metrics information, like compaction and garbage collection?
Hi Otis, Thank you so much for the reply. I do appreciate it. Actually, I've tried the sematext spm few days ago:) It works well and is easy to deploy. However, in the monitoring output figure for different metrics, the interval is 1 minute, which is longer than I want. What I want is something like one metric value / second and I want to have a close eye on each metric. That's why I post question and want to print out the metrics information in the console. I'm wondering whether you have any other solution for my question. Thanks! Jun From: otis.gospodne...@gmail.com Date: Tue, 14 Jun 2016 15:01:20 -0400 Subject: Re: How to print out the metrics information, like compaction and garbage collection? To: user@cassandra.apache.org Hi Jun, Here's a tool for dumping JMX contents: https://github.com/sematext/jmxcHere's a tool/service for monitoring Cassandra: https://sematext.com/spm/integrations/cassandra-monitoring/Otis -- Monitoring - Log Management - Alerting - Anomaly DetectionSolr & Elasticsearch Consulting Support Training - http://sematext.com/ On Mon, Jun 13, 2016 at 5:17 PM, Jun Wu <wuxiaomi...@hotmail.com> wrote: Hi there, I've deployed 6 node in Amazon EC2. I'm trying to monitor some metrics for each node and print them out when I write/read data into Cassandra. Specifically I want to print out the information about garbage collection and compaction. I do notice that there's metrics for compaction in o.a.c.metrics. CompactionMetrics.java. But I don't know how to get them, I've tried method below: CompactionMetrics metrics = new CompactionMetrics(); System.out.println(metrics.pendingtasks); But it doesn't work. * Another/same question is about the garbage collection, any idea on where should I refer to and get the information about garbage collection, like garbage collection count, collection time, etc. Any hint will be appreciated. Thanks! Jun
How to print out the metrics information, like compaction and garbage collection?
Hi there, I've deployed 6 node in Amazon EC2. I'm trying to monitor some metrics for each node and print them out when I write/read data into Cassandra. Specifically I want to print out the information about garbage collection and compaction. I do notice that there's metrics for compaction in o.a.c.metrics. CompactionMetrics.java. But I don't know how to get them, I've tried method below: CompactionMetrics metrics = new CompactionMetrics(); System.out.println(metrics.pendingtasks); But it doesn't work. * Another/same question is about the garbage collection, any idea on where should I refer to and get the information about garbage collection, like garbage collection count, collection time, etc. Any hint will be appreciated. Thanks! Jun
RE: Snitch for AWS EC2 nondefaultVPC
I've worked on some experiments with AWS EC2. According to the doc you provided and from my own experience, EC2Multiregionsnitich should be the right setting as you have 2 different datacenters. In cassandra.yaml: change seeds to public address list, change listen and rpc address to private address, change broadcast address to public address, use Ec2MultiRegionSnitch. Hope it works! Date: Tue, 1 Mar 2016 15:12:04 -0500 Subject: Snitch for AWS EC2 nondefaultVPC From: arunsandu...@gmail.com To: user@cassandra.apache.org Hi all, All our nodes are launched in AWS EC2 VPC (private). We have 2 datacenters(1 us-east , 1- asiapacific) and all communication is through private IP's and don't have any public IPs. What is the recommended snitch to be used? We currently have GossipingPropertyFileSnitch. 1. If Ec2MultiRegionSnitch, then what would be the broadcast_address? 2. If not Ec2MultiRegionSnitch, which snitch better fits this environment? Ref: As per the document Ec2MultiRegionSnitch,set the listen_address to the private IP address of the node, and the broadcast_address to the public IP address of the node. -- Thanks Arun
Re: Questions about the replicas selection and remote coordinator
Hi Steve, Thank you so much for your kind reply and now it makes more sense. But for the remote coordinator issue, it’s definitely a interesting topic. If you have any other conclusion on this. I’d be pretty happy to learn from you. Thanks again! Jun > On Jan 29, 2016, at 13:09, Steve Robenalt <sroben...@highwire.org> wrote: > > Hi Jun, > > The replicas are chosen according to factors that are generally more easily > selected internally, as is the case with coordinators. Even if the replicas > were selected in a completely round-robin fashion initially, they could end > up being re-distributed as a result of node failures, additions/removals > to/from the cluster, etc, particularly when vnodes are used. As such, the > diagrams and the nodes they refer to are hypothetical, but accurate in the > sense that they are non-contiguous, and that different sets of replicas are > distributed to various parts of the cluster. > > As far as the remote coordinator is concerned, I'm not sure what motivated > the change from 1.2 to 2.1 and would be interested in understanding that > change myself. I do know that improved performance was a big part of the 2.1 > release, but I'm not sure if the change in coordinators was part of that > effort or not. > > Steve > > > On Fri, Jan 29, 2016 at 10:13 AM, Jun Wu <wuxiaomi...@hotmail.com > <mailto:wuxiaomi...@hotmail.com>> wrote: > Hi Steve, > >Thank you so much for your reply. > >Yes, you're right, I'm using the version of 2.1. So based on this, I think > I'm outdated. > > However, this comes to another interesting question: why we change this > part from version 1 to version 2. As we can see that in version 1, there's > connections from node 10 in DC 1 with node 10 in DC 2, then node 10 in DC 2 > send 3 copies to 3 nodes in DC 2, which should be more time-saving than > version 2.1, which send data from node 10 in DC 1 to 3 nodes in DC 2 directly. > > Also, is there any information on how to choose the replicas. Like here > https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsMultiDCWrites_c.html > > <https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsMultiDCWrites_c.html> > Why we choose node 1, 3, 6 as replicas and 4, 8, 11 as another 3 replicas? > > Also, is node 11 working as remote coordinator here? Or is the concept of > remote coordinator really existed, as the figure shows, we even don't need > the remote coordinator. > > Thanks! > > Jun > > > > > Date: Fri, 29 Jan 2016 09:55:58 -0800 > Subject: Re: Questions about the replicas selection and remote coordinator > From: sroben...@highwire.org <mailto:sroben...@highwire.org> > To: user@cassandra.apache.org <mailto:user@cassandra.apache.org> > > > Hi Jun, > > The 2 diagrams you are comparing come from versions of Cassandra that are > significantly different - 1.2 in the first case and 2.1 in the second case, > so it's not surprising that there are differences. since you haven't > qualified your question with the Cassandra version you are asking about, I > would assume that the 2.1 example is more representative of what you would be > likely to see. In any case, it's best to use a consistent version for your > documentation because Cassandra changes quite rapidly with many of the > releases. > > As far as choosing the coordinator node, I don't think there's a way to force > it, nor would it be a good idea to do so. In order to make a reasonable > selection of coordinators, you would need a lot of internal knowledge about > load on the nodes in the cluster and you'd need to also handle certain > classes of failures and retries, so you would end up duplicating what is > already being done for you internally. > > Steve > > > On Fri, Jan 29, 2016 at 9:11 AM, Jun Wu <wuxiaomi...@hotmail.com > <mailto:wuxiaomi...@hotmail.com>> wrote: > Hi there, > > I have some questions about the replicas selection. > > Let's say that we have 2 data centers: DC1 and DC2, the figure also be > got from link here: > https://docs.datastax.com/en/cassandra/1.2/cassandra/images/write_access_multidc_12.png > > <https://docs.datastax.com/en/cassandra/1.2/cassandra/images/write_access_multidc_12.png>. > There're 10 nodes in each data center. We set the replication factor to be 3 > and 3 in each data center, which means there'll be 3 and 3 replicas in each > data center. > > (1) My first question is how to choose which 3 nodes to write data to, in > the link above, the 3 replicas are node 1, 2, 7. But, is there any mec
RE: Questions about the replicas selection and remote coordinator
Hi Steve, Thank you so much for your reply. Yes, you're right, I'm using the version of 2.1. So based on this, I think I'm outdated. However, this comes to another interesting question: why we change this part from version 1 to version 2. As we can see that in version 1, there's connections from node 10 in DC 1 with node 10 in DC 2, then node 10 in DC 2 send 3 copies to 3 nodes in DC 2, which should be more time-saving than version 2.1, which send data from node 10 in DC 1 to 3 nodes in DC 2 directly. Also, is there any information on how to choose the replicas. Like here https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsMultiDCWrites_c.html Why we choose node 1, 3, 6 as replicas and 4, 8, 11 as another 3 replicas? Also, is node 11 working as remote coordinator here? Or is the concept of remote coordinator really existed, as the figure shows, we even don't need the remote coordinator. Thanks! Jun Date: Fri, 29 Jan 2016 09:55:58 -0800 Subject: Re: Questions about the replicas selection and remote coordinator From: sroben...@highwire.org To: user@cassandra.apache.org Hi Jun, The 2 diagrams you are comparing come from versions of Cassandra that are significantly different - 1.2 in the first case and 2.1 in the second case, so it's not surprising that there are differences. since you haven't qualified your question with the Cassandra version you are asking about, I would assume that the 2.1 example is more representative of what you would be likely to see. In any case, it's best to use a consistent version for your documentation because Cassandra changes quite rapidly with many of the releases. As far as choosing the coordinator node, I don't think there's a way to force it, nor would it be a good idea to do so. In order to make a reasonable selection of coordinators, you would need a lot of internal knowledge about load on the nodes in the cluster and you'd need to also handle certain classes of failures and retries, so you would end up duplicating what is already being done for you internally. Steve On Fri, Jan 29, 2016 at 9:11 AM, Jun Wu <wuxiaomi...@hotmail.com> wrote: Hi there, I have some questions about the replicas selection. Let's say that we have 2 data centers: DC1 and DC2, the figure also be got from link here: https://docs.datastax.com/en/cassandra/1.2/cassandra/images/write_access_multidc_12.png. There're 10 nodes in each data center. We set the replication factor to be 3 and 3 in each data center, which means there'll be 3 and 3 replicas in each data center. (1) My first question is how to choose which 3 nodes to write data to, in the link above, the 3 replicas are node 1, 2, 7. But, is there any mechanism to select these 3? (2) Another question is about the remote coordinator, the previous figure shows that node 10 in DC1 will write data to node 10 in DC 2, then node 10 in DC2 will write 3 copies to 3 nodes in DC2. But, another figure from datastax shows different method, the figure can be found here, https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsMultiDCWrites_c.html. It shows that node 10 in DC 1 will send directly 3 copies to 3 nodes in DC2, without using remote coordinator. I'm wondering which case is true, because in multiple data center, the time duration for these two methods varies a lot. Also, is there any mechanism to select which node to be remote coordinator? Thanks! Jun -- Steve Robenalt Software architectsroben...@highwire.org (office/cell): 916-505-1785 HighWire Press, Inc.425 Broadway St, Redwood City, CA 94063www.highwire.org Technology for Scholarly Communication
Questions about the replicas selection and remote coordinator
Hi there, I have some questions about the replicas selection. Let's say that we have 2 data centers: DC1 and DC2, the figure also be got from link here: https://docs.datastax.com/en/cassandra/1.2/cassandra/images/write_access_multidc_12.png. There're 10 nodes in each data center. We set the replication factor to be 3 and 3 in each data center, which means there'll be 3 and 3 replicas in each data center. (1) My first question is how to choose which 3 nodes to write data to, in the link above, the 3 replicas are node 1, 2, 7. But, is there any mechanism to select these 3? (2) Another question is about the remote coordinator, the previous figure shows that node 10 in DC1 will write data to node 10 in DC 2, then node 10 in DC2 will write 3 copies to 3 nodes in DC2. But, another figure from datastax shows different method, the figure can be found here, https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsMultiDCWrites_c.html. It shows that node 10 in DC 1 will send directly 3 copies to 3 nodes in DC2, without using remote coordinator. I'm wondering which case is true, because in multiple data center, the time duration for these two methods varies a lot. Also, is there any mechanism to select which node to be remote coordinator? Thanks! Jun
