Apache Cassandraのバックアップとリカバリ完全ガイド：nodetoolとsstableloaderによる実践手順

データベースのバックアップとリカバリは、データベース管理者（DBA）が日常的に行う最も重要な業務の一つです。データベースのバックアップとは、データ損失が発生した場合にデータを復旧するために使用できる、データのコピーのことです。

本記事では、Apache® Cassandra®データベースのバックアップ方法と、障害発生後の復元方法について詳しく解説します。

はじめに

Apache Cassandraは分散型アーキテクチャを採用しており、クラスタ内の少なくとも1つのノードにデータが残っていれば、単一ノード障害や複数ノード障害が発生してもビジネスデータを失うことなく耐え抜くことができます。しかし、ベストプラクティスとしては、データベースに対してバックアップを構成しておくことが推奨されます。

クラスタ全体の再構築、データ破構築、データ破損、誤ってデータを削除してしまうなどの障害が発生した場合でも、バックアップからデータを復旧し、ビジネスへの影響を最小限（あるいはゼロ）に抑えながら業務を継続できます。

近年、CassandraのようなNoSQLデータベースを採用し、大量のビジネスデータ、いわゆる「ビッグデータ」を効率的に管理する企業が増えています。多くの大手組織で幅広く利用されているCassandraは、スケーラビリティ、フォールトトレランス（耐障害性）、一貫性を備え、ビッグデータを支える基盤として信頼されています。

Cassandraデータベースのバックアップと復元

Cassandraデータベースのスナップショットを作成し、必要なときに復元するには、以下のユーティリティを使用します。

• nodetool（スナップショットの取得用）
• sstableloader（スナップショットバックアップの復元用）

次の図は、sstableloaderを使用してクラウドクラスタからCassandraクラスタへデータを移行する様子を示しています。

画像出典：https://dzone.com/articles/using-casandras-sstable-bulk

バックアップ手順

以下の例では、nodetoolを使用して、keyspace(users)内のemployeeテーブルを持つCassandraデータベースのスナップショットを取得します。

ソースとなるCassandraクラスタの詳細：

$ nodetool -u cassandra -pw ******** -h localhost status

Datacenter: us-central1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.128.0.2  121.52 KiB  256         63.3%             5957997f-7471-4c21-bead-37a6604812e2  f
UN  10.128.0.3  92.22 KiB  256          68.0%             87c2a663-a965-4675-b5ed-c4a46d77c796  f
UN  10.128.0.4  225.3 KiB  256          68.8%             8e12557f-be00-4387-bff3-ef51f431b9a0  f

次のコマンドでkeyspaceのバックアップを実行します。

$ nodetool -h localhost -u cassandra -pw ****** snapshot users -t "users-201904201800"

Requested creating snapshot(s) for [users] with snapshot name [users-201904201800] and options {skipFlush=false}
Snapshot directory: users-201904201800

このコマンドにより、以下のようなバックアップスナップショットが作成されます。

/bitnami/cassandra/data/data/users/employee-c1319df0636211e9a0e3570eb7f8fd5f/snapshots/users-201904201800
$ ls -ltr
total 44
-rw-r--r-- 2 cassandra cassandra   16 Apr 20 12:05 md-1-big-Filter.db
-rw-r--r-- 2 cassandra cassandra   56 Apr 20 12:05 md-1-big-Summary.db
-rw-r--r-- 2 cassandra cassandra   32 Apr 20 12:05 md-1-big-Index.db
-rw-r--r-- 2 cassandra cassandra  134 Apr 20 12:05 md-1-big-Data.db
-rw-r--r-- 2 cassandra cassandra   10 Apr 20 12:05 md-1-big-Digest.crc32
-rw-r--r-- 2 cassandra cassandra   43 Apr 20 12:05 md-1-big-CompressionInfo.db
-rw-r--r-- 2 cassandra cassandra 4683 Apr 20 12:05 md-1-big-Statistics.db
-rw-r--r-- 2 cassandra cassandra   92 Apr 20 12:05 md-1-big-TOC.txt
-rw-r--r-- 1 cassandra cassandra   31 Apr 20 12:05 manifest.json
-rw-r--r-- 1 cassandra cassandra  865 Apr 20 12:05 schema.cql

