How to recreate table?

Hello, I've recreated HBase table with data, but phoenix doesn't work on it. But i still see this table in phoenix. How can I recreate pheonix table now? As I know "drop table ... ; create table ..." in phoenix will destroy my HBase table with data.

Re: How to recreate table?

able with the same schema and then flip the > underlying table out. > > * Rename the existing table to "foo" > * Create your table via Phoenix with correct schema and desired name > * Delete underlying HBase table that Phoenix created > * Rename "foo" to the desired name

Row timestamp

Hello, Im trying to understand what excatly Phoenix row timestamp is I created 2 tables for test: CREATE TABLE test_row_timestamp1( id varchar NOT NULL, created TIMESTAMP NOT NULL, foo varchar, CONSTRAINT PK PRIMARY KEY( id, created ROW_TIMESTAMP ) ) CREATE TABLE

Re: Row timestamp

broken on the page? > > On Thu, Mar 9, 2017 at 11:28 AM, Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Hello, > Im trying to understand what excatly Phoenix row timestamp is > I created 2 tables for test: > > CREATE TABLE test_

Re: How to recover SYSTEM.STATS?

Thank you > On 23 Jul 2017, at 06:09, venk sham <shamv...@gmail.com> wrote: > > Running major compact will build stats to some extent, and as you keep using > tables this will get populated > > On Jul 22, 2017 7:40 PM, "Batyrshin Alexander" <0x62...@g

How to recover SYSTEM.STATS?

Hello, We accidentally lost SYSTEM.STATS. How to recover/recreate it?

Re: Metrics and Phoenix

> On 26 Jul 2017, at 12:49, Batyrshin Alexander <0x62...@gmail.com> wrote: > > Hello, > Im collecting metrics from region servers - > readRequestCount/writeRequestCount. > The problem is that Phoenix SELECT is not affects > readRequestCount/writeRequestCoun

Metrics and Phoenix

Hello, Im collecting metrics from region servers - readRequestCount/writeRequestCount. The problem is that Phoenix SELECT is not affects readRequestCount/writeRequestCount. Is this normal? If yes then which HBase metrics are affected by SELECT statements?

Partial indexes

Hello, Is there any plans to implement partial indexes (CREATE INDEX WHERE predicate)?

Re: Cant run map-reduce index builder because my view/idx is lower case

elieve. > Thanks, > Sergey > > On Mon, Jun 19, 2017 at 11:28 AM, Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Hello again, > > Could you, please, help me to run map-reduce for indexing view with > lower-case name? > > He

Re: Cant run map-reduce index builder because my view/idx is lower case

TABLE_VIEW at org.apache.phoenix.mapreduce.index.IndexTool.run(IndexTool.java:190) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.phoenix.mapreduce.index.IndexTool.main(Index

Re: Partial indexes

Oh, cool. Thank you. > On 8 Jun 2017, at 17:52, James Taylor <jamestay...@apache.org> wrote: > > Hi Alexander, > We support indexes on views which is essentially what you're asking for. > Thanks, > James > > On Thu, Jun 8, 2017 at 1:28 AM Batyrshin Alexander <

Cant run map-reduce index builder because my view/idx is lower case

Hello, Im trying to build ASYNC index by example from https://phoenix.apache.org/secondary_indexing.html My issues is that my view name and index name is lower case, so map-reduce rise error: 2017-06-17 03:45:56,506 ERROR [main]

Phoenix index update on direct HBase row update

We updates our HBase table directly without Phoenix. Is it possible to make indexes keep in sync with this updates?

Re: Phoenix index update on direct HBase row update

ta needed by index maintenance coprocessor in your update > code, or use the Phoenix update APIs which do this for you. > > On Thu, Jun 15, 2017 at 5:29 PM, Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > We updates our HBase table directly witho

Re: Delay between put from HBase shell and result in SELECT from Phoenix

onds) ... 5 seconds later 0: jdbc:phoenix:> select * from test; +++ | K | V | +++ | 1 | b | +++ 1 row selected (0.026 seconds) > On 24 Aug 2017, at 21:38, Batyrshin Alexander <0x62...@gmail.com> wrote: > > Hello, > > How to decrease or even elim

Delay between put from HBase shell and result in SELECT from Phoenix

Hello, How to decrease or even eliminate delay between direct HBase put (for example from HBase shell) and SELECT from Phoenix? My table has only 1 VERSION and do not use any block cache ( {NAME => 'invoice', COMPRESSION => 'LZO', BLOCKCACHE => 'false'} ), so i do not understand where

Re: Delay between put from HBase shell and result in SELECT from Phoenix

