Uploaded image for project: 'ZABBIX BUGS AND ISSUES'
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-25057

upgrade notes 7.0.0 ambiguities

XMLWordPrintable

    • Icon: Documentation task Documentation task
    • Resolution: Fixed
    • Icon: Trivial Trivial
    • 7.0.5rc1, 7.2.0alpha1
    • 7.0.2
    • None
    • RHEL 8.10, PostgreSQL 16, TimescaleDB 2.14.2
    • S24-W34/35, S24-W36/37, S24-W40/41
    • 1

      Steps to reproduce:

      1. 11 Upgrade notes for 7.0.0 (zabbix.com)
      2. 3 Database upgrade to primary keys and double precision data types (zabbix.com)
      3. 11 Upgrade notes for 7.0.0 (zabbix.com)
      4. 11 Upgrade notes for 7.0.0 (zabbix.com)

      Result:

      If history_upgrade_prepare.sql shall be executed also on zabbix_proxy, the warning can be confusing. Not clear, what does "not used" mean - not used at the moment (zabbix_proxy stopped) or not used at all?

      One sentence says DB patches are necessary, others that optional. Other sentence says "Upgrade to primary keys and double precision data types should be done after upgrading Zabbix server to 6.0." but the former that prior 7.0.0, so it would mean direct upgrade from 5.0 to 7.0 is not allowed, if there shall be that "optional" DB patches after Zabbix 6.0 and before 7.0.0. (Context: we upgraded test instance from 5.0.42 to 7.0.2 and now we are going to apply those DB patches, and based on that documentation I'm uncertain, if is it correct.)

      "Note that with TimescaleDB, compression support must only be turned on after applying this patch." - not clear, what does it mean, when upgrading Zabbix with already enabled TimescaleDB compression, if it should be turned off before applying the patch, and then turned on again, or how to understand that.

      Expected:
      Context for that warning could be specified more exactly, e.g. "Run scripts from timescaledb/ directory for the server database only.", leaving space for history_upgrade_prepare.sql, which is not under timescaledb/, to be executed on zabbix_proxy database (if I understand correctly, that it is allowed).

      Upgrade notes could be more consistent, documented sequence of upgrades and applying DB patches more exact, unambiguous.

            adancis Arturs Dancis
            rico Richard Ostrochovský
            Team A
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - Not Specified
                Not Specified
                Logged:
                Time Spent - 16.5h
                16.5h