データベースのバックアップおよびリストア

データを保護するには、TimesTen Scaleoutのバックアップおよびリストア機能が必要不可欠です。潜在的なデータ損失のリスクを最小化するために、定期的なバックアップを実行することをお薦めします。データベースのバックアップを実行すると、TimesTen Scaleoutによって、各レプリカ・セット上で非同期的にバックアップが実行され、バックアップされる各レプリカ・セットのサブコレクションが作成されます。

TimesTen Scaleoutデータベースのバックアップおよびリストアを検討するときには、次のことに注意してください。

• 現在のグリッド・トポロジのサイズは、データベース・バックアップのグリッドからのトポロジ以上である必要があります。現在のグリッド・トポロジの大きさがn個のレプリカ・セットに十分でない場合は、TimesTen Scaleoutでエラー・メッセージが表示されます。つまり、3個のレプリカ・セットを含むデータベースをバックアップし、レプリカ・セットが2個のみのデータベースにリストアすると、操作が失敗します。ただし、TimesTen Scaleoutのエクスポート機能とインポート機能を使用すると、データベースをレプリカ・セットが多いグリッド・トポロジからレプリカ・セットが少ないグリッド・トポロジのデータベースにインポートできます。「データベースのエクスポートおよびインポート」を参照してください。

• 同じグリッド・トポロジのグリッドにバックアップをリストアでき、そのグリッドがバックアップの作成元と同じグリッドの場合も同様です。つまり、3個のレプリカ・セットがあるデータベースのバックアップを作成した場合は、3個のレプリカ・セットがある同じグリッドまたは新しいグリッドにリストアできます。

• バックアップは、バックアップが作成されたグリッドよりもトポロジが大きいグリッドにリストアできます。n個のレプリカ・セットがあるデータベースをバックアップした場合、そのリストア操作では、同じn個のレプリカ・セットがあるデータベースが作成されます。ただし、現在のグリッド・トポロジが元のグリッド・トポロジより大きい場合、TimesTen Scaleoutでは、追加要素が作成されますが、これらの要素はデータベースの分散マップに追加されず、データはこれらの要素に格納されません。かわりに、リストアでは、元のグリッド・トポロジと同じ数のレプリカ・セットが移入されるのみとなります。つまり、3個のレプリカ・セットがあるデータベースのバックアップを作成した場合は、バックアップを4個のレプリカ・セットがある新しいグリッドにリストアできます。ただし、リストアでは、4個のレプリカ・セットのうち3個が移入されるのみとなります。このため、すべてのレプリカ・セットに移入するには、ttGridAdmin dbDistributeコマンドを使用して、リストア後にすべてのレプリカ・セット間でデータを再分散する必要があります。「データベース内のデータの再分散」を参照してください。

• バックアップには、通常とステージングの2つのタイプがあります。

  • 通常のバックアップは、グリッドの各ホストでNFSを使用してマウントされたリポジトリまたはグリッドの各ホストがSSH/SCPを使用して接続しているリポジトリで実行できます。通常のバックアップの作成に要する時間はデータベースのサイズによって異なりますが、どのバックアップもほぼ同じ所要時間で完了することが予想されます。

  • ステージング・バックアップは、グリッドの各ホストがSSH/SCPを使用して接続しているリポジトリでのみ実行できます。最初のステージング・バックアップの完了には通常のバックアップとほぼ同じ時間がかかる(またはネットワークのパフォーマンスによってはさらに時間がかかる)可能性がありますが、後続のすべてのステージング・バックアップの完了にはその時間のわずかしかかかりません。ステージング・バックアップは、メイン・サイトに依存しない2番目のサイトで定期的なバックアップを作成する場合に最適です。

  各バックアップ操作に必要なファイル・システム領域の詳細は、「バックアップまたはエクスポートのサイズの決定」を参照してください。

ノート:

データをリストアするデータベースが、別のメジャー・リリースなど、パッチの互換性がないバージョンのTimesTen Scaleoutのものである場合は、データベースをバックアップおよびリストアできません。かわりに、そのデータベースをエクスポートしてインポートする必要があります。「データベースのエクスポートおよびインポート」を参照してください。

TimesTen Scaleoutを使用すると、バックアップに関する次の手順を実行できます。

• データベースのバックアップ

• リモート・リポジトリへのデータベースのバックアップ(WAN対応)

• バックアップのステータスの確認

• バックアップの削除

• データベースのリストア

• リストアのステータスの確認

• キャッシュ資格証明の設定

データベースのバックアップ

定期的なバックアップでは、潜在的なデータ損失のリスクが最小限に抑えられます。データベースをバックアップする前に、グリッドのリポジトリが構成済であることを確認してください。「リポジトリの使用」を参照してください。

この例では、データベースdatabase1のバックアップが作成され、リポジトリrepo1にそのバックアップが格納されます。デフォルトでは、バックアップには、現在の日付と時刻に基づいて、Byyyymmddhhssという形式で名前が付けられます。バックアップ名の接頭辞Bは、バックアップを表します。管理インスタンスでttGridAdmin dbBackupコマンドを実行してください。

ノート:

-nameパラメータを追加して、バックアップ名を指定できます。たとえば、ttGridAdmin dbBackup database1 -repository repo1 -name mybackupを実行すると、mybackupという名前のバックアップが作成されます。

% ttGridAdmin dbBackup database1 -repository repo1
dbBackup B20170222145544 started

データベースのサイズ、データベースで使用されているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによってバックアップ時間は異なります。ttGridAdmin dbBackupコマンドは、バックアップ・プロセスを起動するのみで、出力はバックアップが完了したことを示すものではありません。バックアップのステータスを確認するには、ttGridAdmin dbBackupStatusコマンドを使用します。「バックアップのステータスの確認」を参照してください。

ttGridAdmin dbBackupコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベースのバックアップ(dbBackup)を参照してください。

リモート・リポジトリへのデータベースのバックアップ(WAN対応)

SCP方式を使用したリポジトリへの通常のバックアップでは、レプリカ・セットごとに最新のチェックポイントおよびトランザクション・ログ・ファイルのコピーが2つ必要です。一方のコピーは、レプリカ・セットごとに1つの要素のチェックポイントおよびログ・ファイルで構成され、これらはインスタンス・ホームのディレクトリに一時的にコピーされます。2番目のコピーは、リポジトリで送信および格納された、レプリカ・セットごとの同じチェックポイントおよびログ・ファイルで構成され、これらによってバックアップ自体が構成されます。

TimesTen Scaleoutでは、SCPリポジトリへのステージング・バックアップを作成できます。このタイプのバックアップを使用すると、チェックポイントおよびログ・ファイルのローカル・コピーの作成によるオーバーヘッドがなくなり、リポジトリにリモート・コピーを作成するために必要なネットワーク・トラフィックが減少します。これを実現するために、ステージング・バックアップでは、一時的なローカル・ファイル(最新のログ・ファイルを除く)ではなくシンボリック・リンクを使用し、リポジトリ上にステージング・ディレクトリを保持します(最新のバックアップで使用されたレプリカ・セットごとのチェックポイントおよびログ・ファイルを含む)。次のステージング・バックアップでは、各レプリカ・セットから最新のログ・ファイルがコピーされ、ステージング・ディレクトリ内の残りのファイルがネットワークを介して同期されます。最後に、リポジトリでステージング・ディレクトリ内の結果ファイルを使用してバックアップが作成され、データ・インスタンスおよびネットワークからそのタスクの負荷が取り除かれます。

ノート:

• リポジトリをホストするシステムでは、Linuxのcpおよびrsyncコマンドと、TimesTen ttTransferAgentユーティリティを使用してステージング・バックアップ操作が実行されます。ttTransferAgentユーティリティが前回のステージング済バックアップから使用できない場合は、ステージング・バックアップの開始時にステージング・ディレクトリにコピーされます。