$ date
Sat Apr 20 12:08:21 UTC 2019

続いて、/snapshotバックアップディレクトリ内のファイルをtar形式でアーカイブし、そのtarファイルを/bitnami/Cassandra/data/data/backupディレクトリへ移動します。

$ tar -cvf users-201904201800.tar *.*
manifest.json
md-1-big-CompressionInfo.db
md-1-big-Data.db
md-1-big-Digest.crc32
md-1-big-Filter.db
md-1-big-Index.db
md-1-big-Statistics.db
md-1-big-Summary.db
md-1-big-TOC.txt
schema.cql

$ ls -ltr
total 64
-rw-r--r-- 2 cassandra cassandra    16 Apr 20 12:05 md-1-big-Filter.db
-rw-r--r-- 2 cassandra cassandra    56 Apr 20 12:05 md-1-big-Summary.db
-rw-r--r-- 2 cassandra cassandra    32 Apr 20 12:05 md-1-big-Index.db
-rw-r--r-- 2 cassandra cassandra   134 Apr 20 12:05 md-1-big-Data.db
-rw-r--r-- 2 cassandra cassandra    10 Apr 20 12:05 md-1-big-Digest.crc32
-rw-r--r-- 2 cassandra cassandra    43 Apr 20 12:05 md-1-big-CompressionInfo.db
-rw-r--r-- 2 cassandra cassandra  4683 Apr 20 12:05 md-1-big-Statistics.db
-rw-r--r-- 2 cassandra cassandra    92 Apr 20 12:05 md-1-big-TOC.txt
-rw-r--r-- 1 cassandra cassandra    31 Apr 20 12:05 manifest.json
-rw-r--r-- 1 cassandra cassandra   865 Apr 20 12:05 schema.cql
-rw-r--r-- 1 cassandra cassandra 20480 Apr 20 12:22 users-201904201800.tar

cp *.tar /bitnami/cassandra/data/data/backup.
/bitnami/cassandra/data/data/backup

$ ls -ltr
-rw-r--r--  1 cassandra cassandra 20480 Apr 20 12:23 users-201904201800.tar

バックアップのtarファイルをデフォルト以外の場所へコピーしたら、employeeテーブルを削除（DROP）します。

注意：Cassandraは定義されたパーティションキーとレプリケーションファクターに基づいて、クラスタ全体にデータを分散配置します。そのため、このバックアップコマンドはすべてのノードで実行する必要があります。この例では、Linux®のシェルスクリプトをcrontabに登録し、すべてのノードを一度にバックアップしています。

$ cqlsh -u cassandra -p *******

Connected to Test_Cassandra at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.

cassandra@cqlsh> use users;
cassandra@cqlsh:users> select * from employee;

 emp_id | employee_address | employee_name
--------+------------------+---------------
   8796 |        Singapore |           Joy
   5647 |           London |          Mike
   3452 |           Canada |         Nancy
   6453 |            China |          John

(4 rows)

cassandra@cqlsh:users> drop table employee;
cassandra@cqlsh:users> select * from employee;
InvalidRequest: Error from server: code=2200 [Invalid query] message="unconfigured table employee"

復元（リストア）手順

keyspace(users)のスナップショットバックアップからemployeeテーブルを復元するには、sstableloaderユーティリティを使用します。sstableloaderは、単にsstablesのセットを各ノードへコピーするだけでなく、クラスタに定義されたレプリケーション戦略に基づいて、各ノードへ適切な部分のデータを転送します。なお、データを復元するために空のテーブルを用意しておく必要はありません。

以下の手順で、tarファイルをbackup/usersへ展開します。

$ pwd
/bitnami/cassandra/data/data/backup/users
$ ls -ltr
total 20
-rw-r--r-- 1 cassandra cassandra 20480 Apr 20 12:23 users-201904201800.tar
$ tar -xvf *.tar
manifest.json
md-1-big-CompressionInfo.db
md-1-big-Data.db
md-1-big-Digest.crc32
md-1-big-Filter.db
md-1-big-Index.db
md-1-big-Statistics.db
md-1-big-Summary.db
md-1-big-TOC.txt
schema.cql

