galife

MongoDB のレプリカセットでアクセス制御（ユーザー認証）を有効化する方法

今回は「MongoDB のレプリカセットに対してアクセス制御（ユーザー認証）を有効化する方法」についてまとめます。

概要
キーファイルを用いたアクセス制御

概要

レプリカセットに対するアクセス制御を有効化するためには内部認証（レプリカセットメンバー間の認証）を有効化する必要があります。内部認証の方法は以下の2通りがあります。

キーファイル (チャレンジレスポンス認証、SCRAM-SHA-1)
x.509（公開鍵認証、TLS/SSL）

今回はお手軽に実現できる「キーファイル」を用いた内部認証の有効化およびアクセス制御の有効化を行います。

キーファイルを用いたアクセス制御

管理ユーザーの追加

アクセス制御を有効化する前に管理ユーザーを作っておきます。

アクセス制御無効化状態でMongoDBのすべてのレプリカセットメンバーを起動
```
mongod --config "C:\mongodb\server1\server1.cfg"
```
プライマリサーバーに接続

mongoシェルでプライマリサーバーに接続します。プライマリサーバーが不明な場合、 rs.status() でプライマリサーバーを確認して接続しなおします。
```
mongo --host 127.0.0.1:8001
```
管理ユーザーを追加

以下のコマンドのように、adminデータベースへスイッチしたのち、管理ユーザーを作成します。

レプリカセットコマンドである rs.xxxx を利用できるのは clusterMonitor というロールのようですが、ここでは clusterAdmin ロールを追加しています。
```
PRIMARY> use admin
PRIMARY> db.createUser({
  user: "admin",
  pwd: "password",
  roles: [
    "userAdminAnyDatabase",
    "dbAdminAnyDatabase",
    "clusterAdmin"
  ]
})
```

MongoDBの設定変更（アクセス制御有効化）

キーファイルの作成

キーファイルは Base64セットの文字列（[a-zA-Z0-9/+] の64種類）を使った 6～1024文字のファイルになります。ランダム文字列生成した後、Base64変換して1024文字までにカットするような方法で良いかと思います。 Linux使えるなら openssl を使った以下のコマンドでランダム文字列を生成できます。
```
$ openssl rand -base64 1024 > keyfile
```
キーファイルは以下のようなBase64文字列で構成される内容になります。以下はサンプルなので、必ず自前で生成してください。ランダム文字列生成するツールを使うとラクかもしれません。

keyfile
```
rMvhlWEIzktbhXN+rcTV43z2YKPGsd8YHNNuOVpZLW9bIPx1MaAeGTVullFVY4A5
B0zRpKLXcB347T/m278LK3BNBynB3mVpoe1pPmSYVjpBmo3LhsDKXywb8dU7UrBl
9bgh4NZfNaBcYykuoQsiloWNP5QtMquBymF2bh+1s+aJpvkq1FzAhsJvwcGeILBc
gnBOwZAsDXlE0M1hr0zvsulkyvFDgE2UcS+2tm4yZPKNDygA2HCcXqJypa9L2f1J
dC83SLNxbN4MkeE+NeY3ZE+LFUqTyvb827VhXfCX+S+TpD5h/otiS1GiQnTcBiSB
fYrMhLsOFPU9UYc705XDw48m
```
ランダム文字列生成ツール
キーファイルをレプリカセットメンバーへ配布

任意の方法で各レプリカセットメンバーに作成したキーファイルを配置します。今回はサンプルとして以下のような場所に配置したものとします。
```
C:\mongodb
  │
  ├ \server1
  │  └ keyfile
  │     
  ├ \server2
  │  └ keyfile
  │     
  └ \server3
      └ keyfile
```

すべてのレプリカセットメンバー設定に認証設定を追加

MongoDB設定ファイル（mongod.config）に対して security.authorization を有効化し、 security.keyFile 設定を追加します。

mongod.config

systemLog:
  destination: file
  path: C:\mongodb\server1\log\mongod.server1.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server1\data
security:
  authorization: enabled
  keyFile: C:\mongodb\server1\keyfile
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8001

すべてのレプリカセットメンバーを再起動

各サーバーに mongoシェルでログインして以下のコマンドを実行してサーバーを停止させます。サーバーを停止させる際、ロールバックを避けるため、プライマリサーバーが最後になるよう停止していきます。

停止
```
SECONDARY> use admin
SECONDARY> db.shutdownServer()
```
開始
```
mongod --config "C:\mongodb\server1\server1.cfg"
```

通常ユーザーの追加

プライマリサーバーに管理ユーザーで接続

mongoシェルでプライマリサーバーに管理ユーザーで接続します。プライマリサーバーが不明な場合、 rs.status() でプライマリサーバーを確認して接続しなおします。

接続方法は「接続時にユーザー名とパスワードを指定する方法」と「接続語にユーザー名とパスワードを指定する方法」の2通りがあります。
- MongoDB へ接続と同時に認証する
```
mongo --host 127.0.0.1:8001 -u admin -p Passw0rd --authenticationDatabase admin
```
- MongoDB へ接続、接続後に認証する
```
mongo --host 127.0.0.1:8001
```
```
PRIMARY> use admin
PRIMARY> db.auth('admin', 'Passw0rd')
```

通常ユーザーを追加

