Запуск ванильного экземпляра MongoDB очень прост, ему просто нужен порт, который он может прослушивать, и каталог, в котором он может сохранить вашу информацию. По умолчанию Mongo прослушивает порт 27017, который должен работать нормально (это не очень часто используемый порт). Мы создадим новый каталог для файлов базы данных:
$ mkdir -p ~/dbs/mydb # -p creates parent directories if they don't exist
А затем запустите нашу базу данных:
$ cd $ bin/mongod --dbpath ~/dbs/mydb
… и вы увидите кучу результатов:
$ bin/mongod --dbpath ~/dbs/mydb Fri Apr 23 11:59:07 Mongo DB : starting : pid = 9831 port = 27017 dbpath = /data/db/ master = 0 slave = 0 32-bit ** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data ** see http://blog.mongodb.org/post/137788967/32-bit-limitations for more Fri Apr 23 11:59:07 db version v1.5.1-pre-, pdfile version 4.5 Fri Apr 23 11:59:07 git version: f86d93fd949777d5fbe00bf9784ec0947d6e75b9 Fri Apr 23 11:59:07 sys info: Linux ubuntu 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 BOOST_LIB_VERSION=1_38 Fri Apr 23 11:59:07 waiting for connections on port 27017 Fri Apr 23 11:59:07 web admin interface listening on port 28017
Теперь Монго так «замерзнет», что смущает некоторых людей. Не волнуйся, просто жду запросов. Вы готовы идти.
Поскольку мы запускаем master и slave на одной машине, им потребуются отдельные порты. Мы будем использовать порт 10000 для ведущего и 20000 для ведомого. Нам также нужны отдельные каталоги для данных, поэтому мы создадим их:
$ mkdir ~/dbs/master ~/dbs/slave
Теперь мы запускаем основную базу данных:
$ bin/mongod --master --port 10000 --dbpath ~/dbs/master
А потом раб, в другом терминале
$ bin/mongod --slave --port 20000 --dbpath ~/dbs/slave --source localhost:10000
Опция «source» указывает, где ведущий должен реплицировать данные от ведомого устройства.
Теперь, если мы хотим добавить еще одно ведомое устройство, нам нужно предпринять невероятные усилия по выбору порта и созданию нового каталога:
$ mkdir ~/dbs/slave2 $ bin/mongod --slave --port 20001 --dbpath ~/dbs/slave2 --source localhost:10000
Тада! Два раба, один хозяин. Для получения дополнительной информации о master-slave см. Основные документы по нему и мой предыдущий пост .
В этом примере главный сервер и подчиненный сервер размещаются на одной и той же машине, но у людей обычно есть мастер на одной машине и ведомый на другой. Он отлично работает, когда их помещают на одну машину, но немного побеждает.
Получить авто-аварийное переключение… Rover
Хорошо, так что не так много людей по имени Ровер, но вы придумаете рифму для «автоматического перехода на другой ресурс» (я тоже попробовал «реплика»).
Пары реплик хороши, потому что это как ведущий-ведомый, но вы получаете автоматическое переключение при сбое: если ведущий становится недоступным, ведомый становится ведущим. Таким образом, это в основном то же самое, что и ведущий-ведомый, но серверы знают друг о друге, и есть, необязательно, сервер-арбитр, который не делает ничего, кроме разрешения «споров» о том, кто является главным.
Когда арбитр может пригодиться? Предположим, что сетевой кабель мастера вытянут. Сервер все еще думает, что он хозяин, но никто не знает, что он там. Раб становится хозяином, и весь остальной мир живет счастливо. Когда сетевой кабель мастера снова подключен, теперь оба сервера думают, что они мастера! В этом случае арбитр вмешивается и мягко сообщает хозяину, который отстает во времена, когда он теперь раб.
Вам не нужно настраивать арбитра, но мы сделаем это, так как это хорошая практика:
$ mkdir ~/dbs/arbiter ~/dbs/replica1 ~/dbs/replica2 $ bin/mongod --port 50000 --dbpath ~/dbs/arbiter
Теперь в отдельных терминалах вы запускаете каждую из реплик:
$ bin/mongod --port 60000 --dbpath ~/dbs/replica1 --pairwith localhost:60001 --arbiter localhost:50000
А потом другой:
$ bin/mongod --port 60001 --dbpath ~/dbs/replica2 --pairwith localhost:60000 --arbiter localhost:50000
После того, как они немного поработали, попробуйте убить (Ctrl-C) один, затем перезапустить его, затем убить другого, туда-сюда.
Для получения дополнительной информации о парах реплик см. Основные документы .
Что это? Реплика пар развивается! * voop * * voop * * voop *
Пары реплик превратились в… наборы реплик ! Ну, ладно, пока нет, но скоро придут. Тогда у вас будет произвольное количество серверов в кольце автоматического перехода на другой ресурс.
Для большого финала, шардинга. Sharding — это способ распространения данных с помощью Mongo. Если вы не знаете, что такое шардинг, посмотрите мой предыдущий пост, объясняющий, как он работает.
Прежде всего, скачайте последнюю версию 1.5.x с сайта. Осколки быстро меняются, вам нужны самые последние и самые лучшие, а не стабильные.
Мы собираемся создать кластер из трех узлов. Так же, как и всегда, создайте каталоги вашей базы данных. Нам нужен один каталог для конфигурации кластера и три каталога для наших шардов (узлов):
$ mkdir ~/dbs/config ~/dbs/shard1 ~/dbs/shard2 ~/dbs/shard3
Конфиг-сервер отслеживает, что и где, поэтому нам нужно сначала это запустить:
$ bin/mongod --configsvr --port 70000 --dbpath ~/dbs/config
Mongos — это просто маршрутизатор запросов, который работает поверх сервера конфигурации. Ему даже не нужен каталог данных, мы просто сообщаем ему, где искать конфигурацию:
$ bin/mongos --configdb localhost:70000
Обратите внимание на «s»: маршрутизатор называется «mongos», а не «mongod». Мы не указали порт для него, поэтому он будет прослушивать порт по умолчанию (27017).
Ладно! Теперь нам нужно настроить наши осколки. Запустите каждый из них в отдельных терминалах:
$ bin/mongod --shardsvr --port 71000 --dbpath ~/dbs/shard1 $ bin/mongod --shardsvr --port 71001 --dbpath ~/dbs/shard2 $ bin/mongod --shardsvr --port 71002 --dbpath ~/dbs/shard3
На самом деле mongos еще не знает об этих шардах, вам нужно сообщить об этом, чтобы добавить эти серверы в кластер. Самый простой способ — запустить оболочку монго:
$ bin/mongo MongoDB shell version: 1.5.1-pre- url: test connecting to: test type "help" for help >
Теперь мы добавляем каждый осколок в кластер:
> db = connect("localhost:70000/admin"); connecting to: localhost:70000 admin > db.runCommand({addshard : "localhost:71000", allowLocal : true}) { "added" : "localhost:71000", "ok" : 1 } > db.runCommand({addshard : "localhost:71001", allowLocal : true}) { "added" : "localhost:71001", "ok" : 1 } > db.runCommand({addshard : "localhost:71002", allowLocal : true}) { "added" : "localhost:71002", "ok" : 1 } >
mongos ожидает, что на удаленных компьютерах будут находиться сегменты, и по умолчанию не разрешит вам добавлять локальные фрагменты (то есть фрагменты с именем «localhost» в имени). Так как мы просто играем, мы указываем «allowLocal», чтобы переопределить это поведение. (Обратите внимание, что «addhard» — это НЕ верблюжий случай, а allowLocal IS — верблюжий, потому что мы согласны с этим.)
Поздравляем, вы используете распределенную базу данных!
Чем вы сейчас занимаетесь? Ну, используйте его как обычную базу данных! Подключитесь к «localhost: 27017» и продолжайте в обычном режиме (или, как обычно, насколько это возможно… пожалуйста, сообщайте о любых ошибках нашему багтрекеру !). Попробуйте учебник (поскольку у вас уже открыта оболочка) или подключитесь через ваш любимый драйвер и поиграйте.
Подключение к mongos должно быть идентичным подключению к обычному серверу Mongo. За кулисами он разделяет ваши запросы / данные по частям, чтобы вы могли сосредоточиться на создании приложения, а не на его масштабировании.
PS Очевидно, этот пример установки полон отдельных точек отказа, но этого вполне можно избежать. Я могу рассказать о том, как настроить распределенную MongoDB с нулевыми точками отказа в последующих постах, если людям это интересно.
КОНЕЦ