Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-54445

Compact in Secondary ReplicaSet 4.4.0 change member state

    • Type: Icon: Question Question
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 4.4.0
    • Component/s: Build, Logging, Replication
    • Labels:
      None
    • Environment:
      OS:
      18.04.4 LTS (Bionic Beaver)

      We have a replicaSet in version 4.4.0 with 1 primary and 2 secondary, as per rs.conf below:

      _"members" : [
      {
      "_id" : 4,
      "host" : "10.208.0.102:27017",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 6,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
      },
      {
      "_id" : 5,
      "host" : "10.208.0.101:27017",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 7,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
      },
      {
      "_id" : 6,
      "host" : "10.208.0.104:27017",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 5,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
      }
      ]_

      When executing a compact on the secondary member (.104) at 12:08, it entered maintenance mode and after that the other secondary member (.102) started to delay synchronization and we started to have unavailability in the applications that were connecting secondary instances.

      After some delay in replication, I stopped the service at around 12:22 and the .102 instance was back in sync with the primary. Then at 12:28 I started the .104 secondary service and everything went back to normal.

      Therefore, I have the following questions:

      1 - Why did the .104 member enter maintenance mode, and the MongoDB documentation states that in version 4.4 the compact does not change the state and can be run at any time? (https://docs.mongodb.com/manual/release-notes/4.4/#compact-behavior-change);

      2 - Even if the status of the .104 secondary member has changed, why was the secondary (.102) affected?

      3 - Even if the secondary .102 had the .104 member as syncSource, once it entered maintenance mode, it should change the syncSource for the primary instance, right? Because in the documentation it informs that it needs to be PRIMARY or SECONDARY (https://docs.mongodb.com/manual/core/replica-set-sync/#initial-sync-source-selection)

      Is it a version bug?

      Thank you!

        1. logcompact_primary.log
          151 kB
        2. logcompact_secondary_2.log
          440 kB
        3. logcompact_secondary_4.log
          24 kB

            Assignee:
            dmitry.agranat@mongodb.com Dmitry Agranat
            Reporter:
            flavioliroa@gmail.com Flavio Liroa Jr
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: