Document upgrade and downgrade processes

[zamazan4ik]

Hi.

After reading the documentation it is not clear for me, how upgrade and downgrade processes should be performed over the solution. Could you please describe somewhere in the documentation:

• How to upgrade Vector to the newer version with no downtime
• How to downgrade Vector to the older version (hopefully with no downtime)
• Maybe some compatibility policies and notes between versions

Thanks in advance!

[tobz]

Hello @zamazan4ik!

In general, upgrading/downgrading Vector depends on the specific versions involved. Due to this, we explicitly document breaking changes in upgrade guides that explain what configuration settings must be changed. If there are changes that cannot be rolled back, they are also called out explicitly, so downgrading is typically no more difficult than simply undoing the changes made in order to upgrade. As well, that document also calls out our general compatibility policy in terms of version-to-version compatibility, and so on.

In terms of no-downtime upgrades, we do have some documentation around best practices when going to production, and running Vector in a high-availability mode (https://vector.dev/docs/setup/going-to-prod/), as doing so will let you upgrade individual Vector instances without dropping traffic elsewhere. Ultimately, however, there is no one reference architecture that will always provide the ability to achieve no-downtime upgrades as this depends on the sources and sinks being used, and whether or not they can be paused, or if traffic must be shifted to another instance, and the capabilities of the software you run in front of Vector for controlling traffic flows, and so on.

[zamazan4ik]

@tobz Thanks! These links are helpful.

However, my case a little bit different. I have a file server, on which Vector accepts logs from a source (a Vector instance too) and then stores these logs into the files. Since it is only 1 node setup and there is no way to add additional nodes (since a storage is located directly on this server and it is a local FS like BTRFS), I cannot add more Vector instances.

Is there a way to update Vector instance on the server with no downtime in this case? Maybe some configuration with running two Vector instances simulateneosly on machine behind LB or something like that. Maybe you know better approaches - that is why I am asking here :)

[tobz]

Sure, you could set up a load balancer pointed to multiple instances on the host, but you'd also have to incur downtime to initially switch over traffic to that load balancer, so... :).

If you're using the vector source/sink, the easiest thing would simply be to stop the aggregator (the one running the source) and upgrade it, which the sender (sink) will notice and retry the requests until the source is back up. You could test this two local Vector processes if you wanted to be sure it would work for your use case.

There's no scenario where you avoid "all downtime" in a technical sense, but if the goal is simply to avoid loss of events, then that is likely already possible given how Vector handles retries when downstream endpoints are temporarily unavailable.