hi,adar:     if both the WAL segments and the CFiles are copied duing a tablet copy,then the follower tablet will  alse flushing wal data to disk when growing up to 8M,in my opinion  there has no difference between master tablet and follower tablet during the reading and writing,is that right? ... View more

Thanks youe reply.  Unfortunately, an upgrade is not available at this time in my company. I have rebalance my tablet server and modified the config 【maintenance_manager_num_threads】to 8 , 【block_cache_capacity_mb】 to 512MB, 【memory_limit_hard_bytes】to 60G。 AND then I try to run MR job on yarn, when get map counts with 96, and memory with 194G on yarn, kudu server is stable. So I continue to run a few job on yarn to to observe Kudu, and kudu server is still stable. So I think it is ok and set up scheduling tasks.   But when today, a job run 179 maps, the kudu server is random quit... this is the memory detail one of tablet server     ... View more

I am able to sqoop the data from Oracle to HDFS and then do a create table as select * from on Impala to write into Kudu.I am abe to manually run the queries here but What is the best way to  automate this when i move the code to production.   ... View more

Yes - that WIP links back to KUDU-1603 that I shared earlier. Guess, we will have to wait it out. Thanks for your response.  ... View more

Hi,   Kudu requires the machine clock of master and tablet servers nodes is synchronized using NTP : https://kudu.apache.org/docs/troubleshooting.html#ntp   Kudu is tested with ntpd, but I guess chronyd might work as well.  Whether using ntpd or chronyd, it's necessary to make sure the machine's clock is synchronized so ntp_adjtime() Linux system call doesn't return an error (see http://man7.org/linux/man-pages/man2/adjtimex.2.html for more technical details).   It's not enough just to have ntpd (or chronyd) running.  It's necessary to make sure the clock is synchronized.  I would verify that the NTP daemon is properly configured and tracks the clocks of the reference servers.  For the instructions to check the sync status of machine's clock, see https://kudu.apache.org/docs/troubleshooting.html#ntp if using ntpd or https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/sect-Checking_if_chrony_is_synchronized.html for chronyd.   Hope this helps,   Alexey   ... View more

thanks for these informations, a little question : where must I define the custom mapping ?   Best regards   Christophe ... View more

@Andreyeff Another thing you can try doing is increasing the raft heartbeat interval from 500ms to 1500ms or even 3000ms, see https://kudu.apache.org/docs/configuration_reference.html#kudu-tserver_raft_heartbeat_interval_ms   This will affect your recovery time by a few seconds if a leader fails since by default, elections don't happen for 3 missed heartbeat periods (controlled by https://kudu.apache.org/docs/configuration_reference.html#kudu-tserver_leader_failure_max_missed_heartbeat_periods ) ... View more

Thank you Alexey, the port in case 1 was endeed the problem. I don't know where I got the 7077, I guess **bleep**ching back and forth form Kudu to Spark addresses got them mixed up. In case 2, I am working the same machine but strangely, changing the ip from localhost to 172.17.0.43 made it work. Thanks again! ... 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