Файл: Учебнопрактическое пособие Владимир 2021.pdf

319
После добавления подписчика установите флажок радом с име- нем экземпляра вашего подпичика. Затем выберите New Database в разделе Subscription Database.
6.
Отобразится диалоговое окно New Database.
Введите ProductReplica в поле Database name, нажмите ОК, а затем нажмите Next:
7.
На вкладке Distribution Agent Security, нажмите кнопку с многоточием
(...).
Введите
<Publish-
er_Machine_Name>\repl_distribution в поле Process account , введите пароль для этой учетной записи, нажмите ОК, а затем нажмите Next.
8.
Нажмите Finish, чтобы принять значения по умолчанию на остальных страницах и завершите работу мастера.
5 Настройка разрешений базы данных на подписчике
1.
Подключитесь к подписчику в среде SQL Server
Management Studio. Раскройте Security, щелкните правой кнопкой мыши на Logins и выберите New Login. а. На вкладке General под Login Name выберите Поиск и до- бавьте логин для <Subscriber_Machine_Name>\repl_distribution. б. На вкладке User Mappings выбрать логин db_owner для ба- зы ProductReplica.
2.
Нажмите ОК, чтобы закрыть диалоговое окно New Login.
6 Просмотр состояния синхронизации подписки
1.
Подключитесь к издателю в среде SQL Server Management
Studio.
Разверните узел сервера, а затем разверните папку Replication.
2.
В
папке
Local
Publications разверните
публикацию
AdvWorksProductTrans, щелкните правой кнопкой мыши по подписке в базе данных ProductReplica, а затем выберите View
Synchronization Status.
Отобразится текущее состояние синхронизации подписки:

320 3.
Если подписка не отображается под
AdvWorksProductTrans, нажмите клавишу F5, чтобы обновить спи- сок.
7 Измерение задержки репликации
В этом разделе используются маркеры трассировки для провер- ки репликации изменений на подписчике и определения задержки.
Задержка-это время, которое требуется для отображения подписчику изменения, внесенного на издателе.
1.
Подключитесь к издателю в среде SQL Server Management
Studio.
Разверните узел сервера, щелкните правой кнопкой мыши на
папку Replication, а затем выберите Launch Replication Monitor:
2.
Раскройте группу издателей на левой панели, разверните экземпляр издателя, а затем выберите публикацию
AdvWorksProductTrans. а. Выберите вкладку Tracer Tokens. б. Выберите Insert Tracer. с. Просмотрите истекшее время для трассировочного токена в следующих столбцах: Publisher to Distributor, Distributor to
Subscriber, Total Latency. Значение Pending указывает, что токен не достиг заданной точки.

321
6.2. Репликация в СУБД MongoDB
1. Цель работы
Изучить механизм репликации данных на примере MongoDB.
Научиться разворачивать кластеры из нескольких узлов и управлять ими.
2. Теоретические сведения
MongoDB — документоориентированная система управления базами данных, не требующая описания схемы таблиц. Считается од- ним из классических примеров NoSQL-систем, использует JSON- подобные документы и схему базы данных. Применяется в веб- разработке, в частности, в рамках JavaScript-ориентированного стека
MEAN.
Система поддерживает ad-hoc-запросы: они могут возвращать конкретные поля документов и пользовательские JavaScript-функции.
Поддерживается поиск по регулярным выражениям. Также можно настроить запрос на возвращение случайного набора результатов.
В MongoDB реализовано две модели репликации: главный- подчиненный (Master-Slave) и наборы реплик (Replica Sets). В обоих случаях единственный первичный узел выполняет все операции запи- си, после чего вторичные узлы считывают описания этих операций и асинхронно применяют их у себя. В основном используют паттерн наборы реплик, потому что он позволяет дополнительно к основным возможностям, еще и восстановить или развернуть новую базу из ре- плики. Единственный случай, когда мы можем применять главный- подчиненный это случай если у нас больше 11 подчиненных, потому что в наборе реплик может быть только 12 членов. Рекомендуется ис- пользовать более новый подход – наборы реплик, как раз в данной лабораторной работе он вынесен на рассмотрение.
Основное назначение репликации – обеспечить резервирова- ние. Это означает, что должна поддерживаться связь между узлом и его репликами. Важно отметить, что, хотя реплики и обеспечивают резервирование, они далеки от резервного копирования. Резервное

