Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
И успешно счёт за приличный Disk IO.
Проблема: Не указан размер oplog. Для 64bit систем по умолчанию он составляет 5% от доступного дискового пространства, но не менее 1Gb. Если диск большой и средняя активность insert/update — стоит ограничить размер в конфиге, 2000Mb вполне достаточно:
oplogSize = 2000
Если данных не так много, а количество insert/update не слишком велико, можно слегка уменьшить дисковую активность следующим образом:
1) Отключить preallocate noprealloc = true
2) Уменьшить размер файлов (уменьшатся как файлы данных, так и журнала) smallfiles = true
Проблема: Не указан размер oplog. Для 64bit систем по умолчанию он составляет 5% от доступного дискового пространства, но не менее 1Gb. Если диск большой и средняя активность insert/update — стоит ограничить размер в конфиге, 2000Mb вполне достаточно:
oplogSize = 2000
Если данных не так много, а количество insert/update не слишком велико, можно слегка уменьшить дисковую активность следующим образом:
1) Отключить preallocate noprealloc = true
2) Уменьшить размер файлов (уменьшатся как файлы данных, так и журнала) smallfiles = true
И да, почему именно нечётное количество? Для production используется 3-12 узлов в replica set, при этом только 7 из них могут голосовать.
Какая, к примеру, будет опасность, если у меня будет replica set из 4 машин?
Какая, к примеру, будет опасность, если у меня будет replica set из 4 машин?
Так пишут в доках. Да и у меня не заработала реплика на двух инстансах, а когда добавил третий всё стало ок.
Реплика на двух инстансах работать будет, но не будет failover (так как нет кворума).
Вообще, иметь более двух нод — это одно из первых правил failover, поэтому минимальная production-конфигурация для mongodb — именно primary, secondary и arbiter, т.е три ноды. Но нет никакого 2n+1, так как на 4 нодах при выходе из строя мастера кворум сохраняется, и они сами вполне себе решат, кому быть новым мастером.
Вообще, иметь более двух нод — это одно из первых правил failover, поэтому минимальная production-конфигурация для mongodb — именно primary, secondary и arbiter, т.е три ноды. Но нет никакого 2n+1, так как на 4 нодах при выходе из строя мастера кворум сохраняется, и они сами вполне себе решат, кому быть новым мастером.
Понял
Смутила эта фраза:
Видимо я её не совсем верно понял.
The set has an odd number of voting members.
If you have an even number of voting members, deploy an arbiter to create an odd number.
Видимо я её не совсем верно понял.
Фразу Вы поняли совершенно верно, и теперь это уже меня начало смущать. Но, как показыавет практика, общее нечётное количество не обязательно, когда реплик больше трёх. Хотя проверю ещё раз, чтобы точно в этом убедиться.
Да, чётное количество нод не катит, когда есть возможность развалить реплика сет на 2 равные части. split-brain — это очень печально. Когда такой возможности нет — вполне себе рабочее решение. Но да, в таком случае лучше всё равно добавить либо арбитра, либо дополнительный голос какой-нибудь из нод.
Потому что надо однозначное понимание, что делать в случае split brain. Если у вас репликасет из 4 машин развалится напополам, то он либо не будет работать совсем, либо будут работать обе половинки, данные вы потом будете с большим трудом восстанавливать. Репликасет с нечётным количеством реплик в принципе не может развалиться напополам, и именно для этого добавляют арбитра (по сути — бесполезную ноду, которая не делает ничего и просто болтается в реплика сете) в сеты с чётным количеством машин.
Спасибо за такое важное уточнение! Я попросту ещё не сталкивался с этой проблемой. Обязательно добавлю в статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Репликация MongoDB на Amazon EC2