これまで遭遇した、複製に伴うトラブル・データ不整合で、「え、そうなの」と私にとって興味深かった事例を紹介させていただきます。複製を通しアプリケーションDB/文書の特徴について理解を深める手がかりになればと思います。

1. テクてくLotus 技術者夜会 (ザ・アドミン編)
2012年4月20日
複製トラブル
３連発
こんな｢消滅｣｢合体｣｢増殖｣
ありました
阿部 覚
所属：ネオアクシス株式会社

2. 2
このセッションの内容
● 私がこれまで出会った複製に関するトラブルで
興味深い！と思ったものを、単純にご紹介します。
● 複製を通しアプリケーションDB/文書の特徴につい
て理解を深める手がかりになればと思います。
(前回担当時もそうでしたが
今回も開発系にすり寄ったアドミン篇です)

3. 3
トラブルその１１
某企業でのメールバージョンアップにて遭遇

4. 4
トラブルその１１
某大企業でのメールバージョンアップ
その基本方針
● これまでのメールDBはデータごと塩漬け
全員分のDB新しく作ろう！
● サーバーがこけても大丈夫なよう
クラスタ化して２重持ちしよう！

5. 5
トラブルその１１
その構成・・・
● ２台のメールサーバーを
● １台の副サーバーでバックアップ
サーバーA サーバーB
クラスター複製
副サーバー

6. 6
トラブルその１１
運用を始めて数日後、
総務の鈴木花子さんから問合わせが
「心当たりのないメールが
届いているんですけど・・・」？

7. 7
トラブルその１１
○○株式会社 営業部
山田次郎さま
いつもお世話になります。
・・・・・・・・・・
私、総務の鈴木なんですけど？

8. 8
トラブルその１１
● 宛先のミス？
To,Cc,Bccには、
花子さんも 総務グループとかも 含まず
完全に他人から他人へのメール
● 間違って山田さんのDBを開いてるとか？
・・・ユーザー文書のメールDBと合致
● 『山田さん宛』は1通だけではない

9. 9
トラブルその１１
こっちも・・
調査を進めるうちに
「営業の山田さんのメールDBにも、
総務の鈴木さん宛が混じっている」
そこで・・・レプリカIDを見たところ
↓
２人のメールDBのレプリカIDが同じと判明

10. 10
トラブルその１１
山田さんと鈴木さんは
メールサーバーが分かれていました
サーバーA サーバーB
クラスター複
製
副サーバー
山田
さん
鈴木
さん
レプリカIDで
識別しているので
山田さん鈴木さんを
区別せず複製

11. 11
トラブルその１１
● そもそも、新メールDBの作成方法、
プログラムで自動作成だった
● 各メールサーバーごとに、
作成プログラム、起動！
● 社員番号ファイルを読み込んで一括生産！
● 同時間帯に並行で実施

12. 12
トラブルその１１
● 同時進行でメールDBを自動作成していたら
一部のDBで 作成時間が かぶってしまった
＝レプリカIDが かぶってしまった
（レプリカIDは時間帯とDB作成日時(1/100秒単位)で構成）

13. 13
トラブルその１１
おまけのはなし
● ２つのサーバーでタイミングを合わせて
「せーの！」同じレプリカ作れる？
● ＠Text(日時値 ; "＊")
以上、
『合体』篇でした

14. 14
トラブルその２２
ヘルプデスク業務で数例遭遇
実はけっこうよくある事例かもしれません

15. 15
トラブルその２２
「経費決裁申請データベース」について
問い合わせの電話
「作成中で保存したはずの文書が行方不明」
調べてみると、ほかの人の分も含め
ドラフト状態の300文書が
みな、無くなっている

16. 16
トラブルその２２
データベースのプロパティ
「ユーザーの使用状況」を調査すると。。
最近開設された Sapporoサーバーが
300件削除した記録が
削除ユーザー
300 SapporoServer/JP/AACCC

17. 17
トラブルその２２
するとSapporoで誰かが消したの？
Sapporoサーバーの申請DBを見ると...
消えていない
300件とも残っている

18. 18
トラブルその２２
ここで、データベースのACLをチェック
LocalDomainServersとは別に
Tokyoサーバーを「管理者」で登録
問題
なさそう
だけど？
ちょっと
待った

19. 19
トラブルその２２
ここで、データベースのACLをチェック
LocalDomainServersとは別に
Tokyoサーバーを「管理者」で登録
ちょっと
待った

