Серия разработок Mongodb – влияние наборов реплик на разработку программ

В этой статье в основном объясняется влияние архитектуры набора реплик на разработку программ со следующих аспектов

Автор делит разработку приложений на основе mongodb на два этапа: эксплуатация и обслуживание программного обеспечения и разработка программного обеспечения

Эта статья будет посвящена обмену практическим опытом на более позднем этапе

Понимание набора реплик и структуры “ведущий-ведомый”
Следуйте за строкой подключения к базе данных

Основные понятия набора реплик

Когда дело доходит до набора реплик, это набор реплик, одно из основных свойств распределенной системы.

Копия

Реплика-это одно из наиболее распространенных понятий распределенной системы, которое относится к избыточному способу передачи данных и услуг, предоставляемых распределенной системой. В общей распределенной системе для предоставления высокодоступных услуг мы часто обрабатываем данные и услуги с помощью реплик. Концепция реплики связана с согласованностью данных реплики.

В среде mongodb нам легко найти основное значение набора реплик из общедоступных данных

Репликация Mongodb (набор реплик) репликация mongodb – это процесс синхронизации данных на нескольких серверах.

Репликация обеспечивает избыточное резервное копирование данных и хранит копии данных на нескольких серверах, что повышает доступность данных и обеспечивает безопасность данных.

Репликация также позволяет восстанавливать данные после сбоев оборудования и перебоев в обслуживании

Роли набора реплик

Набор реплик Mongodb-это набор процессов mongodb, который обеспечивает высокую доступность с помощью ряда механизмов.

mongod-это основной процесс демона для системы MongoDB. Он обрабатывает запросы данных, управляет доступом к данным и выполняет операции фонового управления.

Роли набора реплик в основном включают главный узел, подчиненный узел и арбитражный узел. Главный узел отвечает за все операции записи.

Взаимосвязь между набором реплик и структурой “ведущий-ведомый”

Оба они принадлежат к разным структурам базы данных mongodb, и структура “ведущий-подчиненный” официально не рекомендована

Устарело с версии 3.6: MongoDB 3.6 запрещает использование репликации “ведущий-ведомый”.Репликация “Ведущий-ведомый” устарела для компонентов сегментированных кластеров начиная с MongoDB 3.2.

Основное различие между структурой ведущий-ведомый и набором реплик заключается в том, что первый имеет концепцию реального главного сервера, в то время как набор реплик не имеет концепции главного сервера. Основной узел выбирается путем выборов

Не запускайте арбитра в системах, в которых также размещены первичные или вторичные члены набора реплик

Арбитр должен быть развернут на отдельном сервере, чтобы избежать развертывания с основными узлами и узлами репликации

Традиционное развертывание “ведущий-ведомый”

Набор реплик

Это официальная более рекомендуемая структура развертывания Mongo

Набор реплик

Следуйте за строкой подключения к базе данных

Набор реплик-это метод развертывания архитектуры высокой доступности mongodb. Это должно быть предельно прозрачно для приложения, использующего базу данных. Внутренний переключатель экземпляра master-slave должен быть бессмысленным. То есть приложение не заботится о конкретной операции с базой данных и о том, какой экземпляр должен ее обрабатывать.

Мы можем указать, как подключить набор реплик в программе, и правильный режим подключения может избежать обычного переключения прикладной программы без ведома, когда основной узел выходит из строя или выходит из строя, что иллюстрируется графиком сети

На самом деле, в левой части рисунка есть проблема. Подключите экземпляр напрямую и укажите основной. Для драйвера, подключающего базу данных БД, не должно иметь значения, какой экземпляр является основным, а какой экземпляр является основным, изменится.

Представьте, что O & M предоставляет набор настроек для разрабатываемой строки подключения к базе данных. Как мы можем интегрировать его в приложение?

Установка фундамента

Для приложений PHP в качестве фреймворка используется yii2, а в качестве драйвера-yii2 mongodb

Адрес Github

устанавливать

Either run

php composer.phar require --prefer-dist yiisoft/yii2-mongodb

or add

"yiisoft/yii2-mongodb": "~2.1.0"

Строка подключения

прямое подключение

return [

    'class' => '\yii\mongodb\Connection',

    'dsn'  => 'mongodb://username:[email protected]:10000/databasename',

    'options'=>[

        'socketTimeoutMS' => 1000

    ]

];

Копирование установленного соединения

return [

'class' => '\yii\mongodb\Connection',

'dsn' => 'mongodb://user:[email protected]_test.mongodb.domain.cn:30000,s2.mongodb.domain.cn:30000,s3._test.mongodb.domain.cn:30000/databasename',

];

Проблема надвигается.

1 следует ли подключать все или только один экземпляр базы данных?

В рабочей среде существует три экземпляра коллекции репликации, каждый из которых выделен для строки подключения. У меня нет хорошего объяснения того, должны ли мы подключаться только к одному. Теоретически для подачи заявки требуется только одна запись, а позже все они будут переданы в базу данных для обработки.

2 должны ли отображаться настройки тайм-аута подключения?

Https://docs.mongodb.com/manu… Официальная ссылка на строку подключения.

Когда дело доходит до тайм-аута, давайте рассмотрим цикл подключения к базе данных

Полный запрос состоит из трех этапов: 1. Установление соединения 2. Передача данных 3. Отсоединяюсь.

Вообще говоря, мы говорим о двух типах тайм-аута: тайм-аут подключения и тайм-аут сокета. Первый-это тайм-аут сетевого подключения, а второй-тайм-аут выполнения.

Если время подключения, запрошенное сервером базы данных, превышает connectiontimeout, будет выдано исключение connectiontimeoutexception, то есть время ожидания подключения к серверу, и соединение не будет установлено в течение указанного времени. Если серверу требуется слишком много времени для обработки данных и превышение socketimeout, он выдаст socketimeoutexceptin, то есть истечет время отклика сервера, и сервер не вернет данные клиенту в течение указанного времени. (исключением здесь является исключение, возвращаемое драйвером Java)

Эти два параметра официально задаются как connecttimeoutms и sockettimeoutms

О параметре options в рабочей среде

В рабочей среде параметры replicaset, connecttimeoutms и socketimeoutms не настроены.

Официальные документы

Мнения, изложенные в статье, не являются строгими. Добро пожаловать для комментариев и общения. Автор также изучает коллекцию реплик.

С неуверенным мышлением изучите основные принципы базы данных mongodb: учитесь, практикуйтесь, ориентируйтесь, совершенствуйтесь и развивайтесь в проблемах.

Добро пожаловать на публичное выступление “Технология ТуНан.”