Як я (безпечно) вбиваю тривалі операції в MongoDB?


11

Іноді операції виходять з-під контролю в MongoDB і можуть закінчитися сотнями секунд і впливати на ефективність, поки вони не будуть вбиті або завершені.

Коли це трапляється, я знаю, що у мене є killOp()доступність, але як я вбиваю лише цільові тривалі операції, не вбиваючи (наприклад) тривалих операцій, що беруть участь у реплікації (що може бути небезпечно)?

Відповіді:


15

Це може бути трохи хитро, але той факт, що оболонка MongoDB - це в основному інтерпретатор Javascript, дає нам гідні варіанти щодо фільтрації. Ось функція, яку я використовую для цього:

// kills long running ops in MongoDB (taking seconds as an arg to define "long")
// attempts to be a bit safer than killing all by excluding replication related operations
// and only targeting queries as opposed to commands etc.
killLongRunningOps = function(maxSecsRunning) {
    currOp = db.currentOp();
    for (oper in currOp.inprog) {
        op = currOp.inprog[oper-0];
        if (op.secs_running > maxSecsRunning && op.op == "query" && !op.ns.startsWith("local")) {
            print("Killing opId: " + op.opid
            + " running over for secs: "
            + op.secs_running);
            db.killOp(op.opid);
        }
    }
};

Це знищить запити лише вище maxSecsRunningпорогового значення і не торкнеться нічого, що працює проти localбази даних, і саме там oplogживе життя (а значить, і база даних, яка бере участь у довготривалому операційному режимі реплікації. Додавання критеріїв до внутрішнього ifумовного відношення досить легко). точніше цільові операції в міру необхідності на основі конкретних потреб.

Код також доступний як суть (де я буду пам'ятати, щоб постійно його оновлювати).


Я бачив кілька сценаріїв для цього. Тим не менш, перевірити, чи працює операція проти локальної бази даних - приємне поліпшення.
Жоао

так - я це неодноразово розглядав і бачив публікацію в блозі з дуже небезпечним сценарієм для вбивства оперів, тому думав, що дам собі гарну та легко пов’язану версію
Adam C

3
Я вважаю, що це небезпечний сценарій принаймні при використанні реплікацій. Працюючи db.currentOp()на нашій роздробленій базі даних, повертаються операції в просторі імен ("aka ns:" "), які дуже довго працюють з desc" працівником відписувача n "(де n - ціле число). Я б запропонував додати білі простори імен до ваших фактичних баз даних із запитами, які ви можете вбити. Щось подібне && (['users', 'analytics'].indexOf(op.ns) != -1)замість !op.ns.startsWithумови.
runamok

Добре, і цілком можливо, що порожні простори імен трапляються частіше в новіших версіях - я спочатку мав намір постійно оновлювати сценарій, але зараз залишив MongoDB, тому навряд чи боюся. Якщо ви подасте оновлений код (із зауваженням, що він стосується пізніших версій) тут, як відповідь, я з радістю проголосую за вас :)
Адам C
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.