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

Background index builds on replica set secondaries

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.5.0
    • Component/s: Replication
    • Labels:
      None

      Description

      At present, index builds on replica set secondaries are always performed in the foreground, and so are blocking. So under normal circumstances, all ordinary secondaries (i.e., ones without slavedelay) will start building an index at about the same time, and so all of them will block together.

        Issue Links

          Activity

          Hide
          dwight_10gen Dwight Merriman added a comment -

          there was a reason why it was incorrect to do the background build on the secondaries.

          we should fix it.

          Show
          dwight_10gen Dwight Merriman added a comment - there was a reason why it was incorrect to do the background build on the secondaries. we should fix it.
          Hide
          dwight_10gen Dwight Merriman added a comment -

          if( background && cc().isSyncThread() )

          { /* don't do background indexing on slaves. there are nuances. this could be added later but requires more code. */ log() << "info: indexing in foreground on this replica; was a background index build on the primary" << endl; background = false; }
          Show
          dwight_10gen Dwight Merriman added a comment - if( background && cc().isSyncThread() ) { /* don't do background indexing on slaves. there are nuances. this could be added later but requires more code. */ log() << "info: indexing in foreground on this replica; was a background index build on the primary" << endl; background = false; }
          Hide
          richard.kreuter Richard Kreuter added a comment -

          Is the issue that because only one background index build can happen at a time, if the secondary started a background index build and encounters a subsequent background build op in the oplog, it'd have to either pause replication or do something that amounts to enqueuing the second index build for later processing?

          If that's the only issue, then having a persisted queue of to-be-constructed indexes and a background thread that processes the queue could also mean that createIndex wouldn't have to fail while an index was under construction even in non-RS deployments.

          Show
          richard.kreuter Richard Kreuter added a comment - Is the issue that because only one background index build can happen at a time, if the secondary started a background index build and encounters a subsequent background build op in the oplog, it'd have to either pause replication or do something that amounts to enqueuing the second index build for later processing? If that's the only issue, then having a persisted queue of to-be-constructed indexes and a background thread that processes the queue could also mean that createIndex wouldn't have to fail while an index was under construction even in non-RS deployments.
          Hide
          robfan Sharethrough Engineering added a comment -

          Would love to see this on 1.8.x if at all possible. We create several new collections on a daily basis and add about 5 indices per collection created. With our current size (~1TB) adding an index after-the-fact takes about 15 hours and we can't afford to have the secondaries out of commission for so long.

          Show
          robfan Sharethrough Engineering added a comment - Would love to see this on 1.8.x if at all possible. We create several new collections on a daily basis and add about 5 indices per collection created. With our current size (~1TB) adding an index after-the-fact takes about 15 hours and we can't afford to have the secondaries out of commission for so long.
          Hide
          eliot Eliot Horowitz added a comment -

          @robert - this is basically a new feature, so highly unlikely to be backported to 1.8.
          2.0 should be out in late q2

          Show
          eliot Eliot Horowitz added a comment - @robert - this is basically a new feature, so highly unlikely to be backported to 1.8. 2.0 should be out in late q2
          Hide
          robfan Sharethrough Engineering added a comment -

          Gotcha, thanks Eliot. Doubly for your late-nightedness JIRA mastery Take care, Rob

          Show
          robfan Sharethrough Engineering added a comment - Gotcha, thanks Eliot. Doubly for your late-nightedness JIRA mastery Take care, Rob
          Hide
          dwight_10gen Dwight Merriman added a comment -

          nuances:

          • first the caller to background index doesn't return until that finishes, even though other things do continue. so if done in the initial sync thread it will likely stop until built even though other readers can keep going.
          • if there are unique key constraints, will the behavior be nondeterministic relative to the primary? i think so? one incremental step would be to do background for non-unique indexes as a start
          • what else that i'm forgetting?
          Show
          dwight_10gen Dwight Merriman added a comment - nuances: first the caller to background index doesn't return until that finishes, even though other things do continue. so if done in the initial sync thread it will likely stop until built even though other readers can keep going. if there are unique key constraints, will the behavior be nondeterministic relative to the primary? i think so? one incremental step would be to do background for non-unique indexes as a start what else that i'm forgetting?
          Hide
          dwight_10gen Dwight Merriman added a comment -

          one workaround would be to reconfigure with the secondary member having hidden : true, then create the index, background on primary and foreground on secondary but secondary is then effectively offline for clients. then afterwards go back to original replica set configuration.

          one detail here is that after reconf to hidden the secondary mongod probably needs to be restarted to make it drop existing client connections.

          Show
          dwight_10gen Dwight Merriman added a comment - one workaround would be to reconfigure with the secondary member having hidden : true, then create the index, background on primary and foreground on secondary but secondary is then effectively offline for clients. then afterwards go back to original replica set configuration. one detail here is that after reconf to hidden the secondary mongod probably needs to be restarted to make it drop existing client connections.
          Hide
          jeff.yemin@mtvstaff.com Jeff Yemin added a comment -

          Can someone explain why the master can do background indexing but secondaries can't? Why the need to make a secondary hidden just to build an index?

          Show
          jeff.yemin@mtvstaff.com Jeff Yemin added a comment - Can someone explain why the master can do background indexing but secondaries can't? Why the need to make a secondary hidden just to build an index?
          Hide
          nacuff@igodigital.com Nathan Acuff added a comment -

          Would it be possible to have the secondary go into a RECOVERING state, like it does when compacting? This would let you build indexes in a pinch without sprinkling rs.reconfig everywhere. The current behavior is much worse.

          Show
          nacuff@igodigital.com Nathan Acuff added a comment - Would it be possible to have the secondary go into a RECOVERING state, like it does when compacting? This would let you build indexes in a pinch without sprinkling rs.reconfig everywhere. The current behavior is much worse.
          Hide
          eliot Eliot Horowitz added a comment -

          Nathan - that could be bad if people are querying.
          This will be fixed for 2.2 so the index can be done in the background like on the primary.

          Show
          eliot Eliot Horowitz added a comment - Nathan - that could be bad if people are querying. This will be fixed for 2.2 so the index can be done in the background like on the primary.
          Hide
          nacuff@igodigital.com Nathan Acuff added a comment -

          An index build that takes longer than a couple of seconds is worse.

          Sounds like it's not going to be an issue though, and that's great.

          Show
          nacuff@igodigital.com Nathan Acuff added a comment - An index build that takes longer than a couple of seconds is worse. Sounds like it's not going to be an issue though, and that's great.
          Hide
          dwight_10gen Dwight Merriman added a comment -

          another case to analyze is that well into the bg create on the primary, a killOp stops the operation. as it were likely already placed in oplog, that would be an issue.

          Show
          dwight_10gen Dwight Merriman added a comment - another case to analyze is that well into the bg create on the primary, a killOp stops the operation. as it were likely already placed in oplog, that would be an issue.
          Hide
          redbeard0531 Mathias Stearn added a comment -

          Actually, I think we do want it blocking replication at least at first so that the getLastError(

          {w:'all'}

          ) semantics can be relied on to wait until the index is built on all nodes. This will allow the slave to fall behind, but this is a current issue with building in forground so at least it isn't a regression (other than being slower so increased likely hood of falling out of sync).

          Since we know there will be no other writes to the slave while the index is building would it be possible to do an optimized background build, or maybe even a foreground build that yields or fakes it by using a read lock?

          Show
          redbeard0531 Mathias Stearn added a comment - Actually, I think we do want it blocking replication at least at first so that the getLastError( {w:'all'} ) semantics can be relied on to wait until the index is built on all nodes. This will allow the slave to fall behind, but this is a current issue with building in forground so at least it isn't a regression (other than being slower so increased likely hood of falling out of sync). Since we know there will be no other writes to the slave while the index is building would it be possible to do an optimized background build, or maybe even a foreground build that yields or fakes it by using a read lock?
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}

          Message: Allow background indexes while in secondary state SERVER-2771
          Branch: master
          https://github.com/mongodb/mongo/commit/72dcc0b296306fc432f52ada8eedf4814c791b68

          Show
          auto auto (Inactive) added a comment - Author: {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'} Message: Allow background indexes while in secondary state SERVER-2771 Branch: master https://github.com/mongodb/mongo/commit/72dcc0b296306fc432f52ada8eedf4814c791b68
          Hide
          kristina Kristina Chodorow (Inactive) added a comment -

          Index builds will now happen in the background on secondaries if they happen in the background on the primary. This means that reads can continue while the index builds. However, replication will block until the index build is complete.

          Please see http://www.mongodb.org/display/DOCS/Building+indexes+with+replica+sets#Buildingindexeswithreplicasets-Version2.1.0andlater for details.

          Show
          kristina Kristina Chodorow (Inactive) added a comment - Index builds will now happen in the background on secondaries if they happen in the background on the primary. This means that reads can continue while the index builds. However, replication will block until the index build is complete. Please see http://www.mongodb.org/display/DOCS/Building+indexes+with+replica+sets#Buildingindexeswithreplicasets-Version2.1.0andlater for details.
          Hide
          scotthernandez Scott Hernandez (Inactive) added a comment -

          On a unique, background, dropDups build we should do this synchronously since the order of the drops must be deterministic so replication isn't broken.

          Show
          scotthernandez Scott Hernandez (Inactive) added a comment - On a unique, background, dropDups build we should do this synchronously since the order of the drops must be deterministic so replication isn't broken.
          Hide
          schwerin Andy Schwerin added a comment -

          Correct handling of background operations on secondaries is going to require a more thorough examination of the concurrency model.

          Show
          schwerin Andy Schwerin added a comment - Correct handling of background operations on secondaries is going to require a more thorough examination of the concurrency model.
          Hide
          milkie Eric Milkie added a comment -

          Implementation will proceed as per new technical spec. This will affect all background index builds (not just on secondaries).

          Show
          milkie Eric Milkie added a comment - Implementation will proceed as per new technical spec. This will affect all background index builds (not just on secondaries).
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-10-09T10:24:41-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'}

          Message: SERVER-2771 preliminary code cleanup; no functional change
          Branch: master
          https://github.com/mongodb/mongo/commit/7922e03d36d059a6602541d83b6a26224e6178dd

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-10-09T10:24:41-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'} Message: SERVER-2771 preliminary code cleanup; no functional change Branch: master https://github.com/mongodb/mongo/commit/7922e03d36d059a6602541d83b6a26224e6178dd
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-10-10T13:18:34-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'}

          Message: SERVER-2771 add synchronous kill functionality for background indexing support
          Branch: master
          https://github.com/mongodb/mongo/commit/800eea522786a5a80cec62a6eafc382b3bc377bf

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-10-10T13:18:34-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'} Message: SERVER-2771 add synchronous kill functionality for background indexing support Branch: master https://github.com/mongodb/mongo/commit/800eea522786a5a80cec62a6eafc382b3bc377bf
          Hide
          adamaflynn Adam Flynn added a comment -

          I'd second Nathan's suggestion of adding an option to put the secondary into recovery state in this case as short-term solution to this problem since the fix didn't make it into 2.2. For any index build longer than a few seconds, I think killing the pending queries by going into recovery mode is a good trade-off for the extra operational overhead of doing what the docs propose currently or doing a replica set reconfig to go to hidden and back. Any chance of getting a change like that into 2.2.x while we wait for the secondary background indexing in 2.4?

          Show
          adamaflynn Adam Flynn added a comment - I'd second Nathan's suggestion of adding an option to put the secondary into recovery state in this case as short-term solution to this problem since the fix didn't make it into 2.2. For any index build longer than a few seconds, I think killing the pending queries by going into recovery mode is a good trade-off for the extra operational overhead of doing what the docs propose currently or doing a replica set reconfig to go to hidden and back. Any chance of getting a change like that into 2.2.x while we wait for the secondary background indexing in 2.4?
          Hide
          kristina Kristina Chodorow (Inactive) added a comment -

          Probably not, as there is a workaround (http://docs.mongodb.org/manual/administration/indexes/#index-building-replica-sets, as you mentioned) and we'd like to concentrate on getting this totally done for 2.4.

          Show
          kristina Kristina Chodorow (Inactive) added a comment - Probably not, as there is a workaround ( http://docs.mongodb.org/manual/administration/indexes/#index-building-replica-sets , as you mentioned) and we'd like to concentrate on getting this totally done for 2.4.
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-11-12T15:19:43Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Retry index builds on startup
          Branch: master
          https://github.com/mongodb/mongo/commit/ab9ff1d3ecc7163fc93188efd997bbacd8fe7406

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-11-12T15:19:43Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Retry index builds on startup Branch: master https://github.com/mongodb/mongo/commit/ab9ff1d3ecc7163fc93188efd997bbacd8fe7406
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-11-12T16:50:12Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: Revert "SERVER-2771 Retry index builds on startup"

          This reverts commit ab9ff1d3ecc7163fc93188efd997bbacd8fe7406.
          Branch: master
          https://github.com/mongodb/mongo/commit/3abcc53d43145bcda52016c753e10ff139d41e4d

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-11-12T16:50:12Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: Revert " SERVER-2771 Retry index builds on startup" This reverts commit ab9ff1d3ecc7163fc93188efd997bbacd8fe7406. Branch: master https://github.com/mongodb/mongo/commit/3abcc53d43145bcda52016c753e10ff139d41e4d
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-11-12T15:19:43Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Retry index builds on startup
          Branch: master
          https://github.com/mongodb/mongo/commit/ab1bceba74845666aaad957cab256cadf2a0c8de

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-11-12T15:19:43Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Retry index builds on startup Branch: master https://github.com/mongodb/mongo/commit/ab1bceba74845666aaad957cab256cadf2a0c8de
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-11-12T16:58:14Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Fix tests that use addIndex
          Branch: master
          https://github.com/mongodb/mongo/commit/d9df6423f805b5cd1dc7717b62a13aae9ce3778a

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-11-12T16:58:14Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Fix tests that use addIndex Branch: master https://github.com/mongodb/mongo/commit/d9df6423f805b5cd1dc7717b62a13aae9ce3778a
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-13T19:36:27Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Multiple index builds
          Branch: master
          https://github.com/mongodb/mongo/commit/2812b757dd25de5ca22c3c84135f3c654ffcb928

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-13T19:36:27Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Multiple index builds Branch: master https://github.com/mongodb/mongo/commit/2812b757dd25de5ca22c3c84135f3c654ffcb928
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-17T16:39:26Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Add debugging to test
          Branch: master
          https://github.com/mongodb/mongo/commit/41cce287ffad7ea0c04facdd0986631bade7d027

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-17T16:39:26Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Add debugging to test Branch: master https://github.com/mongodb/mongo/commit/41cce287ffad7ea0c04facdd0986631bade7d027
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-26T21:56:49Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Command handling
          Branch: master
          https://github.com/mongodb/mongo/commit/2f21426abe2d75487c91fb361154261969d303cd

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-26T21:56:49Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Command handling Branch: master https://github.com/mongodb/mongo/commit/2f21426abe2d75487c91fb361154261969d303cd
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-27T00:53:37Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Make foreground indexes not create a client
          Branch: master
          https://github.com/mongodb/mongo/commit/283fc0d291c196232cebc8b964178037aa71f943

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-27T00:53:37Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Make foreground indexes not create a client Branch: master https://github.com/mongodb/mongo/commit/283fc0d291c196232cebc8b964178037aa71f943
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-27T00:59:22Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Use multiplatform sleep function
          Branch: master
          https://github.com/mongodb/mongo/commit/325ec6e4d66dfdc075b47a804314eec8f7ea3eb2

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-27T00:59:22Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Use multiplatform sleep function Branch: master https://github.com/mongodb/mongo/commit/325ec6e4d66dfdc075b47a804314eec8f7ea3eb2
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-27T01:42:47Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Fix test to handle other tests not cleaning up
          Branch: master
          https://github.com/mongodb/mongo/commit/c5e5e6b9c0d9609234afd1390984d08f6055801b

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-27T01:42:47Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Fix test to handle other tests not cleaning up Branch: master https://github.com/mongodb/mongo/commit/c5e5e6b9c0d9609234afd1390984d08f6055801b
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-27T02:23:22Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Fix compact index kill criteria
          Branch: master
          https://github.com/mongodb/mongo/commit/7962e49b40c2bf344187df4c6fdd857c2255d759

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-27T02:23:22Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Fix compact index kill criteria Branch: master https://github.com/mongodb/mongo/commit/7962e49b40c2bf344187df4c6fdd857c2255d759
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2012-12-28T20:05:56Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Test fixes
          Branch: master
          https://github.com/mongodb/mongo/commit/e733331c7edb8871ba2dc58f20fbd2f40bf3adda

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2012-12-28T20:05:56Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Test fixes Branch: master https://github.com/mongodb/mongo/commit/e733331c7edb8871ba2dc58f20fbd2f40bf3adda
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2013-01-02T15:41:44Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

          Message: SERVER-2771 Revert command handling

          This reverts commit e733331c7edb8871ba2dc58f20fbd2f40bf3adda.
          This reverts commit ccf86a0fdbe7f9c9a45e8fad0410a7eef777fea2.
          This reverts commit 7962e49b40c2bf344187df4c6fdd857c2255d759.
          This reverts commit c5e5e6b9c0d9609234afd1390984d08f6055801b.
          This reverts commit 325ec6e4d66dfdc075b47a804314eec8f7ea3eb2.
          This reverts commit 283fc0d291c196232cebc8b964178037aa71f943.
          This reverts commit 2f21426abe2d75487c91fb361154261969d303cd.
          Branch: master
          https://github.com/mongodb/mongo/commit/e04a7396ea753ea6dbff89028c11ed689868d707

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2013-01-02T15:41:44Z', u'email': u'kristina@10gen.com', u'name': u'Kristina'} Message: SERVER-2771 Revert command handling This reverts commit e733331c7edb8871ba2dc58f20fbd2f40bf3adda. This reverts commit ccf86a0fdbe7f9c9a45e8fad0410a7eef777fea2. This reverts commit 7962e49b40c2bf344187df4c6fdd857c2255d759. This reverts commit c5e5e6b9c0d9609234afd1390984d08f6055801b. This reverts commit 325ec6e4d66dfdc075b47a804314eec8f7ea3eb2. This reverts commit 283fc0d291c196232cebc8b964178037aa71f943. This reverts commit 2f21426abe2d75487c91fb361154261969d303cd. Branch: master https://github.com/mongodb/mongo/commit/e04a7396ea753ea6dbff89028c11ed689868d707
          Hide
          colinhowe Colin Howe added a comment -

          We just got hit by this... all our slaves stopped responding to queries and our clients just hung (no timeouts). Looking forward to seeing a fix!

          Show
          colinhowe Colin Howe added a comment - We just got hit by this... all our slaves stopped responding to queries and our clients just hung (no timeouts). Looking forward to seeing a fix!
          Hide
          auto auto (Inactive) added a comment -

          Author:

          {u'date': u'2013-01-25T16:52:45Z', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'}

          Message: SERVER-2771 --noIndexBuildRetry does not take a param
          Branch: master
          https://github.com/mongodb/mongo/commit/7a8fdfc75c26efc9aa4b3849587ef0995ffd9a36

          Show
          auto auto (Inactive) added a comment - Author: {u'date': u'2013-01-25T16:52:45Z', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'} Message: SERVER-2771 --noIndexBuildRetry does not take a param Branch: master https://github.com/mongodb/mongo/commit/7a8fdfc75c26efc9aa4b3849587ef0995ffd9a36
          Hide
          colinhowe Colin Howe added a comment -

          Could we get an update on what is happening here? Some of the comments indicate that this was fixed in 2.2, some say 2.4 and then the status says 2.5.

          We just got bitten by this (again) after thinking that it was fixed 2.2.3...

          Pulling things out of replica sets to add indices really isn't a viable option. At least not for something that claims to make scaling easy with things like sharding support.

          Show
          colinhowe Colin Howe added a comment - Could we get an update on what is happening here? Some of the comments indicate that this was fixed in 2.2, some say 2.4 and then the status says 2.5. We just got bitten by this (again) after thinking that it was fixed 2.2.3... Pulling things out of replica sets to add indices really isn't a viable option. At least not for something that claims to make scaling easy with things like sharding support.
          Hide
          milkie Eric Milkie added a comment -

          The fixVersion field, version 2.5.0, is the current target for this. We have one more thing to iron out before releasing this feature.

          Show
          milkie Eric Milkie added a comment - The fixVersion field, version 2.5.0, is the current target for this. We have one more thing to iron out before releasing this feature.

            People

            • Votes:
              27 Vote for this issue
              Watchers:
              40 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: