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

Handle distributed queries when shards != data nodes #2327

Closed
wants to merge 2 commits into from
Closed

Conversation

jwilder
Copy link
Contributor

@jwilder jwilder commented Apr 17, 2015

Fixes #2272

There was previously an explict panic put in the query engine to prevent
queries where the number of shards was not equal to the number of data nodes
in the cluster. This was waiting for the distributed queries branch to land
but was not removed when that landed.

There may be a more efficient way to do fix this but this fix simply queries
all the shards and merges their outputs. Previously, the code assumed that
only one shard would be hit. Querying multiple shards ended up producing
duplicate values during the map phase so the map output needed to be merged
as opposed to appended to avoid the dups.

Fixes #2272

There was previously a explict panic put in the query engine to prevent
queries where the number of shards was not equal to the number of data nodes
in the cluster.  This was waiting for the distributed queries branch to land
but was not removed when that landed.

There may be a more efficient way to do fix this but this fix simply queries
all the shards and merges their outputs.  Previously, the code assumed that
only one shard would be hit.  Querying multiple shards ended up producing
duplicate values during the map phase so the map output needed to be merged
as opposed to appended to avoid the dups.
@@ -204,6 +204,50 @@ func (m *MapReduceJob) Execute(out chan *Row, filterEmptyResults bool) {
out <- row
}

// mergeOutputs merges two sorted slices of rawQueryMapOutput such that duplicate
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't follow -- how can we end up with duplicate timestamps? Data should only be de-duped if the series and timestamp is the same. But for a given series we should only be hitting 1 shard. I don't see how dupes can arise.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's happens from removing the hard coding of sg.shards[0]here: https://github.com/influxdb/influxdb/blob/master/tx.go#L147

It's now looping over each shard.

@jwilder jwilder closed this Apr 18, 2015
@jwilder jwilder deleted the 2272 branch April 21, 2015 21:20
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.

clustering: influxdb 0.9.0-rc23 panics when doing a GET with merge_metrics in a 3 node cluster
2 participants