phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Young <yomaiq...@gmail.com>
Subject Re: Renaming table schema in hbase
Date Fri, 09 Jun 2017 19:58:47 GMT
Thanks, Ankit!

I have an issue when connecting to sqlline.py using the
CurrentSCN=1490918400000
(3/31/2017)

I get >> java.sql.SQLException: ERROR 1010 (42M01): Not allowed to mutate
table.

I use TS=1 day prior to last timestamp in row data (
timestamp=1491004800000 (4/1/2017)) and my data has only a single day's
worth of data.

However, interestingly I got no error at all when just connecting without
this parameter.

Running 'describe' on my table in Hbase I get the following:

Table MyTable is ENABLED
MyTable, {TABLE_ATTRIBUTES => {coprocessor$1 =>
'|org.apache.phoenix.coprocessor.ScanRegionObserver|805306366|', copr
ocessor$2 =>
'|org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver|805306366|',
coprocessor$3 => '|org.apache.phoenix.copro
cessor.GroupedAggregateRegionObserver|805306366|', coprocessor$4 =>
'|org.apache.phoenix.coprocessor.ServerCachingEndpointImpl|80530636
6|', coprocessor$5 =>
'|org.apache.phoenix.hbase.index.Indexer|805306366|org.apache.hadoop.hbase.index.codec.class=org.apache.phoenix.i
ndex.PhoenixIndexCodec,index.builder=org.apache.phoenix.index.PhoenixIndexBuilder'}
COLUMN FAMILIES DESCRIPTION
{NAME => 'M', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false',
KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'FAST_
DIFF', TTL => 'FOREVER', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0',
BLOCKCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE =>
 '0'}

Is it OK if I CREATE the table without this CurrentSCN parameter?

The data appears to be there and I can query it, so it seems like it's
working.

Thanks,
Michael

On Thu, Jun 8, 2017 at 5:04 PM, Ankit Singhal <ankitsinghal59@gmail.com>
wrote:

> Hi Michael,
>
> bq. "exact DDL" Does this mean including all qualifiers like
> COMPRESSION='SNAPPY', SALT_BUCKETS=64, ... etc...? If we don't use the
> exact DDL, will Phoenix not behave correctly?
>  yes, Phoenix will not behave well if properties affecting the write path
> are not consistent during the read time, SALT_BUCKETS=64 is an important
> one.
>
> bq.if we want to add or remove IMMUTABLE_ROWS=true from the CREATE
> statement?
> Yes, you can ignore IMMUTABLE_ROWS=true or alter table to mutable later.
>
> {code}
> ALTER TABLE table SET IMMUTABLE_ROWS=false
> {code}
>
> bq. Also, is it correct to assume that the "1 day less" timestamp is just
> so we use a timestamp prior to the CurrentSCN?
> Using CurrentSCN less than the oldest timestamp of data during DDL will
> just avoid adding empty KV for each row. As you are renaming the existing
> Phoenix table, these empty KV will already be there and you will just save
> time by doing so.
>
> Regards,
> Ankit Singhal
>
> On Thu, Jun 8, 2017 at 1:34 PM, Michael Young <yomaiquin@gmail.com> wrote:
>
>> I have a doubt about step 2 from Ankit Singhal's response in
>> http://apache-phoenix-user-list.1124778.n5.nabble.com/Phoeni
>> x-4-4-Rename-table-Supported-td1781.html
>>
>> He says:
>>
>> 2. Open phoenix connection at timestamp 1 day less than the oldest data
>> in your tables ( by specifying ts in CurrentSCN ./sqlline.py
>> "localhost;CurrentSCN=<ts>") and create table with the exact DDL used
>> for old table but with the table name changed to new table
>>
>> "exact DDL" Does this mean including all qualifiers like
>> COMPRESSION='SNAPPY', SALT_BUCKETS=64, ... etc...?
>>
>> If we don't use the exact DDL, will Phoenix not behave correctly?  Is it
>> possible to add or change from that list, for example if we want to add or
>> remove IMMUTABLE_ROWS=true from the CREATE statement?
>>
>> Also, is it correct to assume that the "1 day less" timestamp is just so
>> we use a timestamp prior to the CurrentSCN?
>>
>>
>> On Wed, Jun 7, 2017 at 5:06 PM, Michael Young <yomaiquin@gmail.com>
>> wrote:
>>
>>> ah ha....after some googling I found some info from Ankit, copied below
>>>
>>> Looks like I was missing step 2.  I don't know how to get the CurrentSCN.
>>>
>>> Can someone help me with this?
>>>
>>> ====== From http://apache-phoenix-user-list.1124778.n5.nabble.com/Phoenix-4-4-Rename-table-Supported-td1781.html
====
>>>
>>> Currently there is no sql construct but you can do it by following below
>>> steps.(It is highly recommended you try these steps in dev environment
>>> before proceeding to production.
>>>
>>> 1. Take snapshot of the original table from hbase shell and restore it
>>> with another table name.
>>>
>>> hbase> disable 'oldtablename'
>>>
>>> hbase> snapshot 'oldtablename', 'oldtablename_Snapshot'
>>>
>>> hbase> clone_snapshot 'oldtablename_Snapshot', 'newTableName'
>>>
>>> 2. Open phoenix connection at timestamp 1 day less than the oldest data
>>> in your tables ( by specifying ts in CurrentSCN ./sqlline.py
>>> "localhost;CurrentSCN=<ts>") and create table with the exact DDL used
>>> for old table but with the table name changed to new table.
>>>
>>> 3. confirm that your new table is working fine as expected .
>>> 4. Then drop the old table from phoenix and snapshot from hbase shell.
>>>
>>> hbase> delete_snapshot 'oldtablename_Snapshot'
>>>
>>>
>>>
>>> On Wed, Jun 7, 2017 at 4:58 PM, Michael Young <yomaiquin@gmail.com>
>>> wrote:
>>>
>>>> It is possible to rename a table in Hbase, but it doesn't appear to be
>>>> recognized by Phoenix.
>>>>
>>>> I use the approach documented for HBase:
>>>>
>>>> disable 'MySchema.TABLE1'
>>>> snapshot 'MySchema.TABLE1', 'MySchema.TABLE1_SNAPSHOT'
>>>> clone_snapshot 'MySchema.TABLE1_SNAPSHOT', NewSchema.TABLE1'
>>>> delete_snapshot 'MySchema.TABLE1_SNAPSHOT'
>>>> #drop 'MySchema.TABLE1' - let's test before dropping
>>>>
>>>> However, when testing this Phoenix doesn't seem to see the new cloned
>>>> table and there is nothing in the SYSTEM.CATALOG for it, even after
>>>> restarting the phoenix client.
>>>>
>>>> Should this mechanism work in Phoenix or is there another way to rename
>>>> or clone an existing table?
>>>>
>>>> Michael
>>>>
>>>>
>>>
>>
>

Mime
View raw message