Exactly.

J-D

On Thu, Feb 24, 2011 at 2:45 PM, Nanheng Wu <[email protected]> wrote:
> Sorry for trying to bring this topic back again guys, so currently in
> 0.20.6 is there's no way to drop a table without large amount of
> flushing?
>
> On Tue, Feb 22, 2011 at 3:04 PM, Jean-Daniel Cryans <[email protected]> 
> wrote:
>> Moving this discussion to jira: 
>> https://issues.apache.org/jira/browse/HBASE-3557
>>
>> Good stuff guys.
>>
>> J-D
>>
>> On Mon, Feb 21, 2011 at 8:25 AM, Hari Sreekumar
>> <[email protected]> wrote:
>>> I agree, and I have missed this a lot too. We should have a way to directly
>>> drop the table, it would help save a lot of time while developing /testing.
>>> Maybe also have a config entry to enable this behavior, like we have
>>> webinterface.private.actions in hadoop. It can be enabled on the dev cluster
>>> and disabled on production etc.
>>>
>>> Hari
>>>
>>> On Mon, Feb 21, 2011 at 12:41 PM, Lars George <[email protected]> wrote:
>>>
>>>> Could be having some "force" flag specified 3 times and asked for
>>>> confirmation as well, but I like this feature. Whenever I talk to
>>>> people who disable and get stuck it was to prepare a subsequent drop
>>>> table call. So this sounds really useful given enough safety latches
>>>> in place.
>>>>
>>>> Lars
>>>>
>>>> On Thu, Feb 17, 2011 at 1:50 AM, Jean-Daniel Cryans <[email protected]>
>>>> wrote:
>>>> > Actually I never thought of having a special case for that... and I
>>>> > don't see any jira about it. Would you mind opening a new one for
>>>> > that, I think it's a good idea for those times when you're developing
>>>> > something and you want to iterate fast.
>>>> >
>>>> > On the other hand, it's a pretty destructive feature so some people
>>>> > might disagree with having it in the codebase :)
>>>> >
>>>> > J-D
>>>> >
>>>> > On Wed, Feb 16, 2011 at 4:26 PM, Nanheng Wu <[email protected]> wrote:
>>>> >> Actually I wanted to disable the table so I can drop it. It would be
>>>> >> nice to be able to disable the table without flushing memstore. It's
>>>> >> not possible in 0.20.6 is it?
>>>> >>
>>>> >> On Wed, Feb 16, 2011 at 2:30 PM, Jean-Daniel Cryans <
>>>> [email protected]> wrote:
>>>> >>> To disable a region, it's memstore must first be flushed. That's done
>>>> >>> sequentially for all regions that must be disabled inside a table.
>>>> >>> There's not really a way around it unless you don't need that data.
>>>> >>>
>>>> >>> If you're planning to disable a table but at the same time need it to
>>>> >>> be unavailable for the shortest time possible, I recommend calling a
>>>> >>> flush on the table from the shell first and then some time later doing
>>>> >>> the disable. How much later you ask? Well there's currently no easy
>>>> >>> way to tell, I usually just tail any region server log file until I
>>>> >>> see they're done.
>>>> >>>
>>>> >>> J-D
>>>> >>>
>>>> >>> On Wed, Feb 16, 2011 at 2:21 PM, Nanheng Wu <[email protected]>
>>>> wrote:
>>>> >>>> From time to time I run into issues where disabling a table pretty
>>>> >>>> much hangs. I am simply calling the disableTable method fo HBaseAdmin.
>>>> >>>> The table has ~ 500 regions with default region file size. I couldn't
>>>> >>>> tell anything abnormal from the master's log. When I click on the
>>>> >>>> region from Master's web UI I get the "RegionOfflineException". I am
>>>> >>>> using HBase 0.20.6 + Hadoop 0.20.2. My cluster has ~10 nodes with one
>>>> >>>> node running Master/ZK/NameNode. Can someone help me understand what's
>>>> >>>> wrong? Thanks!
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>
>>
>

Reply via email to