Мой вторичный сервер БД вышел из строя, поэтому я загружаю запасной вторичный сервер и пытаюсь выполнить первоначальную синхронизацию. Я следил за учебными пособиями и советами по использованию RAIS 10 в Amazon EBS.
Поэтому я использовал 4x4 ГБ EBS в RAID 10 со следующей настройкой (это было тогда предложено mongodb)
sudo lvcreate -l 90%vg -n data vg0
sudo lvcreate -l 5%vg -n log vg0
sudo lvcreate -l 5%vg -n journal vg0
Поскольку моя первичная версия начинает устареть (v3.2), я одновременно пытаюсь перейти на 3.4, поэтому я просто загрузил вторичную версию на 3.4 (на случай, если это может иметь отношение к проблеме)
Проблема в том, что во время начальной синхронизации MongoDB заполняет слишком много файлов журнала в / journal, всего выделяется 4 файла журнала по 100 МБ.
ec2-user@secondary$ ll /journal/
total 369105
drwx------ 2 root root 12288 Apr 3 14:47 lost+found
-rw-r--r-- 1 mongod mongod 104644096 Apr 3 19:00 WiredTigerLog.0000000001
-rw-r--r-- 1 mongod mongod 104685568 Apr 3 19:00 WiredTigerLog.0000000002
-rw-r--r-- 1 mongod mongod 104857600 Apr 3 19:00 WiredTigerLog.0000000003
-rw-r--r-- 1 mongod mongod 104857600 Apr 3 19:00 WiredTigerLog.0000000004
-rw-r - r-- 1 mongod mongod 0 3 апр 19:00 WiredTigerTmplog.0000000005
которые превышают емкость диска, выделенную для ведения журнала, и вызывают серьезный сбой во время начальной синхронизации
2018-04-03T19:00:18.821+0000 E STORAGE [thread2] WiredTiger error (28) [1522782018:821142][6176:0x7efc0cd3d700], log-server: /data/journal/WiredTigerTmplog.0000000005: handle-write: pwrite: failed to write 128 bytes at offset 0: No space left on device
2018-04-03T19:00:18.821+0000 E STORAGE [thread2] WiredTiger error (28) [1522782018:821213][6176:0x7efc0cd3d700], log-server: journal/WiredTigerTmplog.0000000005: fatal log failure: No space left on device
2018-04-03T19:00:18.821+0000 E STORAGE [thread2] WiredTiger error (-31804) [1522782018:821228][6176:0x7efc0cd3d700], log-server: the process must exit and restart: WT_PANIC: WiredTiger library panic
2018-04-03T19:00:18.821+0000 I - [InitialSyncInserters-my_job_glasses_production.ahoy_events0] Fatal Assertion 28559 at src/mongo/db/storage/wiredtiger/wiredtiger_util.cpp 64
2018-04-03T19:00:18.821+0000 I - [InitialSyncInserters-my_job_glasses_production.ahoy_events0]
***aborting after fassert() failure
2018-04-03T19:00:18.821+0000 I - [thread2] Fatal Assertion 28558 at src/mongo/db/storage/wiredtiger/wiredtiger_util.cpp 365
2018-04-03T19:00:18.821+0000 I - [thread2]
***aborting after fassert() failure
Я не совсем уверен, ПОЧЕМУ это происходит, так как на моем первичном сервере у меня есть только 2 файла журнала по 100 МБ каждый, поэтому я предполагал, что все должно быть в порядке
ec2-user@primary$ ll /data/journal/ -h
total 205M
-rw-r--r-- 1 mongod mongod 4.1M Apr 3 18:49 WiredTigerLog.0000000059
-rw-r--r-- 1 mongod mongod 100M Apr 3 16:43 WiredTigerPreplog.0000000001
-rw-r--r-- 1 mongod mongod 100M Apr 3 16:43 WiredTigerPreplog.0000000002
Я что-то пропустил или что-то не так? Вот мой mongod.conf
systemLog:
destination: file
logAppend: true
path: /log/mongod.log
logRotate: reopen
storage:
dbPath: /data
journal:
enabled: true
processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid
net:
port: 27017
#bindIp added accordingly
security:
authorization: enabled
keyFile: /xxx.key
replication:
replSetName: XXX
РЕДАКТИРОВАТЬ: Казалось бы, во время начальной синхронизации MongoDB создает до дюжины файлов каждые 100 МБ, прежде чем вернуться к файлам 4x100 МБ. Где это задокументировано ?? есть ли способ поставить ограничение на это ??