Influxdb Backup and restoration

Reference: InfluxDB backup and restore

Environment:

  • Influxdb v1.6.0
  • Use the Influx automated console

I. the backup

The backup command

Influxd backup [-database <db_name>] --> Specify the name of the database to be backed up [-portable] --> Indicates online backup [-host <host:port>] --> Influxdb service machine, port defaults to 8088 [- retention < rp_name >] | [- shard < shard_ID > - retention < rp_name >] - > backup retention policy, Note that the shard hangs under the RP; We need backup is shard the data in the [- start < timestamp > [- end < timestamp >] | - since < timestamp >] - > backup designated period data stored < path - to - > -- > Output address of the backup fileCopy the code

1. Example demonstration

Start by creating a database, yHHblog, that contains two measurements, corresponding to the following data

> show databases name: databases name ---- _internal yhhblog > use yhhblog Using database yhhblog > show measurements name: measurements name ---- netLoad serviceLoad > select * from netLoad name: NetLoad time host netIn netOut service ---- ---- ----- ------ ------- 1532658769048100401 127.0.0.1 13m 521K app.service.about > select * from serviceLoad name: ServiceLoad Time CPU Host Load mem QPS RT service ------- ---- ------- ----- ------- 1532658713805369067 45.23 127.0.0.2 1.21 4145m 1341 1312 app.service-about 1532658718726259226 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.aboutCopy the code

A. Back up all databases

Backup all the databases in InfluxDB without any parameters

influxd backup -portable /tmp/data/total
Copy the code

B. Back up the specified database

If you want to back up only the yHHblog database above, add the -database parameter

# influxd backup -portable -database yhhblog /tmp/data/yhhblog2018/07/27 10:38:15 backing up metastore to /tmp/data/yhhblog/meta.00 2018/07/27 10:38:15 backing up db=yhhblog 2018/07/27 10:38:15 backing up the db = yhhblog rp = autogen shard = 10 to/TMP/data/yhhblog/yhhblog autogen. Since 00010.00 0001-01-01T00:00:00Z 2018/07/27 10:38:15 backup complete: 2018/07/27 10:38:15 /tmp/data/yhhblog/20180727T023815Z.meta 2018/07/27 10:38:15 /tmp/data/yhhblog/20180727T023815Z.s10.tar.gz 2018/07/27 10:38:15 /tmp/data/yhhblog/20180727T023815Z.manifestCopy the code

C. Back up the database data of the specified period

For the preceding data, back up only the data that meets the requirements in part of the time. You can add start and end parameters

# influxd backup -portable -database yhhblog -start 2018-07-27T2:31:57Z -end 2018-07-27T2:32:59Z /tmp/data/yhhblog_per2018/07/27 10:42:14 backing up metastore to /tmp/data/yhhblog_per/meta.00 2018/07/27 10:42:14 backing up db=yhhblog 2018/07/27 10:42:14 backing up the db = yhhblog rp = autogen shard = 10 to/TMP/data/yhhblog_per/yhhblog autogen. With 00010.00 boundaries start=2018-07-27T02:31:57Z, end=2018-07-27T02:32:59Z 2018/07/27 10:42:14 backup complete: 2018/07/27 10:42:14 /tmp/data/yhhblog_per/20180727T024214Z.meta 2018/07/27 10:42:14 /tmp/data/yhhblog_per/20180727T024214Z.s10.tar.gz 2018/07/27 10:42:14 /tmp/data/yhhblog_per/20180727T024214Z.manifestCopy the code

Now that the backup is ok, the question is how to confirm the backup problem is there any problem? How to restore the data after backup?

II. The recovery

The command is

Influxd restore [- db < db_name >] -- > database to restore (backup of the database name) - portable | - online [- host < host: port >] - > [influxdb server -newdb <newdb_name>] --> Database names recovered from the influxDB influencer [-rp <rp_name>] --> Retention policy in backup [-newrp <newrp_name>] --> Retention policy recovered [-shard <shard_ID> ] <path-to-backup-files>Copy the code

First, demonstrate the recovery strategy in a simple way, and check to see if there is a problem with the backup data

1. Restore the database that does not exist

To restore the exported backup to a new database yhHBlog_bk, run the following command

influxd restore -portable -db yhhblog -newdb yhhblog_bk yhhblog_per
Copy the code

Note that we are restoring the backup of the time segment data, so the restored data should exclude the data that is not in the above date

> show databases name: databases name ---- _internal yhhblog yhhblog_bk > use yhhblog_bk Using database yhhblog_bk > show measurements name: measurements name ---- netLoad serviceLoad > select * from netLoad name: NetLoad time host netIn netOut service ---- ---- ----- ------ ------- 1532658769048100401 127.0.0.1 13m 521K app.service.about > select * from serviceLoad name: ServiceLoad Time CPU Host Load mem QPS rt service ------- ---- ------- ----- ------- 1532658718726259226 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.aboutCopy the code

Note that the serviceLoad has only one piece of data in it, which indicates that we have no problem backing up by time

2. Restore the database to an existing DB

If you want to restore the database to an existing database, it is not as simple as above. One of the strategies used here is to backup the database to a temporary database. The data in the temporary DB is then written to the existing DB

The detailed demonstration steps are as follows (note that the execution of this summary can be directly dependent on the previously restored backup database)

Restore the backup to the existing database yhhblogNew

The first step is to restore the backup to a non-existent database yhHBLOG_bk
influxd restore -portable -db yhhblog -newdb yhhblog_bk yhhblog_per
Copy the code

Enter the Influx console to copy and delete the temporary database

Prepare yhhblogNew database
> create database yhhblogNew

Import data from temporary database into existing database> use yhhblog_bk > SELECT * INTO yhhblogNew.. :MEASUREMENT FROM /.*/ GROUP BY * > drop yhhblog_bkCopy the code

3. If the retention policy already exists, restore it

influxd restore -portable -db yhhblog -newdb yhhblog_tmp -rp autogen -newrp autogen_tmp  yhhblog
Copy the code

Enter the Influx console and perform a copy

> user yhhblog_tmp
> SELECT * INTO yhhblogNew.autogen.:MEASUREMENT FROM /yhhblog_tmp.autogen_tmp.*/ GROUP BY *
> drop database yhhblog_tmp
Copy the code

4. Other

There are also two other recovery methods officially written, one is abandoned and the other is offline, which leads to data loss and is not recommended. However, backup and recovery is an outdated solution in most blog posts, which is not very friendly and will not be described in detail here

III. The other

1. A gray Blog: https://liuyueyi.github.io/hexblog.

A gray personal blog, recording all the study and work in the blog, welcome everyone to go to stroll

2. Statement

As far as the letter is not as good as, has been the content, purely one’s own words, because of the limited personal ability, it is hard to avoid omissions and mistakes, such as finding bugs or better suggestions, welcome criticism and correction, not grudging gratitude

  • Micro Blog address: Small Gray Blog
  • QQ: a gray /3302797840

3. Scan attention

Small grey Blog& public number

Knowledge of the planet