• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..14-Sep-2018-

b1/H14-Sep-2018-271199

bz1/H14-Sep-2018-372259

stats/H14-Sep-2018-5637

tsdb/H14-Sep-2018-548394

README.mdH A D14-Sep-20187.6 KiB153118

converter.goH A D14-Sep-20182.5 KiB11988

main.goH A D14-Sep-201810.8 KiB420325

tracker.goH A D14-Sep-20183.6 KiB131107

README.md

1# Converting b1 and bz1 shards to tsm1
2
3`influx_tsm` is a tool for converting b1 and bz1 shards to tsm1
4format. Converting shards to tsm1 format results in a very significant
5reduction in disk usage, and significantly improved write-throughput,
6when writing data into those shards.
7
8Conversion can be controlled on a database-by-database basis. By
9default a database is backed up before it is converted, allowing you
10to roll back any changes. Because of the backup process, ensure the
11host system has at least as much free disk space as the disk space
12consumed by the _data_ directory of your InfluxDB system.
13
14The tool automatically ignores tsm1 shards, and can be run
15idempotently on any database.
16
17Conversion is an offline process, and the InfluxDB system must be
18stopped during conversion. However the conversion process reads and
19writes shards directly on disk and should be fast.
20
21## Steps
22
23Follow these steps to perform a conversion.
24
25* Identify the databases you wish to convert. You can convert one or more databases at a time. By default all databases are converted.
26* Decide on parallel operation. By default the conversion operation peforms each operation in a serial manner. This minimizes load on the host system performing the conversion, but also takes the most time. If you wish to minimize the time conversion takes, enable parallel mode. Conversion will then perform as many operations as possible in parallel, but the process may place significant load on the host system (CPU, disk, and RAM, usage will all increase).
27* Stop all write-traffic to your InfluxDB system.
28* Restart the InfluxDB service and wait until all WAL data is flushed to disk -- this has completed when the system responds to queries. This is to ensure all data is present in shards.
29* Stop the InfluxDB service. It should not be restarted until conversion is complete.
30* Run conversion tool. Depending on the size of the data directory, this might be a lengthy operation. Consider running the conversion tool under a "screen" session to avoid any interruptions.
31* Unless you ran the conversion tool as the same user as that which runs InfluxDB, then you may need to set the correct read-and-write permissions on the new tsm1 directories.
32* Restart node and ensure data looks correct.
33* If everything looks OK, you may then wish to remove or archive the backed-up databases.
34* Restart write traffic.
35
36## Example session
37
38Below is an example session, showing a database being converted.
39
40```
41$ # Create a backup location that the `influxdb` user has full access to
42$ mkdir -m 0777 /path/to/influxdb_backup
43$ sudo -u influxdb influx_tsm -backup /path/to/influxdb_backup -parallel /var/lib/influxdb/data
44
45b1 and bz1 shard conversion.
46-----------------------------------
47Data directory is:                  /var/lib/influxdb/data
48Backup directory is:                /path/to/influxdb_backup
49Databases specified:                all
50Database backups enabled:           yes
51Parallel mode enabled (GOMAXPROCS): yes (8)
52
53
54Found 1 shards that will be converted.
55
56Database        Retention       Path                                                    Engine  Size
57_internal       monitor         /var/lib/influxdb/data/_internal/monitor/1           bz1     65536
58
59These shards will be converted. Proceed? y/N: y
60Conversion starting....
61Backing up 1 databases...
622016/01/28 12:23:43.699266 Backup of databse '_internal' started
632016/01/28 12:23:43.699883 Backing up file /var/lib/influxdb/data/_internal/monitor/1
642016/01/28 12:23:43.700052 Database _internal backed up (851.776µs)
652016/01/28 12:23:43.700320 Starting conversion of shard: /var/lib/influxdb/data/_internal/monitor/1
662016/01/28 12:23:43.706276 Conversion of /var/lib/influxdb/data/_internal/monitor/1 successful (6.040148ms)
67
68Summary statistics
69========================================
70Databases converted:                 1
71Shards converted:                    1
72TSM files created:                   1
73Points read:                         369
74Points written:                      369
75NaN filtered:                        0
76Inf filtered:                        0
77Points without fields filtered:      0
78Disk usage pre-conversion (bytes):   65536
79Disk usage post-conversion (bytes):  11000
80Reduction factor:                    83%
81Bytes per TSM point:                 29.81
82Total conversion time:               7.330443ms
83
84$ # restart node, verify data
85$ sudo rm -r /path/to/influxdb_backup
86```
87
88Note that the tool first lists the shards that will be converted,
89before asking for confirmation. You can abort the conversion process
90at this step if you just wish to see what would be converted, or if
91the list of shards does not look correct.
92
93__WARNING:__ If you run the `influx_tsm` tool as a user other than the
94`influxdb` user (or the user that the InfluxDB process runs under),
95please make sure to verify the shard permissions are correct prior to
96starting InfluxDB. If needed, shard permissions can be corrected with
97the `chown` command. For example:
98
99```
100sudo chown -R influxdb:influxdb /var/lib/influxdb
101```
102
103## Rolling back a conversion
104
105After a successful backup (the message `Database XYZ backed up` was
106logged), you have a duplicate of that database in the _backup_
107directory you provided on the command line. If, when checking your
108data after a successful conversion, you notice things missing or
109something just isn't right, you can "undo" the conversion:
110
111- Shut down your node (this is very important)
112- Remove the database's directory from the influxdb `data` directory (default: `~/.influxdb/data/XYZ` for binary installations or `/var/lib/influxdb/data/XYZ` for packaged installations)
113- Copy (to really make sure the shard is preserved) the database's directory from the backup directory you created into the `data` directory.
114
115Using the same directories as above, and assuming a database named `stats`:
116
117```
118$ sudo rm -r /var/lib/influxdb/data/stats
119$ sudo cp -r /path/to/influxdb_backup/stats /var/lib/influxdb/data/
120$ # restart influxd node
121```
122
123#### How to avoid downtime when upgrading shards
124
125*Identify non-`tsm1` shards*
126
127Non-`tsm1` shards are files of the form: `data/<database>/<retention_policy>/<shard_id>`.
128
129`tsm1` shards are files of the form: `data/<database>/<retention_policy>/<shard_id>/<file>.tsm`.
130
131*Determine which `bz`/`bz1` shards are cold for writes*
132
133Run the `SHOW SHARDS` query to see the start and end dates for shards.
134If the date range for a shard does not span the current time then the shard is said to be cold for writes.
135This means that no new points are expected to be added to the shard.
136The shard whose date range spans now is said to be hot for writes.
137You can only safely convert cold shards without stopping the InfluxDB process.
138
139*Convert cold shards*
140
1411. Copy each of the cold shards you'd like to convert to a new directory with the structure `/tmp/data/<database>/<retention_policy>/<shard_id>`.
1422. Run the `influx_tsm` tool on the copied files:
143```
144influx_tsm -parallel /tmp/data/
145```
1463. Remove the existing cold `b1`/`bz1` shards from the production data directory.
1474. Move the new `tsm1` shards into the original directory, overwriting the existing `b1`/`bz1` shards of the same name. Do this simultaneously with step 3 to avoid any query errors.
1485. Wait an hour, a day, or a week (depending on your retention period) for any hot `b1`/`bz1` shards to become cold and repeat steps 1 through 4 on the newly cold shards.
149
150> **Note:** Any points written to the cold shards after making a copy will be lost when the `tsm1` shard overwrites the existing cold shard.
151Nothing in InfluxDB will prevent writes to cold shards, they are merely unexpected, not impossible.
152It is your responsibility to prevent writes to cold shards to prevent data loss.
153