phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun Kumaran Sabtharishi <arun1...@gmail.com>
Subject Re: Undefined column. columnName=IS_ROW_TIMESTAMP
Date Mon, 18 Apr 2016 17:04:50 GMT
James,

We cannot afford to follow this workaround, since the names of the phoenix
views that already exist is stored in MySql as metadata, which is used by
our APIs. We still haven't figured out a way to reproduce this issue as
this is only happening in the production environment.

Thanks,
Arun Sabtharishi

On Mon, Apr 18, 2016 at 11:18 AM, James Taylor <jamestaylor@apache.org>
wrote:

> Arun,
>
> If you're blocked by this, here's a potential way of getting around the
> issue you're hitting. This assumes you have all the DDL statements that
> were used to create tables on the cluster:
> - open an HBase shell and disable and drop the SYSTEM.CATALOG
> - open sqlline connected to your HBase cluster (this will cause the
> SYSTEM.CATALOG to be re-created, now empty)
> - open another sqlline specifying a CurrentSCN property on the URL with a
> long value earlier than any existing data for your tables. For example, the
> following would be 1/1/2011:
>     ./sqlline.py localhost;CurrentSCN=1293840000000
> - issue each of your CREATE TABLE statements for your tables in this
> sqlline. This will create a Phoenix table and map to the existing HBase
> data that's already there (i.e. you won't lose any data). The setting of
> the CurrentSCN property will prevent Phoenix from adding the empty key
> value to every existing row since we know it's already there (making the
> CREATE TABLE statements run faster and not timeout).
>
> If you could get us more info on how to repro this issue, we can make sure
> it doesn't happen any more as we've never seen this before.
>
> Thanks,
> James
>
> On Mon, Apr 18, 2016 at 9:02 AM, Samarth Jain <samarth@apache.org> wrote:
>
>> Arun,
>>
>> Older phoenix views, created pre-4.6, shouldn't have the ROW_TIMESTAMP
>> column. Was the upgrade done correctly i.e. the server jar upgraded before
>> the client jar? Is it possible to get the complete stack trace? Would be
>> great if you could come up with a test case here to understand better where
>> the problem is happening.
>>
>> On Mon, Apr 18, 2016 at 8:09 AM, Arun Kumaran Sabtharishi <
>> arun1087@gmail.com> wrote:
>>
>>> To add details to the original problem that was mentioned in this email,
>>> we migrated to Phoenix-4.6.1 very recently and this problem started
>>> occurring only after that.
>>>
>>> 1. Checking SYSTEM.CATALOG for some older phoenix views in the same
>>> environment, some of the *phoenix views did not have the
>>> IS_ROW_TIMESTAMP column*. But, all the* newer phoenix views and
>>> only some of the older phoenix views had this column* present. Could
>>> this be possibly because those older phoenix views(which did not have the
>>> column present) did not migrate properly to phoenix 4.6.1?
>>>
>>> 2. Is this column IS_ROW_TIMESTAMP specific to phoenix tables and can
>>> this be accessed from HBase directly? If so, how?
>>>
>>> Thanks,
>>> Arun
>>>
>>
>>
>

Mime
View raw message