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.4.1] Drop Measurement for 1 DB drops all measurements of same name #4303

Closed
simcap opened this issue Oct 2, 2015 · 9 comments · Fixed by #5100
Closed

[0.9.4.1] Drop Measurement for 1 DB drops all measurements of same name #4303

simcap opened this issue Oct 2, 2015 · 9 comments · Fixed by #5100
Assignees
Milestone

Comments

@simcap
Copy link
Contributor

simcap commented Oct 2, 2015

Hi,

I have a measurement called p2p in my db viewers. It happens that I also have a testviewers db with also a measurement p2p.

I wanted to clean my testviewers db and drop the p2p measurement. I did the following steps:

> use testviewers
Using database testviewers
> drop measurement p2p
> select count(value) from p2p
> 

So it is empty. The issue is that it also cleaned the db viewers!! Beforehand this db viewers had a lot of data:

> select count(value) from p2p
name: p2p
---------
time      count
1970-01-01T00:00:00Z  1.042289e+06

Now it is empty:

> use viewers
> select count(value) from p2p
name: p2p
---------
time            count
1970-01-01T00:00:00Z    

or 

> select * from p2p
> 

Is there a from clause where we should specify the db from which to drop the measurement. Or it is that it just wipe a measurement across all dbs?

@simcap
Copy link
Contributor Author

simcap commented Oct 2, 2015

Actually the measurement p2p from the viewers db came back!! (a bit more data since we have live customers pushing data)

> select count(value) from p2p
name: p2p
---------
time      count
1970-01-01T00:00:00Z  1.042318e+06

I guess it might be a sync or display issue in the CLI.

@rkuchan
Copy link
Contributor

rkuchan commented Oct 2, 2015

@simcap, thank you for pointing this out. That is definitely unexpected behavior. Interestingly, I'm able to repro the first part with version 0.9.4.1:

> create database first
> use first
Using database first
> insert pumpkin orange=1
> insert pumpkin orange=2
> insert pumpkin orange=3
> create database second
> use second
Using database second
> insert pumpkin orange=11
> insert pumpkin orange=12
> insert pumpkin orange=13
> select * from first."default".pumpkin
name: pumpkin
-------------
time                orange
2015-10-02T19:18:22.026149413Z  1
2015-10-02T19:18:23.487714562Z  2
2015-10-02T19:18:24.668921664Z  3

> select * from second."default".pumpkin
name: pumpkin
-------------
time                orange
2015-10-02T19:18:42.130289879Z  11
2015-10-02T19:18:43.805793895Z  12
2015-10-02T19:18:45.448094234Z  13

> use second
Using database second
> drop measurement pumpkin
> select * from second."default".pumpkin
> select * from first."default".pumpkin
>

but I can't seem to repro the second part:

> use first
Using database first
> select * from pumpkin
> insert pumpkin orange=4
> select * from pumpkin
name: pumpkin
-------------
time                orange
2015-10-02T19:28:18.147674321Z  4

@beckettsean beckettsean changed the title Unexpected drop measurement accross all databases [0.9.4.1] Unexpected drop measurement accross all databases Oct 2, 2015
@otoolep otoolep changed the title [0.9.4.1] Unexpected drop measurement accross all databases [0.9.4.1] Drop Measurements of same name from database erases all Oct 3, 2015
@otoolep otoolep changed the title [0.9.4.1] Drop Measurements of same name from database erases all [0.9.4.1] Drop Measurement for 1 DB drops all measurements of same name Oct 3, 2015
@otoolep
Copy link
Contributor

otoolep commented Oct 3, 2015

This is bad.

If a measurement name is shard across two databases, drop them from 1 drops them from the other.

@otoolep otoolep self-assigned this Oct 3, 2015
@otoolep otoolep modified the milestones: 0.9.6, 0.9.5 Oct 3, 2015
otoolep added a commit that referenced this issue Oct 3, 2015
@otoolep
Copy link
Contributor

otoolep commented Oct 3, 2015

Thanks for the report @simcap -- we definitely need to fix this ASAP.

@otoolep
Copy link
Contributor

otoolep commented Oct 3, 2015

The bz1, and presumably b1, engines suffer from this. However the tsm1 engine does not!

@otoolep
Copy link
Contributor

otoolep commented Oct 3, 2015

This may actually be fixed by moving to the tsm1 engine when it is released.

@simcap
Copy link
Contributor Author

simcap commented Oct 7, 2015

@rkuchan The second part I added (see my second comment) was to say that when I logged out of the shell and logged back in the measurement came back (so the drop only wipe one db as expected). So I was thinking more of a display sync issue in the shell.

But as @otoolep points out some engines seems to suffer from this issue.

Anyway thanks for the promptness, and before doing a lot of work let's ensure it is not just a shell issue.

@markusr
Copy link

markusr commented Dec 4, 2015

Any updates on this?

@pauldix pauldix modified the milestones: 0.10.0, 0.9.5 Dec 8, 2015
@dgnorton
Copy link
Contributor

@markusr fix coming soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants