Управление на журналирането в MongoDB

MongoDB, както всяка друга база данни, може да се провали при изпълнение на операция за запис. В този случай се нуждаем от стратегия, която ще запази операцията някъде, така че базата данни да може да се възобнови, когато бъде възстановена обратно към работа.

В MongoDB използваме дневникиране, при което има записване напред в журналните файлове на диска, за да запазим данните налични в случай на неуспех. Машината за съхранение на WiredTiger може да използва контролни точки, за да осигури последователен изглед на данните на диска и да позволи на MongoDB да се възстанови от последната контролна точка, но само ако не е излязла неочаквано. В противен случай, за информацията, възникнала по време на последната контролна точка, журналирането трябва да е активирано за възстановяване на такива данни.

Процедурата за процеса на възстановяване е, че:базата данни ще търси във файловете с данни, за да намери идентификатора на последната контролна точка, използва този идентификатор, за да търси във файловете на журнала записа, който съвпада с него и след това приложете операциите във файловете на дневника от последната контролна точка.

Как работи журналирането в WiredTiger Storage Engine

За всеки клиент, който инициира операция на запис, WiredTiger създава запис в дневника, който се състои от вътрешни операции на запис, задействани от първоначалното записване. Помислете за документ в колекция, който трябва да бъде актуализиран и очакваме и неговият индекс да бъде променен. WiredTiger ще създаде един запис в дневника, който ще включва операцията за актуализиране и съответните модификации на индекса.

Този запис ще бъде съхранен в буфер в паметта, чийто максимален капацитет е 128 kB. След това механизмът за съхранение синхронизира тези буферирани записи в дневника с диск, когато е изпълнено някое от следните:

Операцията за запис включва/подразбира загриженост за запис от j:true.
WiredTiger създава нов файл с дневник, който е след всеки 100MB данни.
След всеки 100 милисекунди в зависимост от storage.journal.commitIntervalMs.
В случай на членове на набора от реплика:
- Екземпляр на операции, чакащи записи в oplog, т.е. операции за четене, извършени като част от причинно-следствени сесии и препращане на заявки за сканиране към oplog.
- След всяко пакетно приложение на записите в oplog в случай на второстепенните членове.

В случай на тежко изключване на mongod, ако операциите по запис са били в процес, актуализациите могат да бъдат загубени, дори ако записите в дневника останат в буферите на WiredTiger.

Компресиране на данни в дневника

Настройката по подразбиране в MongoDB насочва WiredTiger да използва бърза компресия за данните в дневника. Това може да се промени в зависимост от това кой алгоритъм за компресиране може да искате, като използвате настройката storage.wiredTiger.engineConfig.journalCompressor. Тези регистрационни записи се компресират само ако размерът им е по-голям от 128 байта, което е минималният размер на регистрационния запис на WiredTiger.

Ограничаване на размера на журналния файл

Максималният размер на файл на дневник е 100 MB и следователно, ако файлът надхвърли това ограничение, ще бъде създаден нов.

След като файлът на дневника е бил използван при възстановяване или по-скоро има файлове, по-стари от този, който може да се използва за възстановяване от последната контролна точка, WiredTiger автоматично ги премахва.

Предварително разпределение

Журналните файлове могат да бъдат предварително разпределени с механизма за съхранение на WiredTiger, ако процесът mongod определи, че е по-ефективно да се разпределят предварително файлове на дневници, отколкото да се създават нови.

Как работи журналирането в механизма за съхранение в памет

Механизмът за съхранение в паметта е посочен като част от общата наличност (GA), започвайки с MongoDB Enterprise версия 3.2.6. С този механизъм за съхранение данните се съхраняват в паметта, следователно няма отделна техника за журналиране. Ако има операции по запис с проблем за запис (j:вярно), те ще бъдат незабавно потвърдени.

За набор от реплика с член с право на глас , използващ механизма за съхранение в паметта, трябва да зададете writeConcernMajorityJournalDefault на false. В противен случай, ако това е зададено на true, наборът от реплика ще регистрира предупреждение за стартиране.

Когато тази опция е зададена на false, базата данни няма да чака w:“мнозинство” запис да бъде записано в дневника на диска, преди да потвърди записите. Недостатъкът на този подход е, че при мнозинство операциите за запис могат да се върнат назад в случай на преходна загуба (като рестартиране или срив) на повечето възли в даден набор от реплики.

Ако използвате механизма за съхранение MMapv1, предварителното разпределение на журнала може да бъде деактивирано чрез опцията --nopreallocation при стартиране на mongod.

