Rolling upgrade 2.4 to 2.5


I’m planning to upgrade my 5 graylog servers from 2.4 to 2.5. Am I able to use rolling upgrades? Any caveats other than remembering to upgrade sidecars from 0.1.6 to 0.1.7?

(Ben van Staveren) #2

I think it’s possible, not entirely sure of any pitfalls. Since all my sidecars were already at 0.1.7 I just did a rolling upgrade across 3 nodes and didn’t encounter any strangeness.

(Jan Doberstein) #3

you should do the sidecar upgrade FIRST - otherwise all sidecards will instand fail after the upgrade.

Rolling upgrade are not a supported upgrade method for Graylog in general - BUT it should work if you upgrade the master first. BUT remember - this can bite you …

To be 100% save I would give the system a “cold restart” just to be sure that no migration does break your system.

(Ben van Staveren) #4

@jan actually raised a good point, I did do a rolling upgrade but the master went first, then the 2 “client” nodes; also I use an Ansible role to do this stuff for me so there is a short time window where all 3 servers are basically restarting, so they never talked to eachother on different versions. Should’ve probably mentioned that >.>

(Ionstorm) #5

upgraded all sidecars and did a rolling upgrade successfully with no issues.

(Ofentse) #6

Why do you need to upgrade from 0.1.6 to 0.1.7 when moving from 2.4 to 2.5 line?

I am aware of the below rule for the sidecars. Never seen a rule for 2.5.x…

0.1.x -> 2.2.x,2.3.x,2.4.x

(Jan Doberstein) #7

Because of the added protecting against CSRF you see in the upgrade docs:


GL sidecar will have some main update in the GL 2.5 -> 3.0 update too?
We have 3 mounts to GL 3.0, We don’t want to update twice at client side.

(Jan Doberstein) #9

GL sidecar will have some main update in the GL 2.5 -> 3.0 update too?

Yes - the system is changing dramatically - but the 0.1.7 sidecars can be used with GL 3.0 to carefully shift from the old sidecar to the new sidecar.

(Ofentse) #10

Thank you, makes things clear. I wont forget this point.