This page applies to on-premise deployments.

Related pages:

AppDynamicsでは、コントローラのデータバックアップを日常的に行うことを強く推奨しています。

コントローラのバックアップを保持する方法の 1 つとして、高可用性の実装があります。高可用性を利用することで、セカンダリコントローラ上のデータベースでプライマリコントローラ上のデータの複製コピーを保持します。また、セカンダリコントローラは、コントローラの可用性に影響を与えることなく、セカンダリをシャットダウンしてデータをコピーすることができるため、コントローラデータのコールドコピーを取ることが実用的になります。HA の詳細については、「コントローラ高可用性（HA）」を参照してください。 

その他の方法としては、ディスクスナップショットメカニズムの使用や、データベースバックアップツールの使用などが挙げられます。「バックアップツール」のセクションでは、各方法に対応するツールについて説明します。定期的なバックアップに加え、コントローラやEnterprise Consoleをアップグレードするか別のサーバーに移行する場合にも、事前にバックアップを取得します。

このページでは、コントローラのバックアップに関するタスクと考慮事項の概要を説明します。なお、いずれかのインポート機能を実行する際は、その前にコントローラをシャットダウンしておく必要があります。

コントローラバージョン 4.3 以降は、<Controller Home>/.appd.scskeystore ファイルの復元およびバックアップでのみ機能することに注意してください。

バックアップのベストプラクティス

コントローラの完全なバックアップを実行するには、次の 3 つのディレクトリをバックアップする必要があります。

  1. コントローラのインストールディレクトリ
  2. MySQL datadir
  3. Glassfish で使用する JRE ディレクトリ

多くの場合、コントローラのデプロイによって大量のデータが生成されますが、これらのデータを扱うにあたって、毎晩システム全体をバックアップすることは現実的ではありません。バックアップを実行するコストと、データ損失のリスクとのバランスをとるため、一般的なバックアップ戦略では、異なる時間帯に異なる範囲でシステムをバックアップすることが求められます。つまり、部分バックアップを頻繁に実行し、完全バックアップの頻度を抑えることができます。

コントローラのバックアップの範囲は、以下のレベルに分類されます。

  • レベル1: インストール環境のみの簡易バックアップ。
  • レベル 2：ビッグデータテーブルを除き、インストールに関連付けられたすべてのメタデータを対象とするメタデータバックアップ。
  • レベル3: /dataディレクトリのコールドバックアップを実行するか、サードパーティ製のツールを使用してホットバックアップを実行することによるすべてのデータのバックアップ。

考えられるバックアップ戦略としては、レベル1とレベル2のバックアップを非常に頻繁に、たとえば毎晩実行し、レベル1とレベル3のバックアップを週に1回程度実行します。レベル 1 または 2 のバックアップの実行に加えて、定期的に mysqldump を使用して Enterprise Console のデータもバックアップする必要があります。レベル3のバックアップでは、Enterprise Consoleのデータもバックアップされます。詳細については、「Enterprise Consoleのバックアップと復元」を参照してください。

簡易バックアップ（レベル１）

簡易バックアップは、db.cnf や domain.xml といったコントローラの構成ファイルを対象としています。このタイプのバックアップにより、マシンに障害が発生した場合もコントローラを再構成する必要がありません。

このタイプのバックアップを実行するには、データディレクトリを除くコントローラのインストールディレクトリをすべてコピーします。

簡易バックアップを実行する際、特にコントローラのアップグレードを実行する前には、データディレクトリを除くコントローラホーム全体をコピーすることをおすすめしますが、サイト固有の構成ファイルのみをコピーしたい場合もあります。たとえば、既存のコントローラ構成を新しいコントローラインストールに移行する場合などです。これらのファイルのリストについては、「コントローラの移行」を参照してください。   

メタデータバックアップ（レベル2）

メタデータバックアップでは、コントローラがモニタリングする環境をカプセル化したデータをエクスポートします。メタデータには、コントローラがモニタリングするアプリケーション、ビジネストランザクション、ポリシーなどが定義されています。「ランタイムデータ」と見なされるもの、つまりモニタリング環境で生成されたメトリック、スナップショット、イベント、トップサマリー統計（トップSQL、トップURLなど）が含まれるビッグデータテーブルは含まれません。メタデータをバックアップすることで、障害が発生した場合にコントローラでモニタリングしているアプリケーションを再設定する必要がなくなります。

