ルータ(mongos)経由で 各mongodの「local」データベースを参照するには

[exabugs]

MongoDB JPコミュニティの皆様 

いつもお世話になっております。櫻井と申します。よろしくお願いいたします。 

Mongoシェルから「local」データベースのあるコレクションを見る処理を作成しています。(具体的には oplog.rs コレクション)

シャーディングの必要性から、ルータ(mongos) を使うことになったのですが、

mongos 経由で、各mongodの「local」データベースを参照することはできませんでしょうか？

(つまり「シャーディング環境で、oplogを参照(トリガーと)して、(シャーディングされたコレクションの)データを更新する」を行いたいです。)

以下、できない感じも漂っています。

https://github.com/mongodb/mongo/commit/dcd5c777b7baa2c12636272372a8a1de669ad7c6

皆様方のお知恵、代替案をお借りできればと思います。

何卒よろしくお願いいたします。

[Shoken Fujisaki]

藤崎です。

代替案無く情報だけで恐縮ですが、本家メーリスでmongos経由ではアクセスできないという情報がありました。
https://groups.google.com/forum/#!topic/mongodb-user/rzxoAl03SgQ

質問文から、シャーディング + レプリカセット環境と想定していますが、もう少しやりたいことの意図や背景がわかると代替案が出てくるかもしれません。

まだ全体が理解できてないので的外れかもしれませんが、oplogはオペレーション自身なのでアプリ側でハンドリングできる可能性もあります。
# それができないことが背景にあって質問されたのでしたらすみません。

--
藤崎 祥見（フジサキ ショウケン）

> --
> このメールは Google グループのグループ「MongoDB JP」に登録しているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには mongodb-jp+...@googlegroups.com (mailto:mongodb-jp+...@googlegroups.com) にメールを送信してください。
> このグループに投稿するには mongo...@googlegroups.com (mailto:mongo...@googlegroups.com) にメールを送信してください。
> http://groups.google.com/group/mongodb-jp からこのグループにアクセスしてください。
> その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

[exabugs]

藤崎様

早速のご回答有難うございます。

なるほど、本家MLでは「The oplog cannot be accessed via a mongos instance. 」ですね。。

ご指摘の通り、最終構成はシャーディング + レプリカセット環境 を想定しています。

以前、このMLで相談させて頂きました、「検索のための非正規化項目の更新」を、OpLogをトリガとしてMongoシェルで実装しています。

https://groups.google.com/forum/#!topic/mongodb-jp/Cuup31pV5Qw

非シャーディング 環境では、OpLog / 参照先コレクション / 参照元コレクションが全て同一のmongodに存在していますので、

特に問題なく、OpLogでトリガして参照先の値を参照元にコピーしていました。

参照先コレクション or 参照元コレクションがシャーディングされていると、OpLogをトリガしているmongod上に実態が存在していない可能性があり、

そのため、mongos を通じて OpLog / 参照先コレクション / 参照元コレクション を一元的に扱いたいと思った次第です。

今までは、なるべくアプリに依存しないよう、Mongoシェルだけで実装することを考えていましたが、

アプリとMongoシェルの中間のプログラムで(mongod と mongos の両方に接続して) 処理させてみようと考えています。

ありがとうございました。

[Shoken Fujisaki]

櫻井さん

藤崎です。

ああ、すみません。過去の質問があったのですね。見逃していました。

mongosにはconfig.changelogというcapped collectionがありますが、こちらは使えませんか？
http://docs.mongodb.org/manual/reference/config-database/#config.changelog

実際にどのようなデータが入るかまでは未確認ですが、マニュアルを読む限りshardのcollectionへ行われた
変更のメタデータが格納されているようです。

--
藤崎 祥見（フジサキ ショウケン）

[Tetsutaro Watanabe]

藤崎さん、櫻井さん

渡部です。

実際にどのようなデータが入るかまでは未確認ですが、マニュアルを読む限りshardのcollectionへ行われた
変更のメタデータが格納されているようです。

この「変更のメタデータ」は、シャーディング環境構成情報であり、例えば、どのコレクションがどのキーでシャードされているか？どのチャンクがどのシャードにあるか？といったものです。

ユーザデータに関する情報は持っていません。

今回 ユーザデータに対する変更をトリガを実現したいという要件だと思いますので、残念ながら使えないと思います。

[Shoken Fujisaki]

渡部さん、櫻井さん

藤崎です。

渡部さんの言う通りでした。ソースコードから、config.changelogはシャードに関する変更イベントを
格納することを確認しました。
config.changelogのwhatフィールドに具体的なイベント名が入ります。
- shardCollection.start
- movePrimary.start
- moveChunk.start
- merge
など
mongo/src/mongo/s/config.cppのlogChangeメソッドで更新していました。
https://github.com/mongodb/mongo/blob/master/src/mongo/s/config.cpp#L1183

なので、櫻井さんの要件にはあわなさそうです。

渡部さん、ご指摘ありがとうございました！

--
藤崎 祥見（フジサキ ショウケン）

[Hiroaki Kubota]

窪田です。

シャーディングの前提（というか分散処理の哲学の話）になりますが
スループットに関わるようなデータを集約するような機構はそれ自体がボトルネックです。
よって、シャーディング全体の更新を集約しているようなところは存在しないのです。
（在ってはいけないし、在ったとしても将来取り除かれるべきものです）

つまりシャーディング環境全体のトリガー構造をつくる場合、そのトリガー機構を１箇所に集約するような
設計も間違いなくボトルネックになる（シャーディングを選択するほどのスループットをどうやってさばくのか？）のでやはり間違っています。

レプリカセット毎のトリガーを作るのが正解だと思います。
同時にそのトリガーの結果発行されるクエリーが特定の箇所に集中しないような設計も必要ですね。

2014年7月13日 15:46 Shoken Fujisaki <syo...@gmail.com>:

--
このメールは Google グループのグループ「MongoDB JP」の登録者に送られています。

このグループから退会し、グループからのメールの配信を停止するには mongodb-jp+...@googlegroups.com にメールを送信してください。
このグループに投稿するには、mongo...@googlegroups.com にメールを送信してください。

[Hiroaki Kubota]

追記：
　local DB は admin DBと同じく特殊権限だったはずです。権限的にも共有はありえません。
　またレプリカセットの構成などの情報が入っており、レプリカセット構成が破壊されたときに
　　local DBを削除して・・・のような復旧フローも存在します。
　更にプロファイル等のデータも入ります。やはり共有できません。
　設計上完全にlocal 前提ですね。

2014年7月14日 0:40 Hiroaki Kubota <cat.s...@gmail.com>: