It seems that my Node Red flows which are all writing to an InFlux DB and accessed by grafana have filled up my SD card. Is there a way I could use a USB 2TB hard drive as the storage for the Influx DB?
Cheers
you sure can!
mount it up as /tmp copy the whole /var directory over and then delete the /var and then mount the hdd as /var and off you go!
1 Like
Cheers Will give that a go. Thank you
@swanside: Do you run influxdb with docker? Without special care, logs will in time consume all available space on your disc. Data volume remains rather stable.
1 Like
Do yourself 2 favours here:
-
Get a larger SD-Card before it fails.
You really want an over-sized, good name-brand card so that it can do wear levelling. Anything less is asking for a failed card.
-
Look at your use of InfluxDB and decide whether you are keeping too much data.
InfluxDB has a built-in mechanism for trimming its tables and a second mechanism for creating secondary tables with aggregated data.
If you don't do this, you are likely to hit performance issues anyway because your indexes will be too big for the Pi to handle easily.
2 Likes
No its not in Docker, just added to the image when I was running Node Red
Cheers Will look into that also. Thank you
May get this for now.
Can I just copy the whole card using Balena Etcher Clone ?
Thanks
You can but I assume you run it on a RPi with Rasbian. I always use the already included tool in the Raspbian, SD Card Copier, just connect a USB SD card reader/writer and an empty (larger) SD card
1 Like
It is, with raspbiam, but its about 1 mile away on a remote monitoring site for solar panels.
Yeah, but using a SD card tool would mean you need to shutdown the system, eject the card and put it in a reader. With SD Card Copier, you make a copy while the system is running
But also in that case you need access to the site to insert the new empty card in its reader and connect it to a USB port
1 Like
Thanks all
Ended up removing the card and making a clone using Balena to a 32Gb card. Than expanded it, working for now, but need to have a flush of the data as its keeping it all.
Main problem was it was reading my Modbus every second, so changed that to 5 seconds which should last longer for now.
Thanks again for all your help.
If you are recording that in InfluxDB (or worse still in a different DB), make sure you don't keep the detailed data for too long.
Use InfluxDB's Retention Policy and Continuous Query capabilities to delete the detail data over a reasonable age (e.g. a week or whatever makes sense to you) and aggregate to an hourly (for example) table. Even do a couple of different levels if you want to. Most of my data is per minute and I keep that for 7 days only. The aggregation creates hourly data with avg, max, min values for every measure. That data is kept for several years.
1 Like
Thanks
I guess I need to do some google work to find out how its done, as its recording a lot of info at 5 second intervals.
Cheers
1 Like
Somewhere in the forum is a long response I did to someone on the subject and I think that I may have put in some example commands. It is a pain to work out the first time and I recommend keeping notes because it is only something you want to have to learn once!
SD Cards are not made for rapid and constant writing, they will fail. It's a very bad idea to put a database on an SD, even the good ones.
Deffo consider moving the DB to a different storage medium. I have an SSD in a NAS that homes my mySQL and Maria databases. The drive is something like 300x bigger than the DB's so plenty of room for wear levelling.
I don't think most OS's employ wear leveling on SD cards.
Sorry but this hasn't quite been the case for some years now. It has been well discussed and documented in this forum.
FLASH memory in general has known weaknesses in terms of the number of write cycles it can cope with. It has improved greatly but is still a lot more limited than a spinning platter hard-drive.
However, in reality, with appropriate hardware support (wear levelling built into the card) and plenty of space to play with, a decent card will withstand many years of hard use as many of us can proove.
I certainly wouldn't want to put a production database on one. 
but for home automation and "casual" IoT, they are more than good enough. I do nothing special with mine, I let Linux do whatever it wants with logs and DB's to do whatever they want. Admittedly, I'm only recording a few hundred data points between a few seconds and a minute apart typically (various sensors, heating, lighting, switches, and LOTS of system and LAN/WAN performance data). My cards have been in use for years now with no problems running 24x7.
I've had hard drives fail a lot faster.
I did certainly have problems with cheap cards when I started out on the Pi.
More room will last longer certainly - of course - and on a suitable device will be a LOT more performant.
Truth is though that a Pi (up until Pi4) has really lousy bus throughput. Compared to a NUC or any other type of general purpose compute device. So really, is the cost and complexity worth the effort? Well only you can work that out. It isn't for my use. But then I'm mostly moving away from the Pi. Not that I'm knocking the Pi as a platform - it has been and remains an incredible resource. I just happen to have an old laptop around not doing anything and so it is convenient to consolidate most of the work onto that. I will doubtless find new uses for my Pi's.
The OS's don't need to. The card controller (built into the card) does it. That's the difference between cheap cards and decent ones. That and the quality of the memory chips (though they mostly come from the same factory, I think cheap cards us "B" quality ones that the main vendors reject).
How can you tell them apart? I've personally had an expensive SandDisk SD go corrupt in a RPi4 recently, now that could have been a dodgy card of course; but anecdotal evidence from the main HA forums suggest that as a system grows leaving the DB and to a lesser extent the log on the system SD is not recommended due to the high instances of failure.
I run a NAS anyway (NodeRed is hosted in a container on it) so putting the high IO count elements onto that made more sense, that said I like how power efficient the Pi's are so that's why I keep them
If there was a way to know (For sure) which SD cards have useful WL and which don't that would be great; but since most users don't know what WL is, it's easier to give advise to avoid. Plus the speed bump on my HA DB having it on an SSD is not to be sniffed at when compared to the SD card.
In terms of IO, my DB for HA is a MariaDB instance, and it purges on a rolling 7 days; but even in that time, I've over 6m records taking up over 3.2gb space - That's a lot for an SD card to parse in a reasonable time frame. Speed and reliability are why I recommend people switch their DB's from SD cards to SSD.
This is an interesting read Julian - https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_reminder_that_sd_cards_with_wearleveling/
Read the thread and comments.
What I took from it was, for SD CARDS, SanDisk don't do static WL and those that have (some kinda WL) are rather poor at it. The only one mentioned to have actual WL was the WD Purple cards.
Try till they die?!
Yes, I would certainly not recommend that. On my Pi3, the 2 InfluxDB tables come to a total of 90Mb. But I think InfluxDB is MUCH better than standard SQL DBs at managing large tables using sharding.
I would expect a 3.2GB SQL DB to be doing some very heavy indexing and I'd probably expect a Pi to be swapping quite heavily. Though it depends on your indexes of course. You have to be realistic on something like a Pi. With only 1GB RAM, limited CPU and limited bus bandwidth, you can't expect miracles. It is amazing what it can do but still.
The Pi3 also has MongoDB which is used by the Ubiquiti Wi-Fi controller. Not sure how big that gets to be honest.
Not disagreeing other than to say that it isn't always needed and it adds significant cost and complexity which isn't always warranted.
As I say, my Pi's have no special consideration for the SD-Cards and they've been working hard for years now.
Not as hard as my NAS drives of course 2x3TB RAID0 90% full. Also running 24x7x365 with no issues for years.
Yes, I read that some while ago when I was fact-checking what I was telling people about SD-Cards. I seem to remember some other tests I found as well or maybe some comments somewhere - can't remember now - that mentioned the EVO and EVO Pro cards.
Clearly those cards DO have wear levelling otherwise my abuse of them would have easily killed them off as I did quite quickly with cheaper cards I had prior to those. Unfortunately, just because it says a manufacturer on the label, that does not always mean that they really are from that manufacturer. There are a LOT of fake cards around.
Bottom line is that a decent card from a decent supplier with plenty of room is still going to last most hobbyists for years without much trouble. But be realistic and don't try to capture data every 5ms when it won't have a material change over a minute, or 5 minutes or an hour. And also be realistic about how long you keep detailed data. I blew up several database engines like that before I learned my lesson! MongoDB was terrible, especially on a 32bit device. It died long before it reached anywhere near its supposed file size limit. By contrast, InfluxDB is incredibly well behaved even on limited resources. But it will still start to kill off the performance of a Pi3 if you forget to trim down your data.
If you do need that 5ms data, certainly invest in faster and more robust storage!
And if you have plenty of money - cut out the middle-man and get a NUC or something with a decent storage controller and buss throughput to go with your (relatively) expensive SSD's. And throw a decent amount of memory in it too.
You can't beat physics 
1 Like
