Upgrading Zabbix from 4.4 to 6.0 LTS

[Diggy]

Where can I find information on upgrading Zabbix (server, frontend, and agents) from version 4.4 to 6.0 LTS ??? Is it as easy as upgrading the binary packages in most cases? Do I have to manually run a database upgrade script?

Also, is 6.0 server backwards compatible with 4.4 agents? I.E. can I upgrade the server first and then upgrade agents as opportunity permits?

Any help/guidance is much appreciated.

---

[tim.mooney]

Yes you can upgrade the server and then later (at your convenience) upgrade agents. 4.4 agents should work just fine with a 6.0 server.

No, you do not need to manually run a database upgrade script, although 6.x introduced indexes in a couple of tables and for that upgrade (only) you probably want to manually run the SQL to add those indexes after the main upgrade is complete. One of the very first thing the 'zabbix-server' service does when it starts up is check the database to see if it's for the right MAJOR.MINOR version of the product, and if not the 'zabbix-server' attempts to update the schema to be correct for the new version you're running. That's true of every upgrade to a new X.Y version. The manual process to add indexes is unique to the 6.0.x upgrade. The index creation isn't part of the main upgrade because it can potentially take a *lot* of time, depending on the size of your install.

The database upgrade process that 'zabbix-server' does is one of the most common areas where people run into problems, though. If your schema has been upgraded many times in the past, it may have accumulated small differences from a pristine Zabbix schema that can cause problems with the upgrade. In addition, there are some important known issues if your database is MySQL/MariaDB/Percona. Zabbix 6.x has updated database requirements, so there's a chance you may also have to upgrade your database software before doing the Zabbix update.

In general, you want to carefully read https://www.zabbix.com/documentation...lation/upgrade and the "known issues" section and make sure you understand everything there.

[cyber]

And everything becomes a bit more complicated, if your 4.4 is on a platform, that is not supported by 6.0 any more.. So you need to start with platform upgrade at first...
I just finished that path.. TLDR; version.... Set up parallel environment. Installed old version db schema in new DB... added those double precision patches and primary keys already here... copied all data over (psql -tc "COPY (SELECT * FROM ${table}) TO STDOUT DELIMITER ',' CSV" zabbix | psql postgresql://other db/zabbix -c "COPY ${table} FROM STDIN CSV;")... ran new server, waited until it did needed upgrades in DB, done...
Longer version involves countless data fixings as history and trends in 4.4 do not have primary keys, so duplicate entries may exists, which breaks above copying instantly (because I added keys to that "new" 4.4 DB to avoid that copy to temp tables and back procedure later) ... And don't forget to copy tables in correct order or you may break something as some ID-s do not yet exists in some tables etc etc...:P

[Diggy]

Thanks for all the info. I was able to successfully upgrade our Zabbix server from our original 4.4 install to 6.0 LTS.

Tim,
How can I add those missing indexes you mentioned and anything else so that my current database schema is completely in-sync with intended 6.0 LTS schema? We are using MySQL on OL8.

I was thinking about dumping the database, then creating a new database following the instructions on the Zabbix website
(https://www.zabbix.com/download?zabb...ysql&ws=apache)
then reloading the data. Thoughts?

Regards.

[Diggy]

Okay. I have done some reading and this is how I understand the remaining tasks:

1. Upgrade the 'double' datatype on applicable tables to satisfy the "Database history tables upgraded" displayed in the GUI. The only information I found on this is for upgrading to 5.0 from 4.4 and the script only updates one table, 'trends'. Is that the only table update needed before I edit 'zabbix.conf.php' and set '$DB['DOUBLE_IEEE754'] = true' per the instructions? ref: https://www.zabbix.com/documentation...rade_notes_500

2. Repair character set and collation. ref: https://www.zabbix.com/documentation...b_charset_coll

3. Database upgrade to primary keys. ref: https://www.zabbix.com/documentation...b_primary_keys


Did I miss anything? In advance, thank you for any help offered.

[tim.mooney]

Okay. I have done some reading and this is how I understand the remaining tasks:

1. Upgrade the 'double' datatype on applicable tables to satisfy the "Database history tables upgraded" displayed in the GUI. The only information I found on this is for upgrading to 5.0 from 4.4 and the script only updates one table, 'trends'. Is that the only table update needed before I edit 'zabbix.conf.php' and set '$DB['DOUBLE_IEEE754'] = true' per the instructions? ref: https://www.zabbix.com/documentation...rade_notes_500

The SQL I see referenced from that document alters 2 tables, trends and history. https://git.zabbix.com/projects/ZBX/...sql/double.sql

Because it's changing the schema for what are probably two of your larger tables, it may take a while to run.

2. Repair character set and collation. ref: https://www.zabbix.com/documentation...b_charset_coll

Yes, but that step is only needed if your database or any existing tables are using the wrong character set or collation. It's entirely possible that this step wouldn't apply to you, but you'll have to check your database and tables to see. In particular, since you've successfully upgraded to 6.0, I would think you would be seeing warnings or complaints from the front-end if you had a lot of tables that were wrong.

3. Database upgrade to primary keys. ref: https://www.zabbix.com/documentation...b_primary_keys

I hadn't seen that particular page before and I don't have time right now to look over it carefully, but that document is related to the "add indexes after the upgrade" step I mentioned in my original response.

Overall, I think you're in really good shape. The "double" change will take a while but it's the least scary. The charset/collation may not apply to you, so only proceed with that after verifying at least some of your tables need it. The primary keys process may take a long time, depending upon the size of your history-related tables, so some of the possible approaches that the Zabbix folks are documenting are for sites want to do something like an "export history, recreate table, add primary key, re-import history" process, to speed it up.

Regarding your other question, about dumping the database, creating a new fresh one, and then importing the data: there's nothing wrong with that and it's a way to be certain you have a pristine schema for your exact version. I probably wouldn't go that far unless you had determined a lot of stuff needed fixing. What you could do is create a new database under a different name and then use the "mysqldiff" tool to compare the schema for your existing DB vs the empty but pristine one. That will give you a very good idea about where your database may still not match the expected schema.

I'm sure you have thought of this, but if you do decide to backup your data and import it into a freshly created schema, make sure you use the '--skip-add-drop-table' as part of the mysqldump. Otherwise, loading your backup will replace your pristine schema with the (possibly incorrect) one from your backup.

[cyber]

So.. if you added parallel up-to-date platform with old version of DB schema, then you can apply all those patches, if needed to empty DB, will take no time whatsoever... but now you you need to import data, which may break, if you have duplicate data in those trends and history tables (which is possible, due to lack of primary keys in older versions). So you may need to tweak your import a bit... I think mysql has something like "if error, then ignore it and continue"?? "insert ignore..." or something.. That should resolve your cases with duplicates... I am on PG, so my advice about mysql should be taken not too seriously...:P

Or if your sql-fu is good enough, you can try to search for duplicate data before exporting and remove it .... Mine wasn't...