• SCPリポジトリの詳細は、「リポジトリの使用」を参照してください。

次の各トピックでは、ステージング・バックアップの推奨設定およびステージング・バックアップの作成方法について説明します。

• 前提条件

• SSH構成ファイル

• BackupFailThreshold属性

• ファイル・システム領域

• WANスループット

• ステージング・バックアップの作成

前提条件

ステージング・バックアップには、次の前提条件があります。

• パスワードなしSSHアクセス: ステージング・バックアップでは、インスタンス(データおよび管理)を持つすべてのホストで、リポジトリをホストするシステムに対してインスタンス管理者がパスワードなしでSSHアクセスできる必要があります。「パスワードなしSSHの設定」を参照してください。

• rsyncコマンド: ステージング・バックアップでは、データ・インスタンスを持つホストおよびリポジトリを割り当てるシステムで、rsyncコマンドを使用できる必要があります。

SSH構成ファイル

ステージング・バックアップは、SSHを使用してデータ転送および制御を行います。データ・インスタンスがあるすべてのホストで、ステージング・バックアップの信頼性を向上させるためにインスタンス管理者のSSH構成ファイル(/home/instance_administrator/.ssh/config)またはグローバルSSH構成ファイル(/etc/ssh/ssh_config)を更新することを検討してください。次のオプションが役に立つことがあります。

• HostName: このオプションを使用して、リポジトリの複数の別名を指定できます。SSHはこれらを順番に試行します。各ホストに異なる順序の複数の別名のリストを指定してください。

• Port: SSHはデフォルトでポート22を使用します。SSHがNATゲートウェイを通過する必要がある場合は、別のポート番号を使用することが必要になることがあります。

• BindAddressまたはBindInterface: これらのオプションを使用して、リポジトリへのアクセスに使用するイーサネット・インタフェースSSHを制御できます。

• ConnectionAttempts: デフォルトでは、SSHは1回のみ接続を試行します。このオプションを使用して、SSHが終了して失敗の通知を返すまでに接続を試行する回数を設定できます。

• ConnectTimeout: デフォルトでは、SSHはシステムTCPタイムアウトを使用します。このオプションを使用して、SSH接続を確立するためのタイムアウト(秒単位)を設定できます。待機時間の長いWANリンクでは、この接続タイムアウトを長くすることを検討してください。

• ProxyJump: このオプションを使用して、リポジトリに接続するためのプロキシとなる要塞ホストを設定できます。データ・インスタンスを持つホストは、リポジトリのような他のホストではなく、要塞ホストにアクセスできる場合があります。同様に、要塞ホストはリモート・リポジトリにアクセスできる場合があります。高可用性を実現するために複数の要塞ホストを構成できます。

• ServerAliveCountMax: このオプションを使用して、ホストがリポジトリからのメッセージを受信しないまま暗号化チャネル経由で送信するキープアライブ・メッセージの最大数を設定できます。このしきい値に達すると、接続は終了します。このオプションは、ServerAliveIntervalオプションとともに使用する必要があります。

• ServerAliveInterval: このオプションを使用して、ホストがリポジトリからのデータを受信しなくなってからキープアライブ・メッセージを送信するまでの時間(秒単位)を設定できます。これは、リポジトリがクラッシュしたり、ネットワークが停止したことを検出するのに役立ちます。

リポジトリをホストしているシステムについて、グローバルSSHデーモン構成ファイル(/etc/ssh/sshd_config)でこのオプションを設定することを検討してください。

• MaxStartups: このオプションを使用して、SSHデーモンへの同時未認証接続の最大数を設定できます。startパラメータをレプリカ・セット数より大きい値に設定し、fullパラメータをstartパラメータの値の10倍にすることを検討してください。たとえば、10個のレプリカ・セットがある場合は、このオプションを次のように設定します。

  MaxStartups 15:30:150

