Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1257)
Subject: Re: Increased replication factor not evident in CLI
From: Dustin Wenz <dustinwenz@ebureau.com>
In-Reply-To: <CCB5BD7F-874B-4B8B-8B61-5892D098ED3A@ebureau.com>
Date: Fri, 13 Jul 2012 16:51:30 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <83DA5F29-9A50-4AF6-8C3B-2EBABF49CEF3@ebureau.com>
References: <4944F77D-D759-4BA1-8EF8-62B0B4BC81CD@ebureau.com>
 <73AC9598-4896-40DB-B6A0-08523CA46BE8@thelastpickle.com>
 <CAENxBwz2G8Q_vOta7YgrDABgtARQO7r0aytuo5tSo227mRtTPA@mail.gmail.com>
 <956E6761-EC2B-4C9C-8BDB-147419A4E77C@yahoo.com>
 <CCB5BD7F-874B-4B8B-8B61-5892D098ED3A@ebureau.com>
To: user@cassandra.apache.org

I was able to apply the patch in the cited bug report to the public =
source for version 1.1.2. It seemed pretty straightforward; six lines in =
MigrationManager.java were switched from System.currentTimeMillis() to =
FBUtilities.timestampMicros(). I then re-built the project by running =
'ant artifacts' in the cassandra root.

After I was up and running with the new version, I attempted to increase =
the replication factor, and then the compressions options.

Unfortunately, new patch did not seem to help in my case. Neither of the =
schema attributes would change. Running a "describe cluster" shows that =
all node schemas are consistent.
=09
Are there any other ways that I could potentially force Cassandra to =
accept these changes?

	- .Dustin

On Jul 13, 2012, at 10:02 AM, Dustin Wenz wrote:

> It sounds plausible that is what we are running into. All of our nodes =
report a replication factor of 2 (both using describe, and show schema), =
even though the cluster reported that all schemas agree after I issued =
the change to 4.
>=20
> If this is related to the bug that you filed, it might also explain =
why I've had difficulty changing the compression options on this same =
cluster. I issue an update command, schemas agree, but yet the change is =
not evident.
>=20
> 	- .Dustin
>=20
> On Jul 12, 2012, at 7:56 PM, Michael Theroux wrote:
>=20
>> Sounds a lot like a bug that I hit that was filed and fixed recently:
>>=20
>> https://issues.apache.org/jira/browse/CASSANDRA-4432
>>=20
>> -Mike
>>=20
>> On Jul 12, 2012, at 8:16 PM, Edward Capriolo wrote:
>>=20
>>> Possibly the bug with nanotime causing cassandra to think the change =
happened in the past. Talked about onlist in past few days.
>>> On Thursday, July 12, 2012, aaron morton <aaron@thelastpickle.com> =
wrote:
>>>> Do multiple nodes say the RF is 2 ? Can you show the output from =
the CLI ? Do show schema and show keyspace say the same thing ?
>>>> Cheers
>>>>=20
>>>>=20
>>>> -----------------
>>>> Aaron Morton
>>>> Freelance Developer
>>>> @aaronmorton
>>>> http://www.thelastpickle.com
>>>> On 13/07/2012, at 7:39 AM, Dustin Wenz wrote:
>>>>=20
>>>> We recently increased the replication factor of a keyspace in our =
cassandra 1.1.1 cluster from 2 to 4. This was done by setting the =
replication factor to 4 in cassandra-cli, and then running a repair on =
each node.
>>>>=20
>>>> Everything seems to have worked; the commands completed =
successfully and disk usage increased significantly. However, if I =
perform a describe on the keyspace, it still shows replication_factor:2. =
So, it appears that the replication factor might be 4, but it reports as =
2. I'm not entirely sure how to confirm one or the other.
>>>>=20
>>>> Since then, I've stopped and restarted the cluster, and even ran an =
upgradesstables on each node. The replication factor still doesn't =
report as I would expect. Am I missing something here?
>>>>=20
>>>> - .Dustin
>>>>=20
>>>>=20
>>>>=20
>>=20
>=20