Проблемы с набором реплик и хвостами оплогов в MongoDB 4.x - PullRequest
Новая
       29

Проблемы с набором реплик и хвостами оплогов в MongoDB 4.x

0 голосов
/ 27 февраля 2019

Я перевожу свое приложение на новый сервер, и у меня не получается настроить хвосты оплогов.Идея состоит в том, чтобы настроить один набор реплик, чтобы у моего приложения Meteor был оплог.Я следовал тому же процессу, что и на старом сервере, где он работает нормально.

На моем MongoDB нет контроля доступа, поскольку он доступен только локально.

Старый сервер:

Ubuntu 16.04

Версия оболочки MongoDB v3.4.1

Новый сервер:

Ubuntu 1.04

Версия оболочки MongoDB v4.0.6

Я использую Phusion Passenger для обслуживания приложения Meteor 1.6.

Вот как я настроил набор реплик:

/ etc / mongod.conf 

replication:
  replSetName: rs0
  oplogSizeMB: 100

/etc / hosts / 

127.0.1.1 myhostname myhostname
127.0.0.1 localhost
127.0.0.1 myhostname

Перезапустите MongoDB.Затем в оболочке Mongo: 

use local
rs.initiate()

В моем конфиге Passenger:

sudo nano /etc/nginx/sites-enabled/myappname.conf

passenger_env_var MONGO_OPLOG_URL mongodb://localhost:27017/local;

Иперезапустите Nginx.

Я проверил состояние набора реплик в оболочке Mongo с помощью rs.conf (): 

{
    "_id" : "rs0",
    "version" : 1,
    "protocolVersion" : NumberLong(1),
    "writeConcernMajorityJournalDefault" : true,
    "members" : [
        {
            "_id" : 0,
            "host" : "127.0.0.1:27017",
            "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("5c7580c68631363039a485f1")
    }
}

Однако в журнале Mongo / var / log / mongodb / mongod.log Я вижу это: 

2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] New replica set config in use: { _id: "rs0", version: 1, protocolVersion: 1, writeConcernMajorityJournalDefault: true, members: [ { _id: 0, host: "127.0.0.1:27017", arbiterOnly: false, buildIndexes: true, hidden: false, priority: 1.0, tags: {}, slaveDelay: 0, votes: 1 } ], settings: { chainingAllowed: true, heartbeatIntervalMillis: 2000, heartbeatTimeoutSecs: 10, electionTimeoutMillis: 10000, catchUpTimeoutMillis: -1, catchUpTakeoverDelayMillis: 30000, getLastErrorModes: {}, getLastErrorDefaults: { w: 1, wtimeout: 0 }, replicaSetId: ObjectId('5c7580c68631363039a485f1') } }
2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] This node is 127.0.0.1:27017 in the config
2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] transition to STARTUP2 from STARTUP
2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] Starting replication storage threads
2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] transition to RECOVERING from STARTUP2
2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] Starting replication fetcher thread
2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] Starting replication applier thread
2019-02-27T10:26:14.783+0000 I REPL     [replexec-0] Starting replication reporter thread
2019-02-27T10:26:14.784+0000 I NETWORK  [LogicalSessionCacheRefresh] Starting new replica set monitor for rs0/127.0.0.1:27017
2019-02-27T10:26:14.784+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:34490 #2 (1 connection now open)
2019-02-27T10:26:14.785+0000 I REPL     [rsSync-0] Starting oplog application
2019-02-27T10:26:14.785+0000 I REPL     [rsSync-0] transition to SECONDARY from RECOVERING
2019-02-27T10:26:14.785+0000 I REPL     [rsSync-0] conducting a dry run election to see if we could be elected. current term: 1
2019-02-27T10:26:14.785+0000 I REPL     [replexec-0] dry election run succeeded, running for election in term 2
2019-02-27T10:26:14.786+0000 I NETWORK  [conn2] received client metadata from 127.0.0.1:34490 conn2: { driver: { name: "MongoDB Internal Client", version: "4.0.6" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "18.04" } }
2019-02-27T10:26:14.786+0000 I NETWORK  [LogicalSessionCacheRefresh] Successfully connected to 127.0.0.1:27017 (1 connections now open to 127.0.0.1:27017 with a 5 second timeout)
2019-02-27T10:26:14.786+0000 I REPL     [replexec-0] election succeeded, assuming primary role in term 2
2019-02-27T10:26:14.786+0000 I REPL     [replexec-0] transition to PRIMARY from SECONDARY
2019-02-27T10:26:14.786+0000 I REPL     [replexec-0] Resetting sync source to empty, which was :27017
2019-02-27T10:26:14.786+0000 I REPL     [replexec-0] Entering primary catch-up mode.
2019-02-27T10:26:14.786+0000 I REPL     [replexec-0] Exited primary catch-up mode.
2019-02-27T10:26:14.786+0000 I REPL     [replexec-0] Stopping replication producer
2019-02-27T10:26:14.787+0000 W NETWORK  [LogicalSessionCacheRefresh] Unable to reach primary for set rs0

Сообщение "Невозможно достичь первичного уровня для set rs0" предполагает, что оно не работает, а также в файле mongod.log, который я вижу, запросы регистрируются более 100 мс, которые не должныэто может произойти, если работает оплог.

Есть идеи, что может быть не так?Что-то изменилось между версиями MongoDB?Я охотился, но не нашел ответов.

Спасибо за любую помощь!

...