BackupFailThreshold属性

BackupFailThreshold初期接続属性では、バックアップの開始時からLogDirディレクトリに蓄積できるトランザクション・ログ・ファイルの数を決定し、この数を超えると、TimesTenはチェックポイント操作の保留を強制的に解放します。バックアップが完了する前にチェックポイントが開始された場合、バックアップは無効になります。

BackupFailThreshold属性は、バックアップが安全に完了できるように十分大きい値に設定してください。たとえば、バックアップが完了するのに通常はn秒かかり、データベースが1秒にm個のトランザクション・ログ・ファイルを作成する場合は、BackupFailthresholdをn * mより大きい値に設定します。特定の時間単位ごとにデータベースによって生成されるログ・ファイルの数は、書込みワークロードに正比例し、LogFileSize属性に設定された値に反比例します。

初期接続属性の値を変更する方法の詳細は、「データベースの接続属性の変更」を参照してください。

BackupFailThreshold、LogDirおよびLogFileSize接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性を参照してください。

ファイル・システム領域

ステージング・バックアップによる領域不足エラーを回避するために、次のことを確認します。

• 各データ・インスタンスで使用されるファイル・システムには、インスタンス・ホームの1つのトランザクション・ログ・ファイル用の十分な領域(LogFileSize)と、バックアップ操作の進行中に生成される可能性があるすべてのトランザクション・ログ・ファイルをLogDirに格納するのに十分な領域(BackupFailThreshold * LogFileSize)があること。

• リポジトリで使用されるファイル・システムに、保持する数のバックアップの格納に十分な領域と、同じデータベースのステージング・バックアップすべてについてステージング・ディレクトリに1.25バックアップ用の十分な領域があること。

  各バックアップ操作に必要なファイル・システム領域の詳細は、「バックアップまたはエクスポートのサイズの決定」を参照してください。

LogFileSize、LogDirおよびBackupFailThreshold接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性を参照してください。

WANスループット

後続のステージング・バックアップに必要な最小限のWANスループットは、データベースの集計サイズ、バックアップに必要な時間およびステージング・リポジトリと定義済の転送圧縮で示される高速化要因によって異なります。一連のステージング・バックアップを実行して、ネットワークと設定全体のパフォーマンスにより(さらに、通常のバックアップよりも後続のステージング・バックアップのほうが本質的に利点があるため)、通常のワークロード条件下で定期的なステージング・バックアップのバックアップ時間がどれだけ短縮されるかをテストする必要があります。次の式について考えてみます。

Minimum WAN throughput = file size of a backup/(desired backup time * (first staged backup time/average subsequent staged backups time))

各バックアップ操作に必要なファイル・システム領域の詳細は、「バックアップまたはエクスポートのサイズの決定」を参照してください。

ステージング・バックアップの作成

次の例では、database1データベースのstgbackup1という名前のステージング・バックアップが作成され、scprepo1リポジトリにそのバックアップが格納されます。ステージング・バックアップは、秒当たり62 MBの集約ネットワーク・トラフィックと、そのネットワーク・トラフィックの圧縮レベル9を使用するように設定されます。

% ttGridAdmin dbBackup database1 -repository scprepo1 -name stgbackup1 -backupType staged -bwlimit 62 -compression 9
dbBackup stgbackup1 started

ノート:

アクティブ管理インスタンスでインスタンス管理者としてttGridAdmin dbBackupコマンドを実行していることを確認してください。

データベースのサイズ、データベースで使用されているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによってバックアップ時間は異なります。ttGridAdmin dbBackupコマンドは、バックアップ・プロセスを起動するのみで、出力はバックアップが完了したことを示すものではありません。バックアップのステータスを確認するには、ttGridAdmin dbBackupStatusコマンドを使用します。「バックアップのステータスの確認」を参照してください。

