Я подумываю о внедрении кластера Mongo и провожу исследования. Мы надеемся получить кластер, который может масштабироваться от 10 000 обновлений в секунду до 100 000 обновлений в секунду с очень интенсивным трафиком записи.
Главный вопрос: если мы захотим перейти на более новую версию, возможно ли это без простоев?
Будем ли мы обновлять по одному сегменту / реплике за раз и позволять ему снова присоединяться к группе и надеяться, что он будет обратно совместим и не изменяет данные?
В качестве бонуса, какова оценка кластера при 10 000 обновлений в секунду? 100к?
я смотрел на http://www.mongodb.org/display/DOCS/Sharding+FAQ но не смог найти процедуру обновления.
Вы должны проверить примечания к выпуску для каждой версии, но инструкции по обновлению для 2.0 находятся здесь:
http://www.mongodb.org/display/DOCS/2.0+Release+Notes#2.0ReleaseNotes-Upgrading
Последние два пункта конкретно касаются вашего вопроса:
Для обновления набора реплик. Обновите вторичные серверы сначала по одному, затем пошагово опустите первичный и обновите первичный. Лучше использовать команду stepDown, чем просто выключить ее, так как переключение произойдет быстрее. Чтобы избежать потери нескольких последних обновлений при отработке отказа, вы можете временно остановить свое приложение (отработка отказа должна занять менее 10 секунд) или изменить код приложения, чтобы убедиться, что каждое обновление достигает нескольких серверов. Обратите внимание: после обновления до 2.0 вы можете использовать команду shutdown для выключения основного без потери безопасных обновлений.
Чтобы обновить сегментированный кластер. Обновляйте серверы конфигурации по одному в любом порядке. Поскольку серверы конфигурации используют двухэтапную фиксацию, обновление метаданных конфигурации сегментов будет остановлено, пока все не будут запущены и запущены. Маршрутизаторы mongos можно модернизировать в любом порядке.
Время простоя минимально, требуется только время для набора реплик, чтобы подтвердить, что stepDown произошел, и произойти выборы / продвижение по службе.