このタイプのバックアップを実行するには：

  1. 「mysqldump を使用したコントローラのバックアップ」に記載されているスクリプトを実行します。
  2. 次のコピーを指定して拡張します。
    1. コントローラ Java キーストア（600 バイトファイル）：<controller install>/.appd.scskeystore

    2. および Enterprise Console キーストア：platform-admin/.appd.scs

完全バックアップ（レベル3）

完全バックアップは、コントローラのインストールに関連付けられているランタイムデータをすべて保存します。このバックアップにより、実際のメトリックデータ、スナップショットなどがキャプチャされます。

Percona XtraBackupといった、一部のサードパーティー製バックアップツールはトランザクションに依存しないため、システムのホットバックアップを取得できます（つまり、コントローラのデータベースの実行中にバックアップします）。

完全バックアップは以下のいずれかの方法で実行できます。

  1. 3 つのディレクトリすべて（コントローラのインストールディレクトリ、MySQL datadir、および JRE ディレクトリ）のコールドバックアップ。コールドバックアップを実行するには、コントローラのアプリサーバーとデータベースをシャットダウンします。次に、cp -r コマンド、tar ユーティリティ、rsync などを使用して、3 つのディレクトリのコピーを追加で作成します。  
  2. ホットバックアップ。これは、コントローラが実行中であることを意味します。
    1. コントローラの高可用性設定がある場合は、セカンダリコントローラのデータベースをシャットダウンできます。その後、セカンダリコントローラでコールドバックアップを実行し、データベースを再起動できます。

    2. コントローラの高可用性設定がない場合は、Percona XtraBackup などのサードパーティツールを使用して MySQL datadir をバックアップします。次に、cp -r コマンド、tar ユーティリティ、rsync などを使用してコントローラのインストールディレクトリと JRE ディレクトリをバックアップします。 

      Percona XtraBackup は、ビジー状態のコントローラのホットバックアップに失敗する可能性があります。このエラーを回避するには、次の操作を行います。

      • 代わりにセカンダリコントローラをバックアップする（存在する場合）。
      • MySQL のログサイズを増やす。
      • コントローラがあまりビジー状態でないときにホットバックアップを実行する。

バックアップツール

このセクションでは、コントローラデータのバックアップに使用できるサードパーティ製ツールをいくつか紹介します。ここに記載するツールはほんの一部に過ぎず、コントローラの MySQL データをバックアップができるツールであれば、任意のものを使用して構いません。バックアップと復元のプロセスをテストするかどうかは任意です。ただし、使用するツールはデータをバイナリデータとしてバックアップできる必要があります。  

Linuxシステムの場合：

Windowsシステムの場合：

データベースバックアップツールを使用する代わりに、ディスクスナップショットツールを使用して、コントローラデータが存在するディスクまたはパーティションを複製することもできます。これを実施する際の選択肢は以下のとおりです。

このタイプのバックアップの実行方法に関する詳細は、このドキュメントで扱う範囲を超えるものとなります。詳細については、ご使用のオペレーティングシステムの管理マニュアルを参照してください。

mysqldumpを使用したコントローラのバックアップ

mysqldump ユーティリティは、コントローラの MySQL インスタンスに含まれる MySQL バックアップツールです。

mysqldump は、コントローラのメトリックデータテーブルなどの大規模なデータテーブルでの使用は推奨されていませんが、コントローラのメタデータのバックアップには便利です。メタデータには、アプリケーション、ビジネストランザクション、アラート構成といった、コントローラのモニタリング対象ドメインが定義されています。

以下の手順は、PATH変数にコントローラのMySQLインスタンスのバイナリパスが設定されていることを前提としています。コントローラのMySQLインスタンスへのパスは、システム上の他のMySQLパスより優先される必要があります。これにより、Linuxにデフォルトで組み込まれているMySQLインスタンスといった、マシン上にある他のデータベース管理システムとの競合を防止できます。

コントローラデータベースのデータベース バイナリ ファイルは <controller_home>/db/bin にあります。

mysqldump を使用する前に、まずコントローラのアプリケーションサーバーが停止していることを確認してください。アプリサーバの実行中に mysqldump を実行しようとすると、コントローラのパフォーマンスと安定性が著しく低下します。 

mysqldump を使用するには、mysqldump 実行ファイルを実行し、ルートユーザー名、パスワード、出力ファイルを渡します。実行ファイルは以下のディレクトリにあります。

<controller_home>/db/bin 

コマンドは、次の形式で指定する必要があります。

mysqldump -u root -p<password> <ignore-table_statements> > /tmp/metadata_dump.sql
CODE

メタデータバックアップで除外するテーブルを示した詳しい例については、次のセクションで説明するメタデータバックアップスクリプトの内容を参照してください。

mysqldumpスクリプトのサンプル

以下のスクリプトは、mysqldump を使用して、ランタイムデータテーブルを除外しながらコントローラのメタデータをエクスポートする方法を示しています。 

MySQLのデータディレクトリにカスタムの場所を使用しているコントローラをmysqldumpでバックアップすると、メタデータのダンプが不完全で使用不能なものとなってしまいます。デフォルトでは、コントローラの MySQL のデータディレクトリの場所は appd_install_dir/db/data です。ここにデータディレクトリがなければ、MySQLのデータディレクトリに代わりのディレクトリかマウントポイントを選択して構成していることを意味します。

この問題を修正するには

  1. 次を調査します。<Controller Home>/db/db.cnf
    1. datadir パラメーターを見つけます。これには、コントローラホストのMySQLデータディレクトリへのパスが含まれています。
  2. メタデータのバックアップスクリプトを編集します
    1. $appd_install_dir/db/data を、db.cnf で見つけた datadir パスに置き換えます。

このスクリプトを使用するには

  1. ご使用のオペレーティングシステムに適したバージョンをダウンロードします。
  2. ファイル名から.txt拡張子を削除します。
  3. スクリプトのコメントに記載されている方法でファイルの内容を変更します。 

mysqlを使用したコントローラデータのインポート

コントローラを復元または移行するときに、mysqldump でエクスポートしたデータをインポートできます。

コントローラをシャットダウンしてから、以下のコマンドを使用してデータベースにデータをインポートします。

$install/db/bin/mysql -u controller -p<ControllerDBpassword> < metadata_dump.sql

これによってテーブルが上書きされます。別のホストにインストールの複製を作成し、そこで復元のテストを実施できます。

MySQLデータディレクトリにカスタムの場所を指定してインストールしているコントローラには、追加のフラグが必要になります。

データバックアップスクリプトのサンプル

次のスクリプトは、Percona XtraBackup を使用してコントローラデータをバックアップします。これを使用するには、percona-xtrabackup または xtrabackup および qpress パッケージが必要です。XtraBackup のインストールの詳細については、Percona のインストールドキュメントを参照してください。 

スクリプトを使用するには、以下のファイルをダウンロードします。 

.txt 拡張子を削除してスクリプトの名前を変更します。スクリプト内で以下を行います。

  • スクリプトの先頭にある CONTROLLER_HOME 変数と DESTINATION 変数の値を確認し、ご使用環境に合わせて編集します。
  • バックアップファイルのローテーションを実装する場合は、スクリプトの最後にあるif/then/else句を編集し、エンタープライズのバックアップシステムを呼び出して圧縮したコントローラのデータベースイメージを取得するか、何らかの理由でバックアップが失敗した場合にアラートを送信するようにします。

以下のコマンドは、圧縮したバックアップイメージを復元する方法を示しています。

mkdir /path/to/big/staging/folder

# unpack the compressed backup archive
cd /path/to/big/staging/folder && xbstream -xv < /path/to/backups/dir/controller-yyyymmdd.xbstream
 
# decompress the backup image and apply the log taken during backup
CONTROLLER_HOME=/path/to/AppDynamics/Controller && cd /path/to/big/staging/folder \
&& innobackupex --decompress --parallel=16 . && innobackupex \
--defaults-file=$CONTROLLER_HOME/db/db.cnf --use-memory=1GB --apply-log --parallel=16 .

# Move a prepared backup into an empty controller data directory
CONTROLLER_HOME=/path/to/AppDynamics/Controller && cd /path/to/big/staging/folder \
&& innobackupex --defaults-file=$CONTROLLER_HOME/db/db.cnf --move-back .
BASH

これらのオプションに関する詳細は、Percona の innobackupex Option Reference を参照してください。

バックアップを使用した新規物理サーバーへの移行

ホットバックアップまたはコールドバックアップの手順を使用して、コントローラのデータを新しいサーバーに移行できます。ただし、AppDynamicsではコールドバックアップの実行を推奨しています。ホットバックアップはコントローラを長時間停止させることはありませんが、ホットバックアップの開始時にのみデータの状態をキャプチャするため、データが欠落する可能性が生じます。

コールドバックアップを実行するには、コントローラをシャットダウンし、<controller_home>/db にあるデータディレクトリをバックアップします。