Re: upgrade pinning to v3 protocol: massive drop in writes
Nevermind, it would appear once we looked further out on the metrics there was some huge bump about a month ago from the levels we see now On Tue, Jun 25, 2019 at 1:35 PM Carl Mueller wrote: > Oh we are 2.2.13 currently, seems to be 3.7.1 for the java-driver > > On Tue, Jun 25, 2019 at 1:11 PM Carl Mueller > wrote: > >> We have an app that needs to be pinned to v3 protocol for the upgrade to >> 3.11.X >> >> ... we rolled out the v3 "pinning" and the amount of write counts and >> network traffice plummeted by 60-90%. The app seems to be functioning >> properly. >> >> has anyone seen anything like this? Could it be "Custom Payloads" in v4? >> >
Re: upgrade pinning to v3 protocol: massive drop in writes
Oh we are 2.2.13 currently, seems to be 3.7.1 for the java-driver On Tue, Jun 25, 2019 at 1:11 PM Carl Mueller wrote: > We have an app that needs to be pinned to v3 protocol for the upgrade to > 3.11.X > > ... we rolled out the v3 "pinning" and the amount of write counts and > network traffice plummeted by 60-90%. The app seems to be functioning > properly. > > has anyone seen anything like this? Could it be "Custom Payloads" in v4? >
upgrade pinning to v3 protocol: massive drop in writes
We have an app that needs to be pinned to v3 protocol for the upgrade to 3.11.X ... we rolled out the v3 "pinning" and the amount of write counts and network traffice plummeted by 60-90%. The app seems to be functioning properly. has anyone seen anything like this? Could it be "Custom Payloads" in v4?
Re: commit_log way bigger than allowed
You can delete commitlogs and start the node. But run repair on that node to sync any data mismatch. Regards, Nitan Cell: 510 449 9629 > On Jun 25, 2019, at 4:37 AM, pwozniak wrote: > > Hi, > > I have cluster of three Cassandra (v.2.1) machines. On one of the machines > files with commit logs filled up all available disk space (50 GB). > > I haven't change 'commitlog_total_space_in_mb', so as far as I know It > shouldn't take more that 8GB of disc space. > > I also haven't found any suspicious messages in log file and our cluster was > not hammered by huge amount of requests lately. > > This machine (cassandra process) is not able to boot up now (it crashes while > replaying commit_log) > > > 1. How can I find out what happened? > > 2. Can I just delete all commit_logs, restart machine and run repair to have > consistent data? > > 3. Maybe I can delete just part of the commit_log files so Cassandra will be > able to boot and clean (flush) all commit_log files? > > > Regards, > > Pawel > > > - > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org >
commit_log way bigger than allowed
Hi, I have cluster of three Cassandra (v.2.1) machines. On one of the machines files with commit logs filled up all available disk space (50 GB). I haven't change 'commitlog_total_space_in_mb', so as far as I know It shouldn't take more that 8GB of disc space. I also haven't found any suspicious messages in log file and our cluster was not hammered by huge amount of requests lately. This machine (cassandra process) is not able to boot up now (it crashes while replaying commit_log) 1. How can I find out what happened? 2. Can I just delete all commit_logs, restart machine and run repair to have consistent data? 3. Maybe I can delete just part of the commit_log files so Cassandra will be able to boot and clean (flush) all commit_log files? Regards, Pawel - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
