Мастер и слейв что это
Что такое Master, Slave, Conner Present и Cable Select
Это режимы работы IDE-устройств.
На одном IDE-кабеле могут работать до двух устройств:
Master (MA) — основной, или первый, и
Slave (SL) — дополнительный, или второй.
На некоторых IDE шлейфах есть пометки: Master/Slave.
Мастер — дальний конец шлейфа, слейв — тот, что посередине.
Если устройство на кабеле одно, оно обычно может работать в режиме Master, однако у некоторых для этого есть отдельный режим Single.
Как правило, не допускается работа устройства в режиме Slave при отсутствии Master-устройства, однако многие новые устройства могут работать в этом режиме.
При этом требуется поддержка со стороны BIOS или драйвера: многие драйверы, обнаружив отсутствие Master-устройства, прекращают дальнейший опрос данного контроллера.
Conner Present (CP) — имеющийся на некоторых моделях режим поддержки винчестеров Conner в режиме Slave; введен из-за несовместимостей в диаграммах обмена по интерфейсу.
Cable Select (CS, CSel) — выбор по разъему кабеля — режим, в котором устройство само устанавливается в режим Master/Slave в зависимости от типа разъема на интерфейсном кабеле.
Для этого должен быть выполнен ряд условий:
— оба устройства должны быть установлены в режим Cable Select;
— контакт 28 со стороны контроллера должен быть либо заземлен, либо на нем должен поддерживаться низкий уровень;
— на одном из разъемов кабеля контакт 28 должен быть удален, либо отключен подходящий к нему провод кабеля.
Таким образом, на одном из устройств контакт 28 оказывается заземленным (этот винчестер настраивается на режим Master), а на другом — свободным (Slave).
Это означает, чтобы начал работать режим Cable Select нужен в первую очередь специальный шлейф.
Он симметричен, т.е. если его сложить пополам, то ровно в середине будет коннектор.
Именно этот коннектор включается в мат. плату, а оба оставшихся крайних коннектора — в устройства IDE.
На обоих IDE устройствах перемычки переключаются в режим Cable Select.
Тогда контроллер сам выбирает, кто ведущий, а кто ведомый в этой паре.
Этот режим корректно работает только при наличии двух устройств на кабеле и не получил широкого распространения.
На обычном кабеле этот режим не работает.
В комплекте с мат. платами идут кабели Master-Slave, и лучше перемычками выставить зависимости устройств.
Все перечисленные режимы устанавливаются перемычками (джамперами) на плате устройства.
Положения перемычек обычно описаны на корпусе или в инструкции.
Master&Slave. Какую роль играют ведущие и ведомые устройства в подключении датчиков присутствия?
C английского Master&Slave переводится как «ведущий-ведомый». То есть в схеме один элемент является ведущим, а остальные, подключенные к главному элементы, – ведомыми.
В зависимости от количества устройств такая схема напоминает звезду или последовательное соединение, где сигналы slave-устройств направлены в одну точку master.
Эта схема подключения используется в таких сферах как IT, связь, электроника и автоматика.
Master&Slave устройства в датчиках присутствия
В датчиках присутствия понятия «master» и «slave» относятся к подключению датчиков.
Как и принято, master здесь ведущее устройство, а slave – ведомое.
Такую схему подключения используют для автоматизации помещений с большой площадью или для управления одной нагрузкой с большим количеством светильников на длинных расстояниях, например, на складах.
В проходе между стеллажей, устанавливается один датчик master, у которого есть все необходимые функции. В глубине прохода устанавливают slave-датчики. От них требуется только обнаружение.
Комбинация master и slave-устройств расширяет зону действия ведущего датчика. Это удобно, например, для управления длинной группой светильников.
Кроме экономии важная особенность системы с ведущими и ведомыми элементами – согласованность. Использование двух и более master-устройств в датчиках присутствия может привести к рассогласованности или неправильной работе системы.
В схеме Master&Slave ведущее устройство – «капитан на корабле». Конечные действия принимает только он, ведомые лишь посылают импульс главному датчику по специальному каналу.
Схема подключения Master&Slave датчиков присутствия
В датчиках компании B.E.G. для подключения Slave устройств к датчику Master используется разъем R. Ниже представлена схема подключения ведущего и ведомого устройства.
Нужно иметь в виду, что схемы подключения бывают разные в зависимости от модели. К одному master-устройству можно подключить до десяти slave-датчиков, длина линии не должна при этом превышать ста метров.
Привязки к конкретной модели нет: к любому master-датчику может быть подключен любой slave-датчик. При этом датчики slave не могут использоваться без ведущих устройств, так как master обладает множеством функций, недоступных датчикам slave и только датчик master управляет нагрузкой.
Например, master управляет группой светильников и измеряет освещенность, ведомое же устройство регистрирует движение и присутствие в своей зоне не доступном датчику мастер. Slave-датчики не имеют реле, сенсоров освещенности и программируемых функций, они могут только подавать импульс раз в две или раз в девять секунд.
Также slave-датчик имеет возможность отключения светодиодных индикаторов, для этого у него есть потенциометр на корпусе датчика.
Так как реле и сенсором освещенности оснащен только датчик master, важно правильное его расположение в связке master&slave – master устанавливается подальше от окон, где меньше всего естественного освещения, а ближе к окнам ставится датчик slave.
Схема Master&Slave для датчиков KNX/DALISYS
Среди датчиков присутствия различают модели master и slave. Например, модель PD2-M – это master-устройство, а модель PD2-S – slave.
Датчики присутствия, основанные на шинной технологии KNX или DALI(не включая DALI broadcast), могут назначаться и master-устройствами, и slave-устройствами. Для этого при программировании датчика задается определенный режим.
О возможностях протокола KNX и системы DALI мы уже рассказывали в нашем блоге. Оставьте свой e-mail, чтобы не пропускать новые материалы про автоматизацию освещения.
Python тоже частично отказывается от терминов master/slave
Политкорректность учитывается даже в языках программирования. На прошлой неделе Python-разработчик Виктор Стиннер (Victor Stinner) из Red Hat прислал четыре пул-реквеста на переименование потенциально оскорбительных терминов master/slave (хозяин/раб) в документации и коде Python. Автор предложил заменить их социально нейтральными словами, не оскорбляющими людей, чьи предки были настоящими рабами. В качестве возможной альтернативы есть термины parent/worker.
Предлагаемое изменение — не какая-то прихоть одного разработчика, а общая тенденция для разных языков программирования и технологий. Стиннер привёл примеры аналогичных изменений в Redis, Drupal, CouchDB и Django. Так, Django и CouchDB заменили термины master/slave на leader/follower.
При этом Стиннер высказал мнение, что «рабовладельческую» терминологию всё-таки можно оставить для некоторых терминов, таких как ветка master в Git, веб-мастер и postmaster.
Развернулась жаркая дискуссия.
Поиск по кодовой базе python/cpython находит многочисленные включения «оскоробительных» терминов master и slave рядом друг с другом, в том числе в библиотеках pty и openpty.
Виктор Стиннер говорит, что «поступали жалобы» на такую терминологию, но они высказывались в частном порядке, а не публично, чтобы избежать ругани.
В обсуждении проблемы коллеги обращают внимание, что документация Python не дублирует документацию Linux — а именно оттуда идёт использование терминов master/slave для многих функций. Таким образом, если согласиться на переименование только для Python, то это приведёт к отклонению от общепринятого стандарта Linux. Грубо говоря, одни и те же функции документация Python и Linux будет описывать разными словами. Коллеги предлагают отказаться от изменений «вторичной» документации Python до тех пор, пока соответствующие изменения не будут внесены в документацию Linux.
Внимание разработчиков привлекают в первую очередь такие участки кода и терминологии, где слова «хозяин» и «раб» встречаются рядом друг с другом. Если же master упоминается изолированно, то эти фрагменты можно оставить в неприкосновенности. Например, в модуле doctest есть обозначение doctest.master:
По мнению Виктора Стиннера, это уже выглядит не слишком оскорбительно.
Автор нашёл множество случаев, где упоминается «унизительная лексика». Например, в nntplib.NNTP() есть метод slave(), который отправляет команду slave на сервер. Данное исправление потребует изменений протокола NNTP, а именно раздела 3.12 (команда SLAVE), пишет Стиннер.
Другой пример — атрибут mbuf.master обект PyMemoryViewObject в программных интерфейсах C API:
В общем, master и slave встречаются буквально повсюду. Виктор Стиннер предложил ряд патчей, которые местами исправляют ситуацию. Таким образом, в версии Python 3.8 термины master/slave будут встречаться реже.
Теоретически, в отдельных случаях проблему можно решить, не отказываясь от устоявшейся терминологии. Например, разработчики Redis предложили оригинальный выход из ситуации: с версии 1.0.0 там поддерживается команда SLAVEOF NO ONE, которая превращает сервер-slave в сервер-master. Хуже, если соответствующих изменений в синтаксисе потребуют власти. Предпосылки к этому уже есть. Например, в 2003 году отдел закупок департамента внутренних сервисов округа Лос-Анджелес разослал производителям электроники и бытовой техники уведомление с просьбой избегать терминов master/slave в описании своей продукции.
В 2004 году группа мониторинга Global Language Monitor назвала master/slave самым политически некорректным термином года. В технологической индустрии эти слова употребляются очень давно и стали частью многочисленных стандартов, в том числе RFC 977 от 1986 года.
По поводу пулл-реквестов Виктора Стиннера начались споры, которые полностью отражают аргументы убеждённых противников и сторонников политкорректности — такие споры ведутся на разных форумах. Конец дискуссии положил сам Гвидо ван Россум, который формально уже отошёл от дел, но присматривает за своим детищем Python. Он смерджил три из четырёх предложенных пул-реквеста, а четвёртый отверг, потому что он отражает оригинальную терминологию pty из UNIX.
Заметим, что «оскорбительная» терминология по историческим причинам стала частью современного языка и вряд ли от неё можно полностью избавиться. Например, Дэвид Гребер в книге «Долг: первые 5000 лет истории» приводит пример понятий “dominium” (доминиум) и “familia” (семья):
Что касается понятия “dominium”, то оно происходит от слова “dominus”, которое означает «хозяин», или «рабовладелец», но восходит к слову “domus”, т. е. «дом», или «хозяйство». С этим связан английский термин “domestic” («домашний»), который даже сегодня может использоваться в значении «относящийся к частной жизни» или же обозначать слугу, убирающего дом. “Domus” перекликается со словом “familia”, т. е. «семья», но “familia” происходит от слова “famulus”, т. е. «раб». Изначально под семьёй понимались все люди, находившиеся под домашней властью “pater familias”, которая была, по крайней мере в раннем римском праве, абсолютной.
У мужчины не было полной власти над женой, поскольку она до некоторой степени по-прежнему оставалась под защитой своего отца, но с детьми, рабами и другими зависимыми людьми он мог делать все, что ему вздумается, — во всяком случае, в раннем римском праве он был волен их пороть, пытать или продавать. Отец мог даже казнить своих детей, если обнаруживал, что они совершили тяжкое преступление. А если дело касалось рабов, то ему не требовалось и этого предлога.
Создавая понятие “dominium”, которое легло в основу современного принципа частной собственности, римские юристы обратились к принципу домашней власти, полной власти над людьми, определили некоторых из этих людей (рабов) как вещи, а затем распространили логику, которая изначально применялась по отношению к рабам, на гусей, колесницы, амбары, ювелирные шкатулки и т. д., то есть на любую вещь, имеющую отношение к праву.
То есть даже слова «семья», «фамилия» или понятие частной собственности можно считать неполиткорректными по такой логике: все они имеют отношение к рабству. Эти понятия вошли в современные языки со многими словами, о происхождении которых люди обычно не задумываются. Есть повод оскорбиться и у славян.
«Весьма неполиткорректно присваивать типы объектам до момента их создания!
Мы не должны навязывать объектам, кем им быть, а кем — нет.
Объект может сам решить, какого он типа, прямо в рантайме. Более того, он вправе изменить свой тип, если почувствует к этому внутреннюю расположенность.
Сегрегация объектов по их типу должна быть запрещена на законодательном уровне, покуда не станет интернированной социальной нормой каждого кодера.
Всем объектам на уровне операционной системы должны быть гарантированы равные возможности и по первому требованию предоставлены равные права.
Пока системы далеки от совершенства, стоит предусмотреть в них обязательные квоты для объектов каждого типа и следить за их неукоснительным соблюдением».
Репликация данных
Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других (называемые репликами). Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.
Существует два основных подхода при работе с репликацией данных:
Master-Slave репликация
В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.
В приложении нужно использовать два соединения – одно для Мастера, второе — для Слейва:
Используем два соединения — для Мастера и Слейва — для записи и чтения соответственно
Несколько Слейвов
Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.
Тогда из приложения Вы выбираете случайным образом один из Слейвов для обработки запросов:
Асинхронность репликации означает, что данные на Слейве могут появится с небольшой задержкой. Поэтому, в последовательных операциях необходимо использовать чтение с Мастера, чтобы получить актуальные данные:
При обращении к изменяемым данным, необходимо использовать Мастер-соединение
Выход из строя
При выходе из строя Слейва, достаточно просто переключить все приложение на работу с Мастером. После этого восстановить репликацию на Слейве и снова его запустить.
Если выходит из строя Мастер, нужно переключить все операции (и чтения и записи) на Слейв. Таким образом он станет новым Мастером. После восстановления старого Мастера, настроить на нем реплику, и он станет новым Слейвом.
Резервирование
Намного чаще репликацию Master-Slave используют не для масштабирования, а для резервирования. В этом случае, Мастер сервер обрабатывает все запросы от приложения. Слейв сервер работает в пассивном режиме. Но в случае выхода из строя Мастера, все операции переключаются на Слейв.
Master-Master репликация
В этой схеме, любой из серверов может использоваться как для чтения так и для записи: 
При использовании такого типа репликации достаточно выбирать случайное соединение из доступных Мастеров:
Выбор случайного Мастера для обработки соединений
Выход из строя
Вероятные поломки делают Master-Master репликацию непривлекательной. Выход из строя одного из серверов практически всегда приводит к потере каких-то данных. Последующее восстановление также сильно затрудняется необходимостью ручного анализа данных, которые успели либо не успели скопироваться.
Используйте Master-Master репликацию только в крайнем случае. Вместо нее лучше пользоваться техникой “ручной” репликации, описанной ниже.
Асинхронность репликации
В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Слейве. 
Задержка в репликации (replication lag) может быть как очень маленькой, так и очень большой. Обычно рост задержки говорит о том, что сервера не справляются с текущей нагрузкой и их необходимо масштабировать дальше, например техниками горизонтального и вертикального шардинга.
Синхронный режим
Синхронный режим репликации позволит гарантировать копирование данных на Слейв. 
Это упростит работу в приложении, т.к. все операции чтения можно будет всегда отправлять на Слейв. Однако это может значительно уменьшить скорость работы MySQL. Синхронный режим не следует использовать в Web приложениях.
“Ручная” репликация
Следует помнить, что репликация — это не технология, а методика. Встроенные механизмы репликации могут принести ненужные усложнения либо не иметь какой-то нужной функции. Некоторые технологии вообще не имеют встроенной репликации.
В таких случаях, следует использовать самостоятельную реализацию репликации. В самом простом случае, приложение будет дублировать все запросы сразу на несколько серверов базы данных: 
При записи данных, все запросы будут отправляться на несколько серверов. Зато операции чтения можно будет отправлять на любой сервер. Нагрузка при этом будет распределяться по всем доступным серверам:
Все операции изменения данных происходят на нескольких серверах, а чтения — на одном случайном
Это позволит использовать преимущества репликации даже если сама технология ее не поддерживает.
Выход из строя
При поломке одного из серверов в такой схеме необходимо сделать следующее:
Самое важное
Репликация используется в большей мере для резервирования баз данных и в меньшей для масштабирования. Master-Slave репликация удобна для распределения запросов чтения по нескольким серверам. Подход ручной репликации позволит использовать преимущества репликации для технологий, которые ее не поддерживают. Зачастую репликация используется вместе с шардингом при решении вопросов масштабирования.
Этот текст был написан несколько лет назад. С тех пор упомянутые здесь инструменты и софт могли получить обновления. Пожалуйста, проверяйте их актуальность.
Что такое индексы в Mysql и как их использовать для оптимизации запросов
Как исправить ошибку доступа к базе 1045 Access denied for user
Основные понятия о шардинге и репликации
Настройка Master-Master репликации на MySQL за 6 шагов
Примеры ad-hoc запросов и технологии для их исполнения
Как создать и использовать составной индекс в Mysql
Анализ медленных запросов (профилирование) в MySQL с помощью Percona Toolkit
Синтаксис и оптимизация Mysql LIMIT
Настройка Master-Slave репликации на MySQL за 6 простых шагов
Правильная настройка Mysql под нагрузки и не только. Обновлено.
Check-unused-keys для определения неиспользуемых индексов в базе данных
Запрос для определения версии Mysql: SELECT version()
И как правильно работать с длительными соединениями в MySQL
3 примера установки индексов в JOIN запросах
Анализ медленных запросов с помощью EXPLAIN
Быстрый подсчет уникальных значений за разные периоды времени
Описание, рекомендации и значение параметра query_cache_size
Что значит и как это починить
Использование партиций для ускорения сложных удалений
Правила выбора типов данных для максимальной производительности в Mysql
Включение и использование логов ошибок, запросов и медленных запросов, бинарного лога для проверки работы MySQL
Что такое репликация данных
Репликация — одна из техник масштабирования баз данных.
Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других (называемые репликами). Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.
Существует два основных подхода при работе с репликацией данных:
Master-Slave репликация
В этом подходе выделяется один основной сервер базы данных, который называется Master. На нем происходят все изменения в данных (любые запросы INSERT/UPDATE/DELETE ).
Slave сервер постоянно копирует все изменения с Master. С приложения на Slave-сервер отправляются запросы чтения данных (запросы SELECT ). Таким образом Master-сервер отвечает за изменения данных, а Slave за чтение.
В приложении нужно использовать два соединения — одно для Master, второе — для Slave:
(Используем два соединения — для Master и Slave — для записи и чтения соответственно)
Несколько Slave серверов
Преимущество этого типа репликации в том, что мы можем использовать более одного Slave сервера. Обычно следует использовать не более 20 Slave серверов при работе с одним Master.
Тогда приложение выбирает случайным образом один из Slave серверов для обработки запросов:
Задержка репликации
Асинхронность репликации означает, что данные на Slave могут появиться с небольшой задержкой. Поэтому, в последовательных операциях необходимо использовать чтение с Master, чтобы получить актуальные данные:
(При обращении к изменяемым данным, необходимо использовать Master-соединение)
Выход из строя
При выходе из строя Slave, достаточно просто переключить все приложение на работу с Master. После этого восстановить репликацию на Slave и снова его запустить.
Если выходит из строя Master, нужно переключить все операции (и чтения и записи) на Slave. Таким образом он станет новым Master. После восстановления старого Master, настроить на нем реплику, и он станет новым Slave.
Резервирование
Намного чаще репликацию Master-Slave используют не для масштабирования, а для резервирования. В этом случае, Master сервер обрабатывает все запросы от приложения. Slave сервер работает в пассивном режиме. Но в случае выхода из строя Master, все операции переключаются на Slave.
Master-Master репликация
В этой схеме, любой из серверов может использоваться как для чтения так и для записи:
При использовании такого типа репликации достаточно выбирать случайное соединение из доступных Master серверов:
(Выбор случайного Master для обработки соединений)
Выход из строя
Вероятные поломки делают Master-Master репликацию непривлекательной. Выход из строя одного из серверов практически всегда приводит к потере каких-то данных. Последующее восстановление также сильно затрудняется необходимостью ручного анализа данных, которые успели либо не успели скопироваться.
Используйте Master-Master репликацию только в крайнем случае. Вместо нее лучше пользоваться техникой “ручной” репликации, описанной ниже.
Асинхронность репликации
В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Slave.
Задержка в репликации (replication lag) может быть как очень маленькой, так и очень большой. Обычно рост задержки говорит о том, что сервера не справляются с текущей нагрузкой и их необходимо масштабировать дальше, например техниками горизонтального и вертикального шардинга.
Синхронный режим
Синхронный режим репликации позволит гарантировать копирование данных на Slave.
Это упростит работу в приложении, т.к. все операции чтения можно будет всегда отправлять на Slave. Однако это может значительно уменьшить скорость работы MySQL. Синхронный режим не следует использовать в Web приложениях.
“Ручная” репликация
Следует помнить, что репликация — это не технология, а методика. Встроенные механизмы репликации могут принести ненужные усложнения либо не иметь какой-то нужной функции. Некоторые технологии вообще не имеют встроенной репликации.
В таких случаях, следует использовать самостоятельную реализацию репликации. В самом простом случае, приложение будет дублировать все запросы сразу на несколько серверов базы данных:
При записи данных, все запросы будут отправляться на несколько серверов. Зато операции чтения можно будет отправлять на любой сервер. Нагрузка при этом будет распределяться по всем доступным серверам:
(Все операции изменения данных происходят на нескольких серверах, а чтения — на одном случайном)
Это позволит использовать преимущества репликации даже если сама технология ее не поддерживает.
Выход из строя
При поломке одного из серверов в такой схеме необходимо сделать следующее:
Самое важное
Репликация используется в большей мере для резервирования баз данных и в меньшей для масштабирования. Master-Slave репликация удобна для распределения запросов чтения по нескольким серверам. Подход ручной репликации позволит использовать преимущества репликации для технологий, которые ее не поддерживают. Зачастую репликация используется вместе с шардингом при решении вопросов масштабирования.