С механизма за съхранение на WiredTiger, от MongoDB версия 4.0 нагоре, не е възможно да се посочи опцията --nojournal или дори storage.journal.enabled:false за членове на набор от реплики, използващи механизма за съхранение на WiredTiger.

Управление на журналирането

Деактивиране на водене в журнал

Журналирането може да бъде деактивирано само за самостоятелни внедрявания и не се препоръчва за производствени системи. За MongoDB версия 4.0 нагоре не може да се посочи нито опцията --nojournal, нито storage.journal.enabled:false, когато участват членове на набора от реплики, които използват механизма за съхранение на WiredTiger.

За да деактивирате журналирането, стартирайте mongod с опцията за командния ред --nojournal.

Наблюдавайте състоянието на журнала

За да получите статистика за дневника, използвайте командата db.serverStatus(), която връща wiredTiger.log.

Получаване на потвърждение за ангажимент

Използваме загрижеността за запис с опцията j, за да получим потвърждение за извършване. {j:вярно}. В този случай журналирането трябва да бъде активирано, в противен случай екземплярът на mongod може да доведе до грешка.

Ако воденето на журнал е активирано, w:„мнозинство“, това може да означава j:вярно.

За набор от реплики, когато j:true, настройката изисква само основният да пише в дневника, независимо от проблема w: при запис.

Въпреки това, дори ако j:true е конфигуриран за набор от реплика, може да възникне връщане назад поради първичен отказ при отказ на набор от реплики.

Неочаквано възстановяване на данни при изключване

Всички файлове на журнала в директорията на журнала се възпроизвеждат всеки път, когато MongoDB се рестартира от срив, преди сървърът да бъде открит. Тъй като тази операция ще бъде записана в изхода на журнала, няма да е необходимо да изпълнявате --repair.

Промяна на компресора на WiredTiger Journal

Snappy компресорът е алгоритъмът по подразбиране за компресиране за дневника. Това обаче може да се промени в зависимост от настройката на mongod instance.

За самостоятелен екземпляр на mongod:

Задайте Storage.wiredTiger.engineConfig.journalCompressor на нова стойност, за да го актуализирате. Най-подходящият начин да направите това е чрез конфигурационния файл, но ако използвате опциите на командния ред, трябва да актуализирате опцията --wiredTigerJournalCompressor на командния ред по време на рестартиране.
Изключете екземпляра mongod, като се свържете с mongo shell на екземпляра и издадете командата:db.shutdownServer() или db.getSiblingDB('admin ).shutdownServer()
Рестартирайте екземпляра mongod:
1. Ако използвате конфигурационния файл, използвайте:mongod -f <път до file.conf>
2. Ако използвате опции от командния ред, актуализирайте wiredTigerJournalCompressor:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

За член на набор от реплики:

Изключване на екземпляра на mongod:db.shutdownServer() или db.getSiblingDB(‘admin).shutdownServer()
Направете следните промени в конфигурационния файл:
1. Задайте storage.journal.enabled на false.
2. Коментирайте настройките за репликация
3. Задайте параметъра disableLogicalSessionCacheRefresh на true.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Рестартирайте екземпляра mongod:
1. Ако използвате конфигурационния файл, използвайте:mongod -f <път към file.conf>
2. Ако използвате опциите на командния ред:включете опцията --nojournal, премахнете всички опции на командния ред за репликация т.е --replSet и задайте параметъра disableLogicalSessionCacheRefresh на true
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Изключване на екземпляра mongod:

db.shutdownServer() or db.getSiblingDB(‘admin).shutdownServer()

Актуализирайте конфигурационния файл, за да се подготвите за рестартиране на члена на набора от реплики с новия компресор на журнала:Премахнете хранилището. journal.enabled, декоментирайте настройките за репликация за разполагането, премахнете опцията disableLogicalSessionCacheRefresh и накрая премахнете storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Рестартирайте екземпляра mongod като член на набора реплики

Ако използвате конфигурационния файл, използвайте:mongod -f <път до file.conf>
Ако използвате опциите на командния ред:премахнете опциите --nojournal и --wiredTigerJournalCompressor. Включете опциите на командния ред за репликация и премахнете параметъра disableLogicalSessionCacheRefresh.

mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...

Заключение

За да може MongoDB да гарантира трайност на операцията на запис, се използва дневник, при който данните се записват на диска напред сеч. Доколкото механизмът за съхранение на WiredTiger (който е най-предпочитаният) може да възстанови данни през последните контролни точки, ако MongoDB излезе неочаквано и журналирането не е активирано, възстановяването на такива данни става невъзможно. В противен случай, ако журналирането е активирано, MongoDB може да приложи повторно операциите за запис при рестартиране и да поддържа последователно състояние.