データベースを指定して通常ユーザーを追加します。

PRIMARY> use test
PRIMARY> db.createUser({
  user: "test",
  pwd: "test",
  roles: [{
    role: "readWrite",
    db: "test"
  }]
})

ユーザー名とパスワードを指定してデータベースへ接続

プライマリサーバーに通常ユーザーで接続

mongoシェルでプライマリサーバーに通常ユーザーで接続します。

接続方法は管理ユーザーで接続するのと同じで、「接続時にユーザー名とパスワードを指定する方法」と「接続語にユーザー名とパスワードを指定する方法」の2通りがあります。
- MongoDB へ接続と同時に認証する
```
mongo --host 127.0.0.1:8001 -u test -p test --authenticationDatabase test
```
- MongoDB へ接続、接続後に認証する
```
mongo --host 127.0.0.1:8001
```
```
PRIMARY> use test
PRIMARY> db.auth(test, test)
```

今回は「MongoDB のレプリカセットに対してキーファイルを用いたアクセス制御（ユーザー認証）を有効化する方法」についてまとめました。ポイントは以下の通りです。

MongoDBのレプリカセットでアクセス制御は「キーファイル」と「x.509」の2種類が選べる
アクセス制御有効化前に管理ユーザーを作成しておく

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB の既存レプリカセットからメンバーを削除する方法

MongoDB の既存レプリカセットにメンバーを追加する方法

今回は「MongoDBの既存レプリカセットに新しいメンバーを追加する方法」についてまとめます。

前提・制約
レプリカセットへの追加手順

前提・制約

MongoDBのレプリカセットにおけるそもそもの制約も含めて追加しようとしている新しいMongoDBサーバーが以下の前提や制約を満たしていることを確認しておきます。

有効なレプリカセットが既に存在している
追加したい新しいMongoDBは有効なレプリカセットにアクセス可能な状態
追加するメンバーを含めて投票権は7台以下になっている
追加するメンバー含めてレプリカセット全体が50台以下になっている

レプリカセットへの追加手順

レプリカセットに追加

MongoDBを起動

mongod --config "C:\mongodb\server4\mongod4.cfg"

プライマリサーバーに接続

プライマリサーバーが不明な場合、任意のサーバーに接続して rs.status() を実行することでプライマリサーバーがどれか確認できます。
```
mongo --host 127.0.0.1:8001
```
レプリカセットに追加する新しいメンバー情報を作成

優先度(priority）、隠し（hidden）、遅延（slaveDelay）など必要な設定があれば合わせて準備しておきます。
```
PRIMARY> member = { host: "127.0.0.1:8004" }
```
アービターの場合、以下のように arbiterOnly を設定しておきます。
```
PRIMARY> member = { host: "127.0.0.1:8004", arbiterOnly: true }
```
レプリカセットに新規メンバーを追加
```
PRIMARY> rs.add(member)
```

追加したメンバーのデータ確認

レプリカセットメンバーに追加されると自動的にデータ同期が始まります。データ同期されていることを以下の手順で確認します。

追加したメンバーへ接続
```
mongo --host 127.0.0.1:8004
```
参照設定変更

セカンダリ接続しただけだとデータ参照できないので、以下の mongoシェルを実行して参照できるようにします。
```
SECONDARY> rs.slaveOk()
```
データ確認

以下はサンプルとして test データベースの users コレクションを参照するようなコードです。存在する任意のコレクションを確認してみてください。
```
SECONDARY> use test
SECONDARY> db.users.find()
```

新規メンバーのデータを同期

基本的にはデータは自動的に同期されますが、何かしらの理由でうまくいかなかった場合、以下の手順で強制的に再同期させます。

追加した新規メンバーを停止

追加した新規メンバーに mongoシェルでログインし、以下のコマンドを実行します。
```
> use admin
> db.shutdownServer()
```
追加したMongoDBサーバーの dbPath 配下のファイル・フォルダを削除

追加した後に再同期を自動的におこなえるようにするため、 dbPath 配下のファイル・フォルダは削除しておきます。
追加した新規メンバーを起動

コマンドプロンプト上で以下のコマンドを実行します。
```
mongo --config "C:\mongo\server4\server4.cfg"
```

今回は「MongoDBの既存レプリカセットに新しいメンバーを追加する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB のレプリカセットメンバー設定の初期化および変更する

今回は「MongoDB のレプリカセットメンバー設定」について「設定を初期化/変更する方法」と「変更できる内容」まとめます。

レプリカセット設定を初期化する
レプリカセット設定を変更する
主なレプリカセット設定例

レプリカセット設定を初期化する

レプリカセット構築時に行う初期化処理は mongo シェルで任意のメンバーに接続したのち、 rs.initiate() で初期化を行います。

任意のMongoDBレプリカセットメンバーへ接続
```
mongo --host 127.0.0.1:8001
```

初期設定オブジェクトを作成

> config = {
   _id : "rs0",
   members: [
      { _id: 0, host: "172.0.0.1:27001" },
      { _id: 1, host: "172.0.0.1:27002" },
      { _id: 2, host: "172.0.0.1:27003", arbiterOnly; true },
   ]
}

レプリカセットを初期化
```
> rs.initiate(config)
```

レプリカセット設定を変更する

設定変更の手順は基本的に以下の4ステップで行います。以下では「優先度」を変更する方法をサンプルに手順を載せています。いずれも mongoシェル上で実施します。

設定変更を行うと、プライマリサーバーは降格して、クライアントからの接続が切断されます。この処理に10～20秒かかるので、設定変更はメンテナンス期間に実施するようにします。

任意のMongoDBレプリカセットメンバーへ接続
```
mongo --host 127.0.0.1:8001
```
現在の設定を取得
```
> config = rs.config()
```

設定を変更

> config.members[0].priority = 1
> config.members[1].priority = 2
> config.members[2].priority = 2

変更した設定を適用
```
> rs.reconfig(config)
```

主なレプリカセット設定例

レプリカセットメンバーの設定には以下のような項目があります。

config = {
  ...
  members: [
    {
      _id: <int>,
      host: <string>,
      arbiterOnly: <boolean>,
      buildIndexes: <boolean>,
      hidden: <boolean>,
      priority: <number>,
      tags: <document>,
      slaveDelay: <int>,
      votes: <number>
    },
    ...
  ]
  ...
}

以下ではよくある設定パターンを例に取り上げます。

プライマリにならないようにする
隠しメンバーにする
遅延メンバーにする
投票権のないメンバーにする
アービターにする

プライマリにならないようにする

優先度（Priority）を 0 に設定することで、フェイルオーバー時にプライマリサーバーにならなくなります。設定例は以下のようになります。

> config = rs.config()
> config.members[2].priority = 0
> rs.reconfig(config)

隠しメンバーにする

優先度（Priority）を 0 、隠し（hidden）を true に設定します。

> config = rs.config()
> config.members[2].priority = 0
> config.members[2].hidden = true
> rs.reconfig(config)

遅延メンバーにする

優先度（Priority）を 0 、隠し（hidden）を true 、遅延時間（slaveDelay）に遅延させたい時間（秒）を設定します。以下のサンプルでは1時間遅延させて反映するような遅延メンバー設定になっています。

遅延メンバーを利用する場合、遅延時間が長くなればなるほど oplog サイズが大きくなるので、oplog サイズが十分大きなサイズに設定されるよう注意が必要です。

> config = rs.config()
> config.members[2].priority = 0
> config.members[2].hidden = true
> config.members[2].slaveDelay = 3600
> rs.reconfig(config)

投票権のないメンバーにする

投票権（votes）のないメンバーは読み取り専用サーバーで、プライマリになれないサーバーです。

そのため、投票権（votes）が 0 のメンバーは必ず優先度（priority）も 0 にします。逆に、優先度（priority）が 1以上のメンバーは必ず投票権（votes）に 1 を設定します。投票権は1つのレプリカセットで7つまでで奇数表となるよう設定する必要があるので投票権の設定時には制約が満たされていることを確認するよう注意します。

> config = rs.config()
> config.members[2].priority = 0
> config.members[2].votes = 0
> rs.reconfig(config)

アービターにする

アービターサーバーは投票権だけあるサーバーです。優先度（Priority）は 1 、アービター（arbiterOnly）を true に設定します。以下は通常のセカンダリ（優先度が1以上で投票権がある状態）に対する設定を前提に記載しています。

> config = rs.config()
> config.members[2].arbiterOnly = true
> rs.reconfig(config)

今回は「MongoDB のレプリカセットメンバー設定」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB で 2台構成のレプリカセットを構築する方法

今回は「MongoDB で 2台構成のレプリカセットを作成する方法」についてまとめます。

…いきなりですが、MongoDB で 2台構成のレプリカセットを作ることはできません。低スペックで構いませんので必ず3台構成にする必要があります。

概要
レプリカセットの構築
- レプリカセットメンバーの準備
- レプリカセットの初期化
レプリカセットの動作確認

概要

今回は物理2台サーバーでレプリカセットを構築する方法について実際のコードを交えながら見ていきます。 …が、先に述べた通りMongoDBにおけるレプリカセットは最小構成が3台なので、物理2台の場合もう1台追加する必要があります。追加するサーバーはデータを持たないインスタンスのみが稼働するサーバーで良いので、スペックの低いサーバー（アプリケーションサーバーや管理サーバーなど）でも問題ありません。このデータを保持せず投票権だけを持つサーバーをアービターサーバーと呼びます。 アービターをプライマリやセカンダリに同居させるのも、冗長性の観点で意味がないので行わないでください。

今回は以下の図のようなサーバー3台構成（プライマリ1台、セカンダリ1台、アービター1台）のMongoDBレプリカセットを構築していきます。

今回は動作確認をお試しで行いたいので、以下の制約をつけた環境でのサンプルになります。

1台の物理マシンの中に上記3インスタンスを構築
認証制御は行わない

どちらかというと本番向けというよりは開発環境向けのデータベースサーバー構築になります。

レプリカセットの構築

今回はテスト用として物理1台の中に3台分のMongoDBインスタンスを作成するサンプルです。実運用だと先述の通り「冗長性を持たせたい高スペック2サーバーそれぞれに1インスタンス（プライマリ、セカンダリ）、低スペックな1サーバーに1インスタンス（アービター）」になるはずなので、一部設定は読み替えていただければと思います。

レプリカセットメンバーの準備

各インスタンス用にフォルダ・ファイルを作成

C:\mongodb
  │
  ├ \server1
  │  ├ \data
  │  ├ \log
  │  └ mongod.srver1.cfg
  │     
  ├ \server2
  │  ├ \data
  │  ├ \log
  │  └ mongod.server2.cfg
  │     
  └ \server3
      ├ \data
      ├ \log
      └ mongod.server3.cfg

各インスタンスの設定ファイル（mongod.serverN.cfg）を修正

1サーバー中に複数インスタンス生成しているため、ポート番号を分けています。 1サーバー1インスタンスであればポートはすべて同じ（27017 など) でも問題ないです。

レプリカセット名（replSetName）はすべて共通（今回は rs0 ）で設定しておきます。また、開発環境向けであれば bindIpAll 設定を入れておくとバインドIPを列挙しなくてよいので設定が簡単です。プロダクション向けは bindIp を面倒でも設定しておくほうが良いと思いますが…。 アービターサーバーにはファイル保存しないので storage.journal.enabled: false を設定しておきます。

mongod.srver1.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server1\log\mongod.srver1.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server1\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8001
```
mongod.server2.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server2\log\mongod.server2.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server2\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8002
```
mongod.server3.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server3\log\mongod.server3.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server3\data
  journal:
    enabled: false
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8003
```

各インスタンスを起動

分かりやすいようコマンドプロンプトを3つ立ち上げてそれぞれのインスタンスを起動します。

mongod --config "C:\mongodb\server1\mongod.srver1.cfg"

mongod --config "C:\mongodb\server2\mongod.server2.cfg"

mongod --config "C:\mongodb\server3\mongod.server3.cfg"

レプリカセットの初期化

いずれかのインスタンスにログイン

今回は以下のコマンドを実行して server1 へログインします。
```
mongo --host 127.0.0.1:27001
```
レプリカセット初期化処理の実行

mongoコマンドの rs.initiate() を実行することでレプリカセットを初期化します。渡したい引数はあらかじめ config オブジェクトへ代入してから渡します（そのほうが誤りを訂正できるので）。 アービターサーバーには arbiterOnly: true を付与します。
```
> config = {
   _id : "rs0",
   members: [
      { _id: 0, host: "127.0.0.1:8001" },
      { _id: 1, host: "127.0.0.1:8002" },
      { _id: 2, host: "127.0.0.1:8003", arbiterOnly: true },
   ]
}
> rs.initiate(config)
```

以上で設定は完了してレプリカセットが利用できる状態になりました。次の章で簡単な動作確認をしてみます。

レプリカセットの動作確認

今回は動作確認として以下の以下の3つを行ってみます。

レプリカセットの設定確認
レプリカセットのステータス確認
フェールオーバーの動作確認

レプリカセットの設定確認

コマンドプロンプトで rs.config() を実行
```
> rs.config()
```

コマンド実行結果としてレプリカセット設定が表示されることを確認

{
  "_id" : "rs0",
  "version" : 1,
  "protocolVersion" : NumberLong(1),
  "members" : [
    {
      "_id" : 0,
      "host" : "127.0.0.1:8001",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 1,
      "host" : "127.0.0.1:8002",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 2,
      "host" : "127.0.0.1:8003",
      "arbiterOnly" : true,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 0,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    }
  ],
  "settings" : {
    "chainingAllowed" : true,
    "heartbeatIntervalMillis" : 2000,
    "heartbeatTimeoutSecs" : 10,
    "electionTimeoutMillis" : 10000,
    "catchUpTimeoutMillis" : -1,
    "catchUpTakeoverDelayMillis" : 30000,
    "getLastErrorModes" : {

    },
    "getLastErrorDefaults" : {
      "w" : 1,
      "wtimeout" : 0
    },
    "replicaSetId" : ObjectId("5a76f437386f5b1a0a9f8f01")
  }
}

サーバーのステータス確認

コマンドで rs.status() を実行
```
> rs.status()
```

コマンド実行結果として現在のサーバーステータスが表示されることを確認

{
  "set" : "rs0",
  "date" : ISODate("2018-02-04T11:53:38.972Z"),
  "myState" : 1,
  "term" : NumberLong(1),
  "heartbeatIntervalMillis" : NumberLong(2000),
  "optimes" : {
    "lastCommittedOpTime" : {
      "ts" : Timestamp(0, 0),
      "t" : NumberLong(-1)
    },
    "appliedOpTime" : {
      "ts" : Timestamp(1517745207, 1),
      "t" : NumberLong(-1)
    },
    "durableOpTime" : {
      "ts" : Timestamp(1517745207, 1),
      "t" : NumberLong(-1)
    }
  },
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      "uptime" : 117,
      "optime" : {
        "ts" : Timestamp(1517745207, 1),
        "t" : NumberLong(-1)
      },
      "optimeDate" : ISODate("2018-02-04T11:53:27Z"),
      "infoMessage" : "could not find member to sync from",
      "electionTime" : Timestamp(1517745218, 1),
      "electionDate" : ISODate("2018-02-04T11:53:38Z"),
      "configVersion" : 1,
      "self" : true
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 11,
      "optime" : {
        "ts" : Timestamp(1517745207, 1),
        "t" : NumberLong(-1)
      },
      "optimeDurable" : {
        "ts" : Timestamp(1517745207, 1),
        "t" : NumberLong(-1)
      },
      "optimeDate" : ISODate("2018-02-04T11:53:27Z"),
      "optimeDurableDate" : ISODate("2018-02-04T11:53:27Z"),
      "lastHeartbeat" : ISODate("2018-02-04T11:53:38.520Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-04T11:53:34.281Z"),
      "pingMs" : NumberLong(0),
      "configVersion" : 1
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      "uptime" : 11,
      "lastHeartbeat" : ISODate("2018-02-04T11:53:38.524Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-04T11:53:34.205Z"),
      "pingMs" : NumberLong(0),
      "configVersion" : 1
    }
  ],
  "ok" : 1,
  "operationTime" : Timestamp(1517745207, 1),
  "$clusterTime" : {
    "clusterTime" : Timestamp(1517745218, 1),
    "signature" : {
      "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
      "keyId" : NumberLong(0)
    }
  }
}

フェールオーバーの動作確認

MongoDBではプライマリサーバーがダウンしたとき（通信不能になったとき）、自動でセカンダリサーバーがプライマリサーバーに昇格するようになっています。今回はプライマリサーバーを強制的に落としてセカンダリサーバーがプライマリサーバーに昇格することを確認します。

現在のステータスを確認

先述の rs.status() で状況を確認します。結果出力内容は一部省略しています。

PRIMARY> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      ...
    }
  ],
  ...
}

プライマリサーバーのコマンドプロンプトを停止

先ほどの rs.status() の結果から _id: 0 のサーバーがプライマリサーバーだとわかりましたので、 _id: 0 のサーバーを起動しているコマンドプロンプト上で Ctrl + C を実行し、停止させます。

ステータスの確認

ハートビート（生死確認）は2秒間隔なので、3秒程度待ってから rs.status() を実行します。セカンダリサーバーのどちらかがプライマリサーバーに昇格していることが確認できます。

PRIMARY> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 0,
      "state" : 8,
      "stateStr" : "(not reachable/healthy)",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      ...
    }
  ],
  ...
}

今回は「MongoDBの2台構成レプリカセットの構築」についてまとめました。ポイントは以下の通りです。

物理2台構成のレプリカセットは作成できない。
高スペック2台構成（プライマリ、セカンダリ）＋低スペック1台（アービター）の3台構成にする。
1台サーバーに3インスタンスの場合、ポートを分ける。
アービターサーバーには以下の設定を入れる
- storage.journal.enabled: false
- arbiterOnly: true

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB で 3台構成のレプリカセットを構築する方法

今回は「MongoDB で 3台構成のレプリカセットを作成する方法」についてまとめます。

概要
レプリカセットの構築
- レプリカセットメンバーの準備
- レプリカセットの初期化
レプリカセットの動作確認

概要

今回は以下の図のようなサーバー3台構成（プライマリ1台、セカンダリ2台）のMongoDBサーバーを構築していきます。

今回は動作確認をお試しで行いたいので、以下の制約をつけた環境でのサンプルになります。

1台の物理マシンの中に上記3インスタンスを構築
認証制御は行わない

どちらかというと本番向けというよりは開発環境向けのデータベースサーバー構築になります。

レプリカセットの構築

今回はテスト用として物理1台の中に3台分のMongoDBインスタンスを作成するサンプルです。実運用だと1サーバー1インスタンスになるはずなので、一部設定は読み替えていただければと思います。

レプリカセットメンバーの準備

各インスタンス用にフォルダ・ファイルを作成

C:\mongodb
  │
  ├ \server1
  │  ├ \data
  │  ├ \log
  │  └ mongod.srver1.cfg
  │     
  ├ \server2
  │  ├ \data
  │  ├ \log
  │  └ mongod.server2.cfg
  │     
  └ \server3
      ├ \data
      ├ \log
      └ mongod.server3.cfg

各インスタンスの設定ファイル（mongod.serverN.cfg）を修正

1サーバー中に複数インスタンス生成しているため、ポート番号を分けています。 1サーバー1インスタンスであればポートはすべて同じ（27017 など) でも問題ないです。

レプリカセット名（replSetName）はすべて共通（今回は rs0 ）で設定しておきます。また、開発環境向けであれば bindIpAll 設定を入れておくとバインドIPを列挙しなくてよいので設定が簡単です。プロダクション向けは bindIp を面倒でも設定しておくほうが良いと思いますが…。

mongod.srver1.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server1\log\mongod.srver1.log
storage:
  dbPath: C:\mongodb\server1\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 27001
```
mongod.server2.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server2\log\mongod.server2.log
storage:
  dbPath: C:\mongodb\server2\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 27002
```
mongod.server3.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server3\log\mongod.server3.log
storage:
  dbPath: C:\mongodb\server3\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 27003
```

各インスタンスを起動

分かりやすいようコマンドプロンプトを3つ立ち上げてそれぞれのインスタンスを起動します。

mongod --config "C:\mongodb\server1\mongod.srver1.cfg"

mongod --config "C:\mongodb\server2\mongod.server2.cfg"

mongod --config "C:\mongodb\server3\mongod.server3.cfg"

レプリカセットの初期化

いずれかのインスタンスにログイン

今回は以下のコマンドを実行して server1 へログインします。
```
mongo --host 127.0.0.1:27001
```
レプリカセット初期化処理の実行

mongoコマンドの rs.initiate() を実行することでレプリカセットを初期化します。渡したい引数はあらかじめ config オブジェクトへ代入してから渡します（そのほうが誤りを訂正できるので）。
```
> config = {
   _id : "rs0",
   members: [
      { _id: 0, host: "127.0.0.1:27001" },
      { _id: 1, host: "127.0.0.1:27002" },
      { _id: 2, host: "127.0.0.1:27003" },
   ]
}
> rs.initiate(config)
```

以上で設定は完了してレプリカセットが利用できる状態になりました。次の章で簡単な動作確認をしてみます。

レプリカセットの動作確認

今回は動作確認として以下の以下の3つを行ってみます。

レプリカセットの設定確認
レプリカセットのステータス確認
フェールオーバーの動作確認

レプリカセットの設定確認

コマンドプロンプトで rs.config() を実行
```
> rs.config()
```

コマンド実行結果としてレプリカセット設定が表示されることを確認

{
  "_id" : "rs0",
  "version" : 1,
  "protocolVersion" : NumberLong(1),
  "members" : [
    {
      "_id" : 0,
      "host" : "127.0.0.1:8001",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 1,
      "host" : "127.0.0.1:8002",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 2,
      "host" : "127.0.0.1:8003",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    }
  ],
  "settings" : {
    "chainingAllowed" : true,
    "heartbeatIntervalMillis" : 2000,
    "heartbeatTimeoutSecs" : 10,
    "electionTimeoutMillis" : 10000,
    "catchUpTimeoutMillis" : -1,
    "catchUpTakeoverDelayMillis" : 30000,
    "getLastErrorModes" : {

    },
    "getLastErrorDefaults" : {
      "w" : 1,
      "wtimeout" : 0
    },
    "replicaSetId" : ObjectId("5a75b603abca086c328afd4f")
  }
}

サーバーのステータス確認

コマンドで rs.status() を実行
```
> rs.status()
```

コマンド実行結果として現在のサーバーステータスが表示されることを確認

{
  "set" : "rs0",
  "date" : ISODate("2018-02-03T13:21:42.450Z"),
  "myState" : 1,
  "term" : NumberLong(1),
  "heartbeatIntervalMillis" : NumberLong(2000),
  "optimes" : {
    "lastCommittedOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    },
    "readConcernMajorityOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    },
    "appliedOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    },
    "durableOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    }
  },
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      "uptime" : 602,
      "optime" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDate" : ISODate("2018-02-03T13:21:41Z"),
      "electionTime" : Timestamp(1517663759, 1),
      "electionDate" : ISODate("2018-02-03T13:15:59Z"),
      "configVersion" : 1,
      "self" : true
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 354,
      "optime" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDurable" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDate" : ISODate("2018-02-03T13:21:41Z"),
      "optimeDurableDate" : ISODate("2018-02-03T13:21:41Z"),
      "lastHeartbeat" : ISODate("2018-02-03T13:21:41.665Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-03T13:21:40.647Z"),
      "pingMs" : NumberLong(0),
      "syncingTo" : "127.0.0.1:8001",
      "configVersion" : 1
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 354,
      "optime" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDurable" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDate" : ISODate("2018-02-03T13:21:41Z"),
      "optimeDurableDate" : ISODate("2018-02-03T13:21:41Z"),
      "lastHeartbeat" : ISODate("2018-02-03T13:21:41.662Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-03T13:21:40.652Z"),
      "pingMs" : NumberLong(0),
      "syncingTo" : "127.0.0.1:8001",
      "configVersion" : 1
    }
  ],
  "ok" : 1,
  "operationTime" : Timestamp(1517664101, 1),
  "$clusterTime" : {
    "clusterTime" : Timestamp(1517664101, 1),
    "signature" : {
      "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
      "keyId" : NumberLong(0)
    }
  }
}

フェールオーバーの動作確認

MongoDBではプライマリサーバーがダウンしたとき（通信不能になったとき）、自動でセカンダリサーバーがプライマリサーバーに昇格するようになっています。今回はプライマリサーバーを強制的に落としてセカンダリサーバーのどちらかがプライマリサーバーに昇格することを確認します。

現在のステータスを確認

先述の rs.status() で状況を確認します。結果出力内容は一部省略しています。

> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    }
  ],
  ...
}

プライマリサーバーのコマンドプロンプトを停止

先ほどの rs.status() の結果から _id: 0 のサーバーがプライマリサーバーだとわかりましたので、 _id: 0 のサーバーを起動しているコマンドプロンプト上で Ctrl + C を実行し、停止させます。

ステータスの確認

> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 0,
      "state" : 8,
      "stateStr" : "(not reachable/healthy)",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    }
  ],
  ...
}

今回は「MongoDBの3台構成レプリカセットの構築」についてまとめました。ポイントは以下の通りです。

3台構成の場合、プライマリ1台＋セカンダリ2台
1台サーバーに3インスタンスの場合、ポートを分ける

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB のレプリケーション概要

今回は「MongoDB のレプリケーション」についてその概要をまとめます。

タイトルには「レプリケーション」とありますがMongoDBでの実装にあたる「レプリカセット」の概要についてまとめています。

レプリケーション
MongoDBにおけるレプリケーション
レプリカセットメンバー
レプリカセットの構成
自動フェールオーバー
データの読み書き

レプリケーション

「レプリケーション」はデータを複数のデータベースサーバーへコピーすることで冗長性と可用性を提供する仕組みです。保存するデータセンターが異なれば災害対策にもなります。また、同一データがコピーされているので読取が多いアプリケーションでは負荷分散も行えます。

MongoDBにおけるレプリケーション

MongoDB では同一データを保持するデータベースインスタンス群を「レプリカセット」と呼ばれるひとくくりのグループとして管理します。 MongoDB ではこのレプリカセットの仕組みで冗長性と可用性を提供します。

プライマリサーバーはすべての書き込み操作を受け取るサーバーで、データに対する変更を記録してログに残します。セカンダリサーバーはプライマリサーバーの操作ログをコピーして適用することでプライマリサーバーと同じデータの状態を作ります。もし、プライマリサーバーが不通となった場合は適切なセカンダリサーバーがプライマリサーバーに選任されてサービスを継続します。

レプリカセットメンバー

MongoDB のレプリカセットに含まれるメンバー（サーバー）の種類は以下にあげる3種類があります。

プライマリ
セカンダリ
アービター

それぞれについて以下で詳しく紹介します。

プライマリ

レプリカセット中に1台だけ存在する書き込み可能なサーバーです。プライマリサーバーに書き込んだ操作情報はログ oplog として残り、この操作ログがセカンダリサーバーへ伝達、コピーされます。

プライマリサーバーが何かしらの理由でお亡くなりになった場合、残ったセカンダリサーバーの中から次のプライマリサーバーが投票で選任されます。

セカンダリ

プライマリサーバーの操作ログをもとにデータ更新を行う読み取り専用のサーバーです。セカンダリサーバーを複数台用意することで大量の読み取り操作に耐えられるようにします。

クライアントからのデータ読み取りは、基本的にセカンダリサーバー優先で読みに行くようにし、即時性が求められるデータのみプライマリサーバー優先で読みに行くようにします。

セカンダリサーバーの主な設定には「優先度（Priority）」「隠し（Hidden）」「遅延（Delayed）」の３つがあります。

優先度（Priority）

Priority: 0 を指定するとプライマリサーバーに昇格しません。優先度が0より大きな値が設定されているサーバーからプライマリサーバーが選任されます。また、優先度に高い値が設定されているサーバーが優先的にプライマリサーバーとして選任されます。
隠し（Hidden）

プライマリサーバーから操作ログをコピーしてデータ最新化は行いますが、クライアントアプリケーションからは見えない設定です。クライアントアプリケーションから見えないので、他のサーバーに比べて負荷は低くなります。隠し設定にしたメンバーはデータ分析やバックアップなど通常業務と異なる専用端末として利用します。
遅延（Delayed）

プライマリサーバーから操作ログをコピーしてデータ反映は行いますが、プライマリサーバーよりも指定時間分だけ遅延させて反映します。プライマリサーバーよりも遅延させて反映させることで、何かしら操作ミスを起こしてしまった時のリカバリに利用できるようにします。

アービター

レプリカセットで投票権のあるサーバーを奇数台にするために追加する調整用のサーバーです。アービターサーバー自体はデータを持たず、プライマリサーバーが亡くなった場合に行われる新しいプライマリサーバーの選任で投票を行うことが主な役割です。自身がプライマリサーバーになることはないので Priority: 0 を指定しておきます。

レプリカセットの構成

レプリカセットには最大50台までのメンバーを含めることができ、そのうち最大7台までが投票権を持ちます。投票権を持つサーバー台数は奇数になるよう設計します。足りない場合はアービターを追加して調整します。

最小のレプリカセットは3台構成で、以下のような構成が想定されます。

プライマリとセカンダリ2台
プライマリとセカンダリ、アービター

地理的に離れたデータセンターにメンバーを配置することでより高い可用性を実現することができます。

プライマリとセカンダリ2台

このパターンの場合、セカンダリサーバー2台ともがプライマリサーバーになれるので、より可用性が高い構成となります。

通常時は2台のセカンダリサーバーに完全なコピーが作られます。プライマリサーバーが不通となった場合、残っている2台のセカンダリサーバーが投票を行い、どちらかがプライマリサーバーに昇格します。

プライマリとセカンダリ、アービター

いわゆるサーバー2台構成です。実態として動いているのはプライマリサーバーとセカンダリサーバーの2台のみで、アービターサーバーはフェールオーバー時の投票に参加するくらいです（とはいえ、セカンダリにアービター相乗りさせるのは推奨されないので、管理用サーバーなど物理的に異なる低スペックサーバーにしておきます）。

このパターンの場合、アービターサーバーにデータコピーされないので、完全なコピーはセカンダリサーバーのみとなります。プライマリサーバーが不通となった場合、プライマリサーバーの投票は行われますが必然的に残っているセカンダリサーバーがプライマリサーバーに昇格します。

自動フェールオーバー

レプリカセットは自動フェールオーバーによって高可用性を実現します。具体的には、プライマリサーバーが応答しなくなった際、セカンダリサーバーから次のプライマリサーバーを選任し、選任されたセカンダリサーバーがプライマリサーバーに昇格することで実現します。

