我正在关注本教程(https://github.com/drginm/docker-boilerplates/tree/master/mongodb-replicaset),以获取可在docker-compose中工作的三个实例的mongodb副本集。
这是我到目前为止采取的步骤:
1)我已经将setup
和mongo-rs0-1
文件夹复制到了我的根目录。
2)我已将三个mongo实例和安装实例添加到我的docker-compose文件中。现在看起来像这样:
version: '3'
services:
mongo-rs0-1:
image: "mongo-start"
build: ./mongo-rs0-1
ports:
- "27017:27017"
volumes:
- ./mongo-rs0-1/data:/data/db
networks:
- app-network
depends_on:
- "mongo-rs0-2"
- "mongo-rs0-3"
mongo-rs0-2:
image: "mongo"
command: --replSet rs0 --smallfiles --oplogSize 128
networks:
- app-network
ports:
- "27018:27017"
volumes:
- ./mongo-rs0-2/data:/data/db
mongo-rs0-3:
image: "mongo"
command: --replSet rs0 --smallfiles --oplogSize 128
networks:
- app-network
ports:
- "27019:27017"
volumes:
- ./mongo-rs0-3/data:/data/db
setup-rs:
image: "setup-rs"
build: ./setup
networks:
- app-network
depends_on:
- "mongo-rs0-1"
nodejs:
build:
context: .
dockerfile: Dockerfile
ports:
- "8000:8000"
container_name: nodejs
restart: unless-stopped
networks:
- app-network
depends_on:
- setup-rs
nextjs:
build:
context: ../.
dockerfile: Dockerfile
ports:
- "3000:3000"
container_name: nextjs
restart: unless-stopped
networks:
- app-network
depends_on:
- nodejs
webserver:
image: nginx:mainline-alpine
container_name: webserver
restart: unless-stopped
ports:
- "80:80"
volumes:
- ./picFolder:/picFolder
- web-root:/var/www/html
- ./nginx-conf:/etc/nginx/conf.d
- certbot-etc:/etc/letsencrypt
- certbot-var:/var/lib/letsencrypt
depends_on:
- nodejs
- nextjs
- setup-rs
networks:
- app-network
volumes:
certbot-etc:
certbot-var:
web-root:
driver: local
driver_opts:
type: none
device: /
o: bind
networks:
app-network:
driver: bridge
3)不需要修改我的nginx.conf
文件,但是我已经在这里添加了它以简化:
server {
listen 80;
listen [::]:80;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name example.com www.example.com localhost;
location /socket.io {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_pass http://nodejs:8000/socket.io/;
}
location /back {
proxy_connect_timeout 75s;
proxy_read_timeout 75s;
proxy_send_timeout 75s;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_pass http://nodejs:8000/back/;
}
location /staticBack{
alias /picFolder;
expires 1y;
access_log off;
add_header Cache-Control "public";
}
location / {
proxy_pass http://nextjs:3000;
}
location ~ /.well-known/acme-challenge {
allow all;
root /var/www/html;
}
}
4)最后,我将连接字符串更改为'mongodb://mongo-rs0-1,mongo-rs0-2,mongo-rs0-3/test'
,如下所示(https://github.com/drginm/docker-boilerplates/blob/master/mongodb-replicaset/web-site/database.js)
这一切似乎都是正确的,但是我的nodejs在尝试连接到Mongoose时抛出以下错误
mongoose.connect("mongodb://mongo-rs0-1,mongo-rs0-2,mongo-rs0-3/test");
MongoDB connection error: { MongoError: no mongos proxy available
at Timeout.<anonymous> (/var/www/back/node_modules/mongodb-core/lib/topologies/mongos.js:757:28)
at ontimeout (timers.js:498:11)
at tryOnTimeout (timers.js:323:5)
at Timer.listOnTimeout (timers.js:290:5) name: 'MongoError', [Symbol(mongoErrorContextSymbol)]: {} }
有人看到发生了什么事吗?我曾尝试搜索此问题,但似乎通用的答案是mongodb某种程度上并未“看到”实例。我有点迷茫,我们将不胜感激。
编辑:
经过更多的挖掘,我发现了这个SO(Mongoose connection to replica set),发现mongo.conf
文件(https://github.com/drginm/docker-boilerplates/blob/master/mongodb-replicaset/mongo-rs0-1/mongo.conf)似乎表示副本集名称为rs0
。现在,我连接:
mongoose.connect("mongodb://mongo-rs0-1,mongo-rs0-2,mongo-rs0-3/test?replicaSet=rs0");
但是,我仍然遇到以下错误(至少有所不同!):
MongoDB connection error: { MongoError: no primary found in replicaset or invalid replica set name
at /var/www/back/node_modules/mongodb-core/lib/topologies/replset.js:636:11
at Server.<anonymous> (/var/www/back/node_modules/mongodb-core/lib/topologies/replset.js:357:9)
at Object.onceWrapper (events.js:315:30)
at emitOne (events.js:116:13)
at Server.emit (events.js:211:7)
at /var/www/back/node_modules/mongodb-core/lib/topologies/server.js:508:16
at /var/www/back/node_modules/mongodb-core/lib/connection/pool.js:532:18
at _combinedTickCallback (internal/process/next_tick.js:132:7)
at process._tickCallback (internal/process/next_tick.js:181:9) name: 'MongoError', [Symbol(mongoErrorContextSymbol)]: {} }
我很确定副本集名称现在正确,但是我想也许我必须指定哪个是主要的?但是,此SO(https://dba.stackexchange.com/questions/136621/how-to-set-a-mongodb-node-to-return-as-the-primary-of-a-replication-set)似乎暗示这应该自动发生。任何帮助仍然表示赞赏。
编辑编辑:
进一步的研究发现了这个SO帖子(Mongoose connection to replica set)。考虑到较新的v5 mongodb,以下连接选项似乎是最好的选择:
var options = {
native_parser: true,
auto_reconnect: false,
poolSize: 10,
connectWithNoPrimary: true,
sslValidate: false,
socketOptions: {
keepAlive: 1000,
connectTimeoutMS: 30000
}
};
mongoose.connect("mongodb://mongo-rs0-1:27017,mongo-rs0-2:27017,mongo-rs0-3:27017/test?replicaSet=rs0", options);
connectWithNoPrimary: true
似乎特别重要,因为nodejs处于竞争状态,而mongo服务从Docker启动,它们可能还没有选择主要对象。
但是,我仍然遇到以下错误(再次,略有不同):
MongoDB connection error: { MongoError: no secondary found in replicaset or invalid replica set name
at /var/www/back/node_modules/mongodb-core/lib/topologies/replset.js:649:11
at Server.<anonymous> (/var/www/back/node_modules/mongodb-core/lib/topologies/replset.js:357:9)
at Object.onceWrapper (events.js:315:30)
at emitOne (events.js:116:13)
at Server.emit (events.js:211:7)
at /var/www/back/node_modules/mongodb-core/lib/topologies/server.js:508:16
at /var/www/back/node_modules/mongodb-core/lib/connection/pool.js:532:18
at _combinedTickCallback (internal/process/next_tick.js:132:7)
at process._tickCallback (internal/process/next_tick.js:181:9) name: 'MongoError', [Symbol(mongoErrorContextSymbol)]: {} }
因此,现在它找不到辅助副本集。添加connectwithnosecondary
不会执行任何操作,并且会导致相同的错误-我认为这不是有效的选择。仍然受阻,我们将不胜感激。
编辑编辑编辑:
我已将我的nodejs connect函数更改为存在错误的回归回调中。我希望这将继续尝试连接,直到docker-compose中的任何潜在竞争条件得到解决,并且我可以成功连接。但是,我不断收到上述错误MongoError: no secondary found in replicaset or invalid replica set name
。因此,我不再认为问题是连接上的竞争条件-至少这似乎不是当前的错误。
var options = {
native_parser: true,
auto_reconnect: false,
poolSize: 10,
connectWithNoPrimary: true,
sslValidate: false
};
// mongoose.connect("mongodb://mongo-rs0-1,mongo-rs0-2,mongo-rs0-3/?replicaSet=rs0", { useNewUrlParser: true, connectWithNoPrimary: true });
const connectFunc = () => {
mongoose.connect("mongodb://mongo-rs0-1:27017,mongo-rs0-2:27017,mongo-rs0-3:27017/test?replicaSet=rs0", options);
mongoose.Promise = global.Promise;
var db = mongoose.connection;
db.on('error', (error)=>{
console.log('MongoDB connection error:', error)
console.log('now calling connectFunc() again');
connectFunc()
});
db.once('open', function() {
// we're connected!
console.log('connected to mongoose db')
});
}
connectFunc()
修改x4:
这里是另一个示例教程,但我遇到了相同的错误:https://gist.github.com/patientplatypus/e48e6efdcc9f0f1aa551cc8342d0f2f3。我现在一半相信这可能是自动/猫鼬的错误,所以我打开了一个错误报告,可以在这里查看:https://github.com/Automattic/mongoose/issues/7705。这可能与2016年提出的这一长期问题有关:https://github.com/Automattic/mongoose/issues/4596。
修改x5:
这是mongo容器之一的日志输出:
patientplatypus:~/Documents/patientplatypus.com/forum/back:19:47:11$docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d46cfb5e1927 nginx:mainline-alpine "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 0.0.0.0:80->80/tcp webserver
6798fe1f6093 back_nextjs "npm start" 3 minutes ago Up 3 minutes 0.0.0.0:3000->3000/tcp nextjs
ab6888f703c7 back_nodejs "/docker-entrypoint.…" 3 minutes ago Up 3 minutes 0.0.0.0:8000->8000/tcp nodejs
48131a82b34e mongo-start "docker-entrypoint.s…" 3 minutes ago Up 3 minutes 0.0.0.0:27017->27017/tcp mongo1
312772b1b0f1 mongo "docker-entrypoint.s…" 3 minutes ago Up 3 minutes 0.0.0.0:27019->27017/tcp mongo3
9fe9a16eb20e mongo "docker-entrypoint.s…" 3 minutes ago Up 3 minutes 0.0.0.0:27018->27017/tcp mongo2
patientplatypus:~/Documents/patientplatypus.com/forum/back:19:48:55$docker logs 9fe9a16eb20e
2019-04-12T00:45:29.689+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-04-12T00:45:29.727+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=9fe9a16eb20e
2019-04-12T00:45:29.728+0000 I CONTROL [initandlisten] db version v4.0.8
2019-04-12T00:45:29.728+0000 I CONTROL [initandlisten] git version: 9b00696ed75f65e1ebc8d635593bed79b290cfbb
2019-04-12T00:45:29.728+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-04-12T00:45:29.728+0000 I CONTROL [initandlisten] allocator: tcmalloc
2019-04-12T00:45:29.728+0000 I CONTROL [initandlisten] modules: none
2019-04-12T00:45:29.729+0000 I CONTROL [initandlisten] build environment:
2019-04-12T00:45:29.729+0000 I CONTROL [initandlisten] distmod: ubuntu1604
2019-04-12T00:45:29.729+0000 I CONTROL [initandlisten] distarch: x86_64
2019-04-12T00:45:29.729+0000 I CONTROL [initandlisten] target_arch: x86_64
2019-04-12T00:45:29.729+0000 I CONTROL [initandlisten] options: { net: { bindIpAll: true }, replication: { oplogSizeMB: 128, replSet: "rs" }, storage: { mmapv1: { smallFiles: true } } }
2019-04-12T00:45:29.734+0000 W STORAGE [initandlisten] Detected unclean shutdown - /data/db/mongod.lock is not empty.
2019-04-12T00:45:29.738+0000 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-04-12T00:45:29.741+0000 W STORAGE [initandlisten] Recovering data from the last clean checkpoint.
2019-04-12T00:45:29.742+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1461M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2019-04-12T00:45:43.165+0000 I STORAGE [initandlisten] WiredTiger message [1555029943:165420][1:0x7f7051ca9a40], txn-recover: Main recovery loop: starting at 7/4608 to 8/256
2019-04-12T00:45:43.214+0000 I STORAGE [initandlisten] WiredTiger message [1555029943:214706][1:0x7f7051ca9a40], txn-recover: Recovering log 7 through 8
2019-04-12T00:45:43.787+0000 I STORAGE [initandlisten] WiredTiger message [1555029943:787329][1:0x7f7051ca9a40], txn-recover: Recovering log 8 through 8
2019-04-12T00:45:43.849+0000 I STORAGE [initandlisten] WiredTiger message [1555029943:849811][1:0x7f7051ca9a40], txn-recover: Set global recovery timestamp: 0
2019-04-12T00:45:43.892+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-04-12T00:45:43.972+0000 W STORAGE [initandlisten] Detected configuration for non-active storage engine mmapv1 when current storage engine is wiredTiger
2019-04-12T00:45:43.972+0000 I CONTROL [initandlisten]
2019-04-12T00:45:43.972+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-04-12T00:45:43.972+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-04-12T00:45:43.973+0000 I CONTROL [initandlisten]
2019-04-12T00:45:44.035+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-04-12T00:45:44.054+0000 I REPL [initandlisten] Did not find local voted for document at startup.
2019-04-12T00:45:44.064+0000 I REPL [initandlisten] Rollback ID is 1
2019-04-12T00:45:44.064+0000 I REPL [initandlisten] Did not find local replica set configuration document at startup; NoMatchingDocument: Did not find replica set configuration document in local.system.replset
2019-04-12T00:45:44.065+0000 I CONTROL [LogicalSessionCacheRefresh] Sessions collection is not set up; waiting until next sessions refresh interval: Replication has not yet been configured
2019-04-12T00:45:44.065+0000 I NETWORK [initandlisten] waiting for connections on port 27017
2019-04-12T00:45:44.069+0000 I CONTROL [LogicalSessionCacheReap] Sessions collection is not set up; waiting until next sessions reap interval: config.system.sessions does not exist
2019-04-12T00:45:45.080+0000 I FTDC [ftdc] Unclean full-time diagnostic data capture shutdown detected, found interim file, some metrics may have been lost. OK
尤其是这一行
Did not find local replica set configuration document at startup; NoMatchingDocument: Did not find replica set configuration document in local.system.replset
看起来令人担忧,我将不得不继续研究它。如果有人看到任何东西,请告诉我。
EDITx6
所以我将docker执行到mongo副本之一并输出rs.status()。
我先使用docker exec -it mongo1 mongo
然后使用rs.status()
并得到以下输出:
{
"operationTime" : Timestamp(0, 0),
"ok" : 0,
"errmsg" : "no replset config has been received",
"code" : 94,
"codeName" : "NotYetInitialized",
"$clusterTime" : {
"clusterTime" : Timestamp(0, 0),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
这似乎与上面的mongodb副本日志(2019-04-12T00:45:44.064+0000 I REPL [initandlisten] Did not find local replica set configuration document at startup; NoMatchingDocument: Did not find replica set configuration document in local.system.replset
)中的错误非常相似。有人知道它认为的缺失吗?
答案 0 :(得分:1)
您需要初始化副本集才能访问它。否则,应用程序将无法连接到本地实例。
理想情况下,您需要在副本集配置(setup-rs
步骤)和下一个副本集配置之间增加一些时间,因为副本集配置所花费的时间可能会比应用程序启动时间更长。
或者如果脚本本身有问题,请修复该脚本。
答案 1 :(得分:0)
我有一个类似的问题。我经常收到“ MongoError:没有可用的mongos代理”错误。最终,我设法通过以下方式解决了该问题:
// The mongoose connection options
let options = {
ssl: true,
sslValidate: true,
poolSize: 1,
reconnectTries: 1,
useNewUrlParser: true,
dbName: 'myDb' // Specify the database here
}
我的连接字符串如下所示:
mongodb://<usr>:<pass>@host1.com:12345,host2.com:12346/adminDb?authSource=admin&ssl=true
我在连接字符串中保留了默认的管理数据库,而是在选项中定义了要连接的数据库。那解决了这个问题。
答案 2 :(得分:0)
可能您正在使用副本集,因此应调整您的连接字符串。
尝试在连接字符串的末尾添加参数replicaSet=rs0
这样就可以了。
mongodb://<usr>:<pass>@<host1>:<port1>,<host2>:<port2>/<database_name>?replicaSet=rs0<&otherParams>
答案 3 :(得分:0)
尝试使用var verify_fn1 = document.getElementById("sign_verify1");
var verify_fn = SignedData.Verify(szSignature, false, CAPICOM_VERIFY_SIGNATURE_ONLY);
verify_fn1.value = verify_fn;
/ Node.js 0.10
连接到副本集时出现此错误。该错误是由代理要求mongodb 2.2.36
引起的。
要解决此问题,请将您的TLS 1.2
运行时升级到Node.js
或更高版本。