hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: HBASE-4358
Date Sun, 11 Sep 2011 21:33:22 GMT
Below sounds good.  There is a tmp dir under each region.  That is
probably better place to do the messing.
St.Ack

On Sat, Sep 10, 2011 at 3:10 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> We should also protect the HTableDescriptor in memory against possible
> failure.
>
> How about:
> 1. Create new HTableDescriptor, htd1, whose storage is under /tmp on hdfs
> and is a clone of original HTableDescriptor, htd
> 2. Perform series of modifications on htd1
> 3. Assuming there is no error, copy contents of htd1 onto htd and rename the
> file under /tmp as Michael suggested.
> 4. If there was error, report back the exception and skip step 3 above
>
> It seems we need more helper methods in HTableDescriptor to fulfill the
> above.
>
> Cheers
>
> On Sat, Sep 10, 2011 at 2:33 PM, Stack <stack@duboce.net> wrote:
>
>> Its as though we should do all the mods in a tmp dir and then if all
>> go through, only then do fs.rename moving the new schema into place.
>>
>> St.Ack
>>
>> On Fri, Sep 9, 2011 at 7:25 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>> > I ran unit tests for HBASE-4358 patch 3 and they passed.
>> >
>> > The only issue remaining is in TableMultiFamilyHandler.java
>> >  @Override
>> >  protected void updateTableDescriptor(HTableDescriptor desc)
>> >    throws IOException {
>> >    // just ask all of the sub-operations to update the descriptor
>> >    for (TableFamilyHandler op : operations) {
>> >      op.updateTableDescriptor(desc);
>> >    }
>> >  }
>> > where we don't have ACID guarantee that either all modifications go
>> through
>> > or none of the modifications go through.
>> >
>> > If the above is Okay, I can add javadoc for the above at time of commit.
>> >
>> > If anyone thinks this is not good, please comment on ways of supporting
>> ACID
>> > guarantee.
>> >
>> > Thanks
>> >
>>
>

Mime
View raw message