Specific upgrade process

EventStoreDB
#1

All,

I know this will sound like an overly simple question, but I have not been able to find documentation on the specific upgrade steps for EventStore. I would imagine it is only a step or two, but can someone validate the specific steps they took to upgrade 3.4 > 3.5?

Once done, I may take what I learn here and in my own upgrade experience and add a quick section to the documentation repo. I believe there are others who could benefit from that documentation.

Thanks!

#2

For a single node? For a cluster? What do clients look like?

#3

I’m specifically looking for both single node and cluster upgrades. We are currently running on Windows (Server 2012 R2 Datacenter). I’d love to document the process on Linux boxes as well - we are contemplating a move in the direction eventually.

#4

For any minor upgrade (not major revision though many major revisions
support its in release nots)

Single Node. Shutdown node. Bring up with new software. Upgrade
clients as you see fit.
Cluster. Start with non master nodes. Shutdown bring up with new
software, let join cluster. Last do Master. Upgrade clients as you see
fit.

#5

Ok, and a related follow up on this:

I’ve seen the kill -9 conversation on the boards - cringe - is there another recommended/scripted shutdown process other than using the GUI Admin shutdown feature? Kill always makes me nervous. =) I’m thinking specifically when shutting down clustered nodes.

#6

Kill is a good thing.

This how we ourselves kill our dbs every day. Complex shutdown
procedures are scary, just ask yourself what if something bad happens
during normal running? :slight_smile:

#7

We use Ansible for managing installations (serial, e.g. one by one) of eventstore in ubuntu - When doing an upgrade (not caring that master should be last), apt-get makes sure that the eventstore service is being shutdown via upstart - seems to work out pretty nice so far.

Why do you need to do a kill when doing a planned upgrade?

#8

@ahjohannessen - we are running this in a Windows environment at the moment, but a Linux-based environment may be in the works down the road, so thanks for the Ansible tip! To answer your question, we likely woundn’t need to use Kill…just making sure I have my assumptions/bases covered.

Thanks for the feedback!

#9

@Greg - good to know and and excellent point! Thanks for the feedback!

#10

You can "shutdown" if you want there is a http post to /admin/shutdown
if you want to automate it. There is however no actual need for this