ttGridAdmin dbBackupコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベースのバックアップ(dbBackup)を参照してください。

バックアップのステータスの確認

ttGridAdmin dbBackupStatusコマンドを使用すると、特定のデータベースのすべてのバックアップ・プロセスの進行状況を表示できます。

次の例では、データベースdatabase1のすべてのバックアップ・プロセスのステータスが表示されます。

% ttGridAdmin dbBackupStatus database1
Database  Backup          Repository Host  Instance  Elem State     Started       Finished
--------- --------------- ---------- ----- --------- ---- --------- ------------- --------
database1 B20170222145544 repo1                           Completed 2017-02-22... Y
                                     host3 instance1    1 Complete
                                     host6 instance1    3 Complete

ttGridAdmin dbBackupStatusの出力で、バックアップ・プロセス全体の状態がCompletedとしてマークされていることを確認してください。状態の値がFailedと表示される場合は、次のタスクを実行します。

• ttGridAdmin dbStatus database1 -detailsコマンドを使用して、その要素のホストおよびインスタンスが稼働していることを確認します。各レプリカ・セットの1つ以上のホストが稼働中である場合は、ttGridAdmin dbBackupコマンドは、データベースの全体バックアップを作成できます。『Oracle TimesTen In-Memory Databaseリファレンス』のデータベースのステータスの監視(dbStatus)を参照してください。

• バックアップを作成しようとしているリポジトリに、データベースのバックアップの作成に十分な空きファイル・システム領域があることを確認してください。

バックアップが失敗した場合は、異なるバックアップ名を使用して、別のバックアップを実行することもできます。新しいバックアップ名でもバックアップが正常に実行されない場合は、問題を診断し、必要な修正を実行します。問題を解決した後、ttGridAdmin dbBackupDeleteを使用して、失敗したバックアップを削除します。TimesTen Scaleoutでは、失敗したバックアップは自動的には削除されません。次に、ttGridAdmin dbBackupコマンドを使用して新しいバックアップを開始します。使用可能なファイル・システム領域に応じて、次のコマンドを任意の順序で使用できます。「バックアップの削除」および「データベースのバックアップ」を参照してください。

ttGridAdmin dbBackupStatusコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベース・バックアップのステータスの表示(dbBackupStatus)を参照してください。

バックアップの削除

TimesTen Scaleoutでは、バックアップは自動的には削除されません。失敗したバックアップまたは古いバックアップがあるバックアップを削除するか、ファイル・システム領域を解放できる場合があります。

ttGridAdmin repositoryList -contentsコマンドを使用して、使用可能なバックアップとそれらに対応するリポジトリのすべてを表示します。「リポジトリおよびコレクションのリスト」を参照してください。

次の例では、リポジトリrepo1からB20170222145544という名前のバックアップを削除します。

% ttGridAdmin dbBackupDelete -repository repo1 -name B20170222145544
Backup B20170222145544 deleted

TimesTen Scaleoutでは、バックアップに含まれるコレクションおよびすべてのサブコレクションが削除されます。

ttGridAdmin dbBackupDeleteコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベース・バックアップの削除(dbBackupDelete)を参照してください。

データベースのリストア

データベースをリストアする前に、次の点を考慮してください。

• データベースのリストアを実行する場合は、データベース定義名が他のデータベースで使用中でない必要があります。たとえば、別のデータベースでdatabase1という名前が使用されている場合は、リストアしたデータベースにdatabase1にという名前を付けることはできません。

• バックアップされたデータベースのデータベース定義は、リストアするデータベースのデータベース名と一致している必要はありません。たとえば、payrollデータベースのバックアップをnew_payrollデータベース定義にリストアできます。

• バックアップしたデータベースのK-safety値はリストア・データベースのK-safety値と一致している必要はありません。

• データベース定義には、少なくともバックアップされたデータベースのデータベース定義と同じ数の接続が必要です。

次の例では、リポジトリrepo1のバックアップB20170222145544からデータベースres_db1をリストアします。管理インスタンスでttGridAdmin dbRestoreコマンドを実行してください。

% ttGridAdmin dbRestore res_db1 -repository repo1 -name B20170222145544
dbRestore B20170222145544 started

ノート:

リストアを実行する前に、res_db1データベース定義が存在することを確認してください。このデータベース定義からデータベースを作成する必要はありません。「データベース定義の作成」を参照してください。

リストア時間は、バックアップのサイズ、データベースが使用しているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによって異なります。ttGridAdmin dbRestoreコマンドはリストア・プロセスを起動するのみで、出力はリストアが完了したことを示すものではありません。リストア・プロセスは、各要素に対して非同期的に実行されます。リストアのステータスを確認するには、ttGridAdmin dbRestoreStatusコマンドを使用します。「リストアのステータスの確認」を参照してください。

ttGridAdmin dbRestoreコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベースのリストア(dbRestore)を参照してください。

リストアのステータスの確認

ttGridAdmin dbRestoreStatusコマンドを使用すると、特定のデータベースのリストア・プロセスの進行状況を表示できます。

次の例では、データベースres_db1のすべてのリストア・プロセスのステータスが表示されます。

% ttGridAdmin dbRestoreStatus res_db1
Database Restore Repository Host  Instance  Elem State                     Started       Finished
-------- ------- ---------- ----- --------- ---- ------------------------- ------------- –-------
res_db1  mybkup  repo1                           Restore_Finale_Complete   2017-03-03... Y
                            host3 instance1      Restore_Instance_Complete
                            host4 instance1      Restore_Instance_Complete
                            host5 instance1      Restore_Instance_Complete
                            host6 instance1      Restore_Instance_Complete
                            host7 instance1      Restore_Instance_Complete
                            host8 instance1      Restore_Finale_Complete

ttGridAdmin dbRestoreStatusの出力で、グリッドの各要素のリストアが完了していることを確認してください。データベース名のある行のState列がCompletedとしてマークされている場合、リストア操作は完全に完了しています。

ttGridAdmin dbRestoreStatusの出力で、リストア・プロセス全体の状態がCompletedとしてマークされていることを確認してください。ある要素の状態の値がFailedかRestore_Instance_Failedである場合、または全体的な状態がRestore_Finale_FailedかRestore_Init_Failedである場合は、ttGridAdmin dbCloseおよびttGridAdmin dbUnloadの各コマンドを使用してデータベースを停止します。データベースを停止した後、ttGridAdmin dbDestroyコマンドを使用して、正常にリストアされなかったデータベースを削除します。次に、リストア操作を再試行してください。「メモリーからのデータベースのアンロード」および「データベースの破棄」を参照してください。

ttGridAdmin dbRestoreStatusコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベース・リストアのステータスの表示(dbRestoreStatus)を参照してください。

キャッシュ資格証明の設定

キャッシュ・グループを含むデータベース・バックアップをリストアした後、ttGridAdmin dbCacheCredentialSetコマンドを使用して、データベースのOracleキャッシュ管理ユーザー名とパスワードを設定する必要があります。

キャッシュ資格証明を設定した後にのみ、ttGridAdmin dbDistributeコマンドを使用してすべてのレプリカ・セットにデータを再分散できます。キャッシュ資格証明を設定する前にデータを再分散すると、キャッシュ・グループのキャッシュ資格証明を設定できません。

次の例では、リストアされたデータベースのキャッシュ管理ユーザーの名前およびパスワードを設定します。その後、データの再分散を要求します。

% ttGridAdmin dbCacheCredentialSet res_db1
Provide Oracle user id: cacheadmin
Provide Oracle password: orapwd
Configuring cache.....................................................OK

% ttGridAdmin dbDistribute res_db1 -apply

「TimesTenデータベースでのキャッシュ管理ユーザーの名前およびパスワードの登録」を参照してください。