サーバー移行時のDB複製はビュー索引に注意

この間、せりあさんのお誘いで徒然草の関さん、うちのグループの村上さんと4人で飲む機会がありました。せりあさんの抱えている案件の相談が本来の趣旨でしたが、せりあさんの底が見えぬ好奇心・知識・ノーツへの想いを軸に、会話は様々な展開を見せ、相談に乗るはずが、逆に僕がいろいろと示唆・刺激をもらってしまいました。

その中の１つが、「僕らが当たり前に思っていることはサービスの現場には伝わっていない」 という事。メーカーとして情報は出しているのですが、英語だったり、リンクの深いところにあったり、うまく検索しないと探せなかったりで、ちょっと考えると現状では確かに伝わるのは難しいなと思います。現場では、ノーツ専門のSEがサービスに入る事ばかりでなく、コスト・時間・要員の関係上、今そこにいる人間でなんとかしようとしてしまうことがあり、そういうケースではなおさらです。

そんな話を考えていると、今、僕が相談を受けているトラブルもそんなものの１つかもしれません。

トラブルの現象は、メールサーバーをバージョンアップして新H/Wに移行したら、移行当日にメールDBを開くのに20分位かかってしまうようになったというもの。相談を受けた時に、メールDBを新サーバーに移行する時にレプリカで移行したという事を聞いて、これはビュー索引のせいだなと真っ先に思いつきました。、レプリカではビュー索引は対象とならないのです。こういう状態で新サーバーにユーザーがアクセスしてくると、まず受信ボックスのビュー索引が自動的に作成される事になるのですが、この処理自体が重く、且つ、複数ユーザー分重なってきますから、なかなか受信ボックスが開かないという事になるのです。

従って、ユーザーに開放する前にビュー索引を予め作っておく必要があります。コンソールコマンド"load updall mail\ -C"を実行すると、まだ索引が作成されていない全てのビューに対して索引を作ってくれます。しかし、普段使わないビューが沢山ありますので、"load updall mail\ -T $Inbox -C"のように、使うビューだけを指定してディスク容量を節約するという事をできればやりたいものです。

このような情報をノーツが専門でない人達に伝えるのはなかなか難しいですね。しかし、必要な人に必要な情報を必要なだけ伝えるという事をもっと考えていかなければなりません。また、メーカー→BP様・お客様という情報の流れ以外にも、ノウハウ系の情報であれば、Wikiのような仕組みでノーツ業界全体でシェアするとか、メーカー提供の情報に対してフィードバックできるような仕組みを用意して情報をブラッシュアップしていくとか、そうやって集まった知識・ノウハウを書籍化するとか、そんな"Wisdom of crowds"のパワーを活用する事が頭の中では思い浮かぶのですが、言うは易し、ですねぇ。