R5 からの機能で、スタンダードになりつつあるものに「トランザクションログ」というものがあります。
ドミノも一種のデーターベースであるわけなのですが、リレーショナル･データベースで存在するようなレコードの変更を記録するようなメカニズムがありませんでした。
リレーショナル･データベースの場合、このメカニズムによってデータの整合性をチェックし、バックアップの取得を正しく整合性の取れた状態で行い、障害時には整合性の取れた状態に戻す(Roll
Back/Roll Forward)、といったようなことを行っています。
ドミノには R5 になるまでこの機能がなかったわけですね。
リレーショナル･データベースではもうこの機能は使用しないことはありえないくらいのものです。
ドミノも、今までの分散での使用から、大きめなサーバーでの集約型での使用へと、運用形態も変わってきています。
特にこのサイトで話題にしている iSeries での稼動ということを考えれば、必ず設定しておきたい機能です。
まずは、トランザクションログを有効にするやり方を見てみましょう。
とりあえずの設定としては、一番上の「トランザクションログ」を「有効」にするだけで OK です。
「ログのパス」は設定をしないと、サーバーのデータディレクトリの下に logdir というサブディレクトリが作成され、そこにログが置かれます。
「最大ログ領域」は指定をしない場合の設定は「R5 システム管理ヘルプ」に以下の記述があります。
トランザクションログの最大サイズ（MB）です。デフォルトは、192MB で、最大サイズは 4096MB（4GB）です。
少なくとも 1028MB（1GB）以上の容量を持つ個別のディスクをトランザクション用に割り当てなければなりません。
ドミノは、ログ用に指定したディスク容量によって、３〜 64 のログファイルをフォーマットします。
この「最大ログ領域」の値は「ログ形式」に「循環」を指定した時のみ有効です。「アーカイブ」が指定されている時は、この値は無視されます。
また、ここに書いてあるように、理想的には「少なくとも 1028MB（1GB）以上の容量を持つ個別のディスクをトランザクション用に割り当て」る必要があるわけなので、ユーザーASPを作って、別のディスクにログを置くのが「正しい」構成とは言えます。
ただ、データベースのジャーナルでも実際には同一のディスクに置いていることもあるように、次善の策として同一のASPに置く、というのでもいいのではないかと思います。まったくやらないよりはいいでしょう。
ちなみに、別のディスクにログを置くためには、UDFS(ユーザー定義ファイルシステム)を別のディスクに作成して、それをマウントする、というやり方で別のユーザーASP用のディレクトリを作成して、それを「ログのパス」に指定するかたちになります。
今のところ、ちょっと環境がないのでお見せできませんが、そんなに難しい作業ではありません。ただ、ユーザーASPは、最初からそういう構成であるか、そのためにディスクを追加するか、といったような状況でなくてはちょっと難しいですが。
「ログ形式」ですが、とりあえず「循環」ではじめればいいと思います。「アーカイブ」については、後でまた説明したいと思います。
これだけ指定して、サーバーを再起動するだけで OK です。
最初の起動はログの作成などで、若干時間がかかりますので、注意してください。
以下のように、"Please wait, creating new transaction logs in directory: /Lotus/Domino/STDomino/logdir/"というメッセージが出て若干時間がかかります。
しばらくしてから "Recover Manager: Assigning new DBIID for ..." と、各データベースに対して DBIID というものを割り当てはじめます。
「アーカイブ」というオプションは BRMS を使用する時に指定してください。
ただし、この時注意していただきたいことがあります。
この「アーカイブ」の時には「最大ログ領域」の値は無視されます。
もともと「循環」の指定の時にある値なので、当然と言えば当然なのですが、これには以下のような理由があります。
「循環」の場合は、「最大ログ領域」の値は最低192MB から 最大 4GB までの指定になります。
トランザクション･ログのためのディスクスペースは、64MB の「ログ･エクステント」という領域に分割されて管理されています。
つまり、最小3 ログ･エクステントから 最大 64 ログ･エクステントになります。
「循環」が指定されている場合は、指定された最大値に達すると一番古いログ･エクステントを再利用していきます。
「アーカイブ」の時のログは、BRMS がバックアップを取るまでログ･エクステントを増やしつづけます。バックアップを取ったところで、やっと一番古いログ･エクステントを再利用するようになっています。
これは SQL Server だって ORACLE だってリレーショナル･データベースでは普通の考え方です。バックアップを取ってもいないうちからログが上書きされていってしまっては
．．．
つまり、BRMS のバックアップのタイミングをまちがえると大変なことになってしまう、ってことです。
一杯になるとどうなるか、については特に記載はありませんが、サーバーの panic
かなにかでのダウンというようなことになりそうですね。
ただし、これは先に述べたようにリカバリーのために使用されるログとしては当然の振る舞いです。
必ず、ディスクが一杯になってサーバーダウンということにならないようにバックアップのスケジュールを立ててください。
BRMS を使用する場合のようにオンラインバックアップや差分バックアップはできませんが、データの整合性と(特に再起動時の)パフォーマンス上のメリットがあります。
循環で得られるメリットに加えて、BRMS を使用してオンラインバックアップや差分バックアップができます。
とりあえず「循環」で始めて、体制ができたところで BRMS+「アーカイブ」に進む、といったところがお勧めです。
トランザクションログを有効にすると、その時にドミノ R5 のデータベースごとに一意のインスタンス
ID（DBIID）が割り当てられるようになっています。
トランザクションのログはこの DBIID と共に記録されるわけです。
復旧を行う際に、データベースと一致するトランザクションを検出するのにこの
DBIID が使われます。
また、以下のような場合に、既存のデータベースにも新しい DBIID が割り当てられます。
以上のように、新しい DBIID がデータベースに割り当てられた後の処理では、ログに記録されたすべての新しいトランザクションは新しい DBIID を使うようになります。
こうしたデータベースでは、古いトランザクションは古い DBIID を持って記録されたままなので、データベースの新しい DBIID とは一致しない状態になってしまうケースがあります。その場合、これらの古い DBIID を持っているトランザクションは、DBIID の不一致のためリストアができない状態になってしまっています。
こうした場合、データが失われないようにするには、新規でバックアップを直ちに実行する必要があります。
新規バックアップをデータベースに対して実行すると、新しいDBIIDが割り当てられる点までのすべてのデータベーストランザクションを検出し、新しい DBIID で整合性のとれた状態にできます。
今後も、新しい DBIID を持った新しいトランザクションだけがデータベースにリストアされます。
DBIID が変更された時はコンソールとログに出力されます。新規バックアップを実行するように一緒にメッセージ (need new backup for media recovery) が出てきます。(下の画面例は新規DBIIDアサイン時のものですが、まったく同じメッセージがでます)
ちなみに別のドミノサーバーからですが、リカバリー時はこんなメッセージができます。
コンソールから以下のコマンドで、トランザクションログ関連の統計情報が確認できます。
sh stat database.rm.*
その他、ドミノのヘルプのトランザクションログにもいろいろな記述がありますので参考にしてください。
こちらの記事も参考になります。
Optimizing server performance: Transaction logging
Making Sense of Transaction Logging
|
|