r data via Phoenix, > you're going to run into less pain if you work completely at the Phoenix API > level, (tl;dr use UPSERT to write data) > > On 8/24/17 2:58 PM, Batyrshin Alexander wrote: >> Here is example: >> CREATE TABLE IF NOT EXISTS test ( >> k VARCHAR NO

Re: Delay between put from HBase shell and result in SELECT from Phoenix

onnection to HConstants.LATEST_TIMESTAMP like this: > > props.put(PhoenixRuntime.CURRENT_SCN_ATTRIB, > Long.toString(HContants.LATEST_TIMESTAMP)); > conn = DriverManager.getConnection(getUrl(), props); > > > > > On Fri, Aug 25, 2017 at 10:14 AM, Batyrshin Alexand

Re: Delay between put from HBase shell and result in SELECT from Phoenix

CURRENT_SCN property on your > connection to HConstants.LATEST_TIMESTAMP like this: > > props.put(PhoenixRuntime.CURRENT_SCN_ATTRIB, > Long.toString(HContants.LATEST_TIMESTAMP)); > conn = DriverManager.getConnection(getUrl(), props); > > > > >

Statements caching

Hi all, Im wondering how to enable statement caching in Phoenix JDBC Driver. Is there anything like "cachePrepStmts"?

Re: Statements caching

hanks, > James > > On Thu, Jul 26, 2018 at 10:45 AM, Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Hi all, > Im wondering how to enable statement caching in Phoenix JDBC Driver. > Is there anything like "cachePrepStmts"? >

Re: All the mappping column values is null when create table(includeing schema) in phoenix 4.12 for exists hbase table

If you already have HBase table then set COLUMN_ENCODED_BYTES = NONE http://phoenix.apache.org/namspace_mapping.html - for details > On 12 Aug 2018, at 10:34, && <331913...@qq.com> wrote: > > Hi there, > I have a quest for phoenix user case,

Re: ABORTING region server and following HBase cluster "crash"

YI > > On Sat, Sep 8, 2018 at 3:32 PM Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Hello, > > We got this exception from prod006 server > > Sep 09 00:38:02 prod006 hbase[18907]: 2018-09-09 00:38:02,532 FATAL > [Mem

Re: SKIP_SCAN on variable length keys

Thank you for reply > On 4 Sep 2018, at 21:04, Sergey Soldatov wrote: > > SKIP SCAN doesn't use FuzzyRowFilter. It has its own SkipScanFilter. If you > see problems, please provide more details or file a JIRA for that. > > Thanks, > Sergey > > On Wed, Aug 29

ABORTING region server and following HBase cluster "crash"

Hello, We got this exception from prod006 server Sep 09 00:38:02 prod006 hbase[18907]: 2018-09-09 00:38:02,532 FATAL [MemStoreFlusher.1] regionserver.HRegionServer: ABORTING region server prod006,60020,1536235102833: Replay of WAL required. Forcing server shutdown Sep 09 00:38:02 prod006

Re: ABORTING region server and following HBase cluster "crash"

:297) Sep 09 02:54:30 prod005 hbase[3772]: at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:277) > On 9 Sep 2018, at 01:44, Batyrshin Alexander <0x62...@gmail.com> wrote: > > Thank you. > We're updating our cluster right now... > > >> O

Re: ABORTING region server and following HBase cluster "crash"

to rebuild index from WAL but B at this time is aborting then A starting aborting too From this moment nothing happens (0 requests to region servers) and A and B is not responsible from Master-status web interface > On 9 Sep 2018, at 04:38, Batyrshin Alexander <0x62...@gmail.com> wrote: &

Re: ABORTING region server and following HBase cluster "crash"

e that you have all of the Regions assigned (no RITs). There could be > a pretty simple explanation as to why the index can't be written to. > > On 9/9/18 3:46 PM, Batyrshin Alexander wrote: >> Correct me if im wrong. >> But looks like if you have A and B region server

SKIP_SCAN on variable length keys

Hello, Im wondering is there any issue with SKIP SCAN when variable length columns used in composite key? My suspicion comes from FuzzyRowFilter that takes fuzzy row key template with fixed positions

Split and distribute regions of SYSTEM.STATS table

Hello, I've discovered that SYSTEM.STATS has only 1 region with size 3.25 GB. Is it ok to split it and distribute over different region servers?

Re: Split and distribute regions of SYSTEM.STATS table

e are on > the same region. > > James > > On Fri, Apr 20, 2018 at 1:37 PM, James Taylor <jamestay...@apache.org > <mailto:jamestay...@apache.org>> wrote: > Thanks for bringing this to our attention. There's a bug here in that the > SYSTEM.STATS > > On Wed, Apr 1

