TL;DR InfluxDB Tech Tips - Querying and Writing a Retention Policy in the CLI and Securing InfluxDB

By Regan Kuchan / Product, Developer
Feb 02, 2017

Navigate to:

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&gt"."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 SETTINGS command:

> 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

Securing InfluxDB

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.

What's next:

  • 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.