322 копирование – это снимок базы на определенный момент времени, а реплика всегда актуальна.
MongoDB достигает репликации с помощью набора реплик.
Набор реплик – это группа экземпляров mongod, которые содержат один и тот же набор данных. В реплике один узел является основным узлом, который получает все операции записи. Все другие экземпля- ры, такие как вторичные, применяют операции с первичного, чтобы у них был тот же набор данных. Набор реплик может иметь только один основной узел.
№1. Запись и чтение с основного сервера
На рисунке 6.19 показана типичная схема репликации
MongoDB, в которой клиентское приложение всегда взаимодействует с первичным узлом, а первичный узел затем реплицирует данные на вторичные узлы.
Рис. 6.19. Запись и чтение с основного сервера.
№2. Чтение с реплики
Альтернативой чтению и записи с Primary является вариант, ко- гда драйвер может читать информацию с Secondary. При этом

323 настройки могут быть разными, например, «читать информацию предпочтительнее с Secondary, а потом с Primary» или «читать ин- формацию с ближайшего по карте сети нода» и т.д. Такие варианты настроек используются чаще, чем первый вариант репликации, где все идет через Primary.
Рис. 6.20. Чтение с реплики.
3 способа сделать реплику доступной для чтения:
•
Указать db.slaveOk()
•
Указать в строке подключения драйвера нужные парамет- ры
•
Указать все, а потом более точечно прописать в самом за- просе, например, читай из Secondary в Южном регионе: db.collection.find ({}).readPref( “secondary”, [ { “region”: “South”} ] )
Проблемы чтения с реплики:
1.
Так как запись асинхронная, она может быть уже сделана на Primary, но не доехать до Secondary, поэтому будут прочитаны старые данные с Secondary.
2.
Записав данные на основной, нельзя быть уверенным, ко- гда остальные получат эти данные. Чтобы было все синхронно, каж- дая нода должна подтвердить получение данных. Сейчас в MongoDB

324 есть общие настройки, а есть на каждый запрос, где можно указать, от скольки нод ожидается подтверждение запроса.
3.
Когда падает основной сервер, запускается процесс выбо- ров (кворум) (Рис. 6.21).
Рис. 6.21. Пример потери основного узла реплики
Настроен процесс репликации может быть двумя способа-
ми.
А) Ноды «слушают» друг друга, эта связь называется Heartbeat
(рисунок 6.22). То есть каждая нода постоянно проверяется другими на предмет «живая/ неживая», для того, чтобы предпринимать какие- то действия, если что-то случилось.
Рис. 6.22. Ноды «слушают» друг друга.
Б) Одна Secondary-нода меняется на Arbiter (рисунок 6.23). Это очень легковесное приложение, запускается как Mongo, практически не ест ресурсов и отвечает за то, что определяет, какую ноду в момент

325 голосования признать главной. И это в целом рекомендуемая конфи- гурация.
Рис. 6.23. Одна Secondary-нода меняется на Arbiter.
Основные особенности этой конфигурации:

Репликация асинхронная

Арбитр не содержит данных, и поэтому очень легковесный

Primary может стать Secondary и наоборот. Арбитр не мо- жет стать ни Primary, ни Secondary

Максимальное количество реплик 50 и только 7 из них имеют право голосовать

Arbiter можно установить и на Primary или Secondary, но делать это не рекомендуется, т.к. если этот сервер упадет, Arbiter то- же не сможет выполнить свою функцию.
3. Репликация в Windows
Итак, перед нами стоит задача развернуть сервера MongoDB, объединенные в реплика-сет. Для упрощения её выполнения будем делать это на одной физической машине, но в разных процессах.
Перед запуском серверов необходимо создать каталоги для хра- нения файлов серверов. Можно это сделать через проводник, но для унификации все действия будем делать через командную строку. md или mkdir – создаем директории (рис. 6.24).

