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 rcoli@eventbrite.com designates
 209.85.216.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADz-ciQe9ATKrwB1ZTOxp4OLHn2HvnN3Vx3U0e-iOr+n5JGOsA@mail.gmail.com>
References: <01c601cebece$ce0c3510$6a249f30$@struq.com>
	<CAEDUwd3rqZ7t3eEqm6iuE_3kzknWh0rdkAbcCeg+utHnndBDJQ@mail.gmail.com>
	<CADz-ciQe9ATKrwB1ZTOxp4OLHn2HvnN3Vx3U0e-iOr+n5JGOsA@mail.gmail.com>
Date: Tue, 1 Oct 2013 17:00:08 -0700
Message-ID: 
 <CAEDUwd0HTG2=YgUCtmUDJM9Ka179sfEMRdWvvaBXHXFmUaTi1A@mail.gmail.com>
Subject: Re: Rollback question regarding system metadata change
From: Robert Coli <rcoli@eventbrite.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Content-Type: multipart/alternative; boundary=001a11c35ab0a5d19b04e7b6c069

--001a11c35ab0a5d19b04e7b6c069
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 1, 2013 at 3:45 PM, Chris Wirt <chris.wirt@struq.com> wrote:

> Yep they still work. They dont acutally have any of the new system CF
> created for 2.0, paxos, etc.. but they do have new rows in the
> schema_columns table preventing startup and bootstrapping of new
> nodes.
>

It *may* be least risky to manually remove these rows and then restart DC3.
But unfortunately without really diving into the code, I can't make any
statement about what effects it might have.


> But anyway, actions to do this would be:
> - drop schema (wont actually delete data?)
>

What actually happens is that you automatically create a snapshot in the
snapshots dir when you drop, so you would have to move (or (better) hard
link) those files back into place.


> - create schema (will create all the metadata and leave my data
> directories alone?)
> - on each node run nodetool refresh (will load my existing data?)
>

Right. Refresh will rename all SSTables while opening them.

As an alternative to refresh, you can restart the node; Cassandra loads
whatever files it finds in the data dir at startup.

=Rob

--001a11c35ab0a5d19b04e7b6c069
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Oct 1, 2013 at 3:45 PM, Chris Wirt <span dir=3D"lt=
r">&lt;<a href=3D"mailto:chris.wirt@struq.com" target=3D"_blank">chris.wirt=
@struq.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Yep they still work. They dont acutally have=
 any of the new system CF<br>
created for 2.0, paxos, etc.. but they do have new rows in the<br>
schema_columns table preventing startup and bootstrapping of new<br>
nodes.<br></blockquote><div><br></div><div>It *may* be least risky to manua=
lly remove these rows and then restart DC3. But unfortunately without reall=
y diving into the code, I can&#39;t make any statement about what effects i=
t might have.</div>
<div>=A0=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">But anyway, actions to do t=
his would be:<br>
- drop schema (wont actually delete data?)<br>
</blockquote><div><br></div><div>What actually happens is that you automati=
cally create a snapshot in the snapshots dir when you drop, so you would ha=
ve to move (or (better) hard link) those files back into place.</div><div>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">- create schema (will create all th=
e metadata and leave my data<br>
directories alone?)<br>
- on each node run nodetool refresh (will load my existing data?)<br></bloc=
kquote><div><br></div><div>Right. Refresh will rename all SSTables while op=
ening them.</div><div><br></div><div>As an alternative to refresh, you can =
restart the node; Cassandra loads whatever files it finds in the data dir a=
t startup.</div>
<div><br></div><div>=3DRob</div><div><br></div><div><br></div><div>=A0</div=
></div></div></div>

--001a11c35ab0a5d19b04e7b6c069--