Yeah, Relay seems promising, but as you mention, it is not really there yet. I was wondering if anyone done some transactional replication so that we could at least do a master/slave type of a setup for failover. Seems like it would be pretty straight forward to implement, but I was wondering if this was already done, before reinventing the wheel :-/
I am not sure about the InfluxEnterprise product - looking at the site it seems like it is either the Cloud hosted solution, which is unfortunately not a good fit here, or a support contract, which I am not sure how helps in this case. Is there another option here? -M On Thursday, July 21, 2016 at 4:03:55 PM UTC-4, Sean Beckett wrote: > Influx Relay is intended to help our OSS users who don't want to use the full > clustering implementation, for whatever reason. It is not intended to be a > full HA solution out of the box, it merely makes HA a little easier by > providing data redundancy without duplicating writes from the clients. > > > If you need the full HA features, please contact [email protected] for a > quote on InfluxEnterprise. > > > On Thu, Jul 21, 2016 at 1:41 PM, <[email protected]> wrote: > Yes, I saw that, but I am not sure how this would work in real life. > > > > Theory is that if one server is inconsistent with another, I back up one and > load into the other - but this opens a number of questions. First, how do I > determine which one has more correct data? In a common split-brain failure of > a pair, it seems like there is a good chance that there will be some data on > each side not present on the other side - how do I merge both sides without > loosing one or the other? And then, If I backup from one server and load into > the other, if I do not shut the server down, there is data coming in during > the time between export and import, where does it go? Assuming the relay is > running and it is going to both, would import override it? Or if import > merges with existing data, what happens if there is data deleted, will it be > re-added? Documentation also points out that data deletion and schema > manipulation cannot work in any case, as it will always result in an > inconsistent data state. :-/ > > > > -M > > > > On Thursday, July 21, 2016 at 4:15:29 AM UTC-4, Konstantin Kulikov wrote: > > > You don't have to bring your databases offline, backup/restore can be done > > on online DB. > > > See relay readme for example > > https://github.com/influxdata/influxdb-relay/blob/master/README.md > > > > > > > > > > > > On Wed, Jul 20, 2016 at 7:58 PM <[email protected]> wrote: > > > With clustering being removed from influx, we are facing a problem with > > viability of continuing with InfluxDB. We are still running a cluster, but > > we want updates and some of the newer features not available in older > > releases. I am curious as to what are our options, since outsourcing it is > > not really an option in our environment. > > > > > > > > > > > > As I understand, the recommended tool is InfluxDB Relay, but that appears > > far from being production ready and is missing much of the functionality to > > make it true "HA". For one, it allows very easily to get data to get out of > > sync between two instances and as far as I see, does not offer any easy way > > to re-sync the instances without taking everything offline, backing both > > instances up and re-starting them from a matched set. > > > > > > > > > > > > I thought I saw some non-cluster replication settings in the documentation, > > but i am not finding it anymore, I am guessing this got removed with > > clustering. > > > > > > > > > > > > Are there any other options? Ideally I would love to see something like a > > transaction log that can be replayed on a replica - so that I can take a > > snapshot of the box and then restore it onto another instance and resume > > transaction log playback from the moment of the snapshot - but any other > > ideas or ways to have at least a hot-standby would be appreciated. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -M > > > > > > > > > > > > -- > > > > > > Remember to include the InfluxDB version number with all issue reports > > > > > > --- > > > > > > You received this message because you are subscribed to the Google Groups > > "InfluxDB" 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/83f962e6-33d6-43e5-8306-664b34fa9210%40googlegroups.com. > > > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > Remember to include the InfluxDB version number with all issue reports > > --- > > You received this message because you are subscribed to the Google Groups > "InfluxDB" 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/f903442e-0831-4266-bd8a-ab7543256109%40googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > Sean Beckett > Director of Support and Professional Services > InfluxDB -- Remember to include the InfluxDB version number with all issue reports --- You received this message because you are subscribed to the Google Groups "InfluxDB" 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/4a82cd7f-75da-478a-8220-40cfdee5ec5c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
