Вот несколько упражнений для боевого тестирования вашего экземпляра MongoDB перед началом производства. Вам понадобится Database Master (aka DM), чтобы сделать плохие вещи с вашей установкой MongoDB, и один или несколько игроков, чтобы попытаться это исправить.
Это собиралось перейти к MongoDB: «Полное руководство» , но оно не совсем соответствовало остальным материалам, поэтому я решил вместо этого разместить его здесь. Наслаждайтесь!
Могила ужасов
Попробуйте убить различные компоненты вашей системы: процессы mongos, серверы конфигурации, первичные, вторичные и арбитры. Попробуйте убить их всеми возможными способами. Вот несколько идей для начала:
- Чистое выключение: выключение из оболочки MongoDB (db.serverShutdown ()) или SIGINT.
- Жесткое отключение: убить -9.
- Выключите базовую машину.
- Если вы работаете на виртуальной машине, остановите виртуальную машину.
- Если вы работаете на физическом оборудовании, отключите компьютер.
Несколько сложнее сделать эти серверы невосстановимыми: вывести виртуальную машину из эксплуатации, заблокировать сетевой ящик из сети, подобрать физическую машину и спрятать ее в шкафу.
Предложение @markofu : сделайте привязку netcat к 27017, чтобы mongod не смог начать снова:
$ while [ 1 ]; do echo -e "MongoDB shell version: 2.4.0\nconnecting to: test\n>"; nc -l 27017; done
Руководство DM: убедитесь, что данные не потеряны.
Приключение исчезающего центра обработки данных
Похоже на выше, но более организовано. Вы можете отключить работу центра обработки данных (отключить все серверы на нем) или просто настроить свою сеть, чтобы не допускать или отключать какие-либо подключения, что является более злым способом сделать это. Если вы делаете это через сеть, после того, как ваши игроки справятся с выходом из строя центра обработки данных, вы можете вернуть его и заставить их справиться и с этим.
Обратите внимание, что любая реплика, установленная с большинством в «выключенном» центре обработки данных, все равно будет иметь первичную базу данных, когда вернется в оперативный режим. Если ваши игроки перенастроили оставшуюся часть набора в другом центре обработки данных на первичную, эти участники будут исключены из набора.
Найти Изгой Запрос
Есть несколько типов запросов, которые вы можете запустить, которые будут работать в вашей системе. Если вы хотите научить операторов, как выслеживать эти типы запросов и убивать их, это хорошая игра.
Чтобы протестировать запрос с нагрузкой на дисковый ввод-вывод, запустите запрос для большой коллекции, которая, вероятно, не находится в памяти, например, для оплога. Если у вас есть большая, специфичная для приложения коллекция, это даже лучше, так как она будет вызывать у игроков меньше красных флажков относительно того, почему она работает. Убедитесь, что он должен вернуть сотни гигабайт данных.
Запуск сложного MapReduce может закрепить одно ядро. Точно так же, если вы можете выполнять сложные агрегации на неиндексированных ключах, вы, вероятно, можете получить несколько ядер.
Нагрузка на память и процессор может быть достигнута путем одновременного создания фоновых индексов для многочисленных баз данных.
Чтобы быть действительно хитрым, вы могли бы найти часто используемый запрос, который использует индекс, и удалить его.
Руководство DM: игрокам следует повторно нагреть кэш, чтобы ускорить возврат приложения в нормальное состояние.
THAC0, ака плохие настройки системы
Попробуйте установить readahead равным 65000 и посмотреть, как уменьшится использование оперативной памяти MongoDB и дисковый ввод-вывод пройдет через крышу.
Установите slaveDelay = 30 для большинства ваших вторичных серверов и наблюдайте за всеми вашими приложениями: большинство записей занимает 30 секунд.
Используйте rs.syncFrom (), чтобы создать цепочку репликации, в которой каждый сервер имеет синхронизацию только с одним сервером (самая длинная цепочка репликации). Затем посмотрите, сколько времени потребуется для записи w: большинства. Как насчет того, чтобы все синхронизировались напрямую с основного?
Леруа Дженкинс!
Что произойдет, если ваш экземпляр MongoDB получит больше, чем может обработать? Это особенно полезно, если вы используете мультитенантную виртуальную машину: что произойдет с вашим приложением, если один из ваших соседей будет вести себя плохо? Однако также полезно проверить, что может случиться, если вы получите намного больше трафика, чем ожидаете. Вы можете использовать инструмент Linux dd, чтобы записать тонны мусора в том данных (не в каталог данных!) И посмотреть, что происходит с вашим приложением.
Сокрытие сервера
Попробуйте использовать скрипт для случайного включения и выключения сети с помощью iptables. Для большей реалистичности более вероятно, что вы потеряете связь между центрами обработки данных, а не внутри центра обработки данных, поэтому обязательно проверьте это.
Проблемы с сетью обычно приводят к отказам и ошибкам приложения. Может быть очень трудно понять, что происходит без хорошего мониторинга или просмотра журналов.