Если вы используете технологию кэширования Redis, вы должны подумать о том, как использовать Redis для добавления нескольких машин, чтобы обеспечить высокую параллельность Redis, и как сделать так, чтобы Redis не умирал сразу после зависания, а Redis был высокодоступным.
Высокий параллелизм Redis: архитектура master-slave, один мастер и несколько ведомых, вообще говоря, на самом деле достаточно многих проектов, один мастер используется для записи данных, одна машина используется для десятков тысяч запросов в секунду, несколько ведомых используются для данные запроса, а несколько подчиненных экземпляров могут обеспечить 100 000 запросов в секунду.
В то же время высокой параллелизма, Redis также должен вмещать большой объем данных: один мастер и несколько подчиненных, и каждый экземпляр содержит полные данные.Например, у мастера Redis есть 10 ГБ памяти, но на самом деле вы можете только вместить 10G данных. Если ваш кеш должен вмещать большой объем данных, достигающий десятков гигабайт, даже сотен гигабайт или нескольких т, тогда вам нужен кластер Redis, а после использования кластера Redis он может предоставлять сотни тысяч данных за один раз. во-вторых, читать и писать одновременно.
Высокая доступность Redis: если вы развернете архитектуру master-slave, вы действительно можете добавить Sentinel и добиться этого.Если какой-либо экземпляр выйдет из строя, переключение master-slave будет выполнено автоматически.
Ниже приводится подробное введение
1. Как Redis выполняет запросы на чтение с числом запросов в секунду, превышающим 100 000+, через разделение чтения и записи?
1. Связь между высоким уровнем параллелизма Redis и высоким уровнем параллелизма всей системы.
Если Redis хочет добиться высокого параллелизма, он должен хорошо работать с базовым кешем, чтобы меньше запросов направлялось непосредственно в базу данных, потому что высокий параллелизм базы данных сложнее реализовать, а некоторые операции требуют транзакций и т. д. ., поэтому очень сложно добиться высокого уровня параллелизма. Параллелизма Redis недостаточно для параллелизма всей системы, но как крупномасштабная архитектура кэширования Redis является очень важной частью архитектуры, поддерживающей высокий параллелизм. Для достижения высокого уровня параллелизма в системе промежуточное ПО кэширования и система кэширования должны сначала поддерживать высокий уровень параллелизма, а затем только после хорошей общей архитектуры кэша (многоуровневый кэш, кеш точек доступа) он сможет действительно поддерживать высокий уровень параллелизма.
2. Redis не может поддерживать узкие места с высоким параллелизмом.
Узким местом, которое Redis не может поддерживать высокий параллелизм, является в основном проблема с одной машиной, то есть существует только одна единственная Redis, независимо от того, насколько хороша производительность машины, есть верхний предел.
3. Как обеспечить более высокую степень параллелизма
Redis для одной машины не может поддерживать слишком высокий параллелизм.Чтобы поддерживать более высокий параллелизм, вы можете сделатьразделение чтения-записи. Что касается кеша, он обычно поддерживает высокий параллелизм чтения, а запрос на запись относительно небольшой, поэтому чтение и запись могут быть разделены на основе архитектуры ведущий-ведомый.
Настройте главный (главный) компьютер для записи данных, настройте несколько подчиненных (подчиненных) для чтения данных и синхронизируйте данные с подчиненным после того, как главный получит данные, чтобы подчиненный мог настроить несколько компьютеров. Это может улучшить общий параллелизм. .
2. Значение безопасности репликации redis и персистентности master для архитектуры master-slave.
1. Принцип репликации redis.
Несколько ведомых узлов подвешиваются под главным узлом, и операция записи записывает данные на главный узел.Затем, после записи ведущего, данные синхронизируются со всеми ведомыми узлами с помощью асинхронных операций, чтобы гарантировать, что данные всех узлов последовательный.
2. Основной механизм репликации redis
(1) Redis реплицирует данные на подчиненный узел асинхронно, но, начиная с Redis 2.8, подчиненный узел каждый раз будет периодически подтверждать количество репликаций, которыми он владеет. (2) Главный узел может быть сконфигурирован с несколькими подчиненными узлами. (3) Ведомый узел также может подключаться к другим ведомым узлам. (4) Когда подчиненный узел выполняет репликацию, он не будет блокировать нормальную работу главного узла. (5) Когда подчиненный узел выполняет репликацию, он не будет блокировать свои собственные операции.Он будет использовать старые данные для предоставления услуг, но когда репликация будет завершена, ему необходимо удалить старые данные и загрузить новые данные. услуга. (6) Ведомый узел в основном используется для горизонтального расширения и разделения чтения и записи.Расширенный подчиненный узел может повысить пропускную способность.
3. Значение для безопасности сохраняемости главного устройства в архитектуре ведущий-подчиненный
Если эта архитектура «главный-подчиненный» принята, должна быть включена персистентность главного узла. Не рекомендуется использовать ведомый узел в качестве горячей резервной копии ведущего узла, так как в этом случае, если ведущий выйдет из строя, данные ведущего будут потеряны, а после перезапуска данные будут пустыми. , поэтому данные всех узлов теряются. Необходимо делать различные холодные резервные копии файлов резервных копий, чтобы предотвратить поломку всей машины и потерю данных резервной копии rdb.
3. Принцип репликации Redis master-slave, возобновление точки останова, бездисковая репликация, обработка просроченных ключей
1. Принцип репликации master-slave
① При запуске ведомого узла он отправляетPSYNCкоманду главному узлу.
②Если ведомый узел должен повторно подключиться к ведущему узлу, то главный узел только скопирует недостающие данные на ведомый; если это первый раз, когда он подключается к ведущему узлу, он будет активирован один раз.full resynchronization.
③ При запуске полной ресинхронизации мастер запуститфоновая нить, начинает генерировать файл моментального снимка RDB, а также кэширует в памяти все вновь полученные от клиента команды записи.
④Главный узел отправляет сгенерированный файл RDB подчиненному узлу,подчиненный теперь записывает его на локальный диск, а затем загружает его в память с диска. Затем главный узел отправит команду записи, кэшированную в памяти, подчиненному узлу,Подчиненный узел также будет синхронизировать эту часть данных.
⑤ Если подчиненный узел отключен от главного узла из-за сбоя в сети,автоматически переподключится.
⑥ Если мастер обнаружит, что есть несколько подчиненных узлов для повторного подключения,только запустит операцию сохранения rdbобслуживать все подчиненные узлы одной копией данных.
2. Точка останова возобновления репликации master-slave
Начиная с redis2.8, поддерживается возобновляемая загрузка. Если сеть внезапно отключилась во время процесса репликации master-slave, вы можете продолжить в последний раз
Куда скопировали, продолжайте копировать, а не копировать с нуля. принцип:
Главный узел создаст невыполненную работу в памяти, и главный, и подчиненный сохранят смещение реплики и идентификатор мастера, а смещение будет сохранено в невыполненной работе. Если сетевое соединение между ведущим и ведомым отключено, ведомое устройство позволит ведущему продолжить репликацию с последнего смещения реплики. Но если смещение не найдено, выполняется полная операция ресинхронизации.
3. Бездисковое копирование
Бездисковая репликация означает, что мастер напрямую создает файл RDB в памяти и отправляет его подчиненному без сохранения данных на своем локальном диске.Как установить Настройте параметры repl-diskless-sync и repl-diskless-sync-delay. repl-diskless-sync: этот параметр обеспечивает бездисковую репликацию. repl-diskless-sync-delay: этот параметр означает ожидание в течение определенного периода времени перед запуском репликации, чтобы можно было повторно подключить несколько подчиненных узлов.
4. Просроченная обработка ключей
раб не истечет ключ, только ожидая, пока мастер истечет срок действия ключа. Если у мастера истекает срок действия ключа или он устаревает, мастер имитируетотправить команду delДля ведомого ведомый удалит ключ после его получения.
4. Углубленный анализ всего процесса потока и принципа репликации redis
1. Полный процесс репликации
①Подчиненный узел запущен, и сохраняется только информация о главном узле, включая хост и IP-адрес главного узла, но репликация данных еще не началась. Хост и ip главного узла настраиваются в slaveOf в файле redis.conf.
② Внутри ведомого узла есть задача синхронизации, которая каждую секунду проверяет, есть ли новый главный узел для подключения к репликации, и, если он найден, устанавливает сетевое соединение сокета с главным узлом.
③ Ведомый узел отправляет команду ping главному узлу.
④ Если мастер устанавливает requirepass, подчиненный узел должен отправить главный пароль авторизации для проверки пароля.
⑤ Главный узел впервые выполняет полную репликацию и отправляет все данные подчиненному узлу.
⑥Главный узел постоянно записывает команды и асинхронно копирует их на подчиненный узел.
2. Механизм синхронизации данных
Относится к ситуации, когда ведомое устройство подключается к ведущему в первый раз и выполняет полную репликацию. ① Ведущий и ведомый устройства поддерживают смещение Ведущее устройство будет продолжать накапливать в себе смещение, а ведомое устройство также будет продолжать накапливать в себе смещение. Ведомое устройство каждую секунду будет сообщать мастеру о своем смещении, а мастер также будет сохранять смещение каждого подчиненного устройства. Это не означает, что он специально используется для полной репликации, основная причина в том, что мастер и ведомый должны знать смещение своих соответствующих данных, чтобы знать несогласованность данных между ними.
②отставание У главного узла есть отставание в памяти, которое по умолчанию составляет 1 МБ. Когда главный узел реплицирует данные на подчиненный узел, он также синхронизирует копию данных в невыполненной работе. Резерв в основном используется для добавочной репликации, когда полная репликация прерывается.
③основной идентификатор запуска Redis может просматривать основной идентификатор запуска через информационный сервер. использовать: ведомое устройство определяет местонахождение единственного ведущего на его основе. Почему бы не использовать host+ip: поскольку использовать host+ip для определения местонахождения главного узла ненадежно, в случае перезапуска главного узла или изменения данных подчиненные устройства следует различать в соответствии с разными идентификаторами запуска мастера, а для разных идентификаторов запуска требуется полная репликация. Если вам нужно перезапустить Redis без изменения идентификатора запуска, вы можете использоватьredis-cli debug reloadЗаказ.
3. Процесс и механизм полной репликации
①Мастер выполняет bgsave для локального создания файла RDB.
②Главный узел отправляет файл моментального снимка RDB подчиненному узлу.Если время репликации файла RDB превышает 60 секунд (repl-timeout), подчиненный узел не сможет скопировать задачу, и этот параметр можно настроить соответствующим образом.
③ Для машины с гигабитной сетевой картой обычно передается 100 МБ в секунду, а передача файлов 6G может превышать 60 секунд.
④Когда главный узел создает файл RDB, он кэширует все вновь полученные команды записи в памяти.После того, как подчиненный узел сохраняет файл RDB, эти команды записи копируются на подчиненный узел.
⑤ Проверьте параметр ведомого устройства client-output-buffer-limit, например [client-output-buffer-limit slave 256MB 64MB 60], что означает, что в течение периода копирования кэш памяти продолжает потреблять более 64 МБ или более 256 МБ за раз, затем остановите копирование, репликация не удалась.
⑥ После того, как подчиненный узел получает файл RDB, он очищает свои данные, а затем перезагружает файл RDB в свою память, в этом процессе он предоставляет внешние услуги на основе старых данных.
⑦ Если на ведомом узле включен AOF, немедленно будет выполнено BRREWRITEAOF, и AOF будет перезапущен.
генерация rdb, копирование rdb по сети, очистка старых данных слейва, перезапись слейва aof, очень трудоемко
Если объем копируемых данных находится между 4G и 6G, вполне вероятно, что время полного копирования займет от 1,5 до 2 минут.
4. Процесс и механизм инкрементной репликации
① Если сетевое соединение между ведущим и ведомым будет разорвано во время процесса полной репликации, повторное подключение ведомого устройства к ведущему вызовет дополнительную репликацию.
②Мастер напрямую получает некоторые потерянные данные из своего невыполненного журнала и отправляет их на подчиненный узел.
③Мастер получает данные из очереди в соответствии со смещением в psync, отправленном ведомым.
5. Сердцебиение
И ведущий, и ведомый отправляют друг другу информацию о пульсе. Мастер отправляет его каждые 10 секунд по умолчанию, а подчиненный узел по умолчанию отправляет его каждую 1 секунду.
6. Асинхронная репликация
Каждый раз, когда мастер получает команду записи, он записывает данные внутрь, а затем асинхронно отправляет их на подчиненный узел.
5. Как добиться высокой доступности на уровне 99,99 % в архитектуре redis master-slave?
1. Что такое высокая доступность на уровне 99,99 %?
высокая доступность(английский: высокая доступность, сокращенно HA), ИТ-термин, относится к способности системы выполнять свои функции без перерыва, отражая степень доступности системы. Это один из критериев проектирования системы. Система высокой доступности может работать дольше, чем отдельные компоненты, составляющие систему.
Высокая доступность обычно достигается за счет повышения отказоустойчивости системы. Определение того, что составляет высокую доступность для системы, часто требует анализа в каждом конкретном случае.
Он измеряется на основе времени, в течение которого система была повреждена, непригодна для использования, и времени, которое потребовалось для восстановления от неработоспособности до рабочего состояния, по сравнению с общим временем безотказной работы системы. Формула расчета:
A (доступность), MTBF (среднее время наработки на отказ), MDT (среднее время до ремонта)
Онлайн-системы и критически важные системы обычно требуют пяти девяток доступности (99,999%).
Доступность
Ежегодный простой
99.9999%
32 секунды
99.999%
5 минут 15 секунд
99.99%
52 минуты 34 секунды
99.9%
8 часов 46 минут
99%
3 дня 15 часов 36 минут
2. редис недоступен
Redis не может учитывать недоступность отдельного экземпляра и недоступность архитектуры «главный-подчиненный». Недоступно: ① Главный узел архитектуры ведущий-подчиненный зависает.Если главный узел зависает, кэшированные данные не могут быть записаны, а данные в подчиненном не могут истечь, что приводит к недоступности.
② Если это один экземпляр, процесс redis может завершиться по другим причинам. Или машина, на которой развернут Redis, сломана.
Последствия недоступности:Во-первых кеш недоступен,затем запрос попадет сразу в БД.Если наплыв запросов превысит пропускную способность БД, то БД зависнет.Если проблема с кешем не может быть вовремя устранена на данном этапе время, то из-за слишком большого количества запросов, после перезапуска базы данных, она снова зависнет, что напрямую делает всю систему недоступной.
3. Как добиться высокой доступности
① Убедитесь, что у каждого Redis есть резервная копия. ② Убедитесь, что после сбоя текущего redis вы можете быстро переключиться на резервный redis. Для решения этой проблемы вводится следующий дозорный механизм.
6. Объяснение базовых знаний об архитектуре Redis Sentinel
1. Что такое Страж?
Sentinal — очень важный компонент в архитектуре кластера Redis, в основном он выполняет следующие функции: ①Кластерный мониторинг, отвечающий за контроль за правильностью работы главного и подчиненного процессов Redis. ②уведомление, если экземпляр redis выходит из строя, часовой отвечает за отправку сообщения администратору в качестве уведомления о тревоге. ③отказоустойчивость, если мастер умирает, он будет автоматически передан слейву. ④Центр конфигурации, если произойдет сбой, уведомите клиентский клиент о подключении к новому мастеру.
2. Основные знания Sentinel
① Дозорный сам по себе является распределенным и должен работать как кластер, а дозорные работают вместе. ② Во время аварийного переключения считается, что мастер не работает, и большинству сигнальных устройств необходимо дать согласие. ③ Даже в случае сбоя некоторых Sentinel кластер Sentinel все еще может нормально работать. ④ Для обеспечения надежности Sentinels требуется не менее 3 экземпляров. ⑤ Структура Sentinel+redis master-slave не может гарантировать нулевой потери данных, а только обеспечивает высокую доступность кластера Redis. ⑥ В соответствии с архитектурой sentinel + redis master-slave, перед его использованием необходимо провести повторные тесты и тренировки.
3. Почему развертывание кластера Sentinel с 2 узлами не работает?
В кластере Sentinel должно быть развернуто более 2 узлов. Если в кластере развернуто только 2 экземпляра дозорных, то кворум = 1 (количество дозорных, которые необходимо согласовать для выполнения отработки отказа).
Как показано на рисунке, если master1 не работает в это время, пока один из Sentinel 1 и Sentinel 2 считает, что master 1 не работает, может быть выполнен переход на другой ресурс. выполнить отказоустойчивость. В то же время в это время требуется большинство (то есть более половины числа часовых во всех кластерах).Если есть два стража, то большинство равно 2, что означает, что по крайней мере два стража все еще работают до отработки отказа. может быть выполнено. Однако, если весь мастер и дозорный 1 отключатся одновременно, останется только один дозорный.В это время не будет большинства для запуска и выполнения аварийного переключения.Хотя дозорный есть на одной машине за пределами двух , 1 не может быть больше 1, и просто нет гарантии, что больше половины, поэтому отработка отказа не будет выполнена.
4. Классический кластер Sentinel с 3 узлами
Конфигурация: кворум=2, большинство=2
Если машина, на которой находится M1, выходит из строя, то остается еще 2 часовых, S2 и S3 могут договориться, что мастер не работает, а затем выбрать один для выполнения аварийного переключения.
В то же время большинство из 3 дозорных устройств равно 2, поэтому оставшиеся 2 дозорных устройства работают, чтобы можно было выполнить отработку отказа.
7. Проблема потери данных при переключении master/slave redis sentinel: асинхронная репликация, разделение мозга кластера
1. Два сценария потери данных
①Потеря данных из-за асинхронной репликации Поскольку процесс репликации данных от мастера к слейву асинхронный, некоторые данные могут не успеть скопировать на слейв, в это время мастер не работает, и эта часть данных теряется.
②Потеря данных, вызванная расщеплением кластера Что такое расщепленный мозг: Split-brain, то есть машина, на которой некий мастер внезапно отключается от обычной сети и не может быть подключен к другим подчиненным машинам, но на самом деле мастер все еще работает. В это время дозорный может подумать, что ведущий вышел из строя, а затем открыть выборы, чтобы переключить других подчиненных на ведущих. В это время в кластере будет два мастера, что является так называемым разделенным мозгом.
В это время, хотя ведомое устройство переключено на ведущее, клиент может не успеть переключиться на новое ведущее, и данные, которые продолжают записываться на старое ведущее, также могут быть потеряны. Поэтому, когда старый мастер снова восстановится, он будет присоединен к новому мастеру в качестве ведомого, его собственные данные будут очищены, а данные будут снова скопированы с нового мастера.
2. Устранение потери данных, вызванной асинхронной репликацией с разделенным мозгом.
Для решения этой проблемы необходимо настроить два параметра: min-slaves-to-write 1иmin-slaves-max-lag: Указывает, что требуется как минимум один ведомый сервер для репликации и синхронизации данных с задержкой не более 10 секунд. Если однажды все подчиненные данные синхронизации и задержки репликации превысят 10 секунд, то в это время мастер примет любой запрос. ①Уменьшить потерю данных при асинхронной репликации. С конфигурацией min-slaves-max-lag можно гарантировать, что после того, как ведомое устройство реплицирует данные, а задержка подтверждения слишком велика, считается, что слишком много данных может быть потеряно после того, как ведущее устройство не работает, и запрос на запись отклоняется, так что когда ведущее устройство не работает, потеря данных, вызванная тем, что некоторые данные не синхронизированы с ведомым устройством, уменьшается до контролируемого диапазона.
(2) Уменьшить потерю данных в разделенном мозгу
Если ведущее устройство имеет разделенный мозг и теряет связь с другими ведомыми устройствами, две приведенные выше конфигурации могут гарантировать, что если оно не сможет продолжать отправлять данные указанному количеству ведомых устройств, а ведомое устройство не выдаст себе сообщение подтверждения в течение более 10 секунд. , то он будет отклонен непосредственно запросом на запись клиента.
Таким образом, старый мастер после разделения мозга не будет принимать новые данные клиента, что позволит избежать потери данных.
Приведенная выше конфигурация гарантирует, что если соединение с каким-либо ведомым устройством будет потеряно, и через 10 секунд будет обнаружено, что нет ведомого устройства для подтверждения, то новый запрос на запись будет отклонен.
Поэтому в сценарии с разделенным мозгом теряется максимум 10 секунд данных.
8. Углубленный анализ нескольких основных принципов redis sentinel (включая алгоритм выбора подчиненного устройства)
1. Два состояния sdown и odown
sdown — это субъективное время простоя.Если дозорный думает, что мастер не работает, то это субъективное время простоя
odown — это объективное время простоя. Если кворум часовых чувствует, что мастер не работает, то это объективное время простоя.
Условия для достижения sdown очень просты: если часовой пингует мастер и превышает количество миллисекунд, указанное is-master-down-after-milliseconds, он субъективно считает, что мастер не работает.
Условия преобразования sdown в odown очень просты: если дозорный получает заданное количество кворумов за указанное время, другие дозорные тоже думают, что мастер sdown, то это считается odown, и объективно считается, что мастер вниз.
2. Механизм обнаружения полей кластера Sentinel
①Обнаружение между часовыми достигается через систему pub/sub Redis, и каждый часовой переходит к__sentinel__:helloПо этому каналу отправляется сообщение.В это время другие дозорные могут использовать это сообщение и воспринимать существование других дозорных.
②Каждые две секунды каждый сигнальный узел переходит к соответствующему главному и подчиненному, за которым он следит.__sentinel__:helloОтправьте сообщение в канале, контент - это собственный хост, ip и идентификатор запуска, а также конфигурация мониторинга мастера.
③ Каждый дозорный также будет контролировать соответствующий ведущий+ведомый, контролируемый им самим.__sentinel__:helloканал, r затем обнаруживает существование других часовых, которые также прослушивают этот ведущий + подчиненный.
④ Каждый дозорный также будет обмениваться конфигурацией мониторинга главного устройства с другими дозорными устройствами и синхронизировать конфигурацию мониторинга друг с другом.
3. Самокоррекция конфигурации слейва
Дозор будет отвечать за автоматическое исправление некоторых конфигураций ведомого устройства.Например, если ведомое устройство должно стать потенциальным кандидатом в ведущее устройство, дозорное устройство проследит за тем, чтобы ведомое устройство реплицировало существующие данные ведущего устройства; если ведомое устройство подключено к неправильному master, например, после аварийного переключения, то часовой убедитесь, что они подключены к правильному мастеру.
4. Алгоритм выборов
Если ведущий считается отключенным, а число сигнальных устройств, составляющее большинство, допускает переключение ведущий-ведомый, то переключение ведущий-ведомый будет выполнять часовой, и первым должен быть выбран подчиненный. В ходе выборов будет учитываться следующее: ①Время, в течение которого ведомое устройство отключается от ведущего. ②Приоритет ведомого ③Смещение данных подчиненной копии ④Идентификатор запуска ведомого
Во-первых, если ведомое устройство было отключено от ведущего более 10 раз в течение миллисекунд, плюс продолжительность времени, в течение которого ведущее устройство было отключено, ведомое устройство считается непригодным для избрания в качестве ведущего. То есть: время отключения> (вниз-после-миллисекунд * 10 + миллисекунды_с_мастера_ис_в_SDOWN_state).
Остальные ведомые устройства сортируются следующим образом: ① Во-первых, отсортируйте по приоритету подчиненного устройства, чем ниже приоритет подчиненного устройства, тем выше приоритет. ② Если приоритет одинаковый, посмотрите на смещение реплики: чем больше данных реплицирует ведомое устройство, чем позднее смещение, тем выше приоритет. ③ Если вы хотите, как указано выше, выберите ведомое устройство с наименьшим идентификатором запуска.
5. кворум и большинство
Каждый раз, когда дозорный узел выполняет переключение ведущий-резервный, ему сначала требуется кворум дозорных для рассмотрения отказа, а затем он выбирает дозорный для переключения ведущий-резервный.
Если кворум
Если кворум >= большинство, перед переключением должно быть авторизовано количество дозорных в кворуме.
6.configuration epoch
Sentinel будет отслеживать набор redis master+slave и иметь соответствующую конфигурацию мониторинга.
Sentinel, выполняющий переключение, получит от нового мастера (salve->master) эпоху конфигурации, которая является номером версии, и номер версии для каждого переключателя должен быть уникальным.
Если первый выбранный дозорный не удается переключиться, другие дозорные будут ждать времени ожидания аварийного переключения, а затем продолжат выполнять переключение.В это время новая эпоха конфигурации будет повторно получена как новый номер версии.
7. разворот конфигурации
После того как дозорный узел завершит переключение, он локально обновит и сгенерирует последнюю основную конфигурацию, а затем синхронизирует ее с другими дозорными с помощью упомянутого ранее механизма публикации/подписки.
Предыдущий номер версии здесь очень важен, потому что через канал публикуются и отслеживаются различные сообщения, поэтому после того, как дозорный завершает новое переключение, за новой основной конфигурацией следует новый номер версии.
Другие дозорные обновляют свою основную конфигурацию в соответствии с размером номера версии.