Re: jdbc not work, phoenix 4.14.0-cdh5.11.2 + kerberos
Hi Josh, thank you for replying. This is an excerpt from the debug log: the client can connected to Zookeeper successfully: 2018-08-01 10:21:15,987 [pool-1-thread-1] INFO org.apache.phoenix.jdbc.PhoenixEmbeddedDriver$ConnectionInfo - Trying to connect to a secure cluster as an...@realm.com with keytab /Users/anung/anung.keytab 2018-08-01 10:21:15,987 [pool-1-thread-1] INFO org.apache.phoenix.jdbc.PhoenixEmbeddedDriver$ConnectionInfo - Successful login to secure cluster 2018-08-01 10:21:17,351 [pool-1-thread-1-SendThread(ZKnode:2181)] INFO org.apache.phoenix.shaded.org.apache.zookeeper.ClientCnxn - Socket connection established, initiating session, client: /10.30.250.156:50181, server: ZKnode:2181 2018-08-01 10:21:17,354 [pool-1-thread-1-SendThread(ZKnode:2181)] DEBUG org.apache.phoenix.shaded.org.apache.zookeeper.ClientCnxn - Session establishment request sent on ZKnode:2181 2018-08-01 10:21:17,376 [pool-1-thread-1-SendThread(ZKnode:2181)] INFO org.apache.phoenix.shaded.org.apache.zookeeper.ClientCnxn - Session establishment complete on server ZKnode:2181, sessionid = 0x364e0801fa52086, negotiated timeout = 6 2018-08-01 10:21:17,380 [pool-1-thread-1-EventThread] DEBUG org.apache.hadoop.hbase.zookeeper.ZooKeeperWatcher - hconnection-0x25f652be0x0, quorum=ZKnode:2181, baseZNode=/hbase Received ZooKeeper Event, type=None, state=SyncConnected, path=null 2018-08-01 10:21:17,384 [pool-1-thread-1-EventThread] DEBUG org.apache.hadoop.hbase.zookeeper.ZooKeeperWatcher - hconnection-0x25f652be-0x364e0801fa52086 connected ... but somehow HBase auth using SIMPLE instead of Kerberos: ... 2018-08-01 10:21:22,744 [hconnection-0x25f652be-shared--pool1-t1] DEBUG org.apache.hadoop.hbase.ipc.RpcClientImpl - Use SIMPLE authentication for service ClientService, sasl=false 2018-08-01 10:21:22,826 [hconnection-0x25f652be-shared--pool1-t1] DEBUG org.apache.hadoop.hbase.ipc.RpcClientImpl - Connecting to Regionserver:60020 ... 2018-08-01 10:22:12,649 [pool-1-thread-1] DEBUG org.apache.hadoop.hbase.client.ResultBoundedCompletionService - Replica 0 returns java.net.SocketTimeoutException: callTimeout=6, callDuration=70972: row 'SYSTEM:CATALOG,,' on table 'hbase:meta' at region=hbase:meta,,1.1588230740, hostname=Regionserver,60020,1533093258500, seqNum=0 ... Thank you, BR, Anung On Wed, Aug 1, 2018 at 1:50 AM Josh Elser wrote: > > Did you enable DEBUG logging on the client or server side? Certainly if > you got a connection timeout, you at least got a stack trace that you > could share. > > You need to provide more information if you want help debugging your setup. > > On 7/31/18 6:29 AM, anung wrote: > > Hi All, > > > > I have CDH 5.11 cluster (kerberized, but HBase is not yet secured), > > installed Phoenix 4.14.0-cdh5.11.2 parcel method, test the JDBC > > connection and succeed. > > I can query, create table, drop table etc. > > > > And then I enabling kerberos security in HBase, restart service, and > > JDBC Phoenix is dead. Connection timeout. Just that, no other > > information. > > > > JDBC connection string: > > > > jdbc:phoenix:node1,node2,node3:2181:/hbase:an...@realm.com:/home/anung/anung.keytab > > > > I try kinit and use sqlline in the datanode and edgenode and yes > > Phoenix is working. > > > > is there something missing in my end? > > > > Thank you > > > > BR, > > Anung > >
Re: Potentially corrupted table
I don't recall any big issues on 4.13.2, but I, admittedly, haven't followed it closely. You weren't doing anything weird on your own -- you wrote data via the JDBC driver? Any index tables? Aside from weirdness in the client with statistics, there isn't much I've seen that ever causes a "bad" table. You have to try pretty hard to "corrupt" a table. On 7/31/18 11:02 AM, Flavio Pompermaier wrote: Hi to all, today I had a very weird, and potentially critical, behavior in my Phoenix installation (4.13.2 on CDH 5.11.2). I started upserting rows in a salted table but I fortunately discovered that some of them were missing (and the PK was unique). After 3 hours of attempts and debugging I gave up and I deleted and recreated the table. Now the upserts works like a charm...this is very bad and I still don't know the source of the problem. Is there a way to check if a table is in a good state or if there's something wrong? Best, Flavio
Re: jdbc not work, phoenix 4.14.0-cdh5.11.2 + kerberos
Did you enable DEBUG logging on the client or server side? Certainly if you got a connection timeout, you at least got a stack trace that you could share. You need to provide more information if you want help debugging your setup. On 7/31/18 6:29 AM, anung wrote: Hi All, I have CDH 5.11 cluster (kerberized, but HBase is not yet secured), installed Phoenix 4.14.0-cdh5.11.2 parcel method, test the JDBC connection and succeed. I can query, create table, drop table etc. And then I enabling kerberos security in HBase, restart service, and JDBC Phoenix is dead. Connection timeout. Just that, no other information. JDBC connection string: jdbc:phoenix:node1,node2,node3:2181:/hbase:an...@realm.com:/home/anung/anung.keytab I try kinit and use sqlline in the datanode and edgenode and yes Phoenix is working. is there something missing in my end? Thank you BR, Anung
Re: order by primary key desc return wrong results
Please file a JIRA. On Mon, Jul 30, 2018 at 10:12 PM, jie chen wrote: > phoenix-4.14-hbase-1.2 > > 0: jdbc:phoenix:localhost> create table test(id bigint not null primary >>> key, a bigint); >> >> No rows affected (1.242 seconds) >> >> 0: jdbc:phoenix:localhost> upsert into test values(1,11); >> >> 1 row affected (0.01 seconds) >> >> 0: jdbc:phoenix:localhost> upsert into test values(2,22); >> >> 1 row affected (0.007 seconds) >> >> 0: jdbc:phoenix:localhost> upsert into test values(3,33); >> >> 1 row affected (0.005 seconds) >> >> 0: jdbc:phoenix:localhost> select * from test; >> >> +-+-+ >> >> | ID | A | >> >> +-+-+ >> >> | 1 | 11 | >> >> | 2 | 22 | >> >> | 3 | 33 | >> >> +-+-+ >> >> 3 rows selected (0.015 seconds) >> >> 0: jdbc:phoenix:localhost> select * from test order by id desc limit 2 >>> offset 0; >> >> +-+-+ >> >> | ID | A | >> >> +-+-+ >> >> | 3 | 33 | >> >> | 2 | 22 | >> >> +-+-+ >> >> 2 rows selected (0.018 seconds) >> >> 0: jdbc:phoenix:localhost> select * from test where id in (select id from >>> test ) order by id desc limit 2 offset 0; >> >> +-+-+ >> >> | ID | A | >> >> +-+-+ >> >> | 2 | 22 | >> >> | 1 | 11 | >> >> +-+-+ >> >> wrong results. should be > >> >>> >>> +-+-+ >> >> | ID | A | >> >> +-+-+ >> >> | 3 | 33 | >> >> | 2 | 22 | >> >> +-+-+ >> >> there may be some errors. ScanUtil.setupReverseScan code. > >
Potentially corrupted table
Hi to all, today I had a very weird, and potentially critical, behavior in my Phoenix installation (4.13.2 on CDH 5.11.2). I started upserting rows in a salted table but I fortunately discovered that some of them were missing (and the PK was unique). After 3 hours of attempts and debugging I gave up and I deleted and recreated the table. Now the upserts works like a charm...this is very bad and I still don't know the source of the problem. Is there a way to check if a table is in a good state or if there's something wrong? Best, Flavio
jdbc not work, phoenix 4.14.0-cdh5.11.2 + kerberos
Hi All, I have CDH 5.11 cluster (kerberized, but HBase is not yet secured), installed Phoenix 4.14.0-cdh5.11.2 parcel method, test the JDBC connection and succeed. I can query, create table, drop table etc. And then I enabling kerberos security in HBase, restart service, and JDBC Phoenix is dead. Connection timeout. Just that, no other information. JDBC connection string: jdbc:phoenix:node1,node2,node3:2181:/hbase:an...@realm.com:/home/anung/anung.keytab I try kinit and use sqlline in the datanode and edgenode and yes Phoenix is working. is there something missing in my end? Thank you BR, Anung
order by primary key desc return wrong results
phoenix-4.14-hbase-1.2 0: jdbc:phoenix:localhost> create table test(id bigint not null primary >> key, a bigint); > > No rows affected (1.242 seconds) > > 0: jdbc:phoenix:localhost> upsert into test values(1,11); > > 1 row affected (0.01 seconds) > > 0: jdbc:phoenix:localhost> upsert into test values(2,22); > > 1 row affected (0.007 seconds) > > 0: jdbc:phoenix:localhost> upsert into test values(3,33); > > 1 row affected (0.005 seconds) > > 0: jdbc:phoenix:localhost> select * from test; > > +-+-+ > > | ID | A | > > +-+-+ > > | 1 | 11 | > > | 2 | 22 | > > | 3 | 33 | > > +-+-+ > > 3 rows selected (0.015 seconds) > > 0: jdbc:phoenix:localhost> select * from test order by id desc limit 2 >> offset 0; > > +-+-+ > > | ID | A | > > +-+-+ > > | 3 | 33 | > > | 2 | 22 | > > +-+-+ > > 2 rows selected (0.018 seconds) > > 0: jdbc:phoenix:localhost> select * from test where id in (select id from >> test ) order by id desc limit 2 offset 0; > > +-+-+ > > | ID | A | > > +-+-+ > > | 2 | 22 | > > | 1 | 11 | > > +-+-+ > > wrong results. should be > >> >> +-+-+ > > | ID | A | > > +-+-+ > > | 3 | 33 | > > | 2 | 22 | > > +-+-+ > > there may be some errors. ScanUtil.setupReverseScan code.
