phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krishna <research...@gmail.com>
Subject Re: Recreating SYSTEM.CATALOG metadata
Date Mon, 29 Sep 2014 01:18:17 GMT
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
> <javascript:;>> 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