Hey Jean,
I think it still does anticompaction by default regardless, it will not do
so only if you do subrange repair. TLP wrote a pretty good article on that:
http://thelastpickle.com/blog/2017/12/14/should-you-use-incremental-repair.html
On 24 May 2018 at 00:42, Jean Carlo wrote:
> Hello
>
>
You should just be able to install 3.1.0 again if you need to as they are
in the 3.X line. To be really safe you can also take a snapshot and backup
your existing SSTables first..and always remember to test before upgrading
in Production :)
On 17 April 2018 at 07:48, Abdul Patel wrote:
> Hi All,
To my knowledge for any version updates to cassandra.yaml will only be
applied after you restart the node..
On 13 March 2018 at 12:24, Kenneth Brotman
wrote:
> Can you update changes to cassandra.yaml in version 2.1x without restating
> the node?
>
>
>
> Kenneth Brotman
>
I would just go with GossipingPropertyFileSnitch, it will work across both
data centers (I once had a test cluster with 1 DC in Azure, 1 DC in AWS and
1 DC in GCP using GPFS). Even if it's just solely AWS, I think GPFS is
superior because you can configure virtual racks if you ever need it while
EC
Dear Lucas,
Those properties that result in the log message you are seeing are
properties common to all compaction strategies. See http://cassandra.apache.
org/doc/latest/operating/compaction.html#common-options. They are
*tombstone_compaction_interval
*and *tombstone_threshold*. If you didn't def
Terraform, Packer and Ansible does pretty decently, you may have to do some
smarts around replacing nodes and attaching the right volumes to replaced
nodes. If you could get Kubernetes working with Cassandra (beyond the
readily available guides) then I think you'll be a total baller.
On 9 February
Tablesnap assumes S3, and tableslurp can set up the stage for restoring by
downloading the relevant SSTables (but then it's up to the operator to
complete the restore from there). Restoring (especially point-in-time
restore) isn't easy to handle so there aren't a lot available out there.
There's a
Out of the box it assumes AWS S3 and is tailored to that using boto, so I
think you would have to checkout the repository and make changes to specify
a different endpoint (and submit a PR back to it if you feel it's useful :)
)
On 15 December 2017 at 08:03, Roger Brown wrote:
> I wanted to use t
I think as Jeff mentioned it sounds like a configuration issue, are you
sure you are using the same configmap/however it's being passed in and just
throwing out ideas, maybe the pods are behind a http proxy and you may have
forgotten to pass in the env vars?
On 6 December 2017 at 08:45, Jeff Jirsa
Hi Paul,
Agh, I don't have any experience with sstableofflinerelevel. Maybe Kurt
does, sorry.
Also, if it wasn't obvious, to add back the node to the cluster once it is
done would be the 3 commands, with enable substituted for disable. It feels
like it will take some time to get through all the c
Hi Paul,
The new node will certainly have a lot of compactions to deal with being
LCS. Have you tried performing the following on the new node once it has
joined?
*nodetool disablebinary && nodetool disablethrift && nodetooldisablegossip*
This will disconnect Cassandra from the cluster, but not
Nitan,
I'm not really familiar with jmxterm but the error it's returning to you is
because that MBean doesn't exist. The full MBean matching your example is
org.apache.cassandra.metrics:type=ClientRequest,scope=CASWrite,name=MutationSizeHistogram.
You can then call the operation values on it to ge
12 matches
Mail list logo