Re: Concurrent phoenix queries throw unable to create new native thread error

there should also be a copy of > hbase-site.xml on the client machine? > > On Thu, Oct 11, 2018 at 5:20 AM Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Problem comes from that "phoenix.query.threadPoolSize" can not be set via &

Re: Connection Pooling?

I've already asked the same question in this thread - http://apache-phoenix-user-list.1124778.n5.nabble.com/Statements-caching-td4674.html > On 18 Oct 2018, at 19:44, Jean-Marc Spaggiari wrote: > > Hi, > > Is this statement in the FAQ still valid? > > "If Phoenix Connections are reused, it

Re: Connection Pooling?

as is the majority of the rest of the > documentation ;)) > > On 10/18/18 1:14 PM, Batyrshin Alexander wrote: >> I've already asked the same question in this thread - >> http://apache-phoenix-user-list.1124778.n5.nabble.com/Statements-caching-td4674.html >>&g

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

gmail.com> <mailto:ankitsingha...@gmail.com >>> <mailto:ankitsingha...@gmail.com>>> wrote: >>> >>> You might be hitting PHOENIX-4785 >>> <https://jira.apache.org/jira/browse/PHOENIX-4785 >>> <https://jira.apache.org/jira/browse/PHOENIX-4

ON DUPLICATE KEY with Global Index

