Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[server][da-vinci-client] Mark a helix replica to error state during ingestion error #1337

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

majisourav99
Copy link
Contributor

@majisourav99 majisourav99 commented Nov 22, 2024

Mark a helix replica to error state during ingestion error

If ingestion task encounters any error, it just marks the CV to error state which never remediates. This PR makes user of a new API helix added to annotate a replica to ERROR state. This will later be picked by the error replica reset task ErrorPartitionResetTask which will attempt to recover those replicas.

How was this PR tested?

GHCI

Does this PR introduce any user-facing changes?

  • No. You can skip the rest of this section.
  • Yes. Make sure to explain your proposed changes and call out the behavior change.

@sushantmane
Copy link
Contributor

sushantmane commented Nov 25, 2024

Can we ensure that not all replicas for the current version are marked as ERROR, so we can still serve traffic with some replicas (even if it's stale)

@majisourav99
Copy link
Contributor Author

Can we ensure that not all replicas for the current version are marked as ERROR, so we can still serve traffic with some replicas (even if it's stale)

Discussed offline, this PR will reset the replica when we are marking CV to error as well, so there will not be any extra risk to read path not having any replica to server reads.

Copy link
Contributor

@gaojieliu gaojieliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments.

@@ -79,7 +79,7 @@ public class HelixParticipationService extends AbstractVeniceService
private final String clusterName;
private final String participantName;
private final String zkAddress;
private final StoreIngestionService ingestionService;
private StoreIngestionService ingestionService = null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change?

@@ -525,6 +533,14 @@ public StoreIngestionTask(
}
this.batchReportIncPushStatusEnabled = !isDaVinciClient && serverConfig.getBatchReportEOIPEnabled();
this.parallelProcessingThreadPool = builder.getAAWCWorkLoadProcessingThreadPool();
this.zkHelixAdmin = Lazy.of(() -> new ZKHelixAdmin(zkAddress));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be very expensive to have one ZKHelixAdmin per SIT, I think we should use a shared ZKHelixAdmin among all the SITs.
I bet each ZKHelixAdmin instance will create one ZK client internally.

// Set the replica state to ERROR so that the controller can attempt to reset the partition.
if (!isDaVinciClient) {
zkHelixAdmin.get()
.setPartitionsToError(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to set EV state as ERROR, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw you mentioned that this logic would only mark EV state as ERROR when CV is in ERROR state, so how can we achieve that by the current logic?
Only the following logic today decides whether to propagate ERROR to CV/EV IIUC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants