The documentation says: It is recommended that new tables which are expected to have heavy read and write workloads have at least as many tablets as tablet servers. If I have as many tablets as data disks (for instance 3 tablet servers, 10 disks per node, I split the table in 30 partitions), will kudu be smart enough to put a tablet per disk or am I actually limiting performance? I wonder in theory (assuming a very big table) what would be the best: 3 partitions (1 per tablet server), 30 partitions (1 per disk), More than 30 (because my table is really big), Something in between?
... View more
I am trying to have the cloudera manager run a check on a kudu cluster, which eventually will be the following command, run as the kudu user:
kudu cluster ksck master_host
The output of this command is:
Not authorized: leader master liveness check error: Could not connect to the cluster: Client connection negotiation failed: client connection to 10.x.y.z:7051: server requires authentication, but client does not have Kerberos credentials available
If I run this command manually from the command line, as kudu, I have the same error. If I try to run kinit, a password is asked for the kudu user.
If I update $HOME/.klogin to allow my user with ksu I do have a krb ticket (klist shows it) but it is still not a ticket for the kudu user, and I end up having the same error message.
My kerberos-fu is weak, but as far as I thought, the cluster was well configured, spark/impala/kudu work well together, without authorisation issue. The inspector is all green, there are kudu credentials for all hosts of the cluster.
How could I have this command run properly from the cloudera manager?
... View more