search

influxdata / influxdb

Scalable datastore for metrics, events, and real-time analytics
https://influxdata.com
Apache License 2.0
28.96k stars 3.56k forks source link

New Tag values not showing in "SHOW TAG VALUES" #9953

Open Pangaj opened 6 years ago

Pangaj commented 6 years ago

I have influxDB machine of 8GB, which consumes of 4 to 5 GB for influxdb of version 1.4.2. I have existing db, measurement, and I have added new tag values for an existing tag keys.

But, after adding the records, SHOW TAG VALUES from measurement with KEY=tagkey, now showing all the tag values, It only shows the older tag values.

LasseTS commented 6 years ago

This is happening to me too! I am using influxdb version 1.5. If I show series I can see the series containing the tag values. If I show tag values the new tags are not present. This is a major problem as I query the database using Group As and the new series are omitted from the data returned. I am using disk based index.

Thanks, Lasse

dswarbrick commented 6 years ago

I have also been seeing this for a while, with InfluxDB 1.5.2.

brycebangerter commented 6 years ago

I've also just hit this issue on 1.5.3

lansalot commented 6 years ago

Me-3, but I was not able to see any values in 1.6.1. Downgrading to 1.5.3-2 worked fine.

Documented it here: https://community.influxdata.com/t/show-tag-values-is-empty-and-a-query-on-schema-design/6361

Strangely, however, a 1.6.1 installation on wintel worked fine. Query it from my (bad) 1.6.1 intallation on linux worked fine. Exact same test data. Querying from wintel -> linux, empty values again.

TheOneValen commented 6 years ago

Same problem on linux. Does not work on 1.6.1. Works on 1.5.2-1 (debian)

Does the downgrade have any side effects?

TinyZzh commented 5 years ago

This is happening to me too! do anyone hava some suggestions?

lishunan246 commented 5 years ago

me toooo version 1.6.0 on Debian

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

lishunan246 commented 5 years ago

Is there any news?

bolausson commented 5 years ago

Same issue here... I can't list the tag values

Any workarounds?

> show tag keys from SensorPush
name: SensorPush
tagKey
------
sensor_id
sensor_name
> show series
SensorPush,sensor_id=147.3530813,sensor_name=Raum1\ Fenster\ S6
SensorPush,sensor_id=3.43595591,sensor_name=Raum2\ Fenster\ S7
SensorPush,sensor_id=1.312398428,sensor_name=Raum3\ Fenster\ S8
SensorPush,sensor_id=33.3264015,sensor_name=Raum4\ S1
> show series from SensorPush where "sensor_name" = 'Raum4 S1'
key
---
SensorPush,sensor_id=33.3264015,sensor_name=Raum4\ S1
> select * from SensorPush limit 2
name: SensorPush
time                humidity sensor_id              sensor_name temperature
----                -------- ---------              ----------- -----------
1537979455000000000 58.94    147.3530813 Raum1 Fenster S6   18.5
1537979515000000000 52.99    147.3530813 Raum1 Fenster S6   19.36
> show tag values from SensorPush with key = "sensor_name"
>
> pi@openhab $ influx -version
> InfluxDB shell version: 1.6.4
pi@openhab $ influxd version
InfluxDB v1.6.4 (git: unknown unknown)
iwittkau commented 5 years ago

I am running into this on multiple deployments:

I have multiple DBs: data is logged permanently into db A and some specific values are selected into B on demand. A and B have different retention policies.

The query

show tag values with key = "tagkey"

