Comments
Description
Transcript
Lotus Domino レプリケーション再勉強 事例から知る の複製
® IBM Software Group Software Service Lotus Knows EXPO 2010 IBM ソフトウェア アクセラレイテッド・バリュー・プログラム 活動事例紹介 事例から知る Lotus Domino® の複製 Tips Lotus Domino レプリケーション再勉強 日本アイ・ビー・エム 株式会社 ソフトウェア アクセラレイテッド・バリュー・プログラム 谷垣篤信 IBM Software Group Software Service 特記事項 本資料の記載内容は、できる限り正確を期すよう努めてはおりますが、いかなる明 示または暗黙の保証も責任も負いかねます。 本資料の情報は、使用先の責任において使用されるべきものであることを、あらかじ めご了承ください。 掲載情報は不定期に変更されることもあります。他のメディア等に無断で転載する 事はご遠慮ください。 当資料をコピー等で複製することは、執筆者の承諾なしではできません。 また、当資料に記載された製品名または会社名はそれぞれの各社の商標または登 録商標です。 IBM、IBMロゴ、Lotus、Lotus Notes、Lotus Domino、WebSphereは、International Business Machines Corporationの米国およびその他の国における商標。 Microsoft, Windows, Windows NT および Windowsロゴは Microsoft Corporationの米国およびその他の国における商標。 -2All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service 目次 はじめに Lotus Domino 複製の動作について基本をおさえる ① レプリケーションタスクの仕様について学ぶ ② 複製に重要な文書 ID について学ぶ ③ 文書 ID の例（詳細） ④ 複製時の競合文書のメカニズムを学ぶ ⑤ 複製と文書の削除について 複製に関わるトラブルシューティング ① トラブルシューティング時における重要なポイント ② 複製時に用いることができるデバッグパラメータ ③ サンプルログアウトプット 事例から学ぶ複製に関する注意事項 ① ディレクトリカタログ（DIRCAT）を用いている場合の複製とデータの整合性について ② レプリカデータベース間で ACL が異なる場合の注意事項 -3All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service はじめに Lotus Domino の基本タスクとして必ず実行されているレプリケーションタスクについて Lotus Domino サーバーの管理や運用に携わっている方であれば、その仕様についてある一定のレベ ルまでは理解されているかと思いますが、具体的に文書や設計要素などにおいて何の要素に よって複製されているかを正しく説明できない方も少なくありません。 データベースの複製時の動作を理解しておくことで日常的に発生しうるレプリケーション関連の トラブルシューティングを短時間で解決する上で非常に重要なポイントとなります。 当資料では、レプリカタスクが行う複製の仕様を改めて説明し、また知ってそうで知らない事例 などを交えた Tips を紹介いたします。 -4All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service Lotus Domino 複製の動作について基本をおさえる ① レプリケーションタスクの仕様について学ぶ 複製時の処理シークエンス： レプリカタスクは以下の順番でデータベース間のデータを比較し、差分 のチェックを行ないます ① レプリカの検索： レプリカタスクは複製元のレプリカIDを元に複製先のサーバーに同一のレプリカIDを持った データベースが正しく存在しているかチェックします。 ② 複製履歴の検索： 複製先サーバーに複製対象のレプリカが見つかった場合、複製元のデータベースの複 製の履歴より前回の複製の日時をチェックします。 ③ 複製対象の文書の検索： 複製は前回の複製から差分のみ同期を取ります。そのため、前回の複製日時 以降に更新された文書をここではチェックします。これが複製対象の文書となります。この時複製対象の文 書は UNID リストとして内部的に生成されます。 ④ 複製対象の文書を複製先で検索： 複製元で複製対象文書が UNID リストとして生成されたのち、その 情報を元に複製先のレプリカに対して検索を行ないます。この時、複製先レプリカから OID 情報を受信し ます。 ⑤ 複製対象の判別：データベース間の複製対象データには、新規文書、更新されている文書、削除されて いる文書、競合している文書などに分けることができます。レプリケーションタスクは最終的に、２データベー ス間のデータを上記 ID を用いてこれらを判別し、複製を実行します。 複製対象のデータベース間で、比較が行われ 文書が新規、更新、同一、削除 などの判別が行われる -5All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service Lotus Domino® 複製の動作について基本をおさえる（続き） ② 複製に重要な文書 ID について学ぶ 前述の複製シークエンスでレプリケーションタスクはその複製対象の文書 （データ）を比較する上ですべての文書毎に割り当てられているいくつかの ID をチェックしています ① データベースのレプリカID： データベース固有の識別IDであり、複製時にはこ のIDを用いて統一のデータベースか否かを識別します。 ② UNID （Universal Note ID）：すべての文書に固有の識別子であり､データ ベースのロケーションや日時の情報は含まれません｡ すべてのレプリカ上の同 一文書は､同じ UNID を保持します｡ この識別子は文書を更新しても変化 しません。 ③ OID （Originator ID）：文書のバージョン情報を表す識別子です｡ すべてのレ プリカ上の同一文書は､同じ OID を保持しますが､ 文書が更新されると OID も更新されます｡ ※文書 ID の構成についての詳細については以下 Technote にてご確認いただけます 「文書 ID とはどのように構成されているのか」(Technote #722654) URL → http://www-06.ibm.com/jp/domino04/lotus/support/faqs/faqs.nsf/all/722654 -6- All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service Lotus Domino 複製の動作について基本をおさえる（続き） ③ 文書 ID の例（詳細） 文書のプロパティより各IDと複製時に用いられる動作について説明します： • 文書ID の例 全文書ID OID UNID • • • UNID はすべての文書に割り振られている固有のIDであり、文書の一意性保つために使われ ます。同一文書の場合はレプリカ間でも同じ UNID で持つため、これによってレプリカタスクは 文書のペアをチェックします。 OID は UNID に 8 バイトの Sequence Time と 4 バイトの Sequence Number を加えたIDで す。文書が編集されると、UNID は変わりませんが、Sequence Time および Sequence Number が変わります。Sequence Time は文書が更新された日時を ID に変換したものです。 Sequence Number は文書の更新回数を表します。この値は文書が更新される度に１インク リメントされます。 これら OID をチェックすることで、文書に対して更新されているか競合しているか判断されます。 -7- All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service Lotus Domino 複製の動作について基本をおさえる（続き） ④ 複製時の競合文書のメカニズムを学ぶ レプリカデータベース間で複製を行った場合、競合文書（Conflict Document）が発生する場合が あります。競合文書とは2つの同一 UNID を持った文書が前回の複製日時以降に両文書ともに更 新されており、かつ更新回数も同じである場合に発生します。 この時、どちらの文書が最新のものであるかがわからない状態となり（厳密に文書の勝者/敗者が Domino では判別がつかずマージができない状態）、2つの文書が同時に保存されます。 具体的な動作については以下のとおりです： ① 文書が更新される度に OID の Sequence Time と Sequence Number が更新されます。 ② 更新された Sequence Time は文書の $Revisions フィールドに移されます（レプリカタスクはこのフィールド の値をチェックし、更新日時を確認します） ③ レプリカタスクは複製対象の2つの文書の $Revisions フィールドをを比較し、分岐（差異の発生）が発生し たときの文書の Sequence Number を確認します。 ④ 次に対応するフィールドの Sequence Number を確認し、分岐が発生してから各フィールドが変化していな いかを確認します。 ⑤ もしも、どちらのフィールドも分岐が発生してから編集が行われたものが 1 つでも存在するのであれば、その 文書に対するマージは行えないためその文書は競合文書として扱われます。 ⑥ 競合文書の勝者/敗者の判定： Sequence Number が高い方を勝者とする、または Sequence Number が同じである場合、Sequence Time が最新のものが勝者となります。 ⑦ 敗者の文書は勝者の文書に対する返答文書として複製対象の両レプリカデータベースに互いに保存され ます。 -8All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service Lotus Domino 複製の動作について基本をおさえる（続き） ④ 複製時の競合文書のメカニズムを学ぶ（続き） 以下は文書の OID 内の Sequence Number の違いについて表したものです。 両文書は UNID こそ同じであるペアであることがわかりますが、Sequence Time および Sequence Number が異なっていることがわかります。 この場合、Sequence Number が高い文書②（SN00000003）が勝者となります。 文書① 文書② ACL、設計要素、エージェントの変更には競合文書を作成しません。 これらのメモには、勝者の変更が複製されて、敗者の変更は破棄されます。 -9All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service Lotus Domino 複製の動作について基本をおさえる（続き） ⑤複製と文書の削除について 文書が削除されると、データベースから文書が削除されると同時に削除スタブが生成されます。削除ス タブとは、その文書の削除フラグのようなものであり、文書と同じ UNID を持っています。レプリカタスクはど の文書が削除されたかを判別するために削除スタブの UNID を用います。 ある文書が 1 つのレプリカ上で削除され、別のレプリカでは削除より前に文書が何回か編集されていた 場合、削除が優先されます。 削除された文書は完全に消されるわけではなく "削除スタブ" データとしてデータベースに残ります。これが複製の際に伝 播して、同じ文書IDの文書を削除させ、削除された文書もまた "削除スタブ" に変わり、複製の際に他のサーバーにある複 製データベースに伝播していきます。このように "削除" が複製データベースが伝わっていくため、"削除" が全ての複製デー タベースに伝わるために "ある一定期間" 削除スタブがデータベース内に存在する必要があります。逆に、"削除" が全ての 複製データベースに伝われば "削除スタブ" は必要ありません。 標準設定では削除スタブが残る日数は９０日となっております。（"複製の設定" - "指定日数間に変更がない文書を 削除する。日数" が "90" になっています。） 90日経過した削除スタブは、設定された日数の 1/3 周期、つまり、30日周期で残る日数を超えた “削除スタブ” がない か確認して、その時点で 90日経過した "削除スタブ" をパージ（データベースから取除く）します。ですので、最大で120日 データベースに "削除スタブ" が残ることがあり得ます。 - 10 All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service 複製に関わるトラブルシューティング ① トラブルシューティング時における重要なポイント 複製だけに限ったものではありませんが、何かしらの障害が発生した場合に対するトラブルシューティングを 行う上で、以下のポイントを必ず押させることが短期に解決する上での重要なポイントです。 Symptom • 何が起きているのかの「症状」を出来る限りおさえること Reproducibility • 問題を簡単に再現させることができるか Dependency • 環境（主にクライアント側）に依存して発生有無が異なるか Frequency • 問題発生の頻度はどれぐらいか Trend • 発生のタイミング（時間帯）にパターンはあるか Modification • システムの構成変更、設定変更、アップグレードを直近で行ったか Recording • ログの取得はできているかどうか - 11 All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service 複製に関わるトラブルシューティング（続き） ② 複製時に用いることができるデバッグパラメータ 前頁にて述べたすべての情報を取得している場合でも、問題の解決に至らない場合は、事象が引 き続き発生していることを前提に詳細ログを取得することで解決へのヒントとなります。 レプリケーションとはこれまでの説明のとおり、2つのデータベース、2つの文書、一つ一つとの比較とそ のデータの送受信が主な処理です。以下に記すデバッグパラメータを Lotus Domino サーバーで有 効にすることによってレプリカタスクが行っている比較処理やデータの送受信の動作を詳細に記録す ることができます。 レプリカに関するトラブルシューティングで有効な Notes.ini デバッグパラメータ Notes.ini パラメータ 説明 Log_Replication=3 複製セッションの開始と終了を Notes Log に記録して、コンソールに表示する かどうかを指定します。 パラメータの値は、0 から 5 まで指定できます。この値を設定することによって データベースレベルからフィールドレベルにおけるレプリカ情報を取得することがで きます。3 はデータベース構成要素レベルでのログの複製操作を記録します。 必要に応じて詳細度を上げます。 Debug_Repl_All=2 複製時における各文書（Note）毎の更新時間の比較、更新回数の比較がコ ンソール上に表示されます。 - 12 All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service 複製に関わるトラブルシューティング（続き） ② 複製時に用いることができるデバッグパラメータ（続き） 詳細ログを確認することで、どの UNID を持った文書が何の理由で複製されているか、または複製対象から外さ れているかが確認することができます。 サンプルログアウトプット： レプリカ間で同一UNIDの文 書が存在するかのチェック [06BC:0002-0A6C] 05/16/2006 11:03:05 AM REPLICA: ...Added note to Source list (UNID OF940F9F10:020AD89CON49256D67:003637EA;Note ID 0x109E;Class 0x0001) レプリカ間でどちらの文書が Source DB has newer note/Skipping note in Destination list (con't) Latest note is already in destination 最新かのチェック [06BC:0002-0A6C] 05/16/2006 11:03:05 AM REPLICA: Source DB has newer note (OF940F9F10:020AD89C文書間の SeqNo の比較 ON49256D67:003637EA;SrcNote ID 0x109E;DestNote ID 0x308E;Class 0x0001) [06BC:0002-0A6C] 05/16/2006 11:03:05 AM REPLICA: ... (con't) SrcSeqNo = 4191, DestSeqNo = 4190; SrcSeqTime = 05/16/2006 09:23:20 AM, DestSeqTime = 05/16/2006 08:35:11 AM レプリカ間で同一UNIDの文 書が存在するかのチェック [06BC:0002-0A6C] 05/16/2006 11:03:05 AM REPLICA: ...Added note to Source list (UNID OF8839D2CE:D9BC1A48ON49256E91:00076809;Note ID 0xC062;Class 0x0001) Skipping note in Destination list (con't) Destination has same note or newer. / Skipping note in Destination list レプリカ間でどちらの文書が (con't) Latest note is already in destination 最新かのチェック [06BC:0002-0A6C] 05/16/2006 11:03:05 AM REPLICA: ...Skipping note in Destination list (UNID 文書間の OF8839D2CE:D9BC1A48-ON49256E91:00076809;SrcNote ID 0xC062;DestNote ID 0x2EE2;Class 0x0001)SeqNo の比較 [06BC:0002-0A6C] 05/16/2006 11:03:05 AM REPLICA: ... (con't) Destination has same note or newer. SrcSeqNo = 16, DestSeqNo = 19; SrcSeqTime = 05/16/2006 09:23:00 AM, DestSeqTime = 04/28/2006 05:49:23 PM - 13 All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service 事例から学ぶ複製に関する注意事項 ① ディレクトリカタログ（DIRCAT）を用いてる場合の複製とデータの整合性について サーバー上に複数の一次や二次などの Domino Directory （names.nsf） がある場合、これらディ レクトリはディレクトリカタログタスク（DIRCAT）を用いることで一つの拡張ディレクトリカタログデータ ベースとして集約することができます。 しかし、これら集約された拡張ディレクトリカタログデータベースをさらに他のサーバーに複製して運用 する場合、注意必要が必要です。 • [注意事項１]ディレクトリカタログタスクによって集約処理が実行されると、データソースである Domino Directory から文書の内容およびその ID （OID や UNID （SeqTime や SeqNo 含む））がそのまま引き継が れますが、事前に拡張ディレクトリカタログデータベース側で文書を更新していた場合でも集約処理によって 元の状態に戻されます。ディレクトリカタログの集約化処理は必ずソース Domino Directory 側の文書デー タが勝者となり、集約先のディレクトリカタログデータベース側の文書データは敗者となり上書きとなりますので、 注意が必要です。 • [注意事項２]そのため、編集内容が元に戻るだけではなく、文書の OID も元に戻るため、拡張ディレクトリ カタログデータベースがさらに他サーバー上でも編集がされている場合には競合文書や文書データの不整合 が発生する場合があります。よって、拡張ディレクトリカタログデータベースを他サーバーと複製する場合は、 編集をしてはいけません。 - 14 All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず IBM Software Group Software Service 事例から学ぶ複製に関する注意事項（続き） ② レプリカデータベース間で ACL が異なる場合の注意事項 複製の設定によってはレプリカデータベース間で異なる ACL を持たせることが可能です。 しかし、データベースの ACL の詳細設定にある 「このデータベースのレプリカは全て共通のアクセス 制御リストを用いる」が有効となっている場合はすべてのレプリカ間で ACL が同一である必要があり ますので注意が必要です。 • [注意事項１] ACL の詳細設定 「このデータベースのレプリカは全て共通のアクセス制御リストを用いる」が 有効に鳴っている場合において、複製対象のレプリカデータベースの ACL が互いに異なる ACL になってい る場合、Pull-Push 複製を行ないますと、「レプリケーターのデータベースの複製はエラー。レプリカのアクセス 制御リストを一定に保てないので複製を続けられません。」のエラーが発生し、複製処理がキャンセルされま すので、注意が必要です。 • [注意事項２] Lotus Domino 6.5 以上の Domino Directory において拡張アクセス制御リスト（xACL）を 用いることができます。xACL を有効にした場合、自動的に「このデータベースのレプリカは全て共通のアクセ ス制御リストを用いる」も有効となり、必然的に全サーバーに存在する Domino Directory の ACL が同一 であることが前提となりますので、設定には運用面から十分に検討する必要があります。 - 15 All Rights Reserved, Copyright(c) IBM Software Group 無断複製、転載を禁ず