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

0.9 Release Cluster Write Errors #2960

Closed
Jhors2 opened this issue Jun 12, 2015 · 5 comments
Closed

0.9 Release Cluster Write Errors #2960

Jhors2 opened this issue Jun 12, 2015 · 5 comments
Assignees

Comments

@Jhors2
Copy link

Jhors2 commented Jun 12, 2015

I am receiving the following message every time I attempt to write points into my DB:
[write] 2015/06/12 06:57:13 write failed for shard 3 on node 1: error code 1: write shard 3: field type conflict: input field "value" is type int64, already exists as type %!s(influxql.DataType=1)

[write] 2015/06/12 06:57:13 write failed for shard 3 on node 2: error code 1: write shard 3: field type conflict: input field "value" is type int64, already exists as type %!s(influxql.DataType=1)

The interesting thing is that all of my values are scraped before writing to make sure some decimal value has not returned. I also dropped my database entirely, created a new one then manually instantiated my measurements with int type to attempt to prevent float type from being set as follows:
curl "http://influx1.internal:8086/write?db=testdb" -d 'cpu value=10 1000000000001'

After performing the above, whenever a write is made to another node it is for some reason created with float type from what I can tell.

Any thoughts here?

@jwilder
Copy link
Contributor

jwilder commented Jun 12, 2015

@Jhors2 What do you see if you query the data? Does it return ints or floats?

@Jhors2
Copy link
Author

Jhors2 commented Jun 12, 2015

@jwilder The queries (I performed one across each measurement) always return ints.
Example:
./influx -database 'testdb' -execute 'select * from cpu limit 5;'

name: cpu
tags: server=web01,site=SFO
time value
2015-06-12T13:46:07.972194Z 1000516
2015-06-12T13:55:08.000088Z 1000516
2015-06-12T13:56:07.983637Z 1000516
2015-06-12T13:58:08.077041Z 1000516
2015-06-12T14:01:08.347279Z 1000516

@jwilder
Copy link
Contributor

jwilder commented Jun 12, 2015

Would you be able to post a sequence of steps to recreate this? E.g. create database, RP, your initial write and then some sample writes that fail. Not sure what's going on.

@Jhors2
Copy link
Author

Jhors2 commented Jun 12, 2015

Sure:
drop database testdb;
create database testdb;
CREATE RETENTION POLICY infrep ON testdb DURATION inf REPLICATION 3 default;
curl "http://influx1.internal:8086/write?db=testdb&precision=s&consistency=quorum" -d 'hose_as_output_bps,hose_id=12345:31150,as_type=peer_dst_as,as_num=39405,protocol=ipv4 value=6632243 1434123302'
curl "http://influx1.internal:8086/write?db=testdb&precision=s&consistency=quorum" -d 'hose_as_output_bps,hose_id=12345:31150,as_type=peer_dst_as,as_num=43100,protocol=ipv4 value=253405 1434123302'

I tested this by replaying legitimate data against the DB and I am getting a lot of failures like this with seemingly random "value" numbers.

I should also mention this was working in RC31 and prior.

jwilder added a commit that referenced this issue Jun 12, 2015
Fixes #2960

Integers were were written back to line protocol using strconv.FormatFloat
incorrectly.  Large integers are written in scientific notation which
causes their type to change to a float when parsed back.
@jwilder jwilder self-assigned this Jun 12, 2015
@jwilder
Copy link
Contributor

jwilder commented Jun 12, 2015

Thanks @Jhors2. I was able to reproduce the issue. Fix is in #2967

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

No branches or pull requests

2 participants