phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Recreating SYSTEM.CATALOG metadata
Date Mon, 29 Sep 2014 23:26:39 GMT
@Lars - any idea why Krishna may run into issues using Phoenix after a
restore from an HBase backup?

On Sun, Sep 28, 2014 at 9:00 PM, James Taylor <jamestaylor@apache.org> wrote:
> Hi Krishna,
> I think that's what we need to figure out - why is Phoenix having
> trouble when you restore the SYSTEM.CATALOG table. Any client or
> server-side exceptions in the logs when it hangs?
> Thanks,
> James
>
> On Sun, Sep 28, 2014 at 6:18 PM, Krishna <research800@gmail.com> wrote:
>> Hi James,
>>
>> I did include SYSTEM.CATALOG table in the backup & restore process. I dont
>> know why sqlline is having trouble using the backup version - it just hangs,
>> unless catalog table is dropped from hbase shell. I will see if there are
>> any errors in logs that's causing the behavior.
>>
>> Regards
>> Krishna
>>
>>
>> On Sunday, September 28, 2014, James Taylor <jamestaylor@apache.org> wrote:
>>>
>>> Hi Krishna,
>>> Any reason why the SYSTEM.CATALOG hbase table isn't restored as well
>>> from backup? Yes, if you try to re-create the SYSTEM.CATALOG by
>>> re-issuing your DDL statement, Phoenix won't know that the tables were
>>> Phoenix tables before, so will try to add the empty key value to each
>>> row. It's possible that an option could be made to avoid this, but
>>> it'd be good to understand a bit more why this is needed.
>>> Thanks,
>>> James
>>>
>>> On Sun, Sep 28, 2014 at 1:56 PM, Krishna <research800@gmail.com> wrote:
>>> > Hi,
>>> >
>>> > When I restore hbase from a backup, sqlline gets stuck unless
>>> > SYSTEM.CATALOG
>>> > table is dropped. It is automatically re-created via sqlline. However,
>>> > metadata of previously created phoenix tables is lost.
>>> >
>>> > So, to restore the metadata, when a 'CREATE TABLE' statement is
>>> > re-issued,
>>> > Phoenix takes very, very long time to execute which I think, is because
>>> > Phoenix is upserting null value for _0 column qualifier again for every
>>> > row
>>> > (billions of rows in the table).
>>> >
>>> > Is there a work-around for this by somehow telling Phoenix that the
>>> > underlying table is already a Phoenix table? Using views is not an
>>> > option
>>> > here. If my understanding is wrong, any pointers as to why it takes so
>>> > long
>>> > for executing 'CREATE TABLE' statement is appreciated.
>>> >
>>> > Thanks
>>> >
>>> >

Mime
View raw message