We have upgraded the central loghost from 32 to 64bit (RPM based). The universal forwarder was just copied from the old onto the new server and is still the 32bit version. We would like to upgrade the UFW to the 64bit version.
Installing a fresh version from scratch would result in resending the already sent files thus duplicating them on the indexer.
Do we just overwrite the 32bit install with a 64bit RPM and that's that?
Haven't really done that, but the docs don't say it shouldn't be done. See the second link especially.
You just want the same configuration,
1 - backup the $SPLUNK_HOME/etc/ folder
2 - remove the old
3 - install the new one (same version)
4 - copy back the etc folder to replace
5 - start splunk
Beware : but the fishbucket index that contains the list of the files already monitored will be reset and the forwarder may reindexed some files. To avoid that you can move the files you do not want out of the monitored folders (or rotate them if you blacklisted the rotated versions)
I was really hoping to to keep the fishbucket so the files would not get reindexed. If there's a way of saving it, I'd be very much interested in it.
Thanks to yannK for the advice on how to procced and kristian.kolb for the additional links to the docs.
First I had a go at it on a test version with only one logfile.
I followed yannK's advice, but I also left the $SPLUNKHOME/var folder in place along with $SPLUNKHOME/etc.
Here's what I did in the end:
1 - backup the $SPLUNKHOME/etc/ folder
2 - backup the $SPLUNKHOME/var/ folder
3 - remove the old 32bit installation
4 - install the new one (same version but 64bit)
5 - copy back the etc folder to replace
6 - copy back the var folder to replace
7 - start splunk
Then I used the same procedure on our production environment.
As far I can see, there are no problems or errors. And no duplicates on the indexer that I can find.
I would conclude that the databases from the 32bit version seem work on the 64bit version. The universal forwarder neatly reports that it started reading files at their respective offsets upon its startup.
Looks like to some extent, different releases don't have an issue with this procedure. I've done this while upgrading from 5.0.2 to 5.0.4 (32bit only) for .tgz based installation without any noticeable issue.