Gustavo Straube Gustavo Straube - 3 months ago 23
Node.js Question

How to make sure Elastic Search is healthy before sending a command?

I'm indexing a bunch of documents using Elastic Search's Bulk API from the Javascript (NodeJS) client. I'm sending a thousand docs with each call. The instance handles it until before it reaches 100 calls (100K documents, approx.). Then it goes down returning a Service Unavailable (503) error.

Before doing a new call, I wait for the previous to complete and an extra second.

Searching on this matter, I found a post that talks about a fix for Rails: https://medium.com/@thetron/dealing-with-503-errors-when-testing-elasticsearch-integration-in-rails-ec7a5f828274. The author uses the following code to make the errors go away:

before do
repository.create_index!
repository.client.cluster.health wait_for_status: ‘yellow’
end


Based on that, I wrote the following:

const body = [
// 1K actions/docs
];
elastic.cluster.health({
waitForStatus: 'yellow',
timeout: '60s', // I also tried using the default timeout
requestTimeout: 60000
}, function (error, response) {
if (!!error) {
console.error(error);
return;
}
elastic.bulk({
body: body
}, function (error, response) {
if (!!error) {
console.error(error);
return;
}
console.log('Success!');
});
});


Not sure if it makes any difference, but the instance is running on AWS. Due the big number of docs, maybe scaling up the instance is a solution. But I wanted to figure out how to handle this error before going that way. Even if I have to make my code somewhat slower.

Answer

Your best bet is to scale up your cluster as you've said, but your loading process should be able to handle failures as well.

That being said, the following are the Elasticsearch cluster statuses:

  • red - There's at least one unallocated primary shard
  • yellow - There's at least one unallocated replica shard
  • green - Everything is allocated and healthy

So in you example above, you don't want to wait for yellow, you want to wait for green.

Comments