Skip to content
This repository has been archived by the owner on Oct 11, 2023. It is now read-only.

Latest commit

 

History

History
25 lines (23 loc) · 1.47 KB

caveats.md

File metadata and controls

25 lines (23 loc) · 1.47 KB

caveats

While influxdb-relay does provide some level of high availability, there are a few scenarios that need to be accounted for:

  • Continuous queries will still only write their results locally. If a server goes down, the continuous query will have to be backfilled after the data has been recovered for that instance.
  • Overwriting points is potentially unpredictable. For example, given servers A and B, if B is down, and point X is written (we'll call the value X1) just before B comes back online, that write is queued behind every other write that occurred while B was offline. Once B is back online, the first buffered write succeeds, and all new writes are now allowed to pass-through. At this point (before X1 is written to B), X is written again (with value X2 this time) to both A and B. When the relay reaches the end of B's buffered writes, it will write X (with value X1) to B... At this point A now has X2, but B has X1.
    • It is probably best to avoid re-writing points (if possible). Otherwise, please be aware that overwriting the same field for a given point can lead to data differences.
    • This could potentially be mitigated by waiting for the buffer to flush before opening writes back up to being passed-through.
  • When a request is buffered, the client recieves a 202 HTTP response indicating that his request will be fullfilled later. So the client will never reveive the response of the actual request.