Учебнопрактическое пособие Владимир 2021
 Скачать 7.94 Mb.
|
|
Глава 6. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ РЕПЛИКАЦИИ В СОВРЕМЕННЫХ СУБД 6.1. Репликация в MS SQL Server Репликация - это механизм распространения данных из основ- ной базы данных(издатель) к базам данным- подписчикам, является одной из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или не- сколько других (называемые репликами). Таким образом появляется возможность распределить нагрузку с одного сервера на несколько. Статья (article) — это объекты, которые мы будем реплициро- вать, такие как таблицы, процедуры, функции и т. д. Публикация(publication) — это набор статей, или проще гово- ря окончательный набор объектов для репликации. Фильтры — набор условий для статьи. В репликации возможно использовать фильтры на таблицы, вьюшки, что позволяет нам реп- лицировать только необходимые данные, благодаря этому уменьша- ется передаваемый трафик, уменьшается избыточность, уменьшается хранимый объем данных. Экземпляр SQL Server, содержащий базу данных, из которой распространяются данные, называется издателем (Publisher). В одной базе данных можно определить одну или более публикаций (Publication), которые логически объединяются в одну или более ста- тей (Article). Статья представляет собой особый объект в базе данных публикации, который требуется переслать в другую базу данных. До- пустимые типы объектов в статьях включают в себя определяемые пользователем таблицы, хранимые процедуры и представления. Для репликации необходима отдельная база данных для хране- ния метаданных и пересылаемых данных. Такая база данных называ- ется базой данных распространителя (Distribution Database), а экзем- пляр SQL Server, на котором она хранится, - распространителем (Distributor). Распространитель может быть тем же экземпляром SQL 300 Server, что и издатель, отдельными экземпляром или экземпляром, на который пересылаются данные. Решение о размещении базы данных распространителя обычно базируется на рассмотрении таких момен- тов как загруженность или доступность (например, если репликация транзакций сочетается с зеркалированием баз данных). Сервер, получающий данные от издателя, называется подписчи- ком (Subscriber). Подписчиком может быть тот же экземпляр SQL Server, что и издатель, экземпляр, являющийся распространителем, или отдельный экземпляр SQL Server. Подписчик определяется с по- мощью добавления подписки на определенную публикацию. База данных подписчика может содержать как реплицированные, так и не- реплицированные объекты, и хранить более одной подписки от раз- ных публикаций. Подписка может быть определена как принудительная (push), при этом данные принудительно пересылаются от распространителя в базу данных подписчика, или как подписка по запросу (pull), когда данные запрашиваются подписчиком. Принудительные подписки бо- лее распространены при развертывании репликации моментальных снимков (snapshot replication) и репликации транзакций (transactional replication). Подписки по запросу обычно используются при реплика- ции слиянием (merge replication), так как подписчик может чаще от- ключаться от коммуникаций и требовать проверки данных, обновля- емых по запросу. Решение о выборе вида подписки также может ба- зироваться на емкости и объеме избыточной нагрузки серверов, участвующих в топологии репликации. Типы репликации Существует три основных типа репликации: репликация мо- ментального снимка, репликация транзакций и репликация слиянием. Встречаются и базирующиеся на этих типах различные вариации, например, одноранговая репликация (peer-to-peer replication). Репликация моментального снимка позволяет распространять данные на определенный момент времени. Снимок пересылается и более не обновляется процессом репликации, пока не будет сделан новый снимок, который будет отправлен подписчику. Репликация 301 моментального снимка обычно используется для формирования схе- мы статей и связанных с ней данных у подписчика для репликации транзакций и репликации слиянием. Репликация слиянием позволяет подписчику напрямую моди- фицировать данные подписки (статьи) и затем синхронизировать мо- дифицированные строки с издателем. Подписчики могут быть неко- торое время отключены от коммуникаций, периодически подклю- чаться и синхронизировать данные по запросу. В этот момент их из- менения синхронизируются с издателем и наоборот. Это может при- вести к конфликту данных, когда издатель и один или более подпис- чиков пытаются модифицировать одни и те же данные. Последний тип репликации - тот, который мы рассмотрим, - ре- пликация транзакций. При правильном проектировании репликация транзакций может обеспечивать потоковое изменение данных с низ- ким уровнем задержек, выполняемое издателем для одного или более подписчиков. Реплицируемые данные, как правило, обрабатываются подписчиком в режиме "только чтение". Модификация данных у под- писчика может привести к нарушению синхронизации всего набора данных с данными издателя. Подготовка MS SQL Server для репликации 1. Необходимые компоненты Для выполнения репликации необходимы SQL Server, Среда SQL Server Management Studio (SSMS) и база данных AdventureWorks: На сервере издателя (source) установите: o Любой выпуск SQL Server, кроме SQL Server Express или SQL Server Compact. Эти выпуски не могут быть издателями репли- кации. o В данных AdventureWorks2012 образец базы данных. Для повышения безопасности образцы баз данных по умолчанию не уста- навливаются. 302 • На сервере подписчика (destination) установите любой вы- пуск SQL Server, кроме SQL Server Compact. SQL Server Compact не может быть подписчиком в репликации транзакций. • Установите SQL Server Management Studio. • Установите SQL Server 2017 Developer edition. • Скачайте образец базы данных AdventureWorks. Важно! Репликация не поддерживается в экземплярах SQL Server с более чем двумя версиями. В SQL Server Management Studio необхо- димо подключиться к издателю и подписчику с помощью имени вхо- да, которые являются членами предопределенной роли сервера sysadmin. 2. Создание учетных записей Windows для репликации В этом разделе создаются учетные записи Windows для запуска агентов репликации. Создайте отдельную учетную запись Windows на локальном сервере для следующих агентов: Таблица 14. Требуемые учетные записи Agent Location Account name Snapshot Agent Publisher <machine_name>\repl_snapshot Log Reader Agent Publisher <machine_name>\repl_logreader Distribution Agent Publisher and subscriber <machine_name>\repl_distribution Merge Agent Publisher and subscriber <machine_name>\repl_merge 303 Важно! В репликации Publisher и Distributor используют один и тот же объект (NODE1\SQL2016) SQL Server. Объект subscriber (NODE2\SQL2016) является удаленным. Publisher и Subscriber могут использовать один и тот же объект SQL Server, но это не является обязательным. В нашем случае Publisher и Subscriber используют один и тот же объект. Создадим локальные учетные записи Windows для агентов ре- пликации Publisher 1. Для Publisher, откройте Computer Management из Ad- ministrative Tools на панели управления. 2. В System Tools, раскройте Local Users and Groups. 3. Щелкните правой кнопкой мыши по пункту Users и выбе- рите New User. 4. Введите в поле User name значение repl_snapshot, введите пароль и другую необходимую информацию, а затем нажмите кнопку Создать, чтобы создать repl_snapshot агента: Рис. 6.1. Создание repl_snapshot агента 304 5. Повторите предыдущий шаг, чтобы создать учетные запи- си repl_logreader, repl_distribution и repl_merge: Рис. 6.2. Создание дополнительных учетных записей. 6. Закройте окно. 3. Подготовка snapshot folder В этом разделе настроим snapshot folder, используемая для со- здания и хранения моментального снимка публикации. Создадим общую папку для snapshot folder и назначим права до- ступа 1. В проводнике перейдите к папке SQL Server date, распо- ложенная по адресу: C:\Program Files\Microsoft SQL Server\MSSQL.X\MSSQL\Data. 2. Создайте новую папку с именем repldata. 3. Нажмите правой кнопкой мыши по созданной папке и вы- берите Свойства. а. Во вкладке Sharing диалогового окна repldata Properties вы- берите Advanced Sharing. б. В диалоговом окне Advanced Sharing выберите Share this Folder, а затем выберите Permissions. 305 Рис. 6.3. Создание новой папки repldata 4. В диалоговом окне Permissions for repldata выберите До- бавить. В Select User, Computers, Service Account, or Groups введи- те имя снимка учетной записи агента, созданной ранее, как er_Machine_Name>\repl_snapshot. Выберите Check Names, а затем выберите ОК. 306 Рис. 6.4. Работа с диалоговыми окнами из пункта 4. 5. Повторите шаг 4, чтобы добавить две другие учетные за- писи, которые вы создали ранее: <Publisher_Machine_Name>\repl_merge и <Publisher_Machine_Name>\repl_distribution. 6. После добавления трех учетных записей назначьте следу- ющие права доступа: repl_distribution: Read repl_merge: Read repl_snapshot: Full Control Рис. 6.5. Назначение прав доступа 7. После предоставления прав доступа, выберите ОК, чтобы закрыть диалоговое окно Permissions for repldata. Нажмите ОК, что- бы закрыть диалоговое окно Advanced Sharing. 8. В диалоговом окне repldata Properties, выберите вкладку Security, затем выберите Edit: 307 Рис. 6.6. Работа с диалоговым окном из пункта 8 9. В диалоговом окне Permissions for repldata выберите До- бавить. В диалоговом окне Select Users, Computers, Service Ac- counts, or Groups введите имя Snapshot Agent account, созданное ранее, как \repl_snapshot. Выберите Check Names, а затем выберите ОК. Рис. 6.7. Работа с диалоговыми окнами из пункта 9. 308 10. Повторите предыдущий шаг, чтобы добавить разрешения для агента распределения, как <Publisher_Machine_Name>\repl_distribution, и для агента слияния как <Publisher_Machine_Name>\repl_merge. 11. Убедитесь, что следующие разрешения разрешены: repl_distribution: Read repl_merge: Read repl_snapshot: Full Control Рис. 6.8. Определение расрешений для агента 12. Перейдите на вкладку Sharing снова и обратите внимание на Network Path для доступа. Этот путь понадобится позже при настройке snapshot folder. 309 Рис. 6.9. Определение пути папки 13. Выберите ОК , чтобы закрыть диалоговое окно repldata Properties. 4 Настройка distribution В этом разделе настраивается distribution для издателей, и уста- навливаются необходимые разрешения publication и distribution для баз данных. Если distributor уже настроен, тогда необходимо перед началом работы с этим разделом отключить публикацию и распро- странение. Не делайте этого, если необходимо сохранить существу- ющую топологию репликации, особенно в рабочей среде. Настройка distribution на publisher 1. Подключитесь к publisher в среде Среда SQL Server Management Studio и разверните узел сервера. 2. Щелкните правой кнопкой мыши на папку Replication и выберите Configure Distribution: 310 Рис. 6.10. Работа с контекстным меню из пункта 2. Важно! Если у вас есть подключение к SQL Server с помощью имени localhost, а не фактическое имя сервера, вам высветится диалоговое окно с предупреждением, что SQL Server не удается подключиться к серверу localhost. Выберите ОК в диалоговом окне предупреждения. В диалоговом окне Connect to Server, измените Server name со зна- чения localhost на имя вашего сервера. Затем выберите подключить- ся. Запустится The Distribution Configuration Wizard. 3. На странице Distributor, выберите <'ServerName'>, кото- рое будет выступать в качестве своего собственного Distributor; SQL Server создаст дистрибутив базы данных и журнала. Затем выберите Next. 311 Рис. 6.11. Создание дистрибутива базы данных и журнала. 4. Если SQL Server Agent не работает, на стартовой страни- це SQL Server Agent установите Да, настройка SQL Server Agent за- пускается автоматически. Выберите Next. 5. Введите путь \\<Publisher_Machine_Name>\repldata в Snapshot folder , а затем выберите Далее. Этот путь должен совпа- дать с тем, что вы запомнили ранее под Network Path для вашего repldata. 312 Рис. 6.12. Ввод пути папки. 6. Примите значения по умолчанию на оставшихся страницах мастера настроек. Рис. 6.13. Выставляем значения настроек 7. Выберите Готово, чтобы включить distribution. При настройке распространителя может появиться следующая ошибка. Это означает, что учетная запись, используемая для запуска учетной записи SQL Server Agent, не является администратором в си- стеме. Необходимо либо запустить SQL Server Agent вручную, предо- 313 ставить эти разрешения существующей учетной записи, или изменить учетную запись, используемую SQL Server Agent. Рис. 6.14. Учетная запись не является администратором в системе Если экземпляр SQL Server Management Studio работает с пра- вами администратора, можно запустить SQL Agent вручную из SSMS. Рис. 6.15. Запуск прав администратора вручную. 314 Важно! Если SQL Agent не запуститься, щелкните правой кнопкой мы- ши SQL Agent в SSMS и выберите Обновить. Если он все еще нахо- дится в остановленном состоянии, запустите его вручную из SQL Server Configuration Manager. 5. Настройка прав доступа базы данных на publisher 1. В SQL Server Management Studio, разверните узел Security, щелкните правой кнопкой мыши по папке Logins и выбери- те New Login: Рис. 6.16. Настройка прав для пользователей 2. На вкладке General, выберите Поиск. Введите \repl_snapshot в поле Enter the object name to select, выберите Check Names, а затем выберите ОК. 315 Рис. 6.17. Работа с диалоговым окном из пункта 2. 3. На вкладке User Mapping, в списке Users mapped to this login выберите distribution и AdventureWorks2012 баз данных. В списке database role membership, выберите роль db_owner для обеих баз данных. Рис. 6.18. Настройка базы данных. 4. Выберите ОК , чтобы создать Login. 316 5. Повторите шаги 1-4, чтобы создать Login для других ло- кальных учетных записей (repl_distribution, repl_logreader и repl_merge). Эти учетные записи должны быть сопоставлены пользо- вателям, которые являются членами фиксированной роли db_owner в distribution и AdventureWorks базе данных. Настройка транзакционной репликации меду двумя постоянно действующими подключенными серверами 1 Настройка издателя для репликации транзакций Создание публикации и определение статей 1. Подключитесь к издателю в среде Среда SQL Server Management Studio и разверните узел сервера. 2. Щелкните правой кнопкой мыши по SQL Server Agent и выберите Start. SQL Server Agent должен быть запущен перед со- зданием публикации. Если SQL Server Agent не получается запу- стить, это необходимо сделать вручную из диспетчера конфигурации SQL Server. 3. Раскройте папку Replication, щелкните правой кнопкой мыши на папку Local Publications и выберите New Publication. На этом шаге запускается Мастер создания публикации: 4. На вкладке Publication Database выберите AdventureWorks2012, а затем выберите Далее. 5. На вкладке Publication Type выберите Transactional pub- lication, а затем нажмите Далее: 6. На вкладке Articles раскройте узел Tables и выберите флажок Product. Затем раскройте узел Product и снимите флажки ря- дом с ListPrice и StandardCost. Нажмите Next. 7. На вкладке Filter Table Rows, выберите Add. 8. В диалоговом окне Add Filter выберите SafetyStockLevel. Нажмите на стрелку вправо, чтобы добавить в filter statement опера- тор WHERE. Затем вручную введите модификатор предложения WHERE следующим образом: 317 WHERE [SafetyStockLevel] < 500 9. Нажмите ОК, а затем нажмите Next. 10. Выберите флажок Create a snapshot immediately and keep the snapshot available to initialize subscriptions и нажмите Next: 11. На вкладке Agent Security снимите флажок Use the securi- ty settings from the Snapshot Agent. Выберите Параметры безопасности для агента моментальных снимков. Введите <Publisher_Machine_Name>\repl_snapshot в про- цесс счета окно, введите пароль для этой учетной записи, а затем вы- берите ОК. 12. Повторите предыдущий шаг, чтобы устано- вить <Publisher_Machine_Name>\repl_logreader в качестве учетной записи для the Log Reader Agent. Затем нажмите ОК. 13. На вкладке Complete the Wizard введите AdvWorksProductTrans в поле Publication name и нажмите Finish: 14. После создания публикации, нажмите Close для заверше- ния работы мастера. Если SQL Server Agent не запущен при попытке создать публи- кацию, может возникнуть следующая ошибка. Эта ошибка указывает на то, что публикация была создана успешно, но Snapshot Agent не смог запустить ее. В этом случае необходимо запустить SQL Server Agent, а затем вручную запустить Snapshot Agent. 2. Просмотр состояния создания моментальных снимков 1. Подключитесь к издателю в SQL Server Management Studio, раскройте узел сервера, а затем разверните папку Replication 2. В папке Local Publications щелкните правой кнопкой мы- ши AdvWorksProductTrans, а затем выберите View Snapshot Agent Status: 3. Отобразится текущий статус Snapshot Agent. Перед пере- ходом к следующему разделу убедитесь, что моментальный снимок выполнен успешно. 318 Если SQL Server Agent не был запущен при создании публика- ции, вы увидите, что Snapshot Agent никогда не запускался. В этом случае нажмите Start , чтобы запустить Snapshot Agent : 3 Добавление логина Distribution Agent в PAL 1. Подключитесь к издателю в SQL Server Management Studio, раскройте узел сервера, а затем разверните папку Replication. 2. В папке Local Publications, щелкните правой кнопкой мыши AdvWorksProductTrans, а затем выберите Properties. Появит- ся диалоговое окно Publication Properties. а. Выберите вкладку Publication Access List и нажмите Add. б. В диалоговом окне Add Publication Access выберите <Publisher_Machine_Name>\repl_distribution, и нажмите ОК. 4 Создание подписки на публикацию транзакций В этом разделе добавляется подписчик к ранее созданной пуб- ликации. В данной работе используется удаленный подписчик (NODE2\SQL2016), но вы также можете добавить локальную подпис- ку на издателя. Создание подписки 1. Подключитесь к издателю в SQL Server Management Studio, раскройте узел сервера, а затем разверните папку Replication. 2. В папке Local Publications щелкните правой кнопкой мыши на AdvWorksProductTrans, а затем выберите New Subscriptions. Запустится New Subscription Wizard: 3. На вкладке Publication, выберите AdvWorksProductTrans, а затем нажмите Next: 4. На вкладке Distribution Agent Location, выберите Run all agents at the Distributor, а затем нажмите Next. 5. На вкладке Subscribers, если не отображается имя под- писчика экземпляра, выберите Add Subscriber, а затем выберите Add SQL Server Subscriber из раскрывающегося списка. Этот шаг открывает диалоговое окно Connect to Server. Введите имя экземпляра подпис- чика и затем нажмите Connect. 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 341 Для установки MongoDB необходимо выполнить следующие шаги: 1) Импортировать публичный ключ, используемый текущим менеджером пакетов sudo apt-get install gnupg Как пакет будет установлен, нужно импортировать ключ: wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add – 2) Создать. list файл для MongoDB: echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org- 4.4.list 3) Перезагрузить локальную базу пакетов: apt-get update 4) Установить пакет MongoDB: sudo apt-get install -y mongodb-org 5) Настроить запуск MongoDB сервиса по умолчанию (рису- нок 6.45): systemctl start mongod systemctl status mongod systemctl enable mongod Рис. 6.45. Результаты выполнения команд Настройка установленной MongoDB Сначала необхо- димо войти в саму базу данных: mngo use admin 342 Теперь нужно создать пользователя базы данных со пра- вами администратора (рисунок 6.46): Рис. 6.46. Создание пользователя базы данных После создания пользователя нужно изменить файл конфигура- ции сервиса Mongod: nano /etc/mongod.conf В открывшемся файле необходимо поправить следующие стро- ки, где Х – номер виртуальной машины: net: port: 27017 bindIp: localhost, mongoreplicaX replication: replSetName: "replica01" Сохраните изменения, перезагрузите сервис mongod следующи- ми командами: systemctl daemon-reload systemctl restart mongod После того, как сервис перезагружен, запускаем его для конфи- гурации реплики: mongo rs.initiate() После выполнения этой команды на одной виртуальной ма- шине реплика создана, но в ней пока только один узел (первоначаль- но инициализируется как SECONDARY, затем быстро переключается в PRIMARY). Чтобы добавить остальные узлы, необходимо добавлять их изначально по IP-адресу: rs.add( Далее необходимо изменить IP-адрес на доменное имя, установ- ленное нами ранее в файле /etc/hosts. Сделать это можно с помощью 343 следующих команд, где Х – номер виртуальной машины (первую до- бавлять уже не нужно, так как она уже является участником ре- плики): cfg = rs.conf() cfg.members[i].host = “mongoreplicaX:27017” rs.reconfig(cfg) После реконфигурации MongoDB, все узлы присоединены к ре- плике, данные уже реплицируются, статусы узлов автоматически рас- пределены на один PRIMARY и два SECONDARY (рисунок 6.47). 344 Рис. 6.47. Готовая конфигурация реплики MongoDB Проверка репликации 345 Для проверки репликации данных необходимо воспользоваться средствами MongoDB (CRUD операции) – создание / чтение / обнов- ление / удаление данных; Для проверки отказоустойчивости необходимо воспользоваться средствами менеджера сервисов system (сервис mongod) и командами статуса реплики MongoDB. 5. Задания для самостоятельной работы 1 вариант: Разверните кластер из 3 узлов с одним арбитром. Чтение данных через основной узел (мастер). 2 вариант: Разверните кластер из 4 узлов: два с повышен- ными приоритетами, один арбитр. Включить чтение данных через одну из реплик. 3 вариант: Разверните кластер из 5 узлов: два с повышен- ными приоритетами, один арбитр. Чтение данных через основной узел (мастер). 4 вариант: Разверните кластер из 6 узлов: один узел с по- вышенным приоритетом, два арбитра. Включить чтение данных через три реплики. 5 вариант: Разверните кластер из 7 узлов: три с повышен- ными приоритетами, два арбитра. Чтение данных через основной узел (мастер). 6 вариант: Разверните кластер из 3 узлов с одним арбитром. Включить чтение данных через одну из реплик. 7 вариант: Разверните кластер из 4 узлов: один узел с по- вышенным приоритетом, один арбитр. Чтение данных через основной узел (мастер). 8 вариант: Разверните кластер из 5 узлов: два с повышен- ными приоритетами, один арбитр. Включить чтение данных через одну из реплик. 6. Контрольные вопросы 1. Что такое репликация данных? 346 2. Для чего нужна репликация данных? 3. Какие виды репликации поддерживает MongoDB? 4. Дайте определение набору реплик. 5. Какие есть проблемы чтения с реплики? 6. Какие есть способы сделать реплику доступной для чте- ния? 7. Что такое Arbiter? Для чего он необходим? 8. Как могут быть настроены процессы репликации? |