MongoDB の構成

単一MongoDBインスタンスを使用する場合、簡単かつ素早く構成することができます。

しかし、もし、当該ホストおよびMongoDBインスタンスに対する予期せぬ問題により、プロセスがdownされるなどの障害が発生したり、データの流失が発生することがあります。

これに備えるために、様々な種類のDBMSと同様、MongoDBも複製構成によるDB HA(High Availability)機能を使用することができます。 こうして構成されたグループはReplica Setといい、さらに多数のReplica Setを一緒に構成してクエリーの分散処理とScale outに有利に構成した形をSharded Clusterと呼びます。

この章では、Replica SetとSharded Clusterに対する構成方法を説明します。

Replica Set(RS) の構成

一つのReplica Setはこれを構成する3つ以上のMemberで構成されており、個々のMemberは3つのうちrole(Primary、Secondary、Arbiter)の一つの役割をします。

(詳しくは https://docs.mongodb.com/manual/core/replica-set-members/index.htmlを参考)

それぞれのroleによってReplica Set構成に差があることがありますが、主に3つのMemberについてP-S-A(Primary-Secondary-Arbiter)またはP-S-S(Primary-Secondary-Secondary)構成が一般的です。

ここではP-S-A構成について説明します。

  1. DBサーバーで使用するサーバー2台、そしてArbiterサーバーで使用する1台を準備します。

    • インストール型MongoDBがインストールされている状態、DBプロセスをshutdownした状態

      • DBプロセスshutdownする方法 :
        • ]$ mongod --shutdown –f /home/mongodb/db/config/mongod.conf
    • Arbiterは、primaryおよびsecondaryのデータを複製せず、プロセスだけで存在し、primaryに問題が生じ、fali-overが発生した時に投票するだけの役割なので、高性能DBサーバーを使用しなくてもいいです。

    • 後述するSharding構成時、Router、Config ServerのようなDBサーバー内に構成する場合も多いです。

  2. MongoDB replica set 3代のデーモン設定ファイル(/home/mongodb/db/config/mongod.conf)を下記のように設定します。(YAML形態)

    • 例: /home/mongodb/db/config/mongod.conf

      systemLog:
         destination: file
         path: "/home/mongodb/db/log/mongod.log"
         logAppend: true
         logRotate: rename
      storage:
         engine: wiredTiger
         directoryPerDB: true
         wiredTiger:
            engineConfig:
               journalCompressor: snappy
            collectionConfig:
               blockCompressor: snappy
            indexConfig:
               prefixCompression: true
         dbPath: "/home/mongodb/db/data"
         journal:
            enabled: true
            commitIntervalMs: 300
      processManagement:
         fork: true
         pidFilePath: "/tmp/mongod.pid"
      net:
         port: 27019
         bindIpAll: true
         maxIncomingConnections: 20000
         unixDomainSocket:
            enabled: false
      replication:
          oplogSizeMB: 10240
          replSetName: "rstest01"
       setParameter:
          failIndexKeyTooLong: false
      
    • 同じReplica Setのメンバーで構成するためにはreplication項目の下のreplSetNameが同一しなければなりません。(例示ではrstest01という名で使用)

    • mongodb shard serverのポートは基本的に27019です。 基本ポート以外の他のポートを使用することをお勧めいたします。

  3. 設定が終わった後、MongoDBのデモンを駆動します。(3機すべて)

    • ]$ numactl --interleave=all mongod -f /home/mongodb/db/config/mongod.conf &
  4. 駆動が終わったらprimaryDBとして使用するサーバーからmongod shellにアクセスします。(DB名:admin)

    • mongoshell 接続方法: mongo < IP または localhost >:< PORT >/DB名
    • ]$ mongo localhost:27019/admin
  5. 該当mongo shell内から下コマンドを通じてReplica Setを設定します。(ここではprimaryとsecondary、計2台)

    > rs.initiate(
               {
          _id: "ReplicaSet명",
          version: 1,
          members: [
             { _id: 0, host : "<primaryIP>:<PORT>" },
             { _id: 1, host : "<SecondaryIP>:<PORT>" }
          ]
       }
    )
    
    • この例題でprimary/secondary/arbiterで使用する装備のIP情報が以下のとおりで、27019 Portを使用する場合、

      • Primary: 192.10.10.11
      • Secondary: 192.10.10.12
      • Arbiter: 192.10.10.13
    • シェルでは下記のように入力します。 (_id’ フィールド値は、上記のmongod.confのreplcation.replSetName値です。)

      rs.initiate(
         {
            _id: "rstest01",
            version: 1,
            members: [
               { _id: 0, host : "192.10.10.11:27019" },
               { _id: 1, host : "192.10.10.12:27019" }
            ]
         }
      )
      
      • 実行結果のメッセージ 「ok」を確認しした後、しばらくしてprimary および secondary の MongoDB shell にアクセスし、prompt が変更されていることを確認します。

        "rstest01:PRIMARY > " または "rstest02:SECONDARY> "
        
  6. PrimaryおよびSecondaryの状態を確認後、下記のようにArbiterを追加します。(2つの方法すべて同じ動作であるため、この中に一つだけを実行すればいいです)

    • Arbiter 追加

      rs.addArb("192.10.10.13:27019")
      または
      rs.add( { host: "192.10.10.13:27019", arbiterOnly: true } )
      
  7. 構成がうまく完了したか、下記のコマンドを確認します。**

    • RS 状態確認

      rstest01:PRIMARY> rs.status()
      
  8. root権限を持つ管理アカウントを作成します。

    • ユーザー作成

      use admin
      db.createUser(
         {
           user: "<アカウント名>",
           pwd: "<パスワード>",
           roles: ["root" ]
         }
      )
      
    • アカウントおよびパスワードを'user'/'0000'に作成する場合は、下記のように入力します。(admin DBで遂行)

      use admin
      db.createUser(
         {
           user: "user",
           pwd: "0000",
           roles: ["root" ]
         }
      )
      
  9. primaryで任意のデータをinsertし、secondaryでデータが入力されているかを確認します。

    • primary 接続後

      db.testcol.insert("seq" : 1)
      
    • Secondary 接続後

      use test
      rs.slaveOk()
      db.testcol.find({})
      

