Distributed topology migrating to Zabbix 7 - looking for recommendations.
We're a high-rate, high value OLTP shop with three standalone Zabbix 6.0.x servers, one each in three semi air-gapped environments. Two of the three environments are active/semi-active* DR colo sites, so I'd like to take the opportunity to consolidate and get single pane of glass views of production. (The third Zabbix is the development and test environment, virtually identical to production, and where Zabbix will remain standalone.)
Monitored devices are via agent, snmp, and https api (vmWare and SANs.) We're not doing any SNMP trapping, but I'd like to for several devices and reasons.
I'd like the new topology to be an HA pair, one in each site and using cross-site replication to effect HA. Effectively, we'd have one server being both GUI and polling local devices, and cross-site replicating to the other... Is this a topology that is supportable? Inter-site link is redundant 10g.
Alternatively, an HA pair in the primary datacenter and a proxy in the secondary is very do-able for us, but we'd prefer distributed HA like all our other services.
Our 6.0.x installations are with integrated non-partitioned MySQL, and we ARE seeing history processing taking too much time and CPU already. For 7.0 I'd be going MySQL partitioned or Postgres timescale out of the gate.
Can 6.0.x non-partitioned data be migrated to 7 partitioned? I'll google MySQL behavior with partitioned destination tables and importing from non-partitioned mysqldump, but figured I'd ask here for any first hand experience. I assume schema changes from 6 to 7 so I may need to upgrade in place before migration? How will this effect partitioning?
Database services may be separate or combined with Zabbix services, I have plenty of hypervisor resources and storage capacity (enterprise SSD and spinners too.)
Lastly, I believe consolidating Zabbix instances is a lot to ask so I may just upgrade the primary in place and write off the history in the (semi-active* DR colo) secondary instance.
*"semi-active" - We have a few OLTP database servers that replicate in realtime to the secondary DR site, making that site "Active" - all other services (and there are MANY!) are passive when we're not failed over to the secondary site.