I haven't tried backfilling yet, but I did come across something unexpected.
I am using my CQ to roll up timers into a timers_1m measurement. When I execute SHOW MEASUREMENTS, I see timers_1m there. So, I try select * from timers_1m where time > now() - 5m and get "success" but nothing else. After digging around some more, I tried changing my query to: select * from "minute_52w".timers_1m where time > now() - 5m (where "minute_52w" is the retention policy) then I get all of the data! That is in every possible way not expected. I was under the impression that retention policies were more transparent, behind the scenes... a means of managing the amount of data stored in the system, not a very front-and-center requirement for querying. I even tried hitting it in chronograf and grafana (interestingly, grafana was able to navigate and find the records once I added the RP, chronograf wasn't) This seems very not-intuitive for someone who comes to the data - either the influx interface or chronograf - to explore or interact with the data. If they did as I, and just did a SHOW MEASUREMENTS, it's not a logical next step to try retention policies in order to find the data. I guess I added all of that to say, either the documentation needs fleshed out tremendously, example queries need to be expanded, or rethinking how queries on measurements with RP's involved is required. Aside from this, I'm really enjoying influxDB so far. Telegraf is great, too.... chronograf needs some work, and I WANT to dig in with kapacitor, just haven't had the opportunity yet. All the Best, Ben On Friday, July 15, 2016 at 4:52:13 PM UTC-4, Sean Beckett wrote: > > I properly should have said there's no way to schedule a backfill query. > CQs and bqckfill queries both involve INTO clauses. > > The CQ should be logging when it runs. Do you see log entries for it? Are > CQs enabled in the config file? Can you include the output from SHOW > CONTINUOUS QUERIES? > > On Fri, Jul 15, 2016 at 8:01 AM, <[email protected] <javascript:>> > wrote: > >> I'm having a similar challenge with a CQ created according to the >> documentation. The DB shows the CQ exists, and if I execute a backfill >> query as given in the documentation, data is populated, but there is >> nothing automatically being added to the DB. >> >> The specific question I have is that documents show the "INTO" being >> necessary if one wants to write to a specific retention policy. That seems >> to contradict the "no way to schedule an INTO query" by Sean. >> >> Any help is appreciated. >> >> I'm working from the most recent documentation (matching the 1.0.0 beta2 >> we're using for evaluating this stack) - >> https://docs.influxdata.com/influxdb/v1.0/query_language/continuous_queries/ >> >> On Tuesday, May 24, 2016 at 11:43:50 AM UTC-4, Sean Beckett wrote: >> > CQs only run against newly arrived data. INTO queries run against >> arbitrary time ranges. There is no way to schedule an INTO query. >> > >> > >> > Use INTO queries to backfill your previous data. Use CQs to downsample >> newly arriving data. >> > >> > >> > CQs do not respect any WHERE time clause. use GROUP BY time(1d) to have >> the CQ run daily. See the docs for more: >> https://docs.influxdata.com/influxdb/v0.13/query_language/continuous_queries/ >> > >> > >> >> Sean Beckett > Director of Support and Professional Services > InfluxDB > -- Remember to include the InfluxDB version number with all issue reports --- You received this message because you are subscribed to the Google Groups "InfluxDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/influxdb. To view this discussion on the web visit https://groups.google.com/d/msgid/influxdb/25bf6d02-3302-4d24-8ace-c8a01e4ffdbc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
