はじめに
InfluxDBは時系列データの管理に特化した高速なデータベースです。今回は、実験サーバーへデータを移行する必要があったのですが、使用していたInfluxDBがv1.6系と古く、思わぬトラブルが発生しました。そこで、調査して試したバックアップと復元の手順を備忘録も兼ねてまとめました。
1. 調査・実験の背景
1.1 移行のきっかけ
DBのデータを操作して新たなアルゴリズムを試すために、実験サーバーへの移行を試みました。
簡単に移動できると予想していたものの、InfluxDBのバージョンが1.6系という古い環境であったため、バックアップ・復元の手順や互換性の問題が発生しました。これを解決するために、実際の作業内容や対応方法をまとめました。
1.2 発生した問題と対策
-
portable形式でのバックアップの問題
現在推奨されているportable形式でのバックアップを試みたところ、InfluxDB 1.6系ではうまく移行できませんでした。具体的には、1.6系でportable形式でバックアップを取ると、2系のデータと誤認識されるようなバックアップデータが作成され、1系では正しくレストアできないという現象が発生しました。
これは、InfluxDB 1.6系以前のDBに依存するエラーであるとの情報もあります。原因の究明には若干の時間を要しました。 -
バックアップ形式の違いと復元手順の注意点
上記の理由から、InfluxDB 1.6系ではportable形式ではなく、従来のレガシー形式でのバックアップを実施する必要があります。また、復元時のメタデータやTSMファイルの扱いにも注意が必要です。
1.3 全体の流れ
①バックアップ元のデータベースのあるサーバーでバックアップを行います。
②ローカルPCにバックアップデータをダウンロードします。
③ローカルPCからデータベースを移行するサーバーにバックアップデータをアップロードします。
④移行サーバーでバックアップデータベースをレストアします。
⑤正常に復元できているかどうかを確認します。
※②を省略して①から③に進むこともできますが、今回は各工程を確認しながら進めるため、すべての手順を踏みました。
1.4 検証環境
移行元
OS：Ubuntu 16.04.7 LTS
influxDBのバージョン：version 1.6.4
ローカル環境
Windowsのバージョン：windows11 version 24H2
wslのバージョン：version2
仮装OS：Ubuntu 20.04.6 LTS
移行先
OS：Ubuntu 20.04.5 LTS
influxDBのバージョン：version 1.8.10
2. バックアップの手順
2.1 バックアップ前の確認
バックアップ前に、各データベースや全体のデータサイズを確認しておくと安心です。以下のコマンドで確認できます。
# 各データベースごとの使用量確認
sudo du -sh /var/lib/influxdb/data/*
# 全体の使用量確認
sudo du -sh /var/lib/influxdb/
※＊には確認したいデータベース名を入力してください。
2.2 バックアップディレクトリの作成
バックアップ用ディレクトリを作成します。例として、以下のようにディレクトリを用意します。
sudo mkdir -p /home/nakamura/backupdb
2.3 レガシー形式でのバックアップの実行
InfluxDB v1.6系でportable形式で取得したバックアップはv2系の形式と誤認識されることがあり、正しくレストアできない問題が発生します。
そのため、v1.6系ではレガシー形式でのバックアップを行う必要があります。
レガシー形式では、以下の2種類のバックアップが必要です
- メタデータ（データベースの構成情報
- データ本体（TSMファイル）
どちらのデータも、先ほど作成した backupdb ディレクトリに保存しておく必要があります。
メタデータのバックアップ
sudo influxd backup /home/nakamura/backupdb
※この方法でメタデータのみバックアップされます
データ本体(TSM)のバックアップ
sudo influxd backup -database mydb /home/your_user/backup/
※特定のデータベースだけをバックアップする場合は、-databaseオプションを利用してください。
-databaseオプションの後のmydbには自分がバックアップしたいデータベースの名前を入れてください。
3. バックアップデータの転送
3.1 tarで圧縮（必要であれば行ってください）
バックアップディレクトリ全体をtar形式で圧縮し、転送しやすい形にまとめます。
tar -czvf backupdb.tar.gz -C /home/nakamura backupdb
3.2 scpを用いた転送
バックアップデータをリモートからローカル、またはクラウドサーバーへ転送します。
今回はローカルサーバにダウンロードしてから、ターゲットのサーバーにアップロードしました。
# ダウンロード元のサーバーからローカルへダウンロード
scp username@<本番サーバーのIP>:/home/nakamura/backupdb.tar.gz .
# または、クラウドサーバーへアップロード
scp /path/to/backupdb.tar.gz username@<アップロード先IP>:/home/username/
※usernameにはリモートサーバーのユーザー名を入力します。
tarで圧縮を行わずにフォルダ単位での転送の場合は、-rオプションを利用してください。
# ダウンロード元のサーバーからローカルへダウンロード
scp -r username@<本番サーバーのIP>:/home/nakamura/backupdb.tar.gz .
# または、クラウドサーバーへアップロード
scp -r /path/to/backupdb.tar.gz username@<アップロード先IP>:/home/username/
4. 復元の手順
4.1 InfluxDBの停止
復元作業前に、InfluxDBサービスを停止します。
停止せずにレストア作業を行うと想定外のトラブルの原因になりますので、停止してからレストア作業を始めてください。
sudo systemctl stop influxdb
4.2 tarファイルの解凍（必要があれば実行してください）
転送したtarファイルを解凍して、バックアップデータを展開します。
tar -xzvf /home/your_user/backupdb.tar.gz -C /home/your_user/
4.3 メタデータの復元
まず、データベースの構造情報を含むメタデータを復元します。
sudo influxd restore -metadir /var/lib/influxdb/meta /home/your_user/backupdb
※この時に、portableでバックアップを取ってるなど、メタデータのバックアップ作成を失敗していると、エラーが起こり失敗します。
meta または *.meta というファイルが存在するかどうかを確認してください。
4.4 データ本体の復元
次に、TSMファイルとして保存されている実データの復元を行います。
sudo influxd restore -database <データベース名> -datadir /var/lib/influxdb/data /home/your_user/backupdb
4.5 所有権確認
復元後は、ファイルの権限設定なども適宜確認してください。
データディレクトリの所有者をinfluxdbに指定しておかないと、データベースが使用できない等のトラブルが発生します。
sudo chown -R influxdb:influxdb /var/lib/influxdb
4.6 influxDBの再起動
その後、InfluxDBを再起動します。
sudo systemctl start influxdb
5. 復元後の確認
復元が正常に行われたか、InfluxDB CLIを利用して以下のコマンドでデータの存在を確認します。
# influxDBの起動
influx
# ここからinfluxDB CLIでの操作になります
# データベース一覧の確認
show databases
# 使用するデータベースを選択
use <データベース名>
# measurementsの一覧確認
show measurements
# 最新データの確認（例：最新10件）
SELECT * FROM <measurement名> LIMIT 10
# フィールドキーの確認
SHOW FIELD KEYS FROM <measurement名>
# タグキーの確認
SHOW TAG KEYS FROM <measurement名>
これらのコマンドで、データが正しく復元されているかをチェックしてください。
データベースの一覧の確認や、measurementsの確認を行った際に何も表示されない場合は、データベースが空ですので、データベースのレストア、もしくはデータベースのバックアップに失敗しています。
また最初から手順を確認してください。
6. まとめ
今回の実験では、InfluxDB 1.6系におけるportable形式でのバックアップが、2系のデータと誤認識される問題により、正しいレストアが行えないことが確認されました。
そのため、1.6系では従来のレガシー形式でのバックアップ・復元手順を利用する必要があります。
バックアップ作業では、データサイズの確認、ディレクトリの作成、そしてレガシー形式でのバックアップを実施。
転送作業では、tarによる圧縮とscpを利用した安全なデータ転送を行いました。
復元作業では、サービス停止、tarファイルの解凍、メタデータおよびデータ本体の復元を行い、その後CLIでの動作確認を実施しました。
InfluxDBのバージョンやバックアップ形式に留意しながら作業を進めることが重要ですので、公式ドキュメントでも確認しながら移行作業を進めてください。
参考情報
InfluxDB v1.x 公式ドキュメント - Backup & Restore
※ コードブロックは読みやすさのために bash でハイライトしていますが、特に Bash である必要はありません。一般的なシェル環境で動作します。