In this weekly post we recap the most interesting InfluxDB and TICK-stack related issues, workarounds, how-tos and Q&A from GitHub, IRC and the InfluxDB Google Group that you might have missed in the last week or so.
Querying a retention policy in the CLI
Q: I’m trying to query data in a database’s default retention policy but I’m getting an unexpected error message. The error says it can’t find a retention policy that doesn’t even exist in the relevant database (see below). I thought the Command Line Interface (CLI) automatically queried the database’s default retention policy. Any advice on what could be going on here?
> USE "groundhog" Using database groundhog > SELECT * FROM "shadow" ERR: retention policy not found: one_day > SHOW RETENTION POLICIES ON "groundhog" name duration shardGroupDuration replicaN default ---- -------- ------------------ -------- ------- autogen 0s 168h0m0s 1 false season 24h0m0s 1h0m0s 1 true
A: Looking at that output, my best guess is that you set the target retention policy in a previous command (maybe you did something like
USE "<different_database>"."one_day"). You can clear that retention policy with the CLI’s
CLEAR command (see below for an example).
CLEAR is a new InfluxDB CLI command in version 1.2.
> CLEAR rp retention policy context cleared > SELECT * FROM "shadow" name: shadow time seen ---- ---- 2017-01-31T17:09:43Z true
Writing to a retention policy in the CLI
Q: I just updated to version 1.2, noticed a change in the InfluxDB CLI‘s behavior, and was wondering if that change was intentional.
In prior versions, when I wrote an
INSERT INTO my-retention-policy command, every subsequent write would go into that retention policy, even if I didn’t include the
INTO clause. Now the
INSERT INTO command doesn’t seem to set the retention policy for every subsequent write. Was this change intentional? Is there a way to get around having to write out
INSERT INTO my-retention-policy for every write into a non-default retention policy?
A: That change was intentional! Version 1.2 introduces new syntax that more clearly sets the target retention policy for writes:
USE "<database>"."<retention_policy>". You can check the current target database and retention policy with the
> USE "groundhog"."season" Using database groundhog Using retention policy season > SETTINGS Setting Value -------- -------- Host localhost:8086 Username gopher Database groundhog RetentionPolicy season Pretty false Format column Write Consistency all
Q: I’ve recently started working with InfluxDB. Do you have any recommendations for keeping my data secure?
A: Yes! If you plan on installing InfluxDB with public internet access we recommend checking out our Security Best Practices pages. It lists the steps you need to take to secure your database and links to any relevant documentation.
- Downloads for the TICK-stack are live on our “downloads” page.
- Deploy on the Cloud: Get started with a FREE trial of InfluxDB Cloud featuring fully-managed clusters, Kapacitor and Grafana.
- Deploy on Your Servers: Want to run InfluxDB clusters on your servers? Try a FREE 14-day trial of InfluxDB Enterprise featuring an intuitive UI for deploying, monitoring and rebalancing clusters, plus managing backups and restores.
- Tell Your Story: Over 300 companies have shared their story on how InfluxDB is helping them succeed. Submit your testimonial and get a limited edition hoodie as a thank you.