History_uint crashes when it reaches 4GB

[tekchimp]

I manage a Zabbix deployment that is running Zabbix 3.4.8 . Zabbix has crashed a few times over the last year when the History_uint table reaches 4GB. That said, in my research to find a solution, I have seen that many admins have history tables that are far larger using the mysql DB platform. I have plenty of room on the HDD partition. I end up having to use a clean up script every month just to keep it at an operational threshold.

Here are the server specs:

Linux OS: Ubuntu 16.04 LTS 32bit (maybe this?)
DB: mysql
Drive space available on / = 51GB
RAM: 6GB total with aprox. 3.5GB free
Swap: 4GB with all free
Kernel: 4.4.0-124-generic
VM guest on VMWare Esxi 5.5
Let me know if anything else is needed.

Thanks for any advice you can provide. Very frustrating.

[vso]

could you please be so kind and provide log of Zabbix server during the crash ?

[tekchimp]

I have taken measures to prevent the crash again and the logs do not exist anymore since the last crash. I am manually purging database items before the file can reach 4GB since this is much easier than rebuilding everything from scratch after the crash. Just thought there might be an easy answer like that I am using a 32bit platform or something like that. Thanks.

[vso]

I think that issue will be gone once you move to 64 bit.

[tekchimp]

You know... I am just going to build a new 64bit server and migrate the database. Seems like I am behind the times. Thanks for the advice.

[vso]

You could also consider using trends:

https://www.zabbix.com/documentation/3.4/manual/config/items/history_and_trends

[kloczek]

I have taken measures to prevent the crash again and the logs do not exist anymore since the last crash. I am manually purging database items before the file can reach 4GB

Which one file reaches 4GB?
Are you talking about using zabbix with sqlite db backend?

[tekchimp]

Well, as in the title of this thread, the History_uint file reaching 4GB causes Zabbix to stop working, that is, the mysql service using innodb stops running and won't start again. I have to jump through a lot of offline db hoops to try to recover. But that said, as I stated previously in this thread, I am just going to build a new server on a 64bit OS with a different partitioning scheme. This current build was poorly designed and won't meet my growth needs. I guess the point of this thread is then moot.

[kloczek]

Still it should be possible to use partitioned (daily for example) history* tables to avoid 4GB max file size (without going ASAP to 64bit arch).