Oplog入門

第1回 MongoDB ソースコードリーディング

doryokujin

[名前] doryokujin ( 井上 敬浩 )

[年齢] 26歳

[専攻] 数学（統計・確率的アルゴリズム）

[会社] 芸者東京エンターテインメント（GTE）

[職業] データマイニングエンジニア

[趣味] マラソン ( 42.195km: 2時間33分 )

[コミュニティ]

・MongoDB JP: もっとMongoDBを日本に！

・TokyoWebMining: 統計解析・データマイニングの各種方法論、WEB上のデータ活用に関する勉強会

・おしゃれStatistics: 名著「statistics」を読み進めながら統計を学ぶ勉強会 with @isseing333 @dichika

自己紹介

お知らせ(2つ)

[日時] ：2011/07/08（金）18:00 ～ 21:00

[ATND]：http://atnd.org/events/17038

・分散処理技術（NoSQL・分散FS・並列プログラミングモデル・大規模データ処理など…）に関するトピックを毎回取り上げる

・トピックに沿ったスピーカーをお呼びしてそれについての議論を座談会形式で行う勉強会

・机を円に並べて、参加者も含めて議論できるような場に

[内容]：第1回は”NoSQL”（特にスケーラビリティに関する話題を中心に）

・okuyama, HBase, Cassandra, MongoDB, Hibari のスピーカー陣！

第1回分散処理ワークショップ

[日時] ：2011/07/31（金）14:00 ～ 19:00

[ATND]：http://atnd.org/events/17136

[参加者特典]

・参加者にMongoDBノベルティグッズ（たぶんマグカップ）をプレゼント

[内容]

・仕組みや機能の説明

・実際の運用事例 など…

発表者募集中です → Twitter: @doryokujin まで！

第5回MongoDB勉強会～真夏の大Mongo祭り～

1. Replica Set

2. Oplog の役割

アジェンダ

1. Replica Set

Member1Primary

Member2Secondary

Member4Secondary

Sync

SyncSync

Member3Secondary

1. Replica Set

[特徴]

・1 Primary + N Secondary

・自動フェイルオーバー機能

・自動リカバリー機能

・Set メンバーの追加・削除が容易

・Primary - Secondary 間は非同期通信

・Write は Primary のみ・Read は Secondary からも ( “Read Scaling” )

1. Replica Set

[自動フェイルオーバー]

Member1Primary

Member2Secondary

Member4Secondary

Sync

SyncSync

Member3Secondary

1. Current Primary

1. Replica Set

[自動フェイルオーバー]

Member1Primary

Member2Secondary

Member4Secondary

Member3Secondary

2. Primary Down

1. Replica Set

[自動フェイルオーバー]

Member1Primary

Member2Secondary

Member4Secondary

Member3Secondary

3. Election Time

Negotiate Negotiate

Negotiate

1. Replica Set

[自動フェイルオーバー]

Member2Primary

Member4Secondary

Member3Secondary

4. New Primary

SyncSync

primary 選出基準1. priority 値が最大2. primary との最終同期が最新3. votes 値が高い

1. Replica Set

[自動リカバリー]

Member2Primary

Member4Secondary

Member3Secondary

Sync Sync

Member1Secondary

CatchUp & Sync

1. Replica Set

2. Oplog の役割

[Replica Set・フェイルオーバーにまつわる疑問]

・[Replication Process]

どうやってPrimary と Secondaryは同期し合っているのか？

・[Failover Process]

フェイルオーバー時、どうやって最終同期時間を確認するの？

・[Recovery Process]

新しいメンバーや復帰したメンバーはデータをどう同期するの？

2. Oplog の役割

[Oplog]

・データ更新が更新されるオペレーションが実行される時は、その”オペレーション自身”をoplogというコレクションに保存

・oplogさえあれば異なるサーバーでもオペレーションを実行してデータを再現できる

・”データ”ではなく、”オペレーション”を同期しあう事でレプリケーションを行う

2. Oplog の役割

[replication process]

[1] insert, update, delete などデータに変更を加えるオペレーションが行われる

[2] これらのオペレーションは自身のデータベースに書き込まれる。同時に oplog collection に対してもオペレーションが書き込まれる

[3] Replication の secondary 達はこの primary の oplog を tailing している

[4] secondary は自身の oplog collection に変更分をコピーしていく

[5] secondary は実際に自身の oplog のオペレーションを実行する i.e. 同期する

http://www.mongodb.org/display/DOCS/Replica+Sets+-+Oplog

[oplog を見てみる]

1. データに変更を加えるmyset:PRIMARY> db.mycoll.insert({x:1})

myset:PRIMARY> db.mycoll.update({x:1}, {$set : {y:1}})

myset:PRIMARY> db.mycoll.update({x:2}, {$set : {y:1}}, true)