各メンバーは2秒間隔でハートビート（ping）を実行します。 10秒間応答が得られなかった場合、該当サーバーを不良サーバーとしてマークします。プライマリサーバーが不良サーバーと設定されると残ったセカンダリサーバーから次のプライマリサーバーの選任始まります。

サーバーが投票を行う際、より高い優先度（Priority）が設定されたサーバーが優先的にプライマリサーバーに選任されます。優先度（Priority）が低いサーバーが選任されている状態で、より高い優先度（Priority）のサーバーが有効になった場合、再び優先度（Priority）が高いサーバーがプライマリサーバーとなるよう投票が行われます。

投票を行わないメンバーは優先度（Priority）を0に設定しておきます。 1つのレプリカセットで投票権は7つまでなので、それ以上のセカンダリサーバーを用記す場合は優先度（Priority）を0として投票権（votes）も0で設定したサーバーにします。

データの読み書き

データの読み込みも書き込みも MongoClient の生成時にオプションで指定できます。書き込みに関しては w, j, wtimeout の3種類、読み込みに関しては readPreference, readConcern.level の2種類があります。

var {MongoClient, ReadPreference}= require("mongodb");

var URL = "mongodb://localhost:27017/test";

MongoClient.connect(URL, {
  // 書き込み設定
  w: "majority",
  j: true,
  wtimeout: 5000,
  // 読み込み設定
  readPreference: ReadPreference.SECONDARY_PREFERRED
  readConcern: {
    level: "local"
  }
}, (client) => {
  client.close();
});

データ書き込み

書き込みは Write Concern 設定でレプリカセットに含まれるサーバーの何台目まで書き込み処理を伝搬するか指定します。

設定値	説明
<number>	指定した台数まで書き込まれることを保証します。
"majority"	投票権のあるサーバーの過半数に書き込まれることを保証します。

設定値	説明
true	ディスクへの書き込みまで行います。
false	デフォルト。メモリ上への書き込みのみを保証します。

wtimeout

設定値	説明
<number>	書き込みをタイムアウトにする時間（ミリ秒）を指定します。設定する場合は1より大きな値を指定します。 0を指定した場合、タイムアウト処理を行いません。

データ読み込み

読み込みは Read Preference 設定でどのサーバーから優先的にデータ読み込みするかを設定することができます。

readPreference

設定値	説明
primary	デフォルトモード。プライマリサーバーから取得します。
primaryPreferred	ほとんどの場合はプライマリサーバーから取得しますが、プライマリサーバーにアクセスできない場合はセカンダリサーバーから取得します。
secondary	セカンダリサーバーから取得します。
secondaryPreferred	ほとんどの場合はセカンダリサーバーから取得しますが、セカンダリサーバーにアクセスできない場合はプライマリサーバーから取得します。
nearest	レプリカセットの種類に関わらず、レイテンシーが最小のサーバーから取得します。

readConcern.level

どのようなデータを取得してくるかを指定します。

設定値	説明
"local"	デフォルトでプライマリを読みに行きます。インスタンスの最も新しいデータを取得してきます。レプリカセットのほとんどに書き込まれたデータかどうかまでは保証しません。
"available"	デフォルトでセカンダリを読みに行きます。インスタンスの最も新しいデータを取得してきます。レプリカセットのほとんどに書き込まれたデータかどうかまでは保証しません。
"majority"	ほとんどのメンバーに書き込まれたデータの最も新しいデータを取得します。
"linearizable"	すべての書き込みが終わった後のロールバックされないデータを取得します。

今回は「MongoDB のレプリケーション」についてまとめました。ポイントは以下の通りです。

書き込みできるのはプライマリサーバーのみ。
プライマリサーバーが不通となった場合、残ったセカンダリサーバーがプライマリサーバーに昇格。

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

C# & JavaScript

概要

キーファイルを用いたアクセス制御

管理ユーザーの追加

MongoDBの設定変更（アクセス制御有効化）

通常ユーザーの追加

ユーザー名とパスワードを指定してデータベースへ接続

前提・制約

レプリカセットからメンバーを削除する手順

前提・制約

レプリカセットへの追加手順

レプリカセットに追加

追加したメンバーのデータ確認

新規メンバーのデータを同期

レプリカセット設定を初期化する

レプリカセット設定を変更する

主なレプリカセット設定例

プライマリにならないようにする

隠しメンバーにする

遅延メンバーにする

投票権のないメンバーにする

アービターにする

概要

レプリカセットの構築

レプリカセットメンバーの準備

レプリカセットの初期化

レプリカセットの動作確認

レプリカセットの設定確認

サーバーのステータス確認

フェールオーバーの動作確認

概要

レプリカセットの構築

レプリカセットメンバーの準備

レプリカセットの初期化

レプリカセットの動作確認

レプリカセットの設定確認

サーバーのステータス確認

フェールオーバーの動作確認

レプリケーション

MongoDBにおけるレプリケーション

レプリカセットメンバー

プライマリ

セカンダリ

アービター

レプリカセットの構成

プライマリ と セカンダリ2台

プライマリ と セカンダリ、アービター

自動フェールオーバー

データの読み書き

データ書き込み

データ読み込み

プライマリとセカンダリ2台

プライマリとセカンダリ、アービター