Hello all, Documentations (http://phoenix.apache.org/atomic_upsert.html) say: "Although global indexes on columns being atomically updated are supported, it’s not recommended as a potentially a separate RPC across the wire would be made while the row is under lock to maintain the secondary

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

I've created bug with reproduce steps: https://issues.apache.org/jira/browse/PHOENIX-4960 > On 3 Oct 2018, at 21:06, Batyrshin Alexander <0x62...@gmail.com> wrote: > > But we see that Phoenix commit() in our cases fails with "ERROR 1120 (XCL20): > Writes to table

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

> > You might be hitting PHOENIX-4785 > <https://jira.apache.org/jira/browse/PHOENIX-4785>, you can apply the patch > on top of 4.14 and see if it fixes your problem. > > Regards, > Ankit Singhal > > On Wed, Sep 26, 2018 at 2:33 PM Batyrshin Alexander <0

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

on.max.filesize 10737418240 hbase-default.xml > On 30 Sep 2018, at 06:09, Jaanai Zhang wrote: > > Did you restart the cluster and you should set 'hbase.hregion.max.filesize' > to a safeguard value which less than RS's capabilities. > > ------

Re: ABORTING region server and following HBase cluster "crash"

egatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Oct 02 03:25:12 prod002 hbase[195373]: at java.lang.reflect.Method.invoke(Method.java:498) Oct 02 03:25:12 prod002 hbase[195373]: at org.apache.hadoop.hbase.util.Methods.call(Methods.java:39) Oct 02 03:25:12 prod002 hba

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

On Wed, Sep 26, 2018 at 3:36 PM Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Thank you. We will try somehow... > Is there any chance that this fix will be included in next release for > HBASE-1.4 (not 2.0)? > >> On 27 Sep 2018, at 0

Re: ON DUPLICATE KEY with Global Index

exception and the related documentation read as being in support of each > other to me. > > On 10/9/18 5:39 AM, Batyrshin Alexander wrote: > > Hello all, > > Documentations (http://phoenix.apache.org/atomic_upsert.html > > <http://phoenix.apache.org/atomic_upsert.html

Re: Concurrent phoenix queries throw unable to create new native thread error

Problem comes from that "phoenix.query.threadPoolSize" can not be set via connection settings. You must set this props via hbase-site.xml. Looks like thread pool initialized before any connections inside JDBC driver. I think that this moment must be clarified in documentation

Unable to find cached index metadata

Hello all, We use mutable table with many indexes on it. On upserts we getting this error: o.a.phoenix.execute.MutationState - Swallowing exception and retrying after clearing meta cache on connection. java.sql.SQLException: ERROR 2008 (INT10): Unable to find cached index metadata. ERROR 2008

Re: Unable to find cached index metadata

he config value of maxServerCacheTimeToLiveMs you will > see the exception because the index metadata expired from the cache. > > > On Sun, Sep 2, 2018 at 4:02 PM, Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Hello all, > We use mutable tabl

MutationState size is bigger than maximum allowed number of bytes

I've tried to copy one table to other via UPSERT SELECT construction and got this errors: Phoenix-4.14-hbase-1.4 0: jdbc:phoenix:> !autocommit on Autocommit status: true 0: jdbc:phoenix:> 0: jdbc:phoenix:> UPSERT INTO TABLE_V2 ("c", "id", "gt") . . . . . . . . > SELECT "c", "id", "gt" FROM

Re: IllegalStateException: Phoenix driver closed because server is shutting down

the shutdown hook for the driver > and that's the only place where we set this message) and after that, another > thread was trying to create a new connection. > > Thanks, > Sergey > > On Wed, Sep 19, 2018 at 11:17 AM Batyrshin Alexander <0x62...@gmail.com > <m

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

. disableIndexOnFailure=true, Failed to write to multiple index tables: [IDX_MARK_O] ,serverTimestamp=1537463364504, > On 20 Sep 2018, at 21:01, Batyrshin Alexander <0x62...@gmail.com> wrote: > > Our setup: > HBase-1.4.7 > Phoenix-4.14-hbase-1.4 > > >> On 20 Sep 2018, at

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

:47:42,022 INFO [prod001,6,1537304851459_ChoreService_1] master.CatalogJanitor: Scanned 779 catalog row(s), gc'd 0 unreferenced merged region(s) and 1 unreferenced parent region(s) > On 20 Sep 2018, at 21:43, Batyrshin Alexander <0x62...@gmail.com> wrote: > > Looks like prob

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

Looks like lock goes away 30 minutes after index region split. So i can assume that this issue comes from cache that configured by this option: phoenix.coprocessor.maxMetaDataCacheTimeToLiveMs > On 21 Sep 2018, at 00:15, Batyrshin Alexander <0x62...@gmail.com> wrote: > > And

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

Any advices? Helps? I can reproduce problem and capture more logs if needed. > On 21 Sep 2018, at 02:13, Batyrshin Alexander <0x62...@gmail.com> wrote: > > Looks like lock goes away 30 minutes after index region split. > So i can assume that this issue comes from cac

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

an apply the patch > on top of 4.14 and see if it fixes your problem. > > Regards, > Ankit Singhal > > On Wed, Sep 26, 2018 at 2:33 PM Batyrshin Alexander <0x62...@gmail.com > <mailto:0x62...@gmail.com>> wrote: > Any advices? Helps? > I can reproduce prob

IllegalStateException: Phoenix driver closed because server is shutting down

Is there any reason for this exception? Which exactly server is shutting down if we use quorum of zookepers? java.lang.IllegalStateException: Phoenix driver closed because server is shutting down at

Re: IllegalStateException: Phoenix driver closed because server is shutting down

(Thread.java:748) > On 19 Sep 2018, at 20:13, Josh Elser wrote: > > What version of Phoenix are you using? Is this the full stack trace you see > that touches Phoenix (or HBase) classes? > > On 9/19/18 12:42 PM, Batyrshin Alexander wrote: >> Is there any reason for this

Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

Hello, Looks live we got dead lock with repeating "ERROR 1120 (XCL20)" exception. At this time all indexes is ACTIVE. Can you help to make deeper diagnose? java.sql.SQLException: ERROR 1120 (XCL20): Writes to table blocked until index can be updated. tableName=TBL_MARK at

Re: MutationState size is bigger than maximum allowed number of bytes

>Jaanai Zhang >Best regards! > > > > Batyrshin Alexander <0x62...@gmail.com <mailto:0x62...@gmail.com>> > 于2018年9月20日周四 上午7:48写道： > I've tried to copy one table to other via UPSERT SELECT construction and got > this errors: > > Phoenix-4.14-hbas

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

Our setup: HBase-1.4.7 Phoenix-4.14-hbase-1.4 > On 20 Sep 2018, at 20:19, Batyrshin Alexander <0x62...@gmail.com> wrote: > > Hello, > Looks live we got dead lock with repeating "ERROR 1120 (XCL20)" exception. At > this time all indexes is ACTIVE. > Ca

Phoenix perform full scan and ignore covered global index

Examples: 1. Ignoring indexes if "*" used for select even index include all columns from source table 0: jdbc:phoenix:127.0.0.1> explain select * from table where "p" = '123123123';

Re: [ANNOUNCE] Apache Phoenix 4.14.1 released

Looks like bin packed with some non standard options. Extracting on Ubuntu-16.04 looks like this: $ tar -xzf apache-phoenix-4.14.1-HBase-1.4-bin.tar.gz tar: Ignoring unknown extended header keyword 'LIBARCHIVE.creationtime' tar: Ignoring unknown extended header keyword 'SCHILY.dev' tar: Ignoring

Re: ABORTING region server and following HBase cluster "crash"

order > will be restored. Lather, rinse, repeat until everything is enabled and > online. > > A big enough failure sprinkled with a little bit of bad luck and what > seems to be a Phoenix flaw == deadlock trying to get HBASE to start up. Fix > by forcing the order that Hbase