单InfluxDB实例下双数据库分存不同磁盘的实现方案咨询

Great question! Let's walk through the solutions to your problem step by step, focusing on clean, production-friendly approaches.

Can a single InfluxDB instance store different databases in separate directories? #

Short answer: InfluxDB (v1.x, which uses the "database" concept natively) doesn’t have built-in configuration to assign unique storage paths per database—by default, all databases live as subdirectories under the main data directory you set. But there are solid workarounds that don’t require running two separate instances, and are more规范 than symlinks.

Better alternatives besides two InfluxDB instances #

1. Retention Policies + Continuous Queries + Directory Binding (the most robust approach) #

This method combines InfluxDB’s native data lifecycle tools with system-level directory mounting to split your data across SSD and HDD properly:

Step 1: Configure Retention Policies (RP)

• For your main database one, create a retention policy that keeps data for 29 days:

  CREATE RETENTION POLICY rp_current ON one DURATION 29d REPLICATION 1 DEFAULT;
  

• For your historical database two, create a retention policy (set to INF if you want to keep data forever):

  CREATE RETENTION POLICY rp_history ON two DURATION INF REPLICATION 1 DEFAULT;
  

Step 2: Set up a Continuous Query (CQ) to auto-migrate old data

Create a continuous query that automatically moves data older than 29 days from one to two:

CREATE CONTINUOUS CQ cq_move_old_data ON one BEGIN
  SELECT * INTO two.rp_history.:MEASUREMENT FROM one.rp_current./.*/ GROUP BY *
END;

This CQ runs at your InfluxDB’s configured interval (default every 10 minutes) and copies qualifying data to the historical database automatically.

Step 3: Bind the two database directory to your HDD

Instead of symlinks, use a directory bind mount—a system-level operation that’s far more stable and规范 than symlinks:

1. Stop the InfluxDB service first:

   sudo systemctl stop influxdb
   

2. Move the existing two database directory from your SSD to the HDD (replace paths with your actual ones):

   sudo mv /var/lib/influxdb/data/two /mnt/hdd/influxdb/data/two
   

3. Create an empty directory in the original SSD location:

   sudo mkdir /var/lib/influxdb/data/two
   

4. Add a bind mount entry to /etc/fstab so it persists after reboot:

   /mnt/hdd/influxdb/data/two /var/lib/influxdb/data/two none bind 0 0
   

5. Mount the directory immediately:

   sudo mount -a
   

6. Start the InfluxDB service again:

   sudo systemctl start influxdb
   

From InfluxDB’s perspective, the two database still lives in its default path—but under the hood, it’s directly mapped to your HDD, with none of the edge cases of symlinks (like permission issues or backup tool conflicts).

2. Notes for InfluxDB 2.x users #

If you’re using InfluxDB 2.x (which uses "buckets" instead of databases), the same logic applies: each bucket’s data lives in a subdirectory under the engine storage path. You can use the same directory bind mount technique to map a specific bucket’s directory to your HDD, paired with InfluxDB 2.x’s retention rules and tasks (the replacement for continuous queries) to auto-migrate data between buckets.

Why this beats symlinks or two instances #

• Better than symlinks: Bind mounts are recognized at the filesystem kernel level, making them more reliable for production—they avoid issues like symlink traversal limits or unexpected behavior with monitoring/backup tools.
• Better than two instances: A single InfluxDB instance uses fewer system resources (CPU, memory, ports) and simplifies monitoring, configuration, and overall maintenance.

内容的提问来源于stack exchange，提问作者Orjanp