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 <yomaiq...@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 <yomaiq...@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 <yomaiq...@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
>>>
>>>
>>
>
