Summary:
Do not use InfluxDB, especially on IoT/RPI3 (32 bit). You will run into an (will stay) unfixable problem when data size gets big
Background/Story:
I have created a great Grafana/InfluxDB (seemed a match in heaven) solution to be deployed to client sites as monitoring for Sungrow SH5k inverters. Beautiful presentation, and all runs off a RaspberryPi3+. Low power and just “does its thing”.
Problem:
After a few months of data, seemed to have fallen down (InfluxDB in a crash loop of compacting). Finally after a lot of research, it seems like there are many others that had the same problem, going back to 2019 : https://github.com/influxdata/influxdb/issues/11339 – with a final solution being created by a user there, and proposed an upstream push to InfluxData’s official branch. Not only did InfluxData not come back positively (private conversation with the patch maker), it was eventually dropped silently in favour of InfluxDB 2.0.
Problem details:
It was tracked down to a mmap issue with 32bit InfluxDB instances. It would not show up in top/etc as it’s mmap’d in, but a large DB would just fail.
Official stance:
This is a big F-U to everyone that had used InfluxDB as a solution for IoT monitoring, which was its main draw card. So why should I look at InfluxDB if I can go to a mature “MySQL/MariaDB” solution for this? Also, what confidence would there be if they decided to not “rock the boat” with their corporate customers in expense of little guys like us?
Conclusion:
- Redesigning solution, and moving away from InfluxDB, not touching InfluxDB 2.0, despite being able to “fix” it with a more expensive RPI4 (64bit and MMap issue resolved).
- No longer running Grafana with InfluxDB with any recommendation (commercial and personal)
- Discouraging InfluxDB as a serious Timeseries DB
- Blog post rant – cos I spent a lot of time designing and implementing this system.. and have to clean up behind the deployments now! Poor form InfluxData! ;P
Final discussion link:
https://github.com/influxdata/influxdb/pull/12362