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.