次に、復元対象のテーブル名と同じ名前で、ユーザーディレクトリへのシンボリックリンク（ソフトリンク）を作成します。

$ ln -s /bitnami/cassandra/data/data/backup/users employee
$ ls -ltr
total 64
-rw-r--r-- 1 cassandra cassandra   865 Apr 20 12:05 schema.cql
-rw-r--r-- 1 cassandra cassandra    92 Apr 20 12:05 md-1-big-TOC.txt
-rw-r--r-- 1 cassandra cassandra    56 Apr 20 12:05 md-1-big-Summary.db
-rw-r--r-- 1 cassandra cassandra  4683 Apr 20 12:05 md-1-big-Statistics.db
-rw-r--r-- 1 cassandra cassandra    32 Apr 20 12:05 md-1-big-Index.db
-rw-r--r-- 1 cassandra cassandra    16 Apr 20 12:05 md-1-big-Filter.db
-rw-r--r-- 1 cassandra cassandra    10 Apr 20 12:05 md-1-big-Digest.crc32
-rw-r--r-- 1 cassandra cassandra   134 Apr 20 12:05 md-1-big-Data.db
-rw-r--r-- 1 cassandra cassandra    43 Apr 20 12:05 md-1-big-CompressionInfo.db
-rw-r--r-- 1 cassandra cassandra    31 Apr 20 12:05 manifest.json
-rw-r--r-- 1 cassandra cassandra 20480 Apr 20 12:23 users-201904201800.tar
lrwxrwxrwx 1 cassandra cassandra    41 Apr 20 15:56 employee -> /bitnami/cassandra/data/data/backup/users

スナップショットバックアップ時に生成された.cqlファイルを使用して、テーブル構造を作成します。

keyspaceのバックアップを実行すると、keyspace内に存在するオブジェクトのデータ定義言語（DDL）を含むschema.cqlというファイルが生成されます。

このschema.cqlを使って、誤って削除されたemployeeオブジェクトを再作成します。

$ cqlsh -u cassandra -p ******** -f schema.cql

Warnings:
dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0

dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0
$ cqlsh -u cassandra -p ******* -f schema.cql

続いて、sstableloaderを使用してスナップショットからデータを復元します。このツールはバックアップ内のすべてのsstablesを読み込み、データをクラスタへストリーミングします。その際、クラスタに定義されたレプリケーション戦略に基づいて、各ノードへ関連する部分のデータが転送されます。

Syntax: sstableloader -u <username> -pw passwrod -d <hostname> <employee table softlink name with location>

以下のコマンドでデータを復元します。

$  sstableloader -u cassandra -pw  ******** -d cassandra-cluster-1-node-0 /bitnami/cassandra/data/data/backup/users/employee
Established connection to initial hosts
Opening sstables and calculating sections to stream
Streaming relevant part of /bitnami/cassandra/data/data/backup/users/md-1-big-Data.db  to [/10.128.0.2, /10.128.0.3, /10.128.0.4]
progress: [/10.128.0.2]0:0/1 0  % [/10.128.0.3]0:0/1 0  % [/10.128.0.4]0:1/1 100% total: 33% 0.032KiB/s (avg: 0.032KiB/s)
progress: [/10.128.0.2]0:0/1 0  % [/10.128.0.3]0:0/1 0  % [/10.128.0.4]0:1/1 100% total: 33% 0.000KiB/s (avg: 0.031KiB/s)
progress: [/10.128.0.2]0:0/1 0  % [/10.128.0.3]0:1/1 100% [/10.128.0.4]0:1/1 100% total: 66% 0.113KiB/s (avg: 0.050KiB/s)
progress: [/10.128.0.2]0:1/1 100% [/10.128.0.3]0:1/1 100% [/10.128.0.4]0:1/1 100% total: 100% 85.129KiB/s (avg: 0.074KiB/s)
progress: [/10.128.0.2]0:1/1 100% [/10.128.0.3]0:1/1 100% [/10.128.0.4]0:1/1 100% total: 100% 0.000KiB/s (avg: 0.073KiB/s)
progress: [/10.128.0.2]0:1/1 100% [/10.128.0.3]0:1/1 100% [/10.128.0.4]0:1/1 100% total: 100% 0.000KiB/s (avg: 0.073KiB/s)

