Re: can I have a mix of 32 and 64 bit machines in a cluster?
On Tuesday 09 of October 2012, Brian Tarbox wrote: I can't imagine why this would be a problem but I wonder if anyone has experience with running a mix of 32 and 64 bit nodes in a cluster. We are running mixed userspace 64/32bit (all kernels 64bit) linux 1.0.10 cluster for our daily operations for months now without issue. Regards, -- Mateusz Korniak
[0.8.x] Node join stuck with all network transfers done
Hi ! I have problem with 0.8.7 node joining cluster of two 0.8.9s (RF=2). Seems all transfers ware done but joining node(.17) does not change it's state [3]. Strange is Nothing streaming from /192.168.3.8 netstats result [2] and still raising number of pending tasks [1], while .8 not transferring anything [4]. I tried to restart each of nodes, it didn't help except joining process started again, transferring all data again, stuck in same moment but having doubled load on joining node. Any hints ? Thanks in advance, regards. [1]: @192.168.3.17 ~]$ nodetool -h localhost compactionstats pending tasks: 836 [2]: @192.168.3.17 ~]$ nodetool -h localhost netstats Mode: Bootstrapping Not sending any streams. Nothing streaming from /192.168.3.8 Pool NameActive Pending Completed Commandsn/a 0171 Responses n/a 09387965 [3]: @192.168.3.17 ~]$ nodetool -h localhost ring Address DC RackStatus State LoadOwns Token 113427455640312821154458202477256070485 192.168.3.8 datacenter1 rack1 Up Normal 128.51 GB 33.33% 0 192.168.3.7 datacenter1 rack1 Up Normal 137.65 GB 50.00% 85070591730234615865843651857942052864 192.168.3.17datacenter1 rack1 Up Joining 127.02 GB 16.67% 113427455640312821154458202477256070485 [4]: @192.168.3.8 ~]$ nodetool -h localhost netstats Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 05261062 Responses n/a 02963742 -- Mateusz Korniak
Re: [0.8.x] Node join stuck with all network transfers done
On Monday 09 of January 2012, aaron morton wrote: (...) Is there a reason you are not adding 0.8.9 ? Only my mistake, I repeated procedure with 0.8.9 node joining and now, after finishing net transfers, node was busy compacting, finally switching to Normal state. Check the logs on .17 for errors. No exceptions, just Finished streaming session, netstats empty, node idling (net, cpu, io ) and rising number of pending tasks without doing anything. Big thanks for caring to answer, regards ! http://www.thelastpickle.com On 9/01/2012, at 8:20 PM, Mateusz Korniak wrote: Hi ! I have problem with 0.8.7 node joining cluster of two 0.8.9s (RF=2). Seems all transfers ware done but joining node(.17) does not change it's state [3]. Strange is Nothing streaming from /192.168.3.8 netstats result [2] and still raising number of pending tasks [1], while .8 not transferring anything [4]. I tried to restart each of nodes, it didn't help except joining process started again, transferring all data again, stuck in same moment but having doubled load on joining node. Any hints ? Thanks in advance, regards. [1]: @192.168.3.17 ~]$ nodetool -h localhost compactionstats pending tasks: 836 [2]: @192.168.3.17 ~]$ nodetool -h localhost netstats Mode: Bootstrapping Not sending any streams. Nothing streaming from /192.168.3.8 Pool NameActive Pending Completed Commandsn/a 0171 Responses n/a 09387965 [3]: @192.168.3.17 ~]$ nodetool -h localhost ring Address DC RackStatus State Load Owns Token 113427455640312821154458202477256070485 192.168.3.8 datacenter1 rack1 Up Normal 128.51 GB 33.33% 0 192.168.3.7 datacenter1 rack1 Up Normal 137.65 GB 50.00% 85070591730234615865843651857942052864 192.168.3.17datacenter1 rack1 Up Joining 127.02 GB 16.67% 113427455640312821154458202477256070485 [4]: @192.168.3.8 ~]$ nodetool -h localhost netstats Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 05261062 Responses n/a 02963742 -- Mateusz Korniak
Re: Doubt regarding CQL
On Wednesday 22 of February 2012, Rishabh Agrawal wrote: I have installed CQL drivers for python. When I try execute cqlsh I get following error cql-1.0.3$ cqlsh localhost 9160 (...) File /usr/local/lib/python2.7/dist-packages/cql/cassandra/ttypes.py, line 7, in module from thrift.Thrift import * ImportError: No module named thrift.Thrift Seems you do not have installed python thrift module. In my distro (PLD) it is: Package:python-thrift-0.5.0-4.i686 /usr/lib/python2.7/site-packages: Thrift-0.1-py2.7.egg-info, /usr/lib/python2.7/site-packages/thrift: TSCons.pyc, TSCons.pyo, TSerialization.pyc, TSerialization.pyo, Thrift.pyc, Thrift.pyo, __init__.pyc, __init__.pyo, /usr/lib/python2.7/site-packages/thrift/protocol: TBinaryProtocol.pyc, TBinaryProtocol.pyo, TCompactProtocol.pyc, TCompactProtocol.pyo, TProtocol.pyc, TProtocol.pyo, __init__.pyc, __init__.pyo, fastbinary.so /usr/lib/python2.7/site-packages/thrift/server: THttpServer.pyc, THttpServer.pyo, TNonblockingServer.pyc, TNonblockingServer.pyo, TServer.pyc, TServer.pyo, __init__.pyc, __init__.pyo /usr/lib/python2.7/site-packages/thrift/transport: THttpClient.pyc, THttpClient.pyo, TSocket.pyc, TSocket.pyo, TTransport.pyc, TTransport.pyo, TTwisted.pyc, TTwisted.pyo, __init__.pyc, __init__.pyo Regards, -- Mateusz Korniak
Re: Bootstrapping a new node to a running cluster (setting RF N)
On Thursday 15 of March 2012, aaron morton wrote: 1. a running cluster of N=3, R=3 2. upgrade R to 4 You should not be allowed to set the RF higher than the number of nodes. I wonder why is that restriction ? It would be easier to increase RF first (similar as having new node down), add node (not responding to client reads), repair new node, turn on clients. Would it be simpler than changing CL ? I'm going to assume that clients on the web server only talk to the local cassandra. So that when you add the new cassandra node it will not have any clients until you serve pages off the node. 0. Personally I would run a repair before doing this to ensure the data is fully distributed. 1. Optionally, increase the CL QUOURM. See step 3. 2. Add the new node with auto_bootstrap off. It will join the ring, write requests will be sent to it (from other cassandra nodes), but it should not get any direct client reads. It will not stream data from other nodes. 3. It is now possible for a READ to be received at an old node where it is no longer a replica for the row. It has to send the request to another node. If it is sent to the new node (at CL ONE) the read will fail. If you are running at a high CL it will always involve the old nodes. 4. Update the RF to 4. Every node is now a replica for every key. 5. Roll back the CL change. 6. Repair the new node. 7. Turn on the clients for the new node. Regards, -- Mateusz Korniak
Re: Advice on architecture
On Wednesday 28 of March 2012, Igor wrote: I'm also trying to evaluate different strategies for RAID0 as drive for cassandra data storage. If I need 2T space to keep node tables, which drive configuration is better: 1T x 2drives or 500G x 4drives? Having _similar_ family of HDDs 4x smaller should be twice faster in reads than 2x bigger. Should I use hardware raid or linux raid is ok? Instead of buying hardware raids buy more disks/nodes - should give more performance gain. I mostly concerned with read performance. -- Mateusz Korniak (...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś, krótko mówiąc - podpora społeczeństwa. Nikos Kazantzakis - Grek Zorba -- Mateusz Korniak
Meaning of compression chunk_length_kb
Hi ! What is meaning of chunk_length_kb: sets the compression chunk size in kilobytes. ? It means that uncompressed sstable data is compressed to approximately chunk_length_kb and every read needs to read approximately chunk_length_kb and decompress it to read any value from compressed range ? Or it means approximately chunk_length_kb of sstable data is compressed and stored on disk, so similar values must be in chunk_length_kb range to make compression efficient ? Or something else ? Thanks in advance, regards, -- Mateusz Korniak
How schema disagreement can be fixed faster on 1.0.10 cluster ?
Hi ! We got into schema disagreement situation on 1.0.10 having 250GB of compressed data per node. Following http://wiki.apache.org/cassandra/FAQ#schema_disagreement after node restart looks like it is replaying all schema changes one be one , right ? As we did a lot of them during cluster lifetime, now node is busy creating long time ago dropped secondary indexes which looks like gonna take hours. Can it be done faster ? 1. Can we move all data SStables out of data/*/ directories, 2. follow FAQ#schema_disagreement (it should be faster on no data node) until we reach schema agreement. 3. Than stop cassandra, 4. Copy files back. 5. Start cassandra. Will it work ? Extra option is to disable thrift during above process (can it be done in config ? In cassandra.yaml rpc_port: 0 ? ) Thanks in advance for any hints, regards, -- Mateusz Korniak
Re: Cassandra 1.0 hangs during GC
On Monday 30 of July 2012, Nikolay Kоvshov wrote: What I plan to compare between 'bad' cluster and 'good' cluster: - Configs, schemas, data etc: same - java version : same - RAM and CPU : 'bad' cluster has more - Ubuntu version - Networking - What else??? - JNA. If it's working and swapping is disabled for cassandra binary. - IO subsystem. kernel, io schedulers, performance of IO, HDDs performance/errors. -- Mateusz Korniak
Re: Cassandra 1.0 hangs during GC
On Monday 30 of July 2012, Nikolay Kоvshov wrote: - JNA is not installed on both machines So your GC times may be strongly [1] affected by swapping. IIRC, also snapshotting is more expensive and may trigger more swapping. I would start with turning JNA mlockall on [2]. [1]: Not sure if up to numbers you presented ( many seconds)... [2]: INFO [main] 2012-07-27 12:18:27,135 CLibrary.java (line 109) JNA mlockall successful -- Mateusz Korniak
Re: lost keyspace
On Wednesday 08 of August 2012, Arend-Jan Wijtzes wrote: Forgot to mention that the keyspace 'twitter' was created, then droppend and re-created a couple of days ago. How about if I create a new keyspace with the same definition and then copy the existing tables into the proper place and call nodetool refresh on each node. Would that work or are there references in the tables to the keyspace name? Worth to try, should work. Perhaps use _copy_ of SStables. I did that during schema version desync solving few times on 1.0.x. Make sure you have same schema version on all nodes first. Regards, -- Mateusz Korniak
Reading data problems during bootstrap. [pycassa 0.7.0 rc4]
hi ! As cassandra newbie, I am trying to convert my single node cluster to cluster with two nodes with RF=2. I have one node cluster , RF=1 all data accessible: nodetool -h 192.168.3.8 ring Address Status State LoadOwnsToken 192.168.3.8 Up Normal 1.59 GB 100.00% 150705614882854895881815284349323762700 Replication Strategy: org.apache.cassandra.locator.SimpleStrategy Replication Factor: 1 If I switch to RF=2 here my cluster will refuse updates and reads. So I bootstrap 2nd node (192.168.3.4) : $ nodetool -h 192.168.3.8 ring Address Status State LoadOwnsToken 150705614882854895881815284349323762700 192.168.3.4 Up Joining 120.94 KB 49.80% 65291865063116528976449321853009633660 192.168.3.8 Up Normal 1.59 GB 50.20% 150705614882854895881815284349323762700 question 1: Why in that point I am unable to read data from part of keys ? Even when node is up: nodetool -h 192.168.3.8 ring Address Status State LoadOwnsToken 150705614882854895881815284349323762700 192.168.3.4 Up Normal 721.37 MB 49.80% 65291865063116528976449321853009633660 192.168.3.8 Up Normal 1.59 GB 50.20% 150705614882854895881815284349323762700 I am still unable to read part of my original set of data with ConsistencyLevel.ONE (NotFoundException in pycassa) :/ question 2: Why is that ? And what should I do to have cluster with full data ? Next I planned to do: update keyspacewith replication_factor=2; repair both nodes, and this point have fully working 2 node cluster with RF=2 question 3: Is this proper approach or there is better one ? question 4: I hoped that during above operations I would be able to _read_ whole dataset as it was at beginning in one node cluster, is it possible ? Thanks in advance for any answers, regards, -- Mateusz Korniak
Re: Cassandra from unprivileged user
On Tuesday 15 of February 2011, ruslan usifov wrote: Is it possible to launch cassandra from unprivileged user? On linux - yes. -- Mateusz Korniak
[0.7.2] Compacting exception
Hi ! I have run with Cassandra 0.7.2 out of disc space and after moving to bigger partition I experience compaction failures[1]. 1) I suspect one of SSTables is broken. If I am right how can I find which one exactly ? 2) Knowing which one is broken is it safe to stop Cassandra, remove -Data.db -Filter.db -Index.db -Statistics.db of broken SSTable and restart ? Sure I will loose data but it's one of RF=3 nodes so it's not big problem. Any suggestions, hints ? Thanks in advance, regards, [1] INFO [CompactionExecutor:1] 2011-03-18 12:27:17,103 CompactionManager.java (line 458) Compacted to /var/lib/cassandra/data/foo/bar-tmp-f-707-Data.db. 42,276,185 to 42,103,628 (~99% of original) bytes for 33,869 keys. Time: 25,924ms. INFO [CompactionExecutor:1] 2011-03-18 12:27:17,133 CompactionManager.java (line 373) Compacting [org.apache.cassandra.io.sstable.SSTableReader(path= '/var/lib/cassandra/data/foo/bar-f-238-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-243-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-361-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-635-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-643-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-680-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-684-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-685-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-687-Data.db')] ERROR [CompactionExecutor:1] 2011-03-18 12:27:18,241 AbstractCassandraDaemon.java (line 114) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:78) at org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:179) at org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:144) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:136) at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:39) at org.apache.commons.collections.iterators.CollatingIterator.set(CollatingIterator.java:284) at org.apache.commons.collections.iterators.CollatingIterator.least(CollatingIterator.java:326) at org.apache.commons.collections.iterators.CollatingIterator.next(CollatingIterator.java:230) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:68) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.CompactionManager.doCompaction(CompactionManager.java:427) at org.apache.cassandra.db.CompactionManager$1.call(CompactionManager.java:123) at org.apache.cassandra.db.CompactionManager$1.call(CompactionManager.java:93) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException at org.apache.cassandra.io.sstable.IndexHelper.skipIndex(IndexHelper.java:65) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:70) ... 20 more -- Mateusz Korniak
Re: [0.7.2] Compacting exception
On Friday 18 of March 2011, Jonathan Ellis wrote: Upgrade to 0.7.4 and run nodetool scrub (then watch the log). Unfortunately nodetool scrub fails with: WARN [CompactionExecutor:1] 2011-03-19 00:34:53,511 CompactionManager.java (line 607) Non-fatal error reading row (stacktrace follows) java.io.IOError: java.io.IOException: Impossible row size 3458764513820542976 at org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:589) at org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56) at org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: Impossible row size 3458764513820542976 ... 8 more INFO [CompactionExecutor:1] 2011-03-19 00:34:53,512 CompactionManager.java (line 613) Retrying from row index; data is 10296 bytes starting at 2648761 ERROR [CompactionExecutor:1] 2011-03-19 00:34:53,512 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.lang.OutOfMemoryError: Requested array size exceeds VM limit at org.apache.cassandra.utils.BloomFilterSerializer.deserialize(BloomFilterSerializer.java:49) at org.apache.cassandra.utils.BloomFilterSerializer.deserialize(BloomFilterSerializer.java:30) at org.apache.cassandra.io.sstable.IndexHelper.defreezeBloomFilter(IndexHelper.java:117) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:87) at org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:618) at org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56) at org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) If it reports bad rows then run repair post-scrub. You mean: nodetool repair ? Thanks for help, regards, On Fri, Mar 18, 2011 at 6:44 AM, Mateusz Korniak mateusz-li...@ant.gliwice.pl wrote: Hi ! I have run with Cassandra 0.7.2 out of disc space and after moving to bigger partition I experience compaction failures[1]. 1) I suspect one of SSTables is broken. If I am right how can I find which one exactly ? 2) Knowing which one is broken is it safe to stop Cassandra, remove -Data.db -Filter.db -Index.db -Statistics.db of broken SSTable and restart ? Sure I will loose data but it's one of RF=3 nodes so it's not big problem. Any suggestions, hints ? Thanks in advance, regards, [1] INFO [CompactionExecutor:1] 2011-03-18 12:27:17,103 CompactionManager.java (line 458) Compacted to /var/lib/cassandra/data/foo/bar-tmp-f-707-Data.db. 42,276,185 to 42,103,628 (~99% of original) bytes for 33,869 keys. Time: 25,924ms. INFO [CompactionExecutor:1] 2011-03-18 12:27:17,133 CompactionManager.java (line 373) Compacting [org.apache.cassandra.io.sstable.SSTableReader(path= '/var/lib/cassandra/data/foo/bar-f-238-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-243-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-361-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-635-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-643-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-680-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-684-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-685-Data.db'), org.apache.cassandra.io.sstable.SSTableReader( path='/var/lib/cassandra/data/foo/bar-f-687-Data.db')] ERROR [CompactionExecutor:1] 2011-03-18 12:27:18,241 AbstractCassandraDaemon.java (line 114) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIde ntityIterator.java:78) at org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(S
Re: Strange nodetool repair behaviour
On Monday 04 of April 2011, Jonas Borgström wrote: I have a 6 node 0.7.4 cluster with replication_factor=3 where nodetool repair keyspace behaves really strange. I think I am observing similar issue. I have three 0.7.4 nodes with RF=3. After compaction I see about 7GB load in node but after running repair few times I see load rising [1] and enormouos data (larger few times than whole data) is being transferred [2]. Also I see lot of compactions, compacting a lot ( 33% or less) which should not happen, as my data loading pattern are only insertions (no updates, no deletions). I have about 200k rows representing observable and columns representing daily values (now around 250 days maximum). Once once per day I insert new values to few CF. Not sure if matters but: Two nodes are in DC1 while 3rd in DC2. DCs are separated by slow internet/VPN link and thus size of data transferred is very important to me. I see no problems with transferring inserted data over that link during insertions, only repair makes transfers so big, that repair of single node single CF is not able to finish in day. I do not know how generation of merkle tree works. Is Cassandra implementation able to detect and transfer only whole rows ? Or row with new column added must be transfered as whole ? [1]: 192.168.3.5 Up Normal 7.85 GB 50.00% 0 10.20.1.66 Up Normal 13.7 GB 25.00% 42535295865117307932921825928971026432 192.168.3.4 Up Normal 12.13 GB25.00% 85070591730234615865843651857942052864 [2]: like twenty or more: progress=0/2086059022 - 0% progress=0/2085191380 - 0% -- Mateusz Korniak
Re: cassandra disks cache on SSD
On Friday 01 April 2016 13:16:53 vincent gromakowski wrote: > (...) looking > for a way to use some kind of tiering with few SSD caching hot data from > HDD. > I have identified two solutions (...) We are using lvmcache for that. Regards, -- Mateusz Korniak "(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś, krótko mówiąc - podpora społeczeństwa." Nikos Kazantzakis - "Grek Zorba"
Re: cassandra disks cache on SSD
On Friday 01 April 2016 21:48:08 vincent gromakowski wrote: > 2016-04-01 19:27 GMT+02:00 Mateusz Korniak <mateusz-li...@ant.gliwice.pl>: > > We are using lvmcache for that. > > Can you provide me a approximate estimation of performance gain ? I suspect it depends on frequently read data size. If it fits into caching SSDs. In our scenario, adding one 250GB SSD to nodes owning 1.2 TB resulted in 75% read cache hit ratio. It was enough to stop nodes being I/O bound and application to work without read timeouts. -- Mateusz Korniak "(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś, krótko mówiąc - podpora społeczeństwa." Nikos Kazantzakis - "Grek Zorba"
Re: Is it safe to upgrade between minor releases without first performing a repair?
On Thursday 20 of July 2017 23:27:55 Jerry wrote: > In general it seems that repairs should be done prior to every upgrade (in > fact they should be done at least weekly), but with a minor upgrade like > this is it safe to upgrade without first repairing? Depends on meaning of "is it safe" ... > Specifically, I'm looking to upgrade from Cassandra 2.0.11 to 2.0.17. This is bugfix only upgrade, so in general Cassandra should perform only better _after_ upgrade. On other hand, _during_ upgrade, you have to restart all nodes. Assuming having data inconsistency among nodes, you may get different query results (old/missing data, etc...) during node restarts. -- Mateusz Korniak "(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś, krótko mówiąc - podpora społeczeństwa." Nikos Kazantzakis - "Grek Zorba" - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
Re: Bootstraping a Node With a Newer Version
On Tuesday 16 of May 2017 15:27:11 Shalom Sagges wrote: > My question is this, after reinstalling the server with the new kernel, can > I first install the upgraded Cassandra version and then bootstrap it to the > cluster? No. Bootstrap/repair may/will not work between nodes with different major versions. Regards, -- Mateusz Korniak "(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś, krótko mówiąc - podpora społeczeństwa." Nikos Kazantzakis - "Grek Zorba" - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
Re: storing indexes on ssd
On Saturday 10 of February 2018 23:09:40 Dan Kinder wrote: > We're optimizing Cassandra right now for fairly random reads on a large > dataset. In this dataset, the values are much larger than the keys. I was > wondering, is it possible to have Cassandra write the *index* files > (*-Index.db) to one drive (SSD), but write the *data* files (*-Data.db) to > another (HDD)? This would be an overall win for us since it's > cost-prohibitive to store the data itself all on SSD, but we hit the limits > if we just use HDD; effectively we would need to buy double, since we are > doing 2 random reads (index + data). Considered putting cassandra data on lvmcache? We are using this on small (3x2TB compressed data, 128/256MB cache) clusters since reaching I/O limits of 2xHDD in RAID10. -- Mateusz Korniak "(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś, krótko mówiąc - podpora społeczeństwa." Nikos Kazantzakis - "Grek Zorba" - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
