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 sylvain@datastax.com designates
 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <125FE5C84575394CB9ED84D5DBB151D5BD1A8CB057@PTPPICEX03.PTPortugal.corpPT.com>
References: 
 <125FE5C84575394CB9ED84D5DBB151D5BD1A8CB057@PTPPICEX03.PTPortugal.corpPT.com>
Date: Tue, 3 Apr 2012 12:36:04 +0200
Message-ID: 
 <CAKkz8Q1Sk-5v9ndQsx72PW6MSMtMzJwp=jjvF1J3sGvAnjYF+Q@mail.gmail.com>
Subject: Re: Repair in loop?
From: Sylvain Lebresne <sylvain@datastax.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

It just means that you have lots of column family and repair does 1
column family at a time. Each line is just saying it's done with one
of the column family. There is nothing wrong, but it does mean the
repair is *not* done yet.

--
Sylvain

On Tue, Apr 3, 2012 at 12:28 PM, Nuno Jordao <nuno-m-jordao@telecom.pt> wro=
te:
> Hello,
>
>
>
> I=92m doing some test with cassandra 1.0.8 using multiple data directorie=
s
> with individual disks in a three node cluster (replica=3D3).
>
> One of the tests was to replace a couple of disks and start a repair
> process.
>
> It started ok and refilled the disks but I noticed that after the recover=
y
> process finished, it started a new one again:
>
>
>
> INFO 09:34:42,481 [repair #69c95b50-7cee-11e1-0000-6b5cbd036faf]
> BlockData_6f is fully synced (6 remaining column family to sync for this
> session)
>
> INFO 09:41:55,288 [repair #69c95b50-7cee-11e1-0000-6b5cbd036faf]
> BlockData_0d is fully synced (5 remaining column family to sync for this
> session)
>
> INFO 09:42:50,169 [repair #69c95b50-7cee-11e1-0000-6b5cbd036faf]
> BlockData_07 is fully synced (4 remaining column family to sync for this
> session)
>
> INFO 09:45:02,743 [repair #69c95b50-7cee-11e1-0000-6b5cbd036faf]
> BlockData_5a is fully synced (3 remaining column family to sync for this
> session)
>
> INFO 09:48:03,010 [repair #69c95b50-7cee-11e1-0000-6b5cbd036faf]
> BlockData_da is fully synced (2 remaining column family to sync for this
> session)
>
> INFO 09:54:51,112 [repair #69c95b50-7cee-11e1-0000-6b5cbd036faf]
> BlockData_e8 is fully synced (1 remaining column family to sync for this
> session)
>
> INFO 10:03:50,269 [repair #a66c8240-7d6a-11e1-0000-6b5cbd036faf]
> BlockData_b6 is fully synced (255 remaining column family to sync for thi=
s
> session)
>
> INFO 10:05:42,803 [repair #a66c8240-7d6a-11e1-0000-6b5cbd036faf]
> BlockData_13 is fully synced (254 remaining column family to sync for thi=
s
> session)
>
> INFO 10:08:43,354 [repair #a66c8240-7d6a-11e1-0000-6b5cbd036faf]
> BlockData_8b is fully synced (253 remaining column family to sync for thi=
s
> session)
>
> INFO 10:12:09,599 [repair #a66c8240-7d6a-11e1-0000-6b5cbd036faf]
> BlockData_31 is fully synced (252 remaining column family to sync for thi=
s
> session)
>
> INFO 10:15:43,426 [repair #a66c8240-7d6a-11e1-0000-6b5cbd036faf]
> BlockData_0c is fully synced (251 remaining column family to sync for thi=
s
> session)
>
> INFO 10:21:47,156 [repair #a66c8240-7d6a-11e1-0000-6b5cbd036faf]
> BlockData_1b is fully synced (250 remaining column family to sync for thi=
s
> session)
>
>
>
> Is this normal? To me it doesn=92t make much sense.
>
>
>
> Regards,
>
>
>
> Nuno