Summary statistics:
   Connections per host    : 1
   Total files transferred : 3
   Total bytes transferred : 0.393KiB
   Total duration          : 5346 ms
   Average transfer rate   : 0.073KiB/s
   Peak transfer rate      : 0.074KiB/s

各ノードに保存されているsstablesからデータを取り出すため、これらの手順をすべてのノードで繰り返し実行します。

次に、nodetool repairを使用してデータを修復します。このコマンドは、実行したノードに格納されているデータのすべてのレプリカを比較し、各レプリカを最新のバージョンへ更新します。

$ nodetool repair -u Cassandra -pw ********

[2019-04-21 07:59:14,701] Starting repair command #1 (5b123ad0-640b-11e9-a0e3-570eb7f8fd5f), repairing keyspace users with repair options (parallelism: parallel, primary range: false, incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 768, pull repair: false)
[2019-04-21 07:59:16,450] Repair completed successfully
[2019-04-21 07:59:16,451] Repair command #1 finished in 1 second
[2019-04-21 07:59:16,460] Replication factor is 1. No repair is needed for keyspace 'system_auth'
[2019-04-21 07:59:16,474] Starting repair command #2 (5c22e780-640b-11e9-a0e3-570eb7f8fd5f), repairing keyspace system_traces with repair options (parallelism: parallel, primary range: false, incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 513, pull repair: false)
finished (progress: 1%)
[2019-04-21 07:59:17,653] Repair completed successfully
[2019-04-21 07:59:17,653] Repair command #2 finished in 1 second

最後に、削除したemployeeテーブルのデータを検証します。先ほどのコマンドにより、事前に取得していたバックアップからデータが復元されています。データが正しく復元されたかどうかを確認しましょう。

$ cqlsh -u cassandra -p ********

Connected to Test_Cassandra at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.

cassandra@cqlsh> use users;

cassandra@cqlsh:users> select * from employee;

 emp_id | employee_address | employee_name
--------+------------------+---------------
   8796 |        Singapore |           Joy
   5647 |           London |          Mike
   3452 |           Canada |         Nancy
   6453 |            China |          John

(4 rows)

まとめ

本記事では、Cassandraデータベースにおけるテーブル単位のバックアップと復元方法を学びました。keyspace（データベース）全体を復元する必要がある場合は、テーブル復元の部分を省略して同じ手順を実行してください。その場合は、keyspaceを再作成し、sstableloaderを使用してデータをロードします。

sstableloaderはバックアップから各sstablesを読み込み、クラスタに定義されたレプリケーション戦略に従ってデータを配置しながらストリーミングするため、ソースとターゲットのクラスタ間でノード数が異なっていても問題ありません。

ご質問やコメントがある場合は、フィードバックタブからお気軽にお寄せください。

専門家による管理・運用で環境を最適化

Rackspaceのアプリケーションサービス(RAS)のエキスパートは、幅広いアプリケーションポートフォリオにわたって、以下のようなプロフェッショナルサービスおよびマネージドサービスを提供しています。

• eコマースおよびデジタルエクスペリエンスプラットフォーム
• エンタープライズ・リソース・プランニング（ERP）
• ビジネスインテリジェンス（BI）
• Salesforce顧客関係管理（CRM）
• データベース
• メールホスティングおよび生産性向上ツール

私たちが提供する価値：

• 偏りのない専門知識：即座に価値をもたらす機能に焦点を当て、モダナイゼーションの旅をシンプルにガイドします。
• ファナティカルな体験（Fanatical Experience™）：「プロセスファースト、テクノロジーセカンド®」のアプローチと専任の技術サポートを組み合わせ、包括的なソリューションを提供します。
• 比類のないポートフォリオ：豊富なクラウド経験を活かし、適切なテクノロジーを適切なクラウド上に選定・導入するお手伝いをします。
• アジャイルなデリバリー：お客様の旅のどの段階においてもお客様のもとへ伺い、私たちの成功をお客様の成功と一致させます。

まずは今すぐチャットでお問い合わせください。