elasticsearch

0.19.3 Released

2012-04-30T00:00:00-07:00

elasticsearch version 0.19.3 is out. You can download it here. The release includes an upgraded Lucene 3.6 version, and several bug fixes, including better handling of network splits with node client nodes and with minimum master nodes.

0.19.3

2012-04-30T00:00:00-07:00

New features:

Upgrade to Lucene 3.6 (#1862)

Enhancements:

Upgrade to Netty 3.4.1 (#1863)
Better handling of fields that have . in their name when doing property based navigation (#1875)
Upgrade to Netty 3.4.1.Final (#1878)
Bulk API: Allow to control if its compressed or not using action.bulk.compress (defaults to true which is current behavior) (#1850)
Date Histogram Facet: Add quarter as an interval (#1884)
Node Stats: Add timestamp per node stats element (#1851)

Bug fixes:

Relocation of shards causes bulk indexing client to hang (#1839)
Setting index.auto_expand_replicas in the elasticsearch config file does not apply (#1852)
XContentBuilder throws NPE on null Boolean (#1853)
On recovery (startup), the recovery translog file handle is not properly closed (#1866)
NullPointerException in geo_distance_range without to (#1865)
JDK 7 requires minimum of 256k stack size, update scripts to set it (#1892)
When a node disconnects from the cluster (not enough master nodes, or a client node) and rejoins it might not update its internal routing table (#1896)
Highlighting: Using “plain” (non term vector) highlighting with custom score within a filtered query fails to highlight (#1894)
Translog: Buffering translog does not write directly to the file channel but to RAF, which causes problems reading from the channel on windows (#1887)

0.19.2 Released

2012-04-04T00:00:00-07:00

elasticsearch version 0.19.2 is out. You can download it here. It is a bug fix release fixing several bugs including a bug not being able to update index level settings on a live index using the index update settings API.

0.19.2

2012-04-04T00:00:00-07:00

Upgrade Notes:

Upgrading from 0.18 requires issuing a full flush of all the indices in the cluster (curl host:9200/_flush) before shutting down the cluster, with no indexing operations happening after the flush.
The local gateway state structure has changed, a backup of the state files is created when upgrading, they can then be used to downgrade back to 0.18. Don’t downgrade without using them.

Enhancements:

Have streams provided to gateway (shared one) allow marking (#1803)
add an index level setting to disable/enable purging of expired docs (is… (#1808)
Add an index level setting to disable/enable purging of expired docs (#1791)
Analysis: Custom analyzer to allow to configure position_offset_gap and offset_gap (#1812)
Java API Query DSL: Add wrapper filter similar to wrapper query accepting a json filter in raw format (#1844)
Mapping: Allow to configure position_offset_gap for string mapping (#1813)
Query DSL: term filter to support the more “complex” form similar to term query (#1830)
Search/Get: Add preference option of _primary_first trying to primary first and then replicas (#1824)
Support for Latvian stemming: latvian analyzer and latvian language for stemmer filter (#1842)

Bug fixes:

Index Update Settings API does not update settings in real time (#1807)
Indexing a document in smile format and getting it through REST in json format fails (#1816)
TransportClient hangs when in sniff mode and no node running (#1818)
TransportClient (sniff) fails to reconnect to nodes once removed if all nodes are removed (#1819)
Disabling deletion of all indices does not work when using _all (#1834)
requesting fields=timestamp,source won’t return _source (#1833)
Getting _settings or _mapping for non-existing index returns 200 OK (#1828)
Number of replicas setting can not be set on a closed index (#1845)
Java API: Calling SearchHit#sourceAsString will not decompress the source to convert it to string (#1814)
Node Stats: OS stats reporting free as the key instead of used (#1804)

Deploying ElasticSearch with Chef Solo

2012-03-21T00:00:00-07:00

ElasticSearch is trivially easy to install and run: you just a download and extract an archive and run a simple script.

It’s a long way from there to production, though. You have to customize the configuration. You want to install some plugins. You’d like to ensure ElasticSearch starts on system boot. You want to monitor that the Java process is running and does not eat too much resources… and many other things.

And then you have to repeat all the steps for each and every node in your cluster.

It would be cool if you could do this in an automated, mechanized manner, wouldn’t it?

As it happens, there’s lots of both open source and commercial or vendor-specific infrastructure provisioning tools available, which make tasks like these a snap.

We’ll focus on Chef, an open-source framework for infrastructure provisioning and management, maintained and supported by Opscode.

What Is Chef?

This article can’t be a full introduction into Chef. You’ll find many learning materials on the Chef wiki, but for our purposes, we’ll manage with some absolute minimum.

The first important thing to understand is that there are actually two different “chefs”:

Chef Server, a central repository for all your infrastructure information and configuration data, which is used with the chef-client tool, and
Chef Solo, which uses a standalone chef-solo tool, which does not need a Chef server.

In the context of this article, we’ll be using Chef Solo, which means we can’t use certain advanced features, such as full text search of our server attributes, executing the same command over SSH on multiple servers at once, or using a web-based GUI, but we’ll still be able to automate without breaking a sweat.

The essential concepts of Chef are the same between the “server” and “solo” variants.

The first of these is a node. A node is simply an abstract configuration for a server, reachable by SSH. You can picture node as a document containing some attributes, such as a name, the port number for an Apache server or the list of software we want to have installed. A “physical representation” of the node is the virtual or physical server itself. (In Chef Server, things are a bit more complicated, but that doesn’t concern us right now.)

Every node can have one or multiple associated roles. A role joins together various configuration options for a certain type of machine: for instance, you can have a “webserver” role which would describe that you want to install an Apache webserver, a Varnish proxy, etc. A role contains recipes, or other roles. We won’t be using roles in this tutorial, though.

The most important concept is a cookbook, containing various recipes which describe, in detail, how we like our node to be set up. A recipe uses a variety of resources to describe these details, such as setting some default node properties, creating directories, creating configuration files with specific content, installing packages, downloading files from the internet, or executing arbitrary scripts and commands. Cookbooks hold together recipes, template files, Chef extensions, etc.

Have a look at the ElasticSearch cookbook we’ll be using in this tutorial, to get a sense of how cookbooks are organized and how do they work. The recipe is written in a simple Ruby-based domain specific language, and should be pretty understandable. Check out also the cookbook templates.

A recipe can also load additional data from data bags. Data bags are simple JSON documents, and can contain arbitrary information, such as user credentials, API tokens and other things not specific to a certain recipe. We won’t be using data bags in this tutorial, because we will store all information directly within the node configuration.

Our goals

OK, now we’re familiar with the essential parts of Chef. What are our goals, then? How would we like to have our ElasticSearch server to be set up? In fact, we would like a number of things:

First of all, install a specific version of ElasticSearch on the node
Create a elasticsearch.yml file with custom configuration
Create a separate user to run ElasticSearch
Register a service to start ElasticSearch automatically on server boot
Increase the open files limit for the elasticsearch user
Configure the memory limits and other settings for the JVM
Monitor the ElasticSearch process and cluster health with Monit
Install the Nginx web server and use it as a proxy for ElasticSearch
Store user credentials for HTTP authentication with Nginx

And optionally:

Install the AWS Cloud plugin
Configure the AWS Cloud plugin with proper credentials to use the EC2 discovery and the S3 gateway

As you can see, not a short list of tasks. If we would be doing them manually, we could easily spend whole afternoon with that. By using Chef, we should be done in under five minutes, once we get hold of it.

One important thing to emphasize is that we will use the Amazon EC2 service to create virtual servers to deploy ElasticSearch nodes at, and we will use some features in ElasticSearch specific to Amazon Web Services (AWS).

You’re not limited to the EC2 platform in any way, though: any virtual or physical server accessible by SSH will be absolutely perfect for the purposes of this tutorial — you’ll just need to configure the node a little bit differently.

Note: for making yourself familiar with running ElasticSearch on EC2, you should read the excellent tutorial by James Cook, “ElasticSearch on EC2”, which explains many important topics related to sucessfully running ElasticSearch in the AWS ecosystem. You don't have to read it for the purposes of this tutorial, though.

Preparation

Before we really start cooking, we must prepare all the tools and ingredients. Assuming EC2, we need to:

download and edit the scripts and configuration files used in this tutorial,
create a dedicated security group in AWS,
launch an instance which we’ll be provisioning via Chef,
download the SSH key used for accessing the instance.

We’ll begin by downloading the files need for this tutorial from the following gist: http://gist.github.com/2050769. We might as well do it with one command:

curl -# -L -k https://gist.github.com/gists/2050769/download | tar xz --strip 1 -C .

Your current directory should now contain 4 files (and a readme). Let’s review them briefly:

The bootstrap.sh file is a generic Bash script, which we’ll use for basic setup of the machine (installing make, Rubygems, etc.). The patches.sh script is used to fix some problems in community cookbooks (and will hopefully be removed from this tutorial soon). You don’t have to edit these files.

The node-example.js file contains an example configuration for the whole “node”: list of cookbooks we want to install, AWS credentials, username and password for the Nginx HTTP authentication, your e-mail address for Monit notifications. We’ll start with a much smaller configuration, though.

The solo.rb file contains configuration for Chef Solo. Again, you don’t have to touch it.

Information for non-AWS environments

From now on, we will assume that we're working with Amazon Elastic Cloud (EC2), provisioning an Amazon Linux operating system. If you'd like to work in a different environment (a VPS on Rackspace or Linode, local virtual machine in VirtualBox or custom hardware), and with a different operating system, you'll have to tweak couple of things.

First, you'll have to make sure you can access the server via SSH and update the SSH_OPTIONS environment variable according to your specific credentials.

Second, in the tutorial, we assume the server already has a working Ruby and Java installation. When it's not the case, they must be installed as part of the bootstrap process.

A bootstrap script and instructions for the Ubuntu operating system are available in this gist.

On Amazon EC2, we’ll start by creating a dedicated security group for our ElasticSearch cluster in the AWS console. We will name the group elasticsearch-test.

Make sure the security group allows connections on following ports:

Port 22 for SSH is open for external access (the default 0.0.0.0/0)
Port 8080 for the Nginx proxy is open for external access (the default 0.0.0.0/0)
Port 9300 for in-cluster communication is open for access only to servers running in the same security group (use the “Group ID” for this group, available on the “Details” tab, such as sg-1a23bcd)

The form for setting up the security group is pictured below.

Important: Don’t forget to click “Apply Rule Changes” so the changes are, in fact, applied.

Now, we’ll launch a new server instance at EC:

Use a meaningful name for the instance. We will use test-elasticsearch-chef-1.
Create a new “Key Pair” for the instance, and download it immediately. We will be using a key named elasticsearch-test.
Use the Amazon Linux AMI (ami-1b814f72). Amazon Linux comes with Ruby and Java pre-installed.
Use the m1.large instance type. You may use the small or even the micro instance type, but the process would take much longer).
Use the security group created in the first step (elasticsearch-test).

The quicklaunch screen for creating the instance is pictured below:

Dont’ forget to download the newly created SSH key!

Don’t forget to click the “Edit Details” link on the next screen and set the proper instance type (“m1.large”) in the “Instance Details” pane, and the proper security group (“elasticsearch-test”) in the “Security Settings” pane.

Now you can click “Launch” to create and start your server.

While the server is being created in EC2, we will copy the SSH key downloaded from AWS console to the tmp/ directory of this project and make sure it has proper permissions:

mkdir -p ./tmp
cp ~/Downloads/elasticsearch-test.pem ./tmp/
chmod 600 ./tmp/elasticsearch-test.pem

Once our server is in the running state, copy its “Public DNS” value in the AWS console (eg. ec2-123-40-123-50.compute-1.amazonaws.com) to clipboard.

Bootstrapping the Machine

We can begin the bootstrap and install process now.

First, we’ll setup the connection details for convenient passing into scp and ssh commands:

HOST=<REPLACE WITH YOUR PUBLIC DNS>
SSH_OPTIONS="-o User=ec2-user -o IdentityFile=./tmp/elasticsearch-test.pem -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"

We’ll check that we can connect to the machine via secure shell:

ssh $SSH_OPTIONS $HOST

You should be successfully logged into the machine. (Log out by pressing Ctrl+D.)

If you have trouble in this step, double-check that the security group is properly set up, that you’re using the correct SSH key, etc.

We will now create a simple configuration JSON file for the machine:

echo '
{
  "run_list": [ "recipe[elasticsearch]" ],
  "elasticsearch" : {
    "cluster_name" : "elasticsearch_test_with_chef"
  }
}
' > ./node.json

As you can see, we’re starting with a really simplified configuration: in the run_list property, we’re saying we want the ElasticSearch cookbook installed and that our cluster will be named elasticsearch_test_with_chef.

Let’s copy all these files to the machine via secure copy:

scp $SSH_OPTIONS ./bootstrap.sh ./patches.sh ./node.json ./solo.rb $HOST:/tmp

We can now begin to bootstrap the machine: install neccessary packages such as make, install Rubygems and the chef gem, download cookbooks from the internet, etc.:

time ssh -t $SSH_OPTIONS $HOST "sudo bash /tmp/bootstrap.sh"

You’ll see lots of lines flying by in your terminal. We’re running the bootstrap script remotely over SSH; it should take about 2 minutes.

We’re left with running the patches.sh script, which will fix some problems from the community cookbooks (create neccessary directories or users, etc.):

time ssh -t $SSH_OPTIONS $HOST "sudo bash /tmp/patches.sh"

Installing and Configuring ElasticSearch

OK – our server is now ready to be provisioned by Chef Solo. We will launch the following command:

time ssh -t $SSH_OPTIONS $HOST "sudo chef-solo --node-name elasticsearch-test-1 -j /tmp/node.json"

This command will perform all the steps neccessary for a bare bones ElasticSearch installation; it will create the directories at /usr/local/var/data/elasticsearch, create the elasticsearch user, download the ElasticSearch package from GitHub and run it.

Let’s have a look around on the server. Is ElasticSearch, in fact, running?

ssh -t $SSH_OPTIONS $HOST "curl localhost:9200"

We can also use the provided service script to check its status:

ssh -t $SSH_OPTIONS $HOST "sudo service elasticsearch status -v"

You can see that our cluster is named elasticsearch_test_with_chef, and that our node is named elasticsearch-test-1, and that the number of open files is 64000. In fact, let’s have a look at the elasticsearch.yml configuration file:

ssh -t $SSH_OPTIONS $HOST "cat /usr/local/etc/elasticsearch/elasticsearch.yml"

That’s all well and good – we have automated the ElasticSearch installation process, downloading the package, extracting it, registering it as a service, and properly configuring it.

But our goals are much more ambitious then that! We want monitoring, and the Nginx proxy, and proper AWS setup with EC2 discovery, and S3 persistence!

Seems like the right time to edit the node.js file has come.

The Full Installation

Let’s start with overwriting our current node.js with the provided example:

cp node-example.json node.json

We have to edit the file and replace the following properties:

elasticsearch.gateway.s3.bucket with a unique name for your bucket
elasticsearch.cloud.aws.access_key with your AWS Access Key
elasticsearch.cloud.aws.secret_key with your AWS Secret Key
monit.notify_email with your e-mail address

You’ll find the access and security keys on the “Security Credentials” page, accessible from the drop-down menu under your name in the top right corner.

All right, let’s upload the updated file to the machine:

scp $SSH_OPTIONS ./bootstrap.sh ./patches.sh ./node.json ./solo.rb $HOST:/tmp

And let’s run the provisioning script again:

time ssh -t $SSH_OPTIONS $HOST "sudo chef-solo --node-name elasticsearch-test-1 -j /tmp/node.json"

You should see, once again, many lines in your terminal flying by, installing Monit and Nginx, downloading the “AWS Cloud plugin” for ElasticSearch, configuring the Nginx proxy, and finally, restarting ElasticSearch itself.

Let’s try the new configuration by accessing the Nginx proxy running on port 8080:

curl http://USERNAME:PASSWORD@$HOST:8080

Pretty nice, right? Notice how trying to access the “Cluster API” is 403 Forbidden:

curl http://USERNAME:PASSWORD@$HOST:8080/_cluster/health

Nevertheless, we can index some documents over the Nginx proxy just fine:

curl -X POST "http://USERNAME:PASSWORD@$HOST:8080/test_chef_cookbook/document/1" -d '{"title" : "Test 1"}'
curl -X POST "http://USERNAME:PASSWORD@$HOST:8080/test_chef_cookbook/document/2" -d '{"title" : "Test 2"}'
curl -X POST "http://USERNAME:PASSWORD@$HOST:8080/test_chef_cookbook/document/3" -d '{"title" : "Test 3"}'
curl -X POST "http://USERNAME:PASSWORD@$HOST:8080/test_chef_cookbook/_refresh"

Let’s try to perform a search:

curl "http://USERNAME:PASSWORD@$HOST:8080/_search?pretty&q=*"

Perfect. We can also check that ElasticSearch is running smoothly via Monit:

ssh -t $SSH_OPTIONS $HOST "sudo monit reload && sudo monit status -v"

You can see that the ElasticSearch process is running and that the connection to port 9200 is online with all services. But what about the elasticsearch_cluster_health check? It says Connection failed. In fact, that’s expected:

ssh -t $SSH_OPTIONS $HOST "curl localhost:9200/_cluster/health?pretty"

Since we’re running with the default setting of one replica with only one ElasticSearch node, the cluster health is yellow: there’s no other server where the cluster can place the replica on.

Time to create another node in our cluster!

Adding Another Node

We’ll launch another node on EC2, using the “Launch More Like This” feature, available under the “Instance Actions” menu:

Name the second node test-elasticsearch-chef-2 and make sure that it runs under the elasticsearch-test security group.

Once the new instance is running, copy its “Public DNS” value. We will again store this value as the HOST environment variable:

HOST=<REPLACE WITH THE PUBLIC DNS FOR THE NEW SERVER>

Now, let’s run all the provisioning steps on the machine, making it the elasticsearch-test-2 node:

scp $SSH_OPTIONS ./bootstrap.sh ./patches.sh ./node.json ./solo.rb $HOST:/tmp
time ssh -t $SSH_OPTIONS $HOST "sudo bash /tmp/bootstrap.sh"
time ssh -t $SSH_OPTIONS $HOST "sudo bash /tmp/patches.sh"
time ssh -t $SSH_OPTIONS $HOST "sudo chef-solo --node-name elasticsearch-test-2 -j /tmp/node.json"

The whole process should be finished under five minutes, no less. Not bad, not at all.

Allow ElasticSearch couple of seconds to boot and check the cluster health again:

ssh -t $SSH_OPTIONS $HOST "curl localhost:9200/_cluster/health?pretty"

You may see the number of relocating_shards briefly increase, and then the cluster health should be green, and the number_of_nodes should be 2.

Not bad! We now have a fully operational, two-node ElasticSearch cluster, with convenient service scripts, an Nginx proxy for external access, and Monit-based supervision.

Going Further

Time to play some tricks with out setup. The first thing we’re going to try is to kill the ElasticSearch process on one of the nodes and see how it’s being started again by Monit.

First, let’s kill the process:

ssh -t $SSH_OPTIONS $HOST "cat '/usr/local/var/run/elasticsearch/elasticsearch_test_2.pid' | xargs -0 sudo kill -9"

If we check the ElasticSearch service status, it should not be running:

ssh -t $SSH_OPTIONS $HOST "sudo service elasticsearch status"

If we check the status in Monit after a while, when the next Monit tick fires off, it should also report the process not running and complain about all sorts of other problems:

ssh -t $SSH_OPTIONS $HOST "sudo monit status"

If you configured the e-mail adress for Monit properly, you’ll also receive a e-mail notification telling you about the incident (most probably in your Spam folder). (Provided you’ve not yet hit limits EC2 imposes on sending e-mail from instances.)

If we now repeatedly check the process status, it will go trough “Does Not Exist” and “Execution Failed” states, and after two or three minutes (based on the default Monit poll period), you should see the process in the running state again:

ssh -t $SSH_OPTIONS $HOST "sudo monit reload && sudo monit status"

So, our monitoring system seems to work quite well!

On EC2, we can try another trick to check out whether the S3 persistence is working.

Terminate both instances in the AWS console and create a new, fresh instance again.

Copy the “Public DNS” setting of the new server, and repeat the whole provisioning process, which should be now quite transparent to you:

HOST=<REPLACE WITH THE PUBLIC DNS VALUE>
scp $SSH_OPTIONS ./bootstrap.sh ./patches.sh ./node.json ./solo.rb $HOST:/tmp
time ssh -t $SSH_OPTIONS $HOST "sudo bash /tmp/bootstrap.sh"
time ssh -t $SSH_OPTIONS $HOST "sudo bash /tmp/patches.sh"
time ssh -t $SSH_OPTIONS $HOST "sudo chef-solo --node-name elasticsearch-test-1 -j /tmp/node.json"

Allow couple of seconds for ElasticSearch to boot and load the data, and perform the search on the freshly provisioned server:

curl "http://USERNAME:PASSWORD@$HOST:8080/_search?pretty&q=*"

You should now see the three documents, which we inserted long ago, on the now destroyed servers, displayed in your terminal: since we have configured our node to persist data into a S3 bucket, ElasticSearch happily loaded all the data from there.

Note: Again, to fully understand the different ElasticSearch persistence and discovery strategies and options at AWS, please read the “ElasticSearch on EC2” tutorial.

Conclusions

Congratulations! By following this tutorial, you were able to:

Establish a repeatable and reliable process for setting up an ElasticSearch server
Bootstrap, install and configure production-ready ElasticSearch cluster without manual intervention
Summarize the whole server configuration in the node.json file

The first thing to take from this exercise is, of course, that automation beats manual labor every single time, and by a long shot. When you’re provisioning a ElasticSearch server for the third time, it’s so painless you don’t even notice it.

When working with a provisioning tool such as Chef, resist the urge to tinker with the system manually, editing configuration files in vim and installing software manually — except in clearly determined cases when you’re trying something out.

It is of course faster to make a small change directly on the system itself, instead of performing all the provisioning steps. But the whole point of Chef is to make your system predictable, to summarize everything what’s needed for its operation in one place, and to eradicate manual intervention.

Notice how we added lots of configuration details in the “The Full Installation” chapter, uploaded the updated node.json file to the system, and then just ran the same command as previously. Chef discovered it needs to update the elasticsearch.yml file, did so, and restarted the ElasticSearch process to pick up the new configuration.

The same applies for changes in the cookbook: when the ElasticSearch cookbook is updated at GitHub, the bootstrap script will fetch the changes, and the next chef-solo run will reflect them on the system.

The second thing to notice is how powerful is a tool like Chef. We didn’t paid too much attention to Chef specifics, but let’s have a look at a small illustration. You should notice the memory settings for the JVM in the elasticsearch-env.sh file:

ssh -t $SSH_OPTIONS $HOST "cat /usr/local/etc/elasticsearch/elasticsearch-env.sh"

Where does the value Xmx4982m, or nearly 5 GB, come from? How does Chef know this value? Well, this Ruby code in the ElasticSearch cookbook did the computation, based on the total available memory on the EC2 large instance type (7.5 GB):

max_mem = "#{(node.memory.total.to_i - (node.memory.total.to_i/3) ) / 1024}m"
default.elasticsearch[:max_mem] = max_mem

Thanks to the Ohai tool, Chef knows many of these “automatic attributes” of the node, and can take them into consideration when provisioning the server. The ElasticSearch cookbook we have worked with makes use of these attribues in other places, for example when setting the node.name.

The final conclusion of this experiment is how open the whole Chef ecosystem is.

We didn’t have to use the hosted Chef Server product to use the other parts of its architecture. The concepts and principles are the same between Chef Solo and Chef Server, and allow you to reuse the most important part: the cookbooks.

Most of the cookbooks are available on the Opscode community page under permissive licenses. For a complex infrastructure, you’re most likely to adapt cookbooks to your needs, adjusting their recipes or templates. As we have seen, it’s trivial to mix “vendor” cookbooks with our own cookbooks: we have downloaded the “stock” Monit and Nginx cookbooks from the internet to the /var/chef-solo/site-cookbooks/ directory, while cloning a custom ElasticSearch cookbook to the /var/chef-solo/cookbooks directory.

The Chef domain specific language uses Ruby, a popular and expressive programming language, which makes adjusting and customizing cookbooks very easy. We can fork most cookbooks at Github and participate in the growing common knowledge of efficient infrastructure provisioning.

Enjoy your cooking!

0.19.1 Released

2012-03-20T00:00:00-07:00

elasticsearch version 0.19.1 is out. You can download it here. It is a bug fix release fixing several bugs including a major bug where a thread can get into CPU spin when its relocated and a search/stats operation is executed against it.

The release also includes an update to the `read_only` option on an index. The option caused both write and metadata operations to be disabled for the relevant index. Now, in 0.19.1, specific read, write and metadata blocks can be set. See more here.

0.19.1

2012-03-20T00:00:00-07:00

Upgrade Notes:

Upgrading from 0.18 requires issuing a full flush of all the indices in the cluster (curl host:9200/_flush) before shutting down the cluster, with no indexing operations happening after the flush.
The local gateway state structure has changed, a backup of the state files is created when upgrading, they can then be used to downgrade back to 0.18. Don’t downgrade without using them.

New features:

Index Blocks: Add index.blocks.write, index.blocks.read, and index.blocks.metadata settings (#1771)

Enhancements:

Add cache thread pool to handle cache loading of async caches (bloom filter) (#1777)
Java API for require_field_match (#1795)
Highlighting using the default highlighter (not using term vectors) only highlights on the first 50*1024 chars (#1796)
Get: Add a specific get thread pool that handles get request (#1778)
Query DSL: indices filter type (#1787)
Scripting: Allow to disable dynamic script execution (#1763)

Bug fixes:

Special host config notation _[interfaceName]_ might fail to resolve the host address (#1754)
RemoteTransportException on _analyze request to specific index (#1770)
Closing a shard can cause a search/stats request that tries to acquire a handle to search while its closing to spin (#1772)
IOException when restricting fields and returning nested arrays. (#1774)
mlt_field doesn’t support boost (#1773)
When node.data is set to false, the upgrade shards process from 0.18 fails (#1793)
Get/MultiGet API with no type provided and doc does not exists causes a failure (#1794)

0.19.0 Released

2012-03-01T00:00:00-08:00

elasticsearch version 0.19.0 is out. You can download it here. It is the final 0.19.0 release (after 3 release candidates). 0.19 major features have been outlined in the previous blog posts for each release candidate release, but, it also marks an important bug fix and stability release over 0.18, upgrade is highly encouraged to all elasticsearch users.

0.19.0

2012-03-01T00:00:00-08:00

Upgrade Notes:

Upgrading from 0.18 requires issuing a full flush of all the indices in the cluster (curl host:9200/_flush) before shutting down the cluster, with no indexing operations happening after the flush.
The local gateway state structure has changed, a backup of the state files is created when upgrading, they can then be used to downgrade back to 0.18. Don’t downgrade without using them.

Enhancements:

msearch should accept a leading \n (#1736)
Date Histogram Facet: Add pre_zone_adjust_large_interval (#1744)
Flush: Add a specific thread pool for flush operations (scheduled and API) (#1734)
Translog Flush: When disabling flush and enabling it again, scheduled flush stops executing (#1727)

Bug fixes:

Real time get on a stored _size field does not return its value (#1724)
query never returns (#1725)
Orderly shutdown with unicast discovery might cause the shutdown node to still be part of the election process (#1740)
NullPointerException when asking for null valued json field when fetching search request (#1749)
Multi level parent/child mapping and search fails (#1751)

Also see release notes for:

0.19.0.RC3 Released

2012-02-21T00:00:00-08:00

elasticsearch version 0.19.0.RC3 is out. You can download it here. Its another bug fix released and (hopefully) the final release of 0.19.0 release candidates.

It also includes two nice features. The first is the ability to use “date math” on date types (especially useful in range queries/filters). See more info in the issue (and documented under the mapping date type).

The second feature is a new API called “Multi Search” (or msearch). It allows to construct a single request holding several search requests, executing them in the cluster (in parallel) and returning the results. More info on the format and how to use it can be found in the issue (and documented under the guide API section).

0.19.0.RC3

2012-02-21T00:00:00-08:00

Upgrade Notes:

Upgrading from 0.18 requires issuing a full flush of all the indices in the cluster (curl host:9200/_flush) before shutting down the cluster, with no indexing operations happening after the flush.
The local gateway state structure has changed, a backup of the state files is created when upgrading, they can then be used to downgrade back to 0.18. Don’t downgrade without using them.

New features:

API: Multi Search (#1722)
Date Mapping: Support “date math” when searching (#1708)

Enhancements:

Indices query should accept alias names (#1698)
Return 503 for search against a node which is not yet ready (#1713)
Failed shards allocation can “poison” allocation and might cause not allocating other shards (#1717)
Analysis: Add trim token filter that trims whitespaces (#1693)
Index Templates: Allow to place them under config/templates (#1703)
Local Gateway: Delete dangling indices after a (configurable) timeout, and not immediately (#1718)
Search: Allow to execute search with no parameters (#1696)

Bug fixes:

Retrieving byte type stored field fails (#1702)
StackOverflowError when accessing NodeIndicesStats.refresh() (#1706)
top_children query returns no results when child field has the same name as a nested field as a nested field in the parent mapping (#1709)
Search: When using _all for types, field name/type resolution might fail (#1704)

0.19.0.RC2 Released

2012-02-08T00:00:00-08:00

elasticsearch version 0.19.0.RC2 is out. You can download it here. Its a bug fix release mainly fixing a major bug in how buffers are read and reused over the network (the optimization done in 0.19.0.RC1 was not complete).

It also include two nice features, the first is the ability to disallow a shard and its replica to be allocated on the same machine when running more than one instance on said machine. It can be enabled by setting cluster.routing.allocation.same_shard.host to true.

The second is an effort to better log GC pause times (without needing to turn on GC logging), with GC type thresholds and logging thresholds (comes with built in default values).

0.19.0.RC2

2012-02-08T00:00:00-08:00

Upgrade Notes:

Upgrading from 0.18 requires issuing a full flush of all the indices in the cluster (curl host:9200/_flush) before shutting down the cluster, with no indexing operations happening after the flush.
The local gateway state structure has changed, a backup of the state files is created when upgrading, they can then be used to downgrade back to 0.18. Don’t downgrade without using them.

Enhancements:

Avoid placing a shard replica on the same machine as shard itself (#1680)
GC logging: Enable back automatic gc logging based on thresholds (even if last gc is not available) (#1679)
Index API: Don’t wait for new mappings to be applied on the cluster by default (#1677)
Nodes Info API: Add all flag to return all data (#1676)

Bug fixes:

Transport buffer overrun can happen because of byte buffer reading optimization introduced in 0.19.0.RC1 (#1686)

0.19.0.RC1 Released

2012-02-07T00:00:00-08:00

elasticsearch version 0.19.0.RC1 is out. You can download it here. It is a major release candidate release of elasticsearch.

This is the first time we release a “release candidate” for elasticsearch. The aim is to get users to try it out, fix any problems found with it, and release a final 0.19.0 release as soon as possible.

Major features include improved indexing performance, more control over shard allocation, more statistics and simpler API for stats, an update API that accepts a script to perform an update on a document, better state storage when using local gateway, and many bug fixes.

Upgrading

This release requires a full cluster restart in order to upgrade to the new version (including issuing a flush across all indices before the restart). If you are using the (default) local gateway, it will automatically be upgraded to a new and improved state format (with backups of the original state).

The structure of the project has also changed, moving all the plugins to their own repos under github. Installing a plugin now requires specifying the location and version to install it from.

0.19.0.RC1

2012-02-07T00:00:00-08:00

Upgrade Notes:

Upgrading from 0.18 requires issuing a full flush of all the indices in the cluster (curl host:9200/_flush) before shutting down the cluster, with no indexing operations happening after the flush.
The local gateway state structure has changed, a backup of the state files is created when upgrading, they can then be used to downgrade back to 0.18. Don’t downgrade without using them.

Breaking changes:

Blank routing should be ignored (#1450)
Highlighting on term vector enabled field should not highlight filters by default (#1469)
Migrate built in plugins to their own repos (#1520)
Move project build to maven (#1523)
Move phonetic token filter to a plugin (#1594)
Improve serialization (stream) of UTF strings, note, requires flush when upgrading (#1595)
Date Histogram Facet: Improve time zone handling, add factor option (#1580)
Date Range: Inclusive upper range does not round up properly (#1463)
Java API: Move all request builders to org.elasticsearch.action… from org.elasticsearch.client.action (#1611)
Node Stats API: Add specific flags for stats, simplified REST paths (#1597)
Nodes Info API: Allow to specify which info to get back, simpler URI paths (#1596)
Thread Pool: Add a specific thread pool for bulk indexing operations (#1668)

New features:

Index shard search slow log (query and fetch) (#1462)
Upgrade to Lucene 3.5 (#1502)
Support Multicast discovery for external clients (#1532)
Set an index / indices to read only, or make the cluster read only (#1573)
Add query validation feature (#1574)
Add thread_pool to nodes info and nodes stats APIs (#1601)
Add generic execution of APIs to Client (and indices/cluster) and allow for plugins to register custom APIs (#1612)
Local Gateway: Store specific index metadata under dedicated index locations (#1631)
Plugins: Allow for plugins to implement onModule method that will be automatically injected with the relevant module type (#1613)
Search: Support partial fields that can returns partial view of the _source (#1570)
Update API: Allow to update a document based on a script (#1583)

Enhancements:

AbstractCompoundWordTokenFilterFactory should store the dictionary as a CharArraySet instance, not a Set (#1449)
XContentBuilder to handle extended classes of java.util.Date (#1465)
HTTPS support for CouchDB river (#1480)
Allow empty Strings to be null for Number’s and don’t autodetect empty string fields as string types (#1473)
By default, set http.compression to false (#1482)
DocumentMapper.java wrong order on build rootMappers (#1493)
Support using _id:1234, or using term query/filter on _id even when _id is not indexed (#1496)
Upgrade to netty 3.2.7 (#1506)
When _source is disabled, don’t return it in realtime get fetching the document from the transaction log (#1509)
Improve highlighting perf (a bit) by reusing some constructs across hits (#1513)
Allow to configure a shard with no file based data location locking (#1535)
source not returned when * specified in fields list (#1541)
Generate pid file even when running in foreground mode (#1553)
Improve multi field mapper with highlighting based on source (#1559)
Allow search to continue when sort field is missing from type mapping (#1558)
Filter cache to have just weighted (node) and none, and index query parser cache to be size based (#1590)
No master (startup / minimum_master_node) / not recovered blocks should cause proper failures on operations (#1589)
_open and _close does not resolve aliases (#1628)
Better failure when passing invalid options to a query/filter (#1640)
Allow for plugins to register REST filter (#1658)
AWS Plugin: Add more automatic region configuration (#1490)
Add a simplified setting to disable shutdown API: action.disable_shutdown (#1606)
Analysis:
- Add language setting to lowercase filter, supporting greek and turkish (#1503)
- Support greek language in the stemmer filter (#1504)
- Add arabic, brazilian, czech to stemmer token filter language options (#1519)
- Add phonetic encodder called bm or beider_morse (#1552)
Analyze API: Allow to execute it without pre-creating an index, and allow to build custom analyzer (tokenizer + token_filters) (#1555)
Boolean Type: Consider F as false as well when searching on it (#1556)
Date Histogram Facet: Add pre_offset and post_offset options (#1599)
Highlighter: Add require_field_match (both global and per field) option (#1577)
Highlighting: Add boundary_chars and boundary_max_size to control text boundaries with fast vector highlighter (term vector) (#1614)
Index Allocation: allow to specify maximum total number of shards per node (#1650)
Indices / Nodes stats: All all flag to easily return all stats (#1662)
JVM Flags: Remove SurvivorRatio and MaxTenuringThreshold since the defaults are good with new JVMs (#1672)
Jmx: Only register JMX beans when jmx.create_connector is set to true, or explicitly set by setting jmx.export to true (#1666)
Local Gateway: Move shard state to be stored under each shard, and not globally under _state (#1618)
Mapping:
- Improve applying guessed types on dynamic templates (#1446)
- _source mapping to allow for format to convert to (if needed) (#1639)
Merge Scheduler: Allow to set index.merge.scheduler.max_merge_count (#1430)
Multicast: Add discovery.zen.ping.multicast.ping.enabled setting to disable sending ping requests while still having multicast enabled (#1533)
Network: Allow to specify sub interfaces (virtual) in network configuration (#1667)
Node Stats:
- Add fs level stats (size + iostats) (#1622)
- JVM stats to provide memory pools allocations (#1665)
- Add more options to get specific stats in REST: /nodes/fs/stats (in addition to /nodes/stats/fs) (#1674)
Plugins: If a plugin has a bin directory, move it under the main bin location under the plugin name (#1584)
Query: Add index.query.default_field allowing to control the default field used to search on (#1657)
Query DSL:
- indices query to allow to set a no_match_query (#1492)
- Replace index.query.bool.max_clause_count with indices.query.bool.max_clause_count (old one still supported) (#1538)
- query_string analyze wildcard option with prefix to automatically do OR’ed wildcard when its broken down into several tokens (#1539)
- Allow to default certain settings in query_string / field queries (#1540)
- custom_filters_score allow score_mode for “min” and “multiply” (#1560)
- Add different execution models for terms filter (#1568)
- prefix query to support _id (#1648)
REST: / to properly return error code (HEAD and GET) when blocked (not recovered, no master), as well as cluster health (red == 503) (#1633)
River: When deleting a river, make sure when its closed that its data is deleted (#1534)
Scan Search: Improve performance while scrolling through it (#1579)
Thread Pool: Add a dedicated thread pool for refresh (#1624)
Translog: When not sync’ing on each operation, buffer writes (#1549)
Transport Client: Improve remote node freeze handling by adding another timeout layer (#1653)
bin: elasticsearch script to support ES_HEAP_SIZE to easily set the heap size to a single value (min and max) and ES_HEAP_NEWSIZE to optionally set the new gen (#1671)

Bug fixes:

External data location configuration fails (path.data setting) (#1429)
data.path locations are unevenly filled (0.18.2) (#1436)
Percolate / Analyzer API can hang if it fails to execute (#1457)
Using root object level mapping (_size, _source) can cause reparsing of the mapping on startup (#1458)
Nested facet execution can fail with ArrayIndexOutOfBounds (#1467)
Inner queries not resolved correctly in has_child filter when searching directly against the parent type (in the URI for example) (#1471)
Broken plugin script (#1474)
Thrift transport handling unexpected URI hangs (#1484)
IndicesQueryBuilder generates the wrong query name (#1485)
Multi field mapper with more than one extra mapping can cause endless re-sync’ing of mapping between nodes (#1487)
Using _parent:123 in a query string query fails to fetch docs (#1497)
Registering a percolate query with additional “object” level metadata can fail (#1505)
search missing from stats when using clear and search params (#1516)
Version missing a space (#1517)
Default mapping means new types not mapped explicitly (#1524)
timestamp term match broken in 0.18.5 (#1543)
0.18.5 ignores query string analyzer (#1547)
Cluster metadata files destroyed when using blob store gateway causing data loss (#1564)
Nested objects not deleted on “delete by query” (#1537)
Two different indexes with the same nested object name causing ArrayIndexOutOfBoundsException (#1575)
TTL does not respect routing when expiring (deleting) documents (#1586)
Multi Get does not respect routing set on aliases (#1591)
Bulk API does delete item does not respect routing associated with an alias (#1592)
/_status doc count of index wrong (#1615)
0.18.7 Failure exception while executing a valid query after an invalid query (#1617)
index.recovery.initial_shards is not being taken into account (#1623)
Removing a node with TRACE logging enabled causes cluster state not to be properly updated (#1626)
Published cluster state might override newer state (rarely) (#1632)
Terms Facet sorting does not handle null values properly with new JDK 7 sorting (#1647)
Cluster Allocation: cluster.routing.allocation.allow_rebalance does not allow for rebalancing on relocating shard (#1651)
Couchdb River: since changes parameter (seq) is not url encoded (#1470)
Index / Delete API: timeout should apply automatically to the auto create index API master timeout (#1664)
Indices Stats API: Providing groups as part of the HTTP API does not return stats for those groups (#1468)
Java API: ScriptSortBuilder does not pass the lang used (#1569)
Multicast Discovery: if it fails, still start in a single cluster mode (#1608)
Nested queries: getDocIdSet NullPointerException (#1536)
Query DSL:
- Bool filter does not take should clauses properly into account (#1511)
- query_string/field/text do not fail when an invalid analyzer is provided (#1663)
Search:
- Fetching fields that end up extracted from source might fail (#1431)
- Search requests execute by mistake on the networking http IO thread, causing other http operations to hang (#1455)
- When searching against a type with a dfs search type, dfs is ignored (#1546)

0.18.7 Released

2012-01-10T00:00:00-08:00

elasticsearch version 0.18.7 is out. You can download it here. It includes bug fixes including major bug fix in state storage with shared gateways (s3 for example), and support for nested documents in delete by query.

0.18.7

2012-01-10T00:00:00-08:00

Bug fixes:

Cluster metadata files destroyed when using blob store gateway causing data loss (#1564)
Nested objects not deleted on “delete by query” (#1537)
Two different indexes with the same nested object name causing ArrayIndexOutOfBoundsException (#1575)
TTL does not respect routing when expiring (deleting) documents (#1586)
Java API: ScriptSortBuilder does not pass the lang used (#1569)
S3 blob storage gateway: deleting an index named x destroys data for any index with name beginning with x (#1582)

0.18.6 Released

2011-12-19T00:00:00-08:00

elasticsearch version 0.18.6 is out. You can download it here. It includes minor features and important bug fixes. Changes can be found here.

0.18.6

2011-12-19T00:00:00-08:00

Enhancements:

Improve highlighting perf (a bit) by reusing some constructs across hits (#1513)
Analysis: Add arabic, brazilian, czech to stemmer token filter language options (#1519)
Query DSL:
- Replace index.query.bool.max_clause_count with indices.query.bool.max_clause_count (old one still supported) (#1538)
- query_string analyze wildcard option with prefix to automatically do OR’ed wildcard when its broken down into several tokens (#1539)
- Allow to default certain settings in query_string / field queries (#1540)

Bug fixes:

search missing from stats when using clear and search params (#1516)
Version missing a space (#1517)
timestamp term match broken in 0.18.5 (#1543)
0.18.5 ignores query string analyzer (#1547)
Nested queries: getDocIdSet NullPointerException (#1536)
Query DSL: Bool filter does not take should clauses properly into account (#1511)
Search: When searching against a type with a dfs search type, dfs is ignored (#1546)

0.18.5 Released

2011-11-29T00:00:00-08:00

elasticsearch version 0.18.5 is out. You can download it here. It includes an upgraded Lucene version (3.5), featuring bug fixes and memory improvements, as well as more bug fixes in elasticsearch itself. Changes can be found here.