[SERVER-1969] Arbiter allocates capped local.oplog.rs collection (unnecessarily?) Created: 19/Oct/10  Updated: 12/Jul/16  Resolved: 21/Oct/10

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 1.6.0
Fix Version/s: 1.7.2

Type: Bug Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Kristina Chodorow (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

When an arbiter is added to a replicaset it allocates a large chunk of disk for the oplog which is not needed (and def. not at that size).

This will cause problems for people trying to use 32bit machines for this purpose.



 Comments   
Comment by auto [ 21/Oct/10 ]

Author:

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

Message: don't allocate oplog for arbiter SERVER-1969
http://github.com/mongodb/mongo/commit/57aecc7f77f848935c4fd946eb16cf55bb77993b

Comment by Scott Hernandez (Inactive) [ 20/Oct/10 ]

What about not allocating the oplog until a replicaset is initialized/configured on that node? Why does it need to exist before being configured/init'd?

It would require a --repair/repairDatabase to release the space if it is dropped and re-created. In most cases a repair on the local db will be extremely fast, and also once auto-compaction (assuming it will release disk space) is implemented then that could help as well.

Comment by Kristina Chodorow (Inactive) [ 20/Oct/10 ]

We recommend people start arbiters with --oplogSize 1, I'm not sure what else can be done here. Maybe the --arbiter command line option should set --oplogSize to 1 if used with --replSet.

The problem is that by the time you initialize the replica set (and the arbiter knows it's going to be an arbiter), the oplog's already been allocated. We could drop the oplog at that point, but it won't actually free the space (since MongoDB holds freed collection space in reserve to use later).

Generated at Thu Feb 08 02:58:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.