Sharded Cluster の構成

もし使用したいmongodbで処理すべきデータ量が多く、分散処理が必要な場合など、一つのreplica Setだけでは運営に困難がある場合、mongodbで提供する「Sharding」機能を使用することができます。

Sharding機能を利用して多数のreplica setを分散構成した形態を"Sharded Cluster"と呼び、これはMongoDBの中核機能の1つです。

Sharded Clusterで必ず必要なmemberは以下の通りです。

Router(= MongoS):応用またはユーザーが接続するポイント クエリーを受けて必要な時にはConfig Serverの分散情報を参照して適切なShard(Replica Set)で伝え、ユーザーに結果をリターンする役割

Config Server: Sharded Clusterで、複数の分散されたShard情報を保存し、管理します。 一つのsharded clusterに config serverは、一つの setだけを構成すればよいでしょう。

1つのグループ以上のShard(=Replica Set):複数のReplica SetにClusterを構成します。 それぞれのReplica SetをShardと呼びます。

ここでは以下のように構成する例を説明します。

  1. Replica Setを構成します。

    "Replica Set(RS)の構成"を参考にして2つのReplica Set(計6台)を構成します。 但し、設定ファイル(/home/mongodb/db/config/mongod.conf)内に下記の設定を追加して駆動します。

    sharding:
       clusterRole: shardsvr
    

    例: /home/mongodb/db/config/mongod.conf

    systemLog:
       destination: file
       path: "/home/mongodb/db/log/mongod.log"
       logAppend: true
       logRotate: rename
    storage:
       engine: wiredTiger
       directoryPerDB: true
       wiredTiger:
          engineConfig:
             journalCompressor: snappy
          collectionConfig:
             blockCompressor: snappy
          indexConfig:
             prefixCompression: true
       dbPath: "/home/mongodb/db/data"
       journal:
          enabled: true
          commitIntervalMs: 300
    processManagement:
       fork: true
       pidFilePath: "/tmp/mongod.pid"
    net:
       port: 27019
       bindIpAll: true
       maxIncomingConnections: 20000
       unixDomainSocket:
          enabled: false
    replication:
        oplogSizeMB: 10240
        replSetName: "rstest01"
    setParameter:
    failIndexKeyTooLong: false
    sharding:
       clusterRole: shardsvr
    

    Mongodb駆動後、各Replica Setメンバーすべてに接続し、PRIMARY、SECONDARY、ARBITERの有無がすべて確認されれば、shardとして使われるreplica setのインストールが完了します。

  2. config serverの構成

    1. 1.Config serverはSharded Cluster一つの中にたった一つのset万の構成します。 Config serverもreplica setと同様、互いに複製される構成です。 したがってインストール方法もreplica set構成と類似していて、上記の「Replica Set(RS)の構成」を参考にして1つのconfig server(計3台)を構成します。 但し、config server構成時には、P-S-Aではなく、P-S-Sの形で構成します。

