Zabbix update is too long

[FreeD]

Hello.

I think it's not normal:

| 11524 | root | localhost | zabbix | Query | 103068 | Sending data | INSERT INTO tmp_events_eventid (eventid,prev_value)

Database: ~65,900,996 rows, InnoDB , 6.1 GB

MySQL used 2.2 GB RAM ( innodb_buffer_pool_size = 2G ) and 100% of one core (one core as i understand because only one request is running).

table "events" ~1,895,409 rows and 290.6 MB

[jerry]

Same here.
Right now it's running for more than 6 hours (first tmp_events_eventid query).
We have more than 41 million rows in table events and it takes more than 2.5GB on disk size.

Does anybody know if I can skip these steps from upgrade procedure?

I think script is only trying to decide which events made changes and which not.
I do not know if this is used somewhere and if it creates problems afterwards or not.

Can somebody explain what should we do?

[FreeD]

I think something wrong in patch

| 17526 | root | localhost | zabbix_2 | Query | 452 | Sending data | INSERT INTO tmp_events_eventid (eventid,prev_value)

mysql> select count(*) from zabbix_2.tmp_events_eventid;
ERROR 1146 (42S02): Table 'zabbix_2.tmp_events_eventid' doesn't exist

[jerry]

That's OK, cause it's temporary table.
I am right now searching code, where is events.value_changed used. I am trying to decide if it will make problem importing historical data without this flag properly set.

[jerry]

From my point of view, these steps could be skipped. You just don't get additional info for old events - info which was not present until 2.0.0 (not counting dev channel (1.9.x) - how many changing events was there.

I am going to give it another 12 hours or so. If it won't make in that time, I will skip this part of migration.

I was searching code and I don't found anything which could create problems in the future. Hopefully I am right.