web-dev-qa-db-ja.com

レプリカセットの設定が無効であるか、メンバーではなく、kubernetesで実行されています

私はこの問題を ここ から投稿しました

シャードされたmongodbをkubernetes環境で実行しており、3つのシャードがあり、各シャードに3つのインスタンスがあります。何らかの理由で、mongodbインスタンスが別のマシンに再スケジュールされました。

問題は、mongodbインスタンスが別のインスタンスに再スケジュールされた場合、その_replica config_が無効になることです。以下のこのエラーが発生します。

_            > rs.status()
            {
                "state" : 10,
                "stateStr" : "REMOVED",
                "uptime" : 2110,
                "optime" : Timestamp(1448462710, 6),
                "optimeDate" : ISODate("2015-11-25T14:45:10Z"),
                "ok" : 0,
                "errmsg" : "Our replica set config is invalid or we are not a member of it",
                "code" : 93
            }
            >
_

これは設定です

_            > rs.config().members
            [
                {
                    "_id" : 0,
                    "Host" : "mongodb-shard2-service:27038",
                    "arbiterOnly" : false,
                    "buildIndexes" : true,
                    "hidden" : false,
                    "priority" : 1,
                    "tags" : {

                    },
                    "slaveDelay" : 0,
                    "votes" : 1
                },
                {
                    "_id" : 1,
                    "Host" : "shard2-slave2-service:27039",
                    "arbiterOnly" : false,
                    "buildIndexes" : true,
                    "hidden" : false,
                    "priority" : 1,
                    "tags" : {

                    },
                    "slaveDelay" : 0,
                    "votes" : 1
                },
                {
                    "_id" : 2,
                    "Host" : "shard2-slave1-service:27033",
                    "arbiterOnly" : false,
                    "buildIndexes" : true,
                    "hidden" : false,
                    "priority" : 1,
                    "tags" : {

                    },
                    "slaveDelay" : 0,
                    "votes" : 1
                }
            ]
_

および再スケジュールされたmongodbインスタンスのdb.serverStatus()のサンプル

_            > db.serverStatus()
            {
                "Host" : "mongodb-shard2-master-ofgrb",
                "version" : "3.0.7",
                "process" : "mongod",
                "pid" : NumberLong(8),
_

私が理にかなっていることを願っています。なぜなら、私はこれをすぐにライブプロダクションで使用するからです。ありがとう！

mongodbkubernetesgoogle-kubernetes-engine
10
Hokutosei

最後に、kubernetes PetSet はこの問題を解決します。それは魔法のように機能します

0
Hokutosei

Mongoを設定する古い方法（PetSetの代わりにReplicationControllersまたはDeploymentsを使用）を使用したい場合、問題はkubernetesサービスのホスト名割り当ての遅延にあるようです。解決策は、コンテナのエントリポイントに（実際のmongoを開始する前に）10秒の遅延を追加することです。

spec:
  containers:
    - name: mongo-node1
      image: mongo
      command: ["/bin/sh", "-c"]
      args: ["sleep 10 && mongod --replSet rs1"]
      ports:
        - containerPort: 27017
      volumeMounts:
        - name: mongo-persistent-storage1
          mountPath: /data/db

関連するディスカッション： https://jira.mongodb.org/browse/SERVER-24778

1
cray0000

遅れて申し訳ありません。これは、mongodbを起動する方法を詳細に説明する投稿です： https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474#.x197hr2ps

インスタンスごとに1つのサービスと1つの単一レプリカReplicationControllerは、各インスタンスが安定した予測可能なIDを必要とするステートフルアプリケーションの現在のアプローチです。このアプローチでは、ポッドごとにPersistentVolumeを割り当てることも簡単です。

その例に示されているサイドカーアプローチやCassandra例）のカスタムシードプロバイダーなど、他のソリューションも可能ですが、もう少し複雑です。

Kubernetes 1.2は、各ポッドのホスト名（コンテナーから見た場合）を設定する手段を提供します。 Kubernetes 1.3は、インスタンスを作成するための新しいコントローラーを追加します。

1
briangrant