326
Рис. 6.24. Создание директорий для серверов.
Для запуска экземпляра сервера MongoDB необходимо исполь- зовать команду mongod. Нам интересны следующие её параметры:
--dbpath директория для файлов сервера
--port номер порта, к которому смогут подключаться клен- ты
--replSet название набора реплик. Должно быть одинаково на всех реплицируемых серверах mongod
Примечание: так как в Windows не поддерживается запуск де-
мона из командной строки, то будем запускать каждый сервер в от-
дельном окне командной строки. На Linux демоны запускать можно,
для этого нужно использовать параметры --fork и –logpath.
Поднимем три экземпляра сервера (рис. 6.25). Первый будет ос- новным (PRIMARY), второй – репликой (SECONDARY), третий – ар- битром (ARBITER).

327
Рис. 6.25. Сервера запущены.
Теперь нужно проинциализировать наш реплика-сет. Инициали- зация выполняется непосредственно на сервере. Для этого будем так- же использовать консольного клиента (команду mongo). Полезные параметры этой команды:
--port – порт сервера
-u – имя пользователя
-p – пароль
Имя пользователя и пароль по умолчанию не установлены
Заходим на первый узел (рис. 6.26).
Рис. 6.26. Консоль первого узла.

328
Смотрим статус реплика-сета командой rs.status(), видим, что он не инициализирован (рис. 6.27).
Рис. 6.27. Реплика-сет не инициализирован.
Инициализируем реплика-сет командой rs.initiate() (рис. 6.28). В качестве параметра этому методу передается JSON с настройками:
{
"_id":"MyReplica",
"members":[
{
"_id":0,
"priority":3,
"host":"127.0.0.1:27001"
},
{
"_id":1,
"host":"127.0.0.1:27002"
},
{
"_id":2,
"host":"127.0.0.1:27003",
"arbiterOnly":true
}

329
]
}
Здесь $._id – идентификатор реплика-сета, указанный при старте серверов в параметре replSet, в массиве $.members перечисляются уз- лы и указываются специфичные для них настройки. Так, для первого узла (_id == 0) указан параметр priority, который указывает на его приоритет при выборе основного узла, а для третьего (_id == 2) ука- зан параметр arbiterOnly, который говорит, что этот узел должен быть арбитром.
Рис. 6.28. Инициализация реплика-сета.
Видим, что текущий узел стал репликой (SECONDARY). Через несколько секунд произойдет выбор основного узла, и он станет ос- новным, так как у него при настройке был указан более высокий при- оритет.
Проверим статус реплика-сета (рис. 6.29).

330
Рис. 6.29. Проверка статуса инициализированного реплика-сета.
Команда выдает большой ответ из которого можно узнать много информации о состоянии реплика-сета. В частности, можно узнать узлы, которые входят в реплика-сет (рис. 6.30).

331
Рис. 6.30. Узлы реплика-сета.
Видим, что все узлы доступны (параметр health) и тип узлов со- ответствует тому, что мы указали в настройках (параметр stateStr).
И в итоге видим, что первый узел стал основным (рис. 6.31).

332
Рис. 6.31. Первый узел стал основным.
Проверим как работает репликация в нашем только что постро- енном кластере. Для этого создадим базу данных, простую коллекцию и запишем туда один документ (рис. 6.32).
Рис. 6.32. Добавление документа.
Теперь подключимся к реплике и попытаемся прочитать запись напрямую из неё, но для начала нужно активировать возможность чи- тать из реплик напрямую. Чтобы разрешить считывание из реплик, нужно выполнить команду rs.slaveOk() или на более новых версиях
Mongo - rs.secondaryOk() на реплике (рис. 6.33).
Рис. 6.33. Включение считывания из реплики.
Теперь можем прочитать недавно записанный документ (рис.
6.34).