20. 20
トラブルその２２
[Draft]ロールがついていない
このDBでは、
文書作者以外がドラフト文書を見るには
[Draft]ロールが必要

21. 21
トラブルその２２
● 私のイメージ（TokyoとSapporoの複製)
Sapporoサーバー
Tokyoサーバー
ちょっと？
うちのドラフトを
何で持ってく
のっ！
ドドララフフトトドラフト申請
だってあんた
[Draft]ロール
持ってないじゃん
預かっとくよ！

22. 22
トラブルその２２
● 私はこの削除を「没収」と呼んでいます。
● 削除スタブは生成されません。
● どこにも複製のないDBであれば、
サーバーに権限が無くても
削除はおきません。
（没収する相手がいないから
・・・だと思います）

23. 全文書削除というトラブル経験も。
没収！
TokyoサーバーSapporoサーバー
23
うち
丸裸
やわ〜
トラブルその２２
条件は
もう１つ
あります
ドドララフフトトドラフト
XX申請書

24. 24
トラブルその２２
おまけのはなし
● 没収時には定期複製の都度、
「削除」し続ける？
（既に削除済みの分を含め）
● グー チョキ パー の関係なら
「没収」の”たらい回し”ができるかも？？
以上、
『消滅』篇でした

25. 25
トラブルその３３
自分が作ったデータベースにて遭遇
原因は、その作り方にありました

26. 26
トラブルその３３
A社では、
子会社のアドレス帳を
２次アドレス帳として１つにまとめることに。
B社の
アドレス
帳
C社の
アドレス
帳
D社の
アドレス
帳
グループの
アドレス帳
１日１回
バッチで
取り込み

27. 27
トラブルその３３
取り込み方
ユーザー文書に
変更があったら
1.旧を削除
2.新をコピー
3.情報付加して
保存
B社のアドレス帳
Mari Sasaki 新
Mari Sasaki 旧
グループのアドレス帳

28. 28
トラブルその３３
取り込み方
ユーザー文書に
変更があったら
1.旧を削除
2.新をコピー
3.情報付加して
保存
B社のアドレス帳
Mari Sasaki 新
Mari Sasaki 新
グループのアドレス帳

29. 29
トラブルその３３
しばらくは順調に運用
ある日からバックアップサーバーに
定期複製されることに
この日から問題が発生

30. 30
トラブルその３３
定期複製の度に、競合文書が増殖・・・
バックアップサーバー本サーバー
Mari Sasaki
◇競合文書
Taro Suzuki
◇競合文書
◇競合文書
Hiromi Saito
Goro Morita
◇競合文書
Mari Sasaki
◇競合文書
Taro Suzuki
◇競合文書
Hiromi Saito
Goro Morita
◇競合文書
◇競合文書
グループの
アドレス帳
グループの
アドレス帳

31. 31
トラブルその３３
取り込み方
ユーザー文書に
変更があったら
1.旧を削除
2.新をコピー
3.情報付加して
保存
B社のアドレス帳
Mari Sasaki 新
Mari Sasaki 旧Mari Sasaki 新
グループのアドレス帳
もう一度

32. 32
トラブルその３３
B社のアドレス帳
Mari Sasaki 新
Mari Sasaki 旧Mari Sasaki 新
グループのアドレス帳
実は、
削除した旧文書と
追加した新文書は
同じ文書IDに
なります。

33. 33
トラブルその３３
● 競合の原因・・・
バックアップサーバー本サーバー
グループの
アドレス帳
Mari Sasaki
更新履歴
（$Revisionsと 最終更新日時)
2010/01/01
2011/02/02
2012/03/03
2012/04/10
2012/04/11
Mari Sasaki
更新履歴
（$Revisionsと 最終更新日時)
2010/01/01
2011/02/02
子会社で
更新
2012/03/03
2012/03/04
子会社で
更新
前回取り込みで
保存今回取り込みで
保存
グループの
アドレス帳

34. 34
トラブルその３３
● この競合の特徴
バックアップサーバーでは
一切の更新保存なし
本サーバー側の「ひとり相撲競合」
● 対策
取込みプログラムでのコピー方法変更

35. 35
トラブルその３３
関連情報
（参考）CopyToDatabase メソッドでコピーされた文書が
元文書から UNID を再利用していることについて
http://www-01.ibm.com/support/docview.wss?
uid=swg21464770
以上、
『増殖』篇でした

36. 36
ご清聴
ありがとうございました。
これで私は
２回講師しました。
次は
たぶん あなたたちの番です！