David Alves commented on KUDU-2342:

>From what I read of the code, there are two main gc mechanisms:
 * one only for voters, that makes sure never to gc more than the committed 
 * one for all peers that is more conservative as it only gcs after everyone 
has an index, but has an upper bound of 80


In this case we gc'd logs after the tablet copy as if the peer as a non-voter 
(second rule), meaning the non-voter can't catch up, but then still promoted 
him to voter, pushing a change config that can never be committed.


> Insert into Lineitem table with 1340 tablets on 129 node cluster failed with 
> "Failed to write batch "
> -----------------------------------------------------------------------------------------------------
>                 Key: KUDU-2342
>                 URL: https://issues.apache.org/jira/browse/KUDU-2342
>             Project: Kudu
>          Issue Type: Bug
>          Components: tablet
>    Affects Versions: 1.7.0
>            Reporter: Mostafa Mokhtar
>            Assignee: Alexey Serbin
>            Priority: Blocker
>              Labels: scalability
>         Attachments: Impala query profile.txt, tablet-info.html
> While loading TPCH 30TB on 129 node cluster via Impala, write operation 
> failed with :
>     Query Status: Kudu error(s) reported, first error: Timed out: Failed to 
> write batch of 38590 ops to tablet b8431200388d486995a4426c88bc06a2 after 1 
> attempt(s): Failed to write to server: a260dca5a9c846e99cb621881a7b86b8 
> (vc1515.halxg.cloudera.com:7050): Write RPC to X.X.X.X:7050 timed out after 
> 180.000s (SENT)

This message was sent by Atlassian JIRA

Reply via email to