I quick glimpse at the code. It seems that truncate only cares about if any
node goes down. It does not check the replication strategy.
Boris
On Thu, Nov 14, 2013 at 9:30 PM, Cyril Scetbon wrote:
> anyone ?
>
> --
> Cyril SCETBON
>
> On 10 Nov 2013, at 10:48, Cyril Scetbon wrote:
>
> > Are you
Hi,
We are running cassandra 1.0.12. From time to time, we see log message like
"*java.io.IOError: java.io.IOException: dataSize of 71530420 starting at
587 would be larger than file {cf name} ...*" inside system.log.
If the cf name is not for secondary index, running "scrub" seems to prevent
the
to stop write not to
> flush, then compact.
>
> On Thu, May 16, 2013 at 3:07 AM, Boris Yen wrote:
> > Hi All,
> >
> > Sorry for the wide distribution.
> >
> > Our cassandra is running on 1.0.10. Recently, we are facing a weird
> > situation. We have a
Hi All,
Sorry for the wide distribution.
Our cassandra is running on 1.0.10. Recently, we are facing a weird
situation. We have a column family containing wide rows (each row might
have a few million of columns). We delete the columns on a daily basis and
we also run major compaction on it everyd
nv.sh
> * check that all indexes are built using nodetool cfstats
> * shut it down
> * put the commit log and data dirs back in place.
>
> All we want to do is get the system KS updated, but in 1.0 that's a
> serialised object and not easy to poke.
>
> Hope that help
Hi All,
Recently, we encountered an error on 1.0.12 that prevented cassandra from
starting up. From the log messages, it looked like the table/keyspace was
opened before the scrubDataDirectories was executed. This created a race
condition between two threads. One was trying to rename files while t
Hi Jonathan,
If our finding is not correct or the patch is going the wrong direction,
please kindly let us know.
Thank you in advance.
Regards,
Boris
On Sat, Mar 9, 2013 at 7:59 AM, Boris Yen wrote:
> Use the following sstable on our file system as an example.
>
> rw-rr- 1 byan admi
,
Boris
On Sat, Mar 9, 2013 at 12:54 AM, Jonathan Ellis wrote:
> Thanks, Boris. Can you explain what the cause is, and why tweaking hashCode
> fixes it?
> On Mar 8, 2013 4:17 AM, "Boris Yen" wrote:
>
> > Hi,
> >
> > We have run into this a few times on 1.0.10.
Hi,
We have run into this a few times on 1.0.10. It seems this happens when the
file-rename after compaction is not completed. We have created a patch for
this. However, in order to make sure we do not break anything, I was
wondering if anyone could help us review the changes to see if this would
rom the internal mechanism of a get_slice query.
Regards
Boris
On Wed, Jul 6, 2011 at 9:01 PM, Jonathan Ellis wrote:
> It was removed because the "right" way to do this is to page by
> last-column-seen, which can take advantage of the per-row column
> index. Offset cannot.
&g
Hi,
It seems it was implemented before. However, due to Cassandra-286, it was
removed. I was wondering if it is possible to put it back. Because computing
the offset on the client side should be less efficient than do it on the
server side.
I am thinking this might be possible to achieve by tweak
11 matches
Mail list logo