👌

ひとりMongoDB University 12/20 - レプリケーション(1)

2020/12/20に公開

この記録は、アドベントカレンダー形式の、MongoDB Universityの学習コースの記録、20日目になります！
ただいまコース: M103^[1]を進めています。Chapter2を1日3つぐらいずつ進めたい。
25日までに15stepが目標です。

アドベントカレンダー / ひとりMongoDB Universityの準備

Chapter 2: What is Replication?

MongoDBのレプリケーションについて
より堅牢なデータベースを構成するためももの
MongoDB uses asynchronous, statement-based replication because it's platform independent and allows more flexibility within a replica set.
- MongoDBはレプリケーションに際しては非同期で statement-based replication (ステートメントベースのレプリケーション) を採用している
- マスタ側で発行されたSQLをそのままレプリカ側に適用（実行）する形
- プラットフォームが異なっていてもレプリケーションを構成できる
  - なんで必要？
- 全てのサーバが常に正常に稼働できるとは限らない
MongoDBの場合はメインのnodeをprimary node、それ以外の複製されたnodeをsecondary nodeという
もしprimary nodeに障害が発生したら、secondary nodeにフェイルオーバーする必要がある

プライマリノードへの昇格ってどう決まるの？

The nodes decide specifically which secondary will become the primary through an election. And this name is not a coincidence.

どうやらレプリカセットの間で「選挙」で決まるらしい！

primary nodeが切り替わったあとは、復旧したnodeは今度はレプリカセットの一員としてsecondary nodeとして参加する

レプリケーションのタイプ

statement based replication
binary replication

バイナリレプリケーション

バイナリレプリケーションの場合は、データの変更をバイナリログに書き出す
セカンダリノードがバイナリログを受けとり、手元のデータファイルに対して変更を適用する
とにかく変更を直にデータファイルに適用するだけなので、プライマリ側でどんなMQL(クエリ)で変更されたかは関与しない
データファイル上の一致が保たれていれば良いので、セカンダリノードは、実際のところ「何をレプリケーションしているか」すら意識しなくて良い

バイナリレプリケーションの制約

バイナリを同じ処理で操作する必要があるため、オペレーションシステムが一致していることが条件
- Windows x Linuxではダメ！
  - 同じOSでも同じインストラクションセットでないとダメ！（x86 と x64が混在ではダメ。一致させること）

※バイナリレプリケーションを構成する場合は、プラットフォームは厳密に組む必要があります！
データベースサーバをアップデートする際も、同時に行わないとレプリカセットのデータが壊れる可能性があります。（プラットフォームが同じでもデータベースのバージョンが異なっていてはダメ！）

ステートメントベースレプリケーション

primary nodeでの書き込みオペレーション（更新操作）が完了すると、oplogに処理内容が書き出される
oplogがsecondary nodeに転送され、その更新操作を適用する
論理的に整合性がとれていることが前提のため、オペレーティングシステムがノード間で異なっていても良い
プライマリノードへの処理内容がoplogに書き出されるが、実際はその直前に変換コマンドが走る
この変換処理で、適切なタイミングで適切なデータの更新を適用することができる
Idempotence （冪等性) という

冪等性を保つための変換例

プライマリノードで、データをインクリメントさせる処理が走る
- 1000 -> 1001
- 操作命令文的には、+1を発行
oplogはこの命令文（+1する)を発行するのではなく、値を 1001 にする、という命令文に変換される
- データ適用のタイミングがずれると、＋1の命令文では結果が変わってしまうため
- 「更新の結果、データとして最終的にどういった値になったか」をoplogに書き出す

レプリケーションまとめ

バイナリレプリケーションは高速、データ転送が少なくて済む
- その分、オペレーティングシステム、バージョンのいった構成を厳密に揃えないといけない
ステートメントベースレプリケーションは若干データ量が増える
- ただし冪等性が担保されていればよいので、プラットフォームやバージョンの制約を超えてノードを増やすことができる

Chapter 2: What is Replication? (クイズ)

Problem

Which of the following are true about binary replication and statement-based replication?

こたえ

Statement-based replication is platform independent.
MongoDB uses statement-based replication, not binary replication.

データの整合性、冪等性、分散という点ではどちらも同じ。

Chapter2. MongoDB Replica Set(動画)

MongoDBのレプリケーションの同期は、異なるバージョンのプロトコルがある。

PV1 and PV0
- 現在はPV1がデフォルト
  - 耐障害性や可用性の点で異なるメカニズムになっている
- RAFTプロトコルがベースになっている

※RAFTはコンセンサスアルゴリズムの1つ。他にもPaxosがあるよ！
（詳しくは参考リンクを参照とのこと。ここでの範囲では触れません）

レプリカセットのsecondary nodeには、役割が2つある。

promary nodeに昇格ができるもの
- promary nodeと同じく読み書きできる
- promary nodeからのoplogを適用し、論理的な冪等性が保たれていること
  - フェイルオーバーの時に「選出」に参加するだけのもの
レプリカセットのメンバーの中には、Arbiterとしての役割のものもある
- 設定で指定できる
- このメンバー（ノード）はデータを持たない
- プライマリノードの選挙（選出）の時にVoteするだけの役割
フェイルオーバーした時に、どのノードがプライマリに選出されるかは、プロトコルバージョンによっても異なる（ここでのスコープではない）
- そのうえで、設定により優先順位の重み付けが可能
- プライマリノード選出のために、セカンダリノードは必ず「奇数」ノードが必要
プライマリノード1、セカンダリノード3の構成で、プライマリとセカンダリノード1つがダウンした場合は...？
- 新しいプライマリノード選出の前に、セカンダリノードが2つだけになってしまった場合は、どちらもプライマリに選出できなくなってしまう

セカンダリノードの数

レプリカセットのメンバーは、地理的な分散も考慮して50ノードまで保持可能
ただし新しいプライマリノード選出の候補になれるのは、7ノードに限定される
リソースの確保その他の理由でArbiterノード（データを保持せずVoteだけできるノード）を設定できるが、取り扱いは慎重に
- できればArbiterノードは避けること

hiddenノード

- 特別な理由で、アプリケーションからは隠したい、もしくはReadOnlyとして保持する場合に、Hiddenノードが設定できる

非同期でもほぼ他のレプリカセットと同じデータを保持するのとは別に、同期を「遅延」させて置くことも可能
Delayedノードと呼ばれる
- 障害ではなく、オペレーションミスによるデータの論理破壊から復旧させたい場合に、Delayedノードが有効

-参考資料

Chapter 2: MongoDB Replica Set (クイズ)

Problem

Which of the following are true for replica sets in MongoDB?

こたえ

Replica set members have a fixed role assigned.

今日の進捗

今日はお休みなので5つ進みました！
分散（レプリケーション）構成のための、合意形成のしくみとかが、難しいーー！
調べながら進めているので、動画が10分以内でも2時間くらいかかりました..。

レプリカセットにいろいろ役割があるのを学習。
明日は、WebのIDEからセカンダリノードを3つ上げるという課題です！

きょうのzenn

ひきつづき同じ方法で進めています :)

脚注

M103: Basic Cluster Administration のコースになります。コースを開始すると、完了までの期限は2ヶ月以内です。 ↩︎