Dc1.com上のMongoDBインスタンスは現在スタンドアロンであり、オンサイトは定期的にmongodumpを介してsshトンネル経由でバックアップをプルします。
次に、2つのインスタンスを作成します。1つはオンサイトで、もう1つは2番目のデータセンターにあり、3つのインスタンスをレプリカセットにして、バックアップがほぼ瞬時になるようにします。この方法では、オンサイトバックアップと2番目のデータセンターに1つがあり、常に最新の状態になります。
Dc1.comのメインMongoDBインスタンスが失敗した場合、それだけです。データを提供できません。オンサイトインスタンスとセカンダリデータセンターのインスタンスが引き継ぐべきではないため、これを手動で修正する必要があります。また、これら2つは照会されることを意図していません。それらはバックアップとして存在します。
私の問題は、-replSetをメインデータベースに追加し、次にrs.initialize()を追加すると、このインスタンスが何らかの理由でlocalhostにバインドされていると認識されず、Dockerインターフェイスである172.17.0.1に認識されることです。コンテナーがMongoDBに接続できるようにバインドする必要があります。次に、dc2.comのインスタンスであるrs.add("localhost:2001")
を介してメンバーを追加しようとすると、ローカルホストデータベースと非ローカルホストデータベースを混在させることができないというエラーが発生します。メインインスタンスはlocalhostとしてではなく、172.17.0.1として認識されます。
"レプリカセット構成内のすべてのホスト名がlocalhost参照であるか、何もない必要があります。2つのうち1つが見つかりました"
次に https://stackoverflow.com/questions/28843496/cant-initiate-replica-set-in-ubunt を使用してrs.initiate({_id:"rs0", members: [{"_id":1, "Host":"127.0.0.1:1000"}]})
を発行し、 localhostにバインドされるdc1.com上のレプリカセット。しかし、rs.add("localhost:2001")
を介してメンバーを追加しようとすると、まだそれを行うことができません。これはもはやホスト名エラーではありませんが、試行錯誤してすべてをロールバックしなければならなかったため、まったく覚えていない別のエラーです。それは接続が拒否されたようなものでした。 mongo --port 2001
「isMaster」に関連する何かに関する警告の後に切断されます。
このような設定を作成することは可能ですか?私がやろうとしているのは、MongoDBでTLSを使用したり、バックアップをグローバルにアクセス可能なインターフェースにバインドしたりしないことです(オンサイトインスタンスはファイアウォールの背後にあるため、0.0.0.0:1002はパブリックにアクセスできません)。
TLSを使用せずに、次の設定が可能です。
データセンター1はプライマリデータセンターです。すべてのクライアントがこのクライアントにonlyを接続します。 Datacenter 2は、レプリケーションによるリアルタイムバックアップ専用です。オンサイトは、レプリケーションによるリアルタイムバックアップ専用です。
この設定はフェイルオーバー用ではなく、災害復旧用です。
データセンター1:
MongoDB
mongod --bind_ip 127.0.0.1,172.17.0.1 --replSet test --port 2000 --rest --httpinterface --logpath data/replica/logs/log.txt --dbpath data/replica/wiredTiger --directoryperdb- storageEnginewiredTiger --wiredTigerDirectoryForIndexes --fork
127.0.0.1はSSHアクセス用、172.17.0.1はDockerコンテナーからのアクセス用です。
SSHトンネル(このサーバーは、Datacenter 2へのトンネルの作成を担当します):
autossh -f -N -L 2001:localhost:2001 [email protected]
autossh -f -N -R 2000:localhost:2000 [email protected]
データセンター2:
MongoDB
mongod --bind_ip 127.0.0.1 --port 2001 --replSet test --rest --httpinterface --logpath data/replica/logs/log.txt --dbpath data/replica/wiredTiger --directoryperdb --storageEngine WiredTiger- WiredTigerDirectoryForIndexes --fork
オンサイト:
MongoDB
mongod --bind_ip 127.0.0.1 --port 2002 --replSet test --rest --httpinterface --logpath data/replica/logs/log.txt --dbpath data/replica/wiredTiger --directoryperdb --storageEngine WiredTiger- WiredTigerDirectoryForIndexes --fork
SSHトンネル(オンサイトはデータセンター1へのトンネルの作成を担当します)データセンター2とオンサイトの間に永続的な接続はありません)
autossh -f -N -R 2002:localhost:2002 [email protected]
autossh -f -N -L 2000:localhost:2000 [email protected]
Datacenter 1のサーバーには複製されるすべてのデータが含まれ、Datacenter 2とOn-Siteは空のデータベースです。
Datacenter 1のマシンで_mongo --port 2000
_と入力してから、
_rs.initiate(
{
_id: "test",
version: 1,
members: [
{ _id: 0, Host : "localhost:2000", priority: 1, votes: 1 },
{ _id: 1, Host : "localhost:2001", priority: 0, votes: 0, hidden: true },
{ _id: 2, Host : "localhost:2002", priority: 0, votes: 0, hidden: true }
]
}
)
_
セカンダリの_priority: 0, votes: 0, hidden: true
_はここではオプションだと思います。これは私がやりたいことを実行します。2つのセカンダリをバックアップ目的のサイレントで非表示のデータコレクタとして使用するだけです。これを変更すると副作用が発生するかどうかはわかりません。この場合、両方のセカンダリ間の接続を利用できるはずですが、この場合は利用できません(お互いを見ることができません)。
隠しメンバーの1つにslaveDelay
を使用して、たとえば半日遅れるようにすることができますが、mongodumpを介して両方の隠しデータベースから大量のバックアップを作成するため、実際には必要ありません。
Mongodbツールを介してセカンダリに接続できるようにするために、rs.slaveOk()
を発行する必要がありました
クライアントで何も変更する必要はなく、_172.17.0.1:2000
_に接続します。
Datacenter 2でマシンの再起動をテストしました。再起動中に約30秒後に、再起動したマシンがDatacenter 1と同期しました。
データセンター1には高速のサーバーがあり、RAMおよびCPUとSSDストレージはほんの少ししかありません。データセンター2には少しRAMですが、 HDDなので、これは良い解決策のようです。