ここではRouter(MongoS)がインストールされる装備3台にそれぞれConfig serverの各メンバーをP-S-S-の形で構成する例を説明します。

mongodb デモン設定ファイル(/home/mongodb/db/config/mongod.conf) とは別の設定ファイルを作成します。(/home/mongodb/db/config/configserver.conf)

例: /home/mongodb/db/config/configserver.conf

   storage:
       dbPath: "/home/mongodb/db/configdata"
       journal:
           enabled: true
   systemLog:
       destination: file
       path: "/home/mongodb/db/log/configlog.log"
       logAppend: true
   processManagement:
       fork: true
   net:
       bindIpAll: true
       port: 27018
   replication:
       oplogSizeMB: 40960
       replSetName: "cstest"
   sharding:
       clusterRole: "configsvr"
  • 例題ではconfig serverのポートを基本ポートの27018に設定しました デフォルトポートではない他のポートに設定することをお勧めします。

  • sharding.clusterRoleは"configsvr"に設定します(上記の例示で、replica setに設定したDBサーバーのsharding.clusterRole値("shardsvr")と差があります。)

    config serverで使用するmongodbデーモンが駆動されると、primaryで使用されるmongodb sheelの中で以下のように複製グループを設定します。

この例題でconfig serverで使用するprimary/secondary/secondaryで、使用する装備のIP情報が以下のとおりで、27017 portを使用する場合、

  • config server 構成情報(例示)

    • Primary: 192.10.10.14
    • Secondary: 192.10.10.15
    • Secondary: 192.10.10.16

    シェルでは以下のように入力します。('_id' フィールド値は上のconfigserver.confのreplication.replSetName値)

    rs.initiate(
     {
        _id: "cstest",
        version: 1,
        members: [
           { _id: 0, host : "192.10.10.14:27018" },
           { _id: 1, host : "192.10.10.15:27018" },
           { _id: 2, host : "192.10.10.16:27018" }
        ]
     }
    )
    

    上記のコマンドの実行後、結果が「ok」であるかを確認した後、しばらくしてprimaryおよびsecondary MongoDB shellにアクセスし、promptが変更されているかを確認します。

  • 例: ]$ mongo localhost:27018/admin

    “cstest:PRIMARY >” または “cstest:SECONDARY> “
    
  1. Router(=MongoS) の構成

    routerで使用されるサーバーの両方で(現在例示では3台)mongod.conf、configserver.confと同様に、同じディレクトリにrouter設定ファイルを作成します。(/home/mongodb/db/config/mongos.conf)

sharding項目はすでにインストールされたconfig server情報を入力し、net.port項目はrouterポート(ユーザ及びアプリが接続するポート)に使用する情報を入力します。(例示では27017)

   sharding:
       configDB: "cstest/192.10.10.14:27018,192.10.10.15:27018,192.10.10.16:27018"
   systemLog:
       destination: file
       path: "/home/mongodb/db/log/mongos.log"
       logAppend: true
   processManagement:
       fork: true
   net:
       port: 27017
       bindIpAll: true
       maxIncomingConnections: 30000
   setParameter:
           ShardingTaskExecutorPoolHostTimeoutMS : 3600000
           ShardingTaskExecutorPoolMaxSize : 20
           ShardingTaskExecutorPoolMinSize : 10

設定が終わった後routerのデモンを駆動します。(3機すべて駆動、mongodがなくmongosコマンドに注意)

  • $] numacl --interleave=all mongos -f /home/mongodb/db/config/mongos.conf &

駆動が終わったら、primaryDBとして使用するサーバーからmongo shellへアクセスします。(DB名:admin)

  • mongo shellアクセス方法: mongo :/DB名 例示)

    ]$ mongo localhost:27017/admin
    

Routerおよびconfig serverで管理するSharding情報(Replica Set)情報を入力します。

(routerのshell(ここでは port:27017) 接続後

   sh.addShard("<replica_set>/<hostname><:port>,<hostname><:port>,…")
例:
   // 第一のreplica set 入力(Arbiterを除外したPrimary及びSecondary情報だけ入力)
   sh.addShard("rstest01/192.10.10.14:27019,192.10.10.15:27019")

   // 第二のreplica set 入力(Arbiterを除外したPrimary及びSecondary情報だけ入力)
   sh.addShard("rstest02/192.10.10.114:27019,192.10.10.115:27019")
  1. root権限を持つ管理アカウントを作成します。

    use admin
    db.createUser(
      {
        user: "<アカウント名>",
        pwd: "<パスワード>",
        roles: ["root" ]
      }
    )
    

    例:アカウントおよびパスワードを「user」/「0000」に作成する場合は、下記のように入力します。(admin DBで遂行)

    use admin
    db.createUser(
      {
        user: "user",
        pwd: "0000",
        roles: ["root" ]
      }
    )
    

    その後、shardingに関するコマンドは下記の公式マニュアルにてご参考ください。

    (https://docs.mongodb.com/manual/reference/method/js-sharding/)

認証モード適用

上記の構成段階までは、一種の「非認証モード」であり、ユーザーアカウント認証がなくても、ほぼすべての管理者権限を使用することができます。

セキュリティ面においてこれを防止し、ユーザー認証(アカウント/パスワード)モードを適用するためには、以下のような設定段階が追加的に行われなければなりません。

  1. 任意の装備からキーファイルを作成します。

    例:

    ]$ openssl rand -base64 755 > /home/mongodb/db/config/mongodb-keyfile
    
  2. 作成された派である(/home/mongodb/db/config/mongodb-keyfile)を全てのmongodbの装備にコピーします。

  3. 各設定ファイルに以下の項目を追加します。

    • shard 設定(/home/mongodb/db/config/mongod.conf)

      security:
        keyFile: /home/mongodb/db/config/mongodb-keyfile
        authorization: enabled
      
    • config server 設定(/home/mongodb/db/config/configserver.conf)

      security:
        keyFile: /home/mongodb/db/config/mongodb-keyfile
        authorization: enabled
      
    • router 設定(/home/mongodb/db/config/mongos.conf): authorization: enabled 項目除外

      security:
        keyFile: /home/mongodb/db/config/mongodb-keyfile
      
  4. すべての装備でプロセス再スタート

    • shard 再スタート**

      mongod --shutdown -f /home/mongodb/db/config/mongod.conf
      
      numactl --interleave=all mongod \
      -f /home/mongodb/db/config/mongod.conf &
      
    • config server 再スタート

      mongod --shutdown -f /home/mongodb/db/config/configserver.conf
      
      numactl --interleave=all mongod \
      -f /home/mongodb/db/config/configserver.conf &
      
    • router 再スタート(ps コマンドで mongosの PIDを確認後)

      kill <PID>
      
      numactl --interleave=all mongod \
      -f /home/mongodb/db/config/mongos.conf &
      

に対する検索結果は~件です。 ""

    に対する検索結果がありません。 ""

    処理中...