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

different shardid for the same shard in 2 different cluster nodes #1006

Closed
xo4n opened this issue Oct 6, 2014 · 7 comments
Closed

different shardid for the same shard in 2 different cluster nodes #1006

xo4n opened this issue Oct 6, 2014 · 7 comments

Comments

@xo4n
Copy link

xo4n commented Oct 6, 2014

we are using influxdb 0.8.3 in a cluster set up (with just 2 nodes to test) and with default configuration and we ended up having 2 different shardids for the same shard, that results in empty results when querying the data from the node with the "wrong" shardid

below the log entries for the same query from the 2 different nodes

[2014/10/06 17:17:18 CEST] INFO Start Query: db: t_metrics, u: root, q: select * from springfield01.disk-sda3.disk_octets.write where time< now() -1d AND time> now() -2d limit 1
[2014/10/06 17:17:18 CEST] DEBG Querying shards sequentially
...
[2014/10/06 17:17:18 CEST] DEBG QUERYING: shard: 0 [ID: 338, START: 1412208000000000, END: 1412812800000000, LOCAL: true, SERVERS: []]
[2014/10/06 17:17:18 CEST] DEBG QUERY: shard 338, query 'select * from "springfield01.disk-sda3.disk_octets.write" limit 1'

[2014/10/06 17:18:36 CEST] INFO Start Query: db: t_metrics, u: root, q: select * from springfield01.disk-sda3.disk_octets.write where time< now() -1d AND time> now() -2d limit 1
[2014/10/06 17:18:36 CEST] DEBG Querying shards sequentially
...
[2014/10/06 17:18:36 CEST] DEBG QUERYING: shard: 0 [ID: 337, START: 1412208000000000, END: 1412812800000000, LOCAL: false, SERVERS: [1]]
[2014/10/06 17:18:36 CEST] DEBG QUERY: shard 337, query 'select * from "springfield01.disk-sda3.disk_octets.write" limit 1'
[2014/10/06 17:18:36 CEST] DEBG Querying server 1 for shard 337

@xo4n
Copy link
Author

xo4n commented Oct 7, 2014

some additional info from the logs at the time of the shard start, looks like we went into a "split brain" like situation. Not sure if it is worthy further analysis on this as clustering is being redesigned

2014/10/02 01:38:29 CEST] WARN Server marked as up. Heartbeat succeeded
[2014/10/02 01:59:15 CEST] INFO No matching shards for write at time 1412208002000000u, creating...
[2014/10/02 01:59:15 CEST] INFO createShards for space default: start: Thu Oct 2 02:00:00 +0200 CEST 2014. end: Thu Oct9 02:00:00 +0200 CEST 2014
[2014/10/02 01:59:15 CEST] INFO No matching shards for write at time 1412208002000000u, creating...
[2014/10/02 01:59:15 CEST] INFO createShards for space default: start: Thu Oct 2 02:00:00 +0200 CEST 2014. end: Thu Oct9 02:00:00 +0200 CEST 2014
[2014/10/02 01:59:15 CEST] INFO DATASTORE: opening or creating shard /appdata/influxdb/shared/data/db/shard_db_v2/00338
[2014/10/02 01:59:16 CEST] INFO Adding shard to default: 338 - start: Thu Oct 2 02:00:00 +0200 CEST 2014 (1412208000). end: Thu Oct 9 02:00:00 +0200 CEST 2014 (1412812800). isLocal: true. servers: [1]
[2014/10/02 03:12:46 CEST] WARN Server marked as down. Heartbeat error for server: 2 - springfield02.local:8099: Serverfailed to return heartbeat in 200ms: 2
[2014/10/02 03:12:48 CEST] [WARN] (github.com/influxdb/influxdb/cluster.(*ClusterServer).heartbeat:1

[2014/10/02 00:18:54 CEST] WARN Server marked as up. Heartbeat succeeded
[2014/10/02 00:47:13 CEST] WARN Server marked as down. Heartbeat error for server: 1 - springfield01.local:8099: Serverfailed to return heartbeat in 200ms: 1
[2014/10/02 00:47:15 CEST] WARN Server marked as up. Heartbeat succeeded
[2014/10/02 02:00:02 CEST] INFO Adding shard to default: 337 - start: Thu Oct 2 02:00:00 +0200 CEST 2014 (1412208000). end: Thu Oct 9 02:00:00 +0200 CEST 2014 (1412812800). isLocal: false. servers: [1]
[2014/10/02 02:31:49 CEST] WARN Server marked as down. Heartbeat error for server: 1 - springfield01.local:8099: Server failed to return heartbeat in 200ms: 1
[2014/10/02 02:31:51 CEST] WARN Server marked as up. Heartbeat succeeded
[2014/10/02 02:47:23 CEST] WARN Server marked as down. Heartbeat error for server: 1 - springfield01.local:8099: Server failed to return heartbeat in 200ms: 1

@jvshahid
Copy link
Contributor

jvshahid commented Oct 7, 2014

can you paste the list of shards that you have on the server. It should be under the cluster tab in the admin ui

@xo4n
Copy link
Author

xo4n commented Oct 8, 2014

Hi here it goes
Id 337 is the one causing trouble

from server1 in the cluster
Shards
Id Database Space Start Time End Time Servers
334 t_logs default 2014-09-25 02:00:00 2014-10-02 02:00:00 [1]
338 t_metrics default 2014-10-02 02:00:00 2014-10-09 02:00:00 [1]
3 t_logs default 2014-09-11 02:00:00 2014-09-18 02:00:00 [1]
241 t_metrics default 2014-09-18 02:00:00 2014-09-25 02:00:00 [2]
1 t_metrics default 2014-09-11 02:00:00 2014-09-18 02:00:00 [1]
348 fluentd_ps_error default 2014-10-02 02:00:00 2014-10-09 02:00:00 [1]
335 grafana default 2001-08-16 02:00:00 2001-09-15 02:00:00 [1]
2 t_logs default 2014-09-04 02:00:00 2014-09-11 02:00:00 [1]
242 t_logs default 2014-09-18 02:00:00 2014-09-25 02:00:00 [1]
333 t_metrics default 2014-09-25 02:00:00 2014-10-02 02:00:00 [1]

from server2 in the cluster
Shards
Id Database Space Start Time End Time Servers
334 grafana default 2001-08-16 02:00:00 2001-09-15 02:00:00 [1]
347 fluentd_ps_error default 2014-10-02 02:00:00 2014-10-09 02:00:00 [1]
241 t_metrics default 2014-09-18 02:00:00 2014-09-25 02:00:00 [2]
3 t_logs default 2014-09-11 02:00:00 2014-09-18 02:00:00 [1]
1 t_metrics default 2014-09-11 02:00:00 2014-09-18 02:00:00 [1]
337 t_metrics default 2014-10-02 02:00:00 2014-10-09 02:00:00 [1]
332 t_metrics default 2014-09-25 02:00:00 2014-10-02 02:00:00 [1]
242 t_logs default 2014-09-18 02:00:00 2014-09-25 02:00:00 [1]
333 t_logs default 2014-09-25 02:00:00 2014-10-02 02:00:00 [1]
2 t_logs default 2014-09-04 02:00:00 2014-09-11 02:00:00 [1]

@jvshahid
Copy link
Contributor

jvshahid commented Oct 8, 2014

Did you upgrade from an earlier version ?

@xo4n
Copy link
Author

xo4n commented Oct 8, 2014

not we dropped all data from previous version and installed from scratch 0.8.3

@jvshahid
Copy link
Contributor

jvshahid commented Oct 8, 2014

This is probably related to https://github.com/goraft/raft/blob/master/server.go#L1188, I opened an issue goraft/raft#238 to discuss a fix for this bug

@jvshahid jvshahid self-assigned this Oct 21, 2014
@toddboom
Copy link
Contributor

The clustering code is being completely rewritten for v0.9.0, so this will no longer be relevant. Closing it out.

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

3 participants