myset:PRIMARY> db.mycoll.remove({x:1})

myset:PRIMARY> db.mycoll.find()

{ "_id" : ObjectId("4def8e5fb07da951204c60e0"), "x" : 1, "y" : 1 }

{ "_id" : ObjectId("4def8e5fd60f868d9ea77776"), "x" : 2, "y" : 1 }

myset:PRIMARY> use local

myset:PRIMARY> db.oplog.rs.find().sort({$natural:-1})

{ "ts" : { "t" : 1307545183000, "i" : 4 }, "h" : NumberLong("-1214445074120755058"), "op" : "d",

"ns" : "test.mycoll", "b" : true, "o" : { "_id" : ObjectId("4def8e5fb07da951204c60e0") } }

{ "ts" : { "t" : 1307545183000, "i" : 3 }, "h" : NumberLong("296197708926251535"), "op" : "i",

"ns" : "test.mycoll", "o" : { "_id" : ObjectId("4def8e5fd60f868d9ea77776"), "x" : 2, "y" : 1 } }

{ "ts" : { "t" : 1307545183000, "i" : 2 }, "h" : NumberLong("6923456793495821492"), "op" : "u",

"ns" : "test.mycoll", "o2" : { "_id" : ObjectId("4def8e5fb07da951204c60e0") }, "o" : { "$set" :

{ "y" : 1 } } }

{ "ts" : { "t" : 1307545183000, "i" : 1 }, "h" : NumberLong("-4148240362977057242"), "op" : "i",

"ns" : "test.mycoll", "o" : { "_id" : ObjectId("4def8e5fb07da951204c60e0"), "x" : 1 } }

...

[oplog を見てみる]

2. Primary のoplogを確認する

Wed Jun 8 23:53:38 [conn6] getmore local.oplog.rs cid:3687673685314762755 getMore:

{ ts: { $gte: new Date(5615858237044687812) } } bytes:20 nreturned:0 3022ms

Wed Jun 8 23:53:38 [conn8] getmore local.oplog.rs cid:9178181051262829411 getMore:

{ ts: { $gte: new Date(5615858237044687812) } } bytes:20 nreturned:0 3046ms

Wed Jun 8 23:53:41 [conn8] getmore local.oplog.rs cid:9178181051262829411 getMore:

{ ts: { $gte: new Date(5615858237044687812) } } bytes:20 nreturned:0 3041ms

Wed Jun 8 23:53:41 [conn6] getmore local.oplog.rs cid:3687673685314762755 getMore:

{ ts: { $gte: new Date(5615858237044687812) } } bytes:20 nreturned:0 3043ms

...

[oplog を見てみる]

3. Primary のサーバーログを確認する

myset:SECONDARY> db.oplog.rs.find().sort({$natural:-1})

{ "ts" : { "t" : 1307545183000, "i" : 4 }, "h" : NumberLong("-1214445074120755058"), "op" : "d",

"ns" : "test.mycoll", "b" : true, "o" : { "_id" : ObjectId("4def8e5fb07da951204c60e0") } }

{ "ts" : { "t" : 1307545183000, "i" : 3 }, "h" : NumberLong("296197708926251535"), "op" : "i",

"ns" : "test.mycoll", "o" : { "_id" : ObjectId("4def8e5fd60f868d9ea77776"), "x" : 2, "y" : 1 } }

{ "ts" : { "t" : 1307545183000, "i" : 2 }, "h" : NumberLong("6923456793495821492"), "op" : "u",

"ns" : "test.mycoll", "o2" : { "_id" : ObjectId("4def8e5fb07da951204c60e0") }, "o" : { "$set" :

{ "y" : 1 } } }

{ "ts" : { "t" : 1307545183000, "i" : 1 }, "h" : NumberLong("-4148240362977057242"), "op" : "i",

"ns" : "test.mycoll", "o" : { "_id" : ObjectId("4def8e5fb07da951204c60e0"), "x" : 1 } }

...

[oplog を見てみる]

4. Secondaryのoplogを確認する

[注意点]

・oplog collection は capped collection

・ある時点以前のオペレーションは保持していない

・secondary の長時間ダウン後の復帰の場合、oplog のオペレーション以前のものもリカバリ対象になる場合がある

・その場合は “Error RS102: too stale” となりマニュアルでリカバリが必要・primary の oplog 情報は以下のコマンドで確認できる (v1.8)

> db.printReplicationInfo()

configured oplog size: 47.6837158203125MB

log length start to end: 132secs (0.04hrs)

oplog first event time: Wed Apr 13 2011 02:58:08 GMT-0400

oplog last event time: Wed Apr 13 2011 03:00:20 GMT-0400

now: Wed Apr 13 2011 14:09:08 GMT-0400

ありがとうございました