Anais, That definitely gives me some food for thought. I don’t know anything about 2.x, but would the same basic idea work in 1.x? I could imagine writing a query which does a “select … into” to transform the data into another retention policy. Then I could discard the original RP. But, I’m not sure what the memory implications of that are. If I duplicate the data into another RP, does that effectively increase the total series cardinality of the whole database once again? Is this something that would be different between 1.x and 2.x?
Regarding expiring old data, that’s an interesting question. We want to keep all of our data in some form, as it can occasionally be useful, but it is rare that we actually look at the older stuff. We can’t continue to grow our one InfluxDB instance forever. In the past we have twice used this strategy: Simply copy the influx data files to another place, and set a new, shorter, retention policy for the live database. That was an emergency reaction both times. It would be nice if the database gave us some feature to sort of roll data out to a cold-storage location. So far we have had some luck “rolling” data out by simply snapshotting/copying the files underneath Influx, but we’re not sure if that’s a valid, supportable option. Any suggestions for this scenario?
