Hi Mark,
The pretty json version of the first 4 points is in the post below. 
I restarted the db (there was a similar bug in previous influx versions 
where a restart fixed 
it: https://github.com/influxdata/influxdb/issues/6946), but that didn't 
help.
I also upgraded to 1.2.0 which also didn't change anything.

However, I did notice that there are two shards that span the same time 
range:
298 default autogen 298 2014-01-06T00:00:00Z 2014-01-13T00:00:00Z 
2019-01-07T00:00:00Z 
390 default autogen 390 2013-10-28T00:00:00Z 2014-01-20T00:00:00Z 
2019-01-14T00:00:00Z

The default retention policy was changed a few days ago (before the data 
was written).  Could there be a bug involving altering the retention policy 
and having overlapping shards representing the same data?




Am Freitag, 10. Februar 2017 10:17:27 UTC+1 schrieb Davis Kirkendall:
>
> {
>     "results": [
>         {
>             "series": [
>                 {
>                     "name": "metricId_1_intervalId_5",
>                     "columns": [
>                         "time",
>                         "flags",
>                         "forecastOffset",
>                         "intervalId",
>                         "sensorId",
>                         "sign",
>                         "sourceId",
>                         "statId",
>                         "value"
>                     ],
>                     "values": [
>                         [
>                             1389574800000000000,
>                             0,
>                             null,
>                             "5",
>                             "132",
>                             "1",
>                             "315",
>                             "0",
>                             152800
>                         ],
>                         [
>                             1389574800000000000,
>                             null,
>                             null,
>                             "5",
>                             "132",
>                             "1",
>                             "315",
>                             "0",
>                             152800
>                         ],
>                         [
>                             1389575700000000000,
>                             0,
>                             null,
>                             "5",
>                             "132",
>                             "1",
>                             "315",
>                             "0",
>                             160000
>                         ],
>                         [
>                             1389575700000000000,
>                             null,
>                             null,
>                             "5",
>                             "132",
>                             "1",
>                             "315",
>                             "0",
>                             160000
>                         ]
>                     ]
>                 }
>             ]
>         }
>     ]
> }
>
>
>
> Am Donnerstag, 9. Februar 2017 22:23:02 UTC+1 schrieb Mark Rushakoff:
>>
>> The indentation is hard to follow in a variable width font. Can you post 
>> the JSON output? (i.e. from the influx CLI run `format json` and then your 
>> query `select * from "metricId_1_intervalId_5" where time >= 
>> '2014-01-13T01:00:00Z' and sourceId = '315' limit 10`. 
>>
>> It looks like maybe the forecastOffset tag is 0 in half of the points and 
>> absent in the other half, in which case I believe the system is behaving as 
>> expected. If it isn't that, are you able to try running with 1.2?
>>
>> On Thu, Feb 9, 2017 at 10:02 AM, Davis Kirkendall <[email protected]
>> > wrote:
>>
>>> I'm trying to track down some weird behavior in Influxdb 1.1 
>>>
>>>
>>> > select * from "metricId_1_intervalId_5" where time >= 
>>> '2014-01-13T01:00:00Z' and sourceId = '315' limit 10
>>>
>>> name: metricId_1_intervalId_5
>>> -----------------------------
>>> time                  flags   forecastOffset  intervalId      sensorId 
>>>        sign    sourceId        statId  value
>>> 1389574800000000000        0                       5               132 
>>>             1       315             0       152800
>>> 1389574800000000000                               5               132   
>>>           1       315             0       152800
>>> 1389575700000000000       0                       5               132   
>>>           1       315             0       160000
>>> 1389575700000000000                               5               132   
>>>           1       315             0       160000
>>> 1389576600000000000       0                       5               132   
>>>           1       315             0       183200
>>> 1389576600000000000                               5               132   
>>>           1       315             0       183200
>>> 1389577500000000000       0                       5               132   
>>>           1       315             0       111200
>>> 1389577500000000000                               5               132   
>>>           1       315             0       111200
>>> 1389578400000000000       0                       5               132   
>>>           1       315             0       158400
>>> 1389578400000000000                               5               132   
>>>           1       315             0       158400
>>>
>>> The interesting part is that "flags" and "values" are fields, meaning 
>>> that there should be no way for duplicate points such as [1,2], [3,4] and 
>>> so on to exist since timestamp and tag set are the same.
>>>
>>> > show field keys from metricId_1_intervalId_5
>>>
>>> name: metricId_1_intervalId_5
>>> -----------------------------
>>> fieldKey  fieldType
>>> value          float
>>> flags              float
>>>
>>>
>>> Am I missing something or has anyone experienced something comparable 
>>> before?  Could this be some sort of bug with the sharding process?
>>>
>>>
>>> -- 
>>> Remember to include the version number!
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "InfluxData" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at https://groups.google.com/group/influxdb.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/influxdb/85f0e693-33d9-4fca-af79-8c1723d732bb%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/influxdb/85f0e693-33d9-4fca-af79-8c1723d732bb%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
Remember to include the version number!
--- 
You received this message because you are subscribed to the Google Groups 
"InfluxData" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/influxdb.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/influxdb/2e723dc5-b175-462b-91f1-a80043098e12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to