333
Рис. 6.34. Чтение из реплики.
Видим, что документ успешно реплицировался.
Теперь проведем эксперимент отказоустойчивости. Отключим основной узел (убьем процесс) и увидим, что основным станет второй узел.
Убиваем любым способом первый процесс (рис. 6.35).
Рис. 6.35. Убиваем первый узел.
Заходим на второй узел (рис. 6.36) и уже тут видим, что он стал основным (PRIMARY).

334
Рис. 6.36. Консоль второго узла.
Теперь проверяем статус реплика-сета и видим, что первый узел недоступен, а второй стал PRIMARY (рис. 6.37).

335
Рис. 6.37. Состояние узлов реплика-сета после отключения первого узла.
Теперь опять поднимем первый узел и проверим статус репли- ка-сета со второго узла (рис. 6.38). Видим, что всё вернулось на свои места – первый узел стал основным, а второй – репликой.

336
Рис. 6.38. Состояние узлов реплика-сета после повторного запуска первого узла.
В реальной жизни, если во время работы приложения упадет ос- новной узел, то клиентский драйвер сам должен разрешить данную

337 ситуацию и найти актуальный основной узел для записи или доступ- ные узлы для чтения.
4. Репликация в Linux
Для начала необходимо определиться, с помощью какого ин- струмента будут создаваться виртуальные машины. Для Windows есть
2 решения – VirtualBox или Hyper-V. В данной работе рассматривает- ся способ работы с виртуальными машинами через Hyper-V, который доступен для Windows Pro версий ОС.
Включаем Hyper-V в системе
Открываем PowerShell от имени администратора, вводим сле- дующую команду:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-
Hyper-V -All
После выполнения данной команды включается надстройка
Hyper-V для Windows (рисунок 6.39).
Рис. 6.39. Выполнение команды
Необходимо нажать Enter и дождаться перезагрузки компьюте- ра.
Создание виртуальных машин
Откройте поиск Windows и введите Hyper-V. Выберите Быстрое создание Hyper-V (рисунок 6.40).

338
Рис. 6.40. Окно Быстрого создания Hyper-V
Необходимо выбрать локальный источник установки, в предло- женном окне выбрать предварительно загруженный образ ubuntu-
18.04.iso, также необходимо убрать галочку «На этой виртуальной машине будет запущена Windows».
Таким образом, создаем три виртуальные машины с соответ- ствующими названиями (Ubuntu 1/2/3 соответственно).
После создания машин, нужно осуществить подключение к ним.
Далее, при появлении следующего диалогового окна, выбрать
Install Ubuntu и дождаться начала установки (рисунок 6.41).
Рис. 6.41 – выбор при первом запуске виртуальной машины

339
Процесс установки максимально прост, но в некоторых окнах нужно установить следующие настройки (рисунки 6.42 - 6.43):
Рис. 6.42. Выбор типа устанавливаемой системы и обновлений
Рис. 6.43. Установка имени пользователя и настройка входа в систему
После успешной установки системы следует перезагрузить вир- туальные машины для перехода к следующему шагу.
Сетевые настройки Ubuntu
Первым делом, нужно переключиться на пользователя root, для чего выполняем команду: sudo -s

340
Вводим пароль, созданный при установке (рисунок 6.43).
Далее необходимо установить пакет, с помощью которого мож- но будет получить IP-адрес данной виртуальной машины, для чего выполняется следующая команда: apt install net-tools
После установки, воспользуемся этим пакетом:
Ifconfig
На результате выполнения мы видим адрес такого типа:
192.168.xx.xx
Необходимо сохранить этот адрес для дальнейшей настройки.
После получения всех адресов виртуальных машин, на каждой
машине необходимо добавить DNS-запись этой машины, добавив в файл /etc/hosts следующие строки (рисунок 6.44):
Рис. 6.44. Строки для добавления (IP-адрес должен быть ваш)
Проверить результаты настройки можно с помощью команды
ping:
Для первой машины: ping mongoreplica2 и ping mongoreplica3;
Для второй машины: ping mongoreplica1 и ping mongoreplica3;
Для третьей машины: ping mongoreplica2 и ping mongoreplica1;
Если пакеты успешно доставляются, значит, все машины могут взаимодействовать друг с другом.
Установка MongoDB