[SERVER-20368] Only start a background thread for the active oplog in WT Created: 11/Sep/15  Updated: 06/Oct/15  Resolved: 06/Oct/15

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 3.1.7
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Max Hirschhorn
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: QuInt A (10/12/15)
Participants:

 Description   

WiredTigerKVEngine::initRsOplogBackgroundThread() starts a background thread for any namespace that starts with "local.oplog."

// static
bool WiredTigerKVEngine::initRsOplogBackgroundThread(StringData ns) {
    if (!NamespaceString::oplog(ns)) {
        return false;
    }
 
    if (storageGlobalParams.repair) {
        LOG(1) << "not starting WiredTigerRecordStoreThread for " << ns
               << " because we are in repair";
        return false;
    }
 
    stdx::lock_guard<stdx::mutex> lock(_backgroundThreadMutex);
    NamespaceString nss(ns);
    if (_backgroundThreadNamespaces.count(nss)) {
        log() << "WiredTigerRecordStoreThread " << ns << " already started";
    } else {
        log() << "Starting WiredTigerRecordStoreThread " << ns;
        BackgroundJob* backgroundThread = new WiredTigerRecordStoreThread(nss);
        backgroundThread->go();
        _backgroundThreadNamespaces.insert(nss);
    }
    return true;
}

Instead, it should only start a background thread for the oplog that will be inserted into when logOp() is called. A background thread should not be started if replication isn't enabled.

This allows users to do updates that change the size of a document on a non-active oplog after SERVER-19551.



 Comments   
Comment by Max Hirschhorn [ 06/Oct/15 ]

The intention of this ticket was to make it possible to update the size of a document in an oplog (i.e. a namespace starting with "local.oplog.") when it isn't the active oplog. Allowing updates on the active oplog would have complicated with the implementation of WT oplog stones in SERVER-19551. However, the changes from SERVER-20529 will make it so that updates to documents in a capped collection cannot change the size of the document ever.

It would be nice to start fewer background threads, but we need a better mechanism for conveying what the active oplog is to the storage engine without tying in the replication code. Closing this ticket as "Won't Fix".

Comment by Geert Bosch [ 05/Oct/15 ]

Isn't this OBE after SERVER-20529 (Prevent size changes in capped updates)?

Generated at Thu Feb 08 03:54:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.