#influxdb

but i've bound all possible instances to a private IP, not loopback interface. there is no separate meta-service bind-address setting, or is there?

(see no mention of this in the documentation)

olivier: I've seen something similar at some point in the past, I wonder if you have 127.0.0.1 in your peers.json?

@Ormod_; i've hardcoded the values to be the private IPs of both boxes (this is just a quick vagrant test on a couple of centos 7 boxes)

olivier, ah ok, no idea then.

the documentation mentions that on the second box i should configure a join in /etc/default/influxdb to the first node

it mentions a port

but not which one

so my assumption is it is the one on which the metaservice runs. which is set to the same private interface on port 8088

however, influxdb seems to ignore that setting completely and bind to loopback on port 8091?

or i might be on crack and seeing unicorns

and the one does not exclude the other

just upgraded to rc2 and now it seems to work magically?

olivier, you're not the firs one I see here complaining about clustering issues with 0.10rc1.

I assume that 0.10rc1 contains some early work for "updated clustering implementation" as announced for rc2 in https://influxdata.com/blog/influxdb-v0-10-beta...

that may have broken clustering.

thanks RV06, i figured it would be something along those lines, as i'm quite easily able to set-up a cluster pre 0.10rc[1-2]

just a good lesson for me to actually properly read the changelogs ;)

(IMO it was already quite unreliable on previous releases, but I expect it to improve with final 0.10)

setting up a cluster was OK, but keeping it alive on the long term was harder.

we've only ran single instances in the past; we're sort of hoping that clustering will deliver on its promise to allow for proper horizontal scalability

instead of non-scalable rrd / whisper graphite clusters, eek.

RV06 what exactly did you find tough in maintaining the cluster? I've also been on single instances here, but would look to scale out...

@ghounds; at this moment i'm not sure whether clustering is even functional in this new release..

been tinkering for hours / days to try and get it to work. 0.9.6 seems to work, sort of.

0.10 = NACK

ghounds, I run 3-nodes clusters, replica 2 with influxdb 0.9.5. It seems they regularly desynchronize, and we can see this on the contents of data dirs.

olivier + RV06: damn. ok. very good to know.

olivier: what's the problem you're seeing in the current release? We've been doing testing on it and it works. There are still a few key features ready so we're not calling it full release

_sometimes I have to wipe all data and restart with a clean cluster as I don't manage to make them see each other anymore. But I agree the problem may be my knowledge in Influxdb clustering, and I could manage some magic copying data across the nodes.

i'm having issues getting it up and running @pauldix

and followed the docs 20 times :D

anyway, if I remember correctly clustering was advertised as «not for production» on influxdb 0.9.x

olivier: we haven't updated the docs for the new release (I don't think). Going to try to get to that today

RV06: that's right

even after having reiterated over this 20 times, i am not excluding PEBCAK btw ;)

pauldix, is it going to change with 0.10?

olivier: most likely thing is that you need to set the three different bind-address values with <hostname>:<port>

in the config files

i am currently setting <private_ip>:<bind_port> for every subsection in the config

RV06: 0.10.0 clustering is still marked as pre-production, but it's getting closer. We have a few more features we're working on that will guarantee eventual consistency and make failure recovery easier. It's something where you could fix up manually, but would take effort

olivier: hmmm, that should be right. this is with RC2?

yep, and attempting the join with the INFLUXD_OPTS param in /etc/default/influxdb

We're going to write up docs for the different things in 0.10.0 today, should get that all out by tomorrow. My guess is there's some config option that is off

olivier: you're not using -join=?

but as the port in the docs for that parameter is not specified, i was assuming it was 8088

good to know pauldix :) The problem with manual fixing is we never know if it's going to work, if the procedure is reproducible, etc… and when you want your servers up quickly and your history data is not that important, you just wipe it all and restart clean.

pauldix: yes i am. setting it as follows: INFLUXD_OPTS="-join 172.28.128.9:8088"

olivier: you seeing any errors in the logs?

yep. the dreaded tcp.mux handler 71 error

for the bind-address settings you have set, which ones do you have set?

which would seem like i am trying to join on the wrong port?

olivier: the join port should be the meta.httpd bind address/pport

but as far as i know 8088 is the meta-service port

not the meta.bind-addresss

i tried other ports

ah.

previously you would join with the meta bind address. Now it's the meta.httpd-bind-address

is meta.httpd going to be a new subsection in the config?

olivier: yeah. Arg, I thought it was already in the sample, but I'm not seeing it there

no worries; that's what you have us for :D

olivier: this one under meta: http-bind-address

default on that is port 8091

ah. perfect. that explains me seeing it bind to localhost on port 8091, but not understanding where this was supposed to be set.

so confirms my suspicion that the meta http service is now separate

[meta] 2016/02/02 08:34:48 Starting meta service

[meta] 2016/02/02 08:34:48 Listening on HTTP: 127.0.0.1:8091

;)

hmmm doesn't matter what i do in the config, it is refusing to bind to anything but the loopback interface @pauldix

http-bind-address= ":8091"

httpd-bind-address= ":8091"

(tried both of these as i am not sure with your wording which of the ones to use)

tcp 0 0 127.0.0.1:8091 0.0.0.0:* LISTEN 998 293374 28836/influxd

also explicitly prepending the priv IP does not make a difference, so i am probably still using the wrong config option

i'll dive into the source

does anyone know a way of deleting all measurements in a database? (I want to restart from scratch)

can't you just drop the database and recreate it?

would probably be quicker than dropping all measurements; which sounds like an expensive operation :)

right. i did not notice my absence of a space before the equal sign typo