Thank you so much ! ... View more

This has come up a few times on mailing lists and on the Apache Kudu slack, so I'll post here too; it's worth noting that if you want a single-partition table, you can omit the PARTITION BY clause entirely. See the "Note" here: https://www.cloudera.com/documentation/enterprise/latest/topics/kudu_impala.html#concept_g51_5vk_ft ... View more

Hi, is this the only solution for this kind of error - increasing the memory limit? Thannks ... View more

This table is monthly range partitioned with day as hash partition. This seems to had happen due to load on server during the specific time. https://issues.apache.org/jira/browse/KUDU-1078   I had to create a new table and delete previous one to get data insertion started, but this has happened again with a different table, providing ksck logs: Tablet 5e5edc9ab5f84dbe8ef3f1e650057cd1 of table 'impala::vertoz.tbl_bid_winimp' is under-replicated: 1 replica(s) not RUNNING 080aabc3c7c94e178e107f09b7959c15 (data-node-4.vrtzads.com:7050): RUNNING 2fe8aae066c1491788f5044a8db31524 (cicloud2.ny1vrtzads.com:7050): bad state State: FAILED Data state: TABLET_DATA_READY Last status: Incomplete: Unable to load Consensus metadata: Could not read header for proto container file /home/kudu/tserver/consensus-meta/5e5edc9ab5f84dbe8ef3f1e650057cd1: File size not large enough to be valid: Proto container file /home/kudu/tserver/consensus-meta/5e5edc9ab5f84dbe8ef3f1e650057cd1: Tried to read 16 bytes at offset 0 but file size is only 0 bytes 9d754b0276bf4a04a46e2fe0d8d414f6 (data-node-3.vrtzads.com:7050): RUNNING [LEADER] 2 replicas' active configs differ from the master's. All the peers reported by the master and tablet servers are: A = 080aabc3c7c94e178e107f09b7959c15 B = 2fe8aae066c1491788f5044a8db31524 C = 9d754b0276bf4a04a46e2fe0d8d414f6 The consensus matrix is: Config source | Voters | Current term | Config index | Committed? ---------------+------------------------+--------------+--------------+------------ master | A B C* | | | Yes A | A B C | 5 | -1 | Yes B | [config not available] | | | C | B C | 5 | 7 | No Table impala::vertoz.tbl_bid_winimp has 17 under-replicated tablet(s) WARNING: 2 out of 7 table(s) are not in a healthy state ================== Errors: ================== table consistency check error: Corruption: 2 table(s) are bad FAILED Runtime error: ksck discovered errors ... View more

Hi,   This looks like a different flavor of something we encountered while testing Sentry in 5.13 (that we didn't resolve). I pinged a few folks internally.   FWIW I tried just spinning up a secure CM5.14.1 + CDH5.12.2 cluster with all the services and my HMS came up just fine without that config. Can you describe more how you upgraded CM, if any other configs were changed before/after the upgrade, and if you added any services before or after?   As an aside, the Impala forum is probably not the best place to get help for this issue.   Thanks,   J-D ... View more

The snippet posted shows that the tablet server is unable to verify the TLS certificate generated for the tablet server because the certificate 'valid from' field is in the future.  That's most likely because the master host's clock is at least 1 second ahead of the tablet server host's clock.   Tablet server TLS certificates are generated by master when the tablet server connects to the master first time after starting up.  Tablet server will retry the connection with next heartbeat to the master, sending a new certificate signing request, and the master will generate a new certificate, with the validity date in the future, again.   I suspect that the error will continue to appear even if you restart Kudu, and restarting Kudu will not help. You need to synchronize clock across machines in the cluster, at least within the delta of 1 second.  If NTP does not work for you, I would recommend trying at least to run 'ntpdate' at every machine of your cluster prior to starting Kudu servers. ... View more

@hindog wrote: "Nor the browser column" -- What if the "browser" column WAS the primary key?  Would increment be possible in similar fashion to upsert, the difference being that internally Kudu would read the existing value and add it to the increment value before saving?   The other Kudu limitation that this runs into is that row key columns cannot be modified. It would be somewhat easier to implement atomic increments on non-key columns, but then that means doing a lot of updates and it's not something Kudu excels at e.g. it supports modifying data but the higher the rate the slower the reads are. ... View more