returns an empty result on B and shows the correct result on A. I suspect that this is why the query part GROUP BY "tagkey" does not work on my db B (#9281).

iwittkau commented 5 years ago

The solution to my problem was related to this FAQ entry, I did use GROUP BY * to preserve tags but the database had old data in it which somehow blocked writing the correct tags for new entries.

I ended up deleting the shards of my db B and ran the select statements with GROUP BY * again which correctly preserved the tags and now made the usable in other queries.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

lishunan246 commented 4 years ago

Any updates? 李书楠

stale[bot] notifications@github.com 于2019年11月25日周一 下午4:53写道：

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/influxdata/influxdb/issues/9953?email_source=notifications&email_token=AA6YW2LHK2SD2YQRAT5T2YLQVOHCFA5CNFSM4FEBG3KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFBTXFA#issuecomment-558054292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6YW2MFFCBOHXOYBMO7ZFTQVOHCFANCNFSM4FEBG3KA .

lansalot commented 4 years ago

For such a serious issue, strange it's getting no developer interest...

TheOneValen commented 4 years ago

There seems to be problem with reproduceability.

I rewrote most of my measurements because of a "schema" change and I am not bitten by this anymore. I think this issue appears somewhere in between updating versions.

iwittkau commented 4 years ago

Same here, I did not encounter this issue in the last months since I wrote my comment above.

TheOneValen commented 4 years ago

So maybe try to rewrite your data as a workaround. If you want to use the same schema anyway, you can use SELECT INTO. And then try your query on the new measurement. If its OK DROP the old and SELECT INTO again to use the rewritten data.

Just hope there is no underlying issue that will bite us again in the future.

xanth commented 4 years ago

Had this same issue in 1.6.4 installed from http://raspbian.raspberrypi.org/raspbian buster/main armhf (armv6) resolved it by upgrading to 1.8.0, this does not feel production ready.

schmidmuc commented 4 years ago

I see the same issue with version 1.6.4 on an Ubuntu 20.04 LTS system.

ckristi commented 4 years ago

I see the same issue with version 1.6.4 on an Ubuntu 20.04 LTS system.

Same here, and it seems the influxdb package is not provided in the Influx repository for 'focal' by default. Only telegraf, kapacitor and chronograf are.

> SHOW TAG VALUES FROM system WITH key = host
> SHOW TAG KEYS FROM system
name: system
tagKey
------
host
tarlen commented 4 years ago

I'm also seeing this issue on Ubuntu 20.04 with v1.6.4 - looks like exactly the same query as @ckristi :)

Fresh install of InfluxDB, so it's not related to an upgrade.

koenwoortman commented 4 years ago

Having the same issue as @ckristi on Ubuntu 20.04 with InfluxDB v1.6.4

MaurUppi commented 4 years ago

Having the same issue as @ckristi @koenwoortman on Ubuntu 20.04 with InfluxDB v1.6.4

xxxx@ubuntu2004:~$ influx -version
InfluxDB shell version: 1.6.4
> select * from system limit 3
name: system
time                host                load1         load15        load5         n_cpus n_users uptim                           e     uptime_format
----                ----                -----         ------        -----         ------ ------- -----                           -     -------------
1597066700000000000 abc.localdomain 0.134765625   0.197265625   0.17822265625 2      1       15970                           66700 18484 days, 13:38
1
> SHOW TAG KEYS FROM "system"
name: system
tagKey
------
host
> show tag values from "system" with key ="host"
>
>

upgraded to 1.8.1 and fixed issues.

> show tag values from "system" with key ="host"
name: system
key  value
---  -----
host abc.localdomain
xmatthias commented 3 years ago

@OUZYcn i don't think it's the upgrade which fixes this, but a simple restart of the influx daemon.

While i'm running 1.7.9 - the fix for me is simply restarting influxdb, after that the new keys appear.

anthonybr07 commented 3 years ago

@xmatthias, I confirm the restart of the daemon resolved our issue.

We had the same issue with influxb v1.8.3. Some tags values weren't indexed... So we just restarted the influxdb daemon and now the tags values are displayed properly .

Thank you all for the help.

bogski87 commented 3 years ago

This is still an issue in Influx 1.5.x and 1.8.x

The fact that I can't run a select query instead of show tags is annoying. Selecting a field and the tag shows them all. Really annoying when it comes deadman and selecting hosts we want to apply alerts to.

Our current work around is a cron task to restart influx every sunday. it isn't permanent though and we still encounter this.

I'll assume the "official response" is "upgrade to influx 2.0!!".

hackery commented 2 years ago

I've also seen this a few times recently - with the additional twist that the admin user can see the new values, but any non-admin user cannot:

Connected to http://localhost:8086 version 1.7.9
InfluxDB shell version: 1.7.9
> use telegraf
Using database telegraf
-- "admin" user
> SHOW TAG VALUES FROM vsphere_cluster_cpu WITH KEY="site"
name: vsphere_cluster_cpu
key  value
---  -----
site xx91
site xxx42
site xx36
site xx96
site xx39
site xx38
site xx89
-- "grafana" user
> SHOW TAG VALUES FROM vsphere_cluster_cpu WITH KEY="site"
name: vsphere_cluster_cpu
key  value
---  -----
site xx91
site xx36
site xx96
site xx39
site xx38
site xx89

I repeated this test by creating a new user, running SHOW TAG VALUES (xxx42 is omitted), then giving it admin rights and repeating (xxx42 is included).

Running a select ... from vsphere_cluster_cpu where site = 'xxx42' order by time asc limit 1 confirms that the xxx42 tag value is recent (about 6 days ago). Shard duration is 24 hours, and other series for this measurement in the last few days are visible to the grafana user.

yjf20127 commented 1 year ago

I encountered similar problem！

I add a new tag named "solutionId", but i can't get it by "show tag keys". however, i can get it by "show tag values from CodeBias with key = "solutionId""

show tag keys from CodeBias; name: CodeBias tagKey

constellation sat_id signal_code show tag values from CodeBias with key = "solutionId"; name: CodeBias key value

solutionId 0