Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of josh@keen.io designates
 209.85.160.52 as permitted sender)
Date: Fri, 27 Dec 2013 18:13:20 -0800
From: Josh Dzielak <josh@keen.io>
To: user@cassandra.apache.org
Message-ID: <DEF28DEC9DAD4C1A8B0C6F22A7DDE10F@keen.io>
Subject: Can't write to row key, even at ALL. Tombstones?
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="52be33c0_595b37f3_77d3"

--52be33c0_595b37f3_77d3
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We have a few row keys that aren=E2=80=99t taking any writes, even using =
both the ALL consistency level to read and write. We can=E2=80=99t insert=
 anything into any column, previously existing or new, using the simplest=
 possible heuristic in cqlsh or cassandra-cli. =20

Our suspicion is that we somehow have a row level tombstone that is futur=
e-dated and has not gone away (we=E2=80=99ve lowered gc=5Fgrace=5Fseconds=
 in hope that it=E2=80=99d get compacted, but no luck so far, even though=
 the stables that hold the row key have all cycled since).

How can we make this row key writeable again=3F Or even better, what can =
we do to debug this=3F Is there a way to get Cassandra to log all of the =
read candidates, including timestamp and host and sstable, before it choo=
ses the one to use=3F =20

Thanks as always,
-Josh


--52be33c0_595b37f3_77d3
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div>We have a few row keys that aren=E2=80=99t taking an=
y writes, even using both the ALL consistency level to read and write. We=
 can=E2=80=99t insert anything into any column, previously existing or ne=
w, using the simplest possible heuristic in cqlsh or cassandra-cli.
                </div><div><br></div><div>Our suspicion is that we someho=
w have a row level tombstone that is&nbsp;future-dated and has not gone a=
way (we=E2=80=99ve lowered gc=5Fgrace=5Fseconds in hope that it=E2=80=99d=
 get compacted, but no luck so far, even though the stables that hold the=
 row key have all cycled since).</div><div><br></div><div>How can we make=
 this row key writeable again=3F Or even better, what can we do to debug =
this=3F Is there a way to get Cassandra to log all of the read candidates=
, including timestamp and host and sstable, before it chooses the one to =
use=3F</div>
                <div><div><br></div><div>Thanks as always,</div><div>-Jos=
h</div></div>
            
--52be33c0_595b37f3_77d3--