自動起動と自動回復 - 動作方式

stored デーモンは、ほかのメッセージストアプロセスが起動する前に起動します。このデーモンによってメッセージストアデータベースは初期化され、必要に応じて回復処理が行われます。メッセージストアデータベースは、フォルダ、容量制限、購読、およびメッセージフラグの情報を保持します。データベースはログ用とトランザクション用であるので、回復はすでに組み込まれています。また、一部のデータベース情報は、各フォルダのインデックス領域に予備でコピーされています。

データベースは非常に堅固ですが、まれに壊れたとしても、ほとんどの場合は stored によって透過的に回復および修復されます。ただし、stored が再起動された場合は毎回、デフォルトのログファイルをチェックして、ほかに管理操作が必要ないことを確認してください。データベースをさらに修復する必要がある場合は、ログファイルのステータスメッセージで reconstruct を実行するように示されます。

メッセージストアデータベースを開く前に、stored はデータベースの完全性を分析し、ステータスメッセージを warning のカテゴリの下にあるデフォルトログに出力します。メッセージには管理者にとって有用なものも、内部分析に使用されるコード化されたデータで構成されるものもあります。stored によって問題が検出された場合は、データベースの修復が試行され、再起動が試行されます。

データベースが開くと、stored は、ほかのサービスが起動することを合図します。自動修復が失敗した場合、デフォルトログのメッセージで実行するべきアクションが示されます。詳細については、「reconstruct -m が必要であることを示すエラーメッセージ」を参照してください。

以前のリリースでは、stored は非常に長い時間がかかる回復プロセスを開始することがあり、stored が「スタック」したかのように見えることがありました。このタイプの長い回復プロセスは取り除かれ、stored は最終的な状態を 1 分以内に判断するようになりました。ただし、stored がスナップショットからの回復などの回復手段を採用する必要がある場合、プロセスは数分かかる場合があります。

ほとんどの回復プロセスでは通常、終了後のデータベースは最新の状態になっていて、ほかに必要な操作はありません。ただし、一部の回復プロセスでは、reconstruct -m を実行してメッセージストアの冗長データを同期させる必要がある場合もあります。これもデフォルトログに示されます。したがって、起動後にデフォルトログを監視することは重要です。メッセージストアが通常どおり起動し、機能しているように見える場合でも、reconstruct など、要求されている操作がある場合は実行することが重要です。

ログファイルを読むもう 1 つの理由は、データベースに障害を引き起こした原因を確認することです。stored は、システムでの問題の種類にかかわらずメッセージストアを回復するように設計されていますが、データベース障害はより大きな問題が潜んでいることの徴候である可能性があるので、原因を解明することをお勧めします。

reconstruct -m が必要であることを示すエラーメッセージ

ここでは、reconstruct -m の実行が必要なエラーメッセージのタイプについて説明します。

エラーメッセージでメールボックスエラーが示された場合は、reconstruct <mailbox> を実行します。次に例を示します。

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

エラーメッセージでデータベースエラーが示された場合は、reconstruct -m を実行します。次に例を示します。

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

データベーススナップショット

スナップショットは、データベースのホットバックアップであり、壊れたデータベースを数分で透過的に回復するために stored で使用されます。これは、ほかの領域に保存された冗長情報に依存する reconstruct を使用するよりもはるかに速い方法です。

メッセージストアのデータベーススナップショット - 動作方式

データベースのスナップショット (mboxlist ディレクトリ内) は自動的に作成されます。デフォルトでは、24 時間ごとに作成されます。デフォルトでは、スナップショットは store ディレクトリのサブディレクトリにコピーされます。デフォルトでは、常時 5 つのスナップショットが保存されています。ライブデータベースが 1 つ、スナップショットが 3 つ、データベース / 削除済みコピーが 1 つです。データベース / 削除済みコピーはより新しいものであり、mboxlist データベースディレクトリの removed サブディレクトリに入れられたデータベースの非常時用のコピーです。

現在のデータベースに障害があるために回復プロセスで削除することが決定されると、stored がデータベースを removed ディレクトリに移動します (可能な場合)。したがって、必要に応じてそのデータベースを分析できるようになっています。

データの移動は、1 週間に 1 度だけ実行されます。データベースのコピーがすでに移動先に存在する場合、stored はストアが起動するたびごとにはコピーを置き換えません。removed ディレクトリのデータが 1 週間よりも古い場合にのみ置き換えます。これは、元のデータベースが一連の起動によってあまりにも早く置き換えられないようにするためです。

メッセージストアのデータベーススナップショットの間隔と場所を指定するには

データベースとスナップショットを組み合わせるには、5 倍の容量が必要です。スナップショットが別のディスク上で実行されるように再設定し、システムの要件に合わせることを強くお勧めします。

stored によって起動時にデータベースに関する問題が検出された場合は、最善のスナップショットが自動的に回復します。3 つのスナップショット変数を使用して設定できるパラメータは、次のとおりです。スナップショットファイルの場所、スナップショットの作成間隔、保存されるスナップショットの数。表 18–15 に、これらの configutil パラメータを示します。

スナップショットの間隔が短すぎると、システムに頻繁に負荷がかかるとともに、データベースの問題がスナップショットとしてコピーされる可能性が高くなります。スナップショットの間隔が長すぎると、データベースはスナップショットが作成された過去の時点の状態を維持することになります。

スナップショット間隔は 1 日にすることをお勧めします。1 週間またはそれより長い間隔のスナップショットは、システムで問題が数日間解消されない場合に、問題が存在する前の状態に戻すのに便利です。

stored はデータベースの監視を実行し、データベースが完全でない可能性がある場合は最新のスナップショットを拒否する高度な機能があります。代わりに最新のもっとも信頼性の高いスナップショットを取り出します。1 日前のスナップショットが取り出される可能性があることにもかかわらず、システムはより新しい冗長データがある場合はそのデータを使用して古いスナップショットデータを無効にします。

つまり、スナップショットの根本的な役割は、システムを最新の状態に近づけることと、進行中のデータを再構築しようとするシステムのほかの部分の負担を軽減することです。

表 18–15 メッセージストアデータベーススナップショットのパラメータ

パラメータ	説明
local.store.snapshotpath	メッセージストアのデータベーススナップショットファイルの場所です。既存の絶対パスまたは store ディレクトリを基準とする相対パスのいずれかになります。 デフォルト: dbdata/snapshots
local.store.snapshotinterval	スナップショット間隔 (単位: 分) です。有効な値: 1 〜 46080  デフォルト: 1440 (1440 分 = 1 日)
local.store.snapshotdirs	保存される異なるスナップショットの数です。有効な値: 2 〜 367  デフォルト: 3