Re: cpp driver warning for create keyspace statement
Michael, it looks like the issue was related to an invalid keyspace. After I dropped one keyspace (with an invalid datacenter name) and and altered another one the warning is gone. But I can not reproduce it, even when recreating the the previous keyspaces. Oliver 2018-02-02 18:41 GMT+01:00 Michael Fero : > Oliver, > > I have been unable to reproduce this issue using the cpp-driver against a > locally created Apache Cassandra cluster using CCM with proper > modifications to enable GosspingPropertyFileSnitch using the data centers > and racks defined by the `nodetool status` information provided. I would > suggest using CQLSH to query every nodes `system.local` and `system.peers` > tables to make sure they all have the same `data_center` attribute defined > as expected. > > NOTE: The only way that I was able to reproduce the issue using the default > data center aware with token awareness was to provide an invalid data > center name during the keyspace creation; however that is to be expected > since that data center would not exist or be known to the cluster. > > ~Fero > Michael Fero - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Coordinator Write Metrics per CF
There is an existing CoordinatorReadLatency table metric. I am looking to add CoordinatorWriteLatency table metric - however, before I attempt a shot at it, would like to know if anyone has context around why we currently do not have such metric (while we have the read metric) - if someone has already attempted and realized its a bad idea for some reason. Thanks, Sumanth
Search in cassandra
As in the "search in lost data" section , we should get tombstone from atleast one node. We should use the database strategy which keeps the deleted data in a table. And in the filtring proccess it should triger bloom filter and search in the table and in the case that the search has result report it to user. This approach cause to increased search speed and it decrease search cost.
Re: Search in cassandra
Are you referencing a specific book or section of docs? Can you link that here so there’s context? -- Jeff Jirsa > On Feb 8, 2018, at 8:21 AM, Mahdi Manavi wrote: > > As in the "search in lost data" section , we should get tombstone from > atleast one node. We should use the database strategy which keeps the > deleted data in a table. And in the filtring proccess it should triger > bloom filter and search in the table and in the case that the search has > result report it to user. This approach cause to increased search speed and > it decrease search cost. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Cassandra 7544 configurable storage port and you
Hi, I want to bring up some important changes to how addresses should be handled in Cassandra after 7544. As of 7544 a Cassandra instance (sometimes referred to as a node in the code) can't be identified by an InetAddress. It can't be identified for the purposes of the internal storage communication, and also for the purpose of the client port used for CQL. InetAddressAndPort is the class we are using and that is almost always a reference to the storage port and it will supply the port from the yaml file if none is provided/available. InetSocketAddress is the type we used to refer to the native protocol address in most places as well as to interface with outside libraries like Netty or Java when opening connections although there are are few places where it is an InetAddressAndPort so you will need to look for variables named rpc address, or native address to know. Using just an InetAddress for comparison is almost always wrong. Unwrapping the address from an InetAddressAndPort is almost always wrong. If you find a comparison where one side is an InetAddressAndPort and the other is an InetAddress it's a bug and there is probably a port available for you construct an InetAddressAndPort. In limited circumstances there might not be a port available such as when talking to a prior version node during rolling upgrade in which case you can let InetAddressAndPort supply the default from the YAML. In FBUtilities you should pretty much never use getJustLocalAddress(), getJustBroadcastAddress() or getJustBroadcastNativeAddress(). You want the AndPort version as that will have the port specific to the instance. I created https://issues.apache.org/jira/browse/CASSANDRA-14226 to add more documentation to the code to cover this a little better. Regards, Ariel - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
