yes it will if you will my 2nd last comment i mention the same that 1 blocks will be in rack1 and 2 blocks will be in rack2 on different DN if you will have 3 racks then either 1 blocks each rack or same 1 block and 2 blocks in each rack ... View more

@yagoaparecidoti  then one each rack will have 2 replica/each rack in different DN so if one rack goes down other will be available but its better to have 3 rack with 7 DN each as per your scenario ... View more

Hi Team Below is your answer: 1. what would be the best scenario to deploy the rack in the cluster? Ans. When you have huge read/writes going on DN and have huge no of DN then toreduce the network traffic while file read/write, which improves the cluster performance 2. will this rack deployment cause unavailability in the cluster? This rack will contain equal no of DN suppose you have 9 DN with 3 rack then each rack will have 3 DN now block placement will be 1-2 Block in each rack with different DN so suppose one rack will fall then you will have another 2 rack to take care of read/write 3. what are the “strengths” and “weaknesses” when deploying the rack in the cluster? Ans. Strength: High Availabilty , Performance improvement Weakness: not seen any with RF=3 blocks but if you have less than 3 then there might be scenario that 2 blocks will be on same rack but in different DN if that rack falls then it will cause unavailabilty ... View more

Hi Team, Did you use hdfs dfsadmin -report command to check the dfs and non-dfs used, dfs is used by HDFS so i blieve 9TB is complete storage with dfs and nondfs. Now when you copying the file to hdfs have you enable the debug HADOOP_ROOT_LOGGER=DEBUG,console Also try to run the below command it will copy the file from local to hdfs hdfs dfs -Ddfs.replication=#noofdatanodes -put /tmp/<3mbfile> /tmp ... View more

Hi Team, looks like you have 3 DN with rack topology have you check how many racks there as per rack awareness 1 block will be on 1 DN in each rach or max 2 block in each rack with different datanode You can try triggering the block report manually from DN to NN hdfs dfsadmin -triggerBlockReport <datanode>:<ipc_port> ... View more

Hello Olivier, if the issue resolved please mark one of above thread as solution if not then provide us the update so that we can prepare next action plan for you.   Regards, Asfahan Zafar ... View more

Hello Olivier, The user you are using to backup has not enough permission, if you using ranger for permission then bypass this try --trusted_user_acl=<username> in kudu service gflag and restart the kudu service then try again the backup let us know.   Regards, Asfahan Zafar ... View more

the command is to show you where all the replica of that tabletid exist now login to those TS go to consensus-meta and check the size in all three TS, ... View more

Hi,   kudu balancer balance tablet per TS but not the size of tablet,    1) what replication factor you have provided for kudu 2) please run the kudu cluster ksck master_address_fqdn <tablet_id>. << it will show you all the replica of this tablet and cross- check the size of tablet in all 3TS   My assumption is this tablet is new and kudu will be downloading the blocks on the same time thats why the replica is showing differ size but its an assumption, you need to trace the same via kudu TS logs which used to be under /var/log/kudu ... View more

Hi Team,   I believe your issue has not been resolved till now hence i am pointing toward a direction where you need to look..!!   if you TS is taking 3-4 hours it means there is a massive overload on them, Please check the scheme/scala from kudu runbook   https://kudu.apache.org/docs/scaling_guide.html   Points need to check:   1) Please check how many Tablet per TS you have, we don't recommend more than 2K per TS post replication 2) Does your master WAL and Data directory is on same disk, as its not recommended too 3) How many data directory you have per TS, keep from 3-12..!! 4) Please run your kudu cluster ksck <master_addrss>  command and check if your cluster is in healthy state..!!     Thanks..!! ... View more