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 устройства
- Режим трубного фильтра
- Режим прокси
- Режим точка-точка
- Режим шины событий
- Модель модель-вид-контроллер
- Шаблон доски
- Режим переводчика
И я представлю подробно ниже Режим Master-Slave устройства Концепция, а также ее использование, общие сценарии применения, преимущества и недостатки и т. Д.
Режим Master-Slave устройства
Режим Master-Slave устройства Также называется Режим Master-Slave Английская аббревиатура Master-Slave Основная идея основана на идее разделяй и властвуй. Примитивная задача разбивается на несколько семантически эквивалентных подзадач, и эти задачи выполняются параллельно специализированными рабочими потоками. Результат исходной задачи формируется путем объединения результатов обработки каждой подзадачи. Основные сценарии использования
- Параллельные вычисления для повышения производительности вычислений
- Отказоустойчивая обработка для повышения надежности вычислений
- Точность расчета для повышения точности расчета
Примеры моделей в параллельных вычислениях
В распределенных системах этот шаблон все еще относительно распространен. От ведущего (Master-Slave) и Процесс — Thread Отношения похожи, Master Только одна машина как Master И другие машины как Slave Эти машины работают одновременно Кластеры . Master В качестве планировщика заданий задайте несколько Slave Назначать вычислительные задачи, когда все Slave Выполнив задание, Master Собирая все вместе, это на самом деле то же самое MapReduce Где мысль лежит.
, например, в Hadoop в HDFS Принят на основе Master/Slave Архитектура Master-Slave распределенная файловая система, HDFS Кластер содержит один Master Узел и несколько Slave Узел-сервер, здесь один главный узел означает, что в системе HDFS имеется только один логический главный компонент. Логический главный узел может включать в себя два физических хоста, то есть два главных сервера и несколько подчиненных серверов. Один главный сервер образует один NameNode Кластер, два главных сервера образуют двойной NameNode К кластеру получают доступ несколько клиентов одновременно.Все эти машины обычно являются обычными машинами Linux, на которых выполняются процессы обслуживания уровня пользователя.
На приведенном выше рисунке показаны имя узла HDFS, узел данных и отношение доступа между клиентом и клиентом. NameNode в качестве Master Служба, которая отвечает за управление пространством имен файловой системы и доступом клиентов к файлам. NameNode Сохранит конкретную информацию о файловой системе, включая информацию о файле, файл делится на конкретные block Блок информации, и каждый block собственности Блок DataNode Информация. Для всего кластера HDFS по NameNode Предоставляет пользователям единое пространство имен. DataNode в качестве slave В кластере может быть несколько служб. Обычно каждый DataNode Оба соответствуют одному физическому узлу. DataNode Ответственный за управление хранилищем, которым они владеют на узле, он делит хранилище на несколько block Блок, управление block Блок информации, и периодически все это block Информация о блокировке отправляется на NameNode 。
Репликация баз данных MySQL по типу Master/Slave
Репликация MySQL – это процесс, позволяющий легко поддерживать несколько копий данных MySQL путем их автоматического копирования из базы данных master (ведущей) в slave (ведомую). Это упрощает резервное копирование данных, помогает анализировать их без использования главной БД, а также используется в качестве средства масштабирования.
Данное руководство приводит очень простой пример репликации MySQL, в котором база данных master передает информацию БД slave. Для выполнения данного процесса нужны два IP: для master-сервера и для slave-сервера.
- 12.34.56.789- Master
- 12.23.34.456- Slave
Требования
В данной статье предполагается наличие пользователя с привилегиями sudo, а также уже установленной системы MySQL. Чтобы установить MySQL, наберите:
sudo apt-get install mysql-server mysql-client
1: Настройка базы данных Master
На master-сервере откройте конфигурационный файл mysql:
sudo nano /etc/mysql/my.cnf
В данный файл нужно внести несколько изменений.
Для начала найдите раздел, который выглядит так (он связывает сервер с локальным хостом):
Замените стандартный IP-адрес IP-адресом сервера.
Следующее изменение касается директивы server-id, расположенной в разделе mysqld. Здесь можно задать любую переменную (возможно, проще всего начать с 1), но число должно быть уникальным и не совпадать ни с одним другим server-id в группе репликации.
Убедитесь, что строка раскомментирована:
Затем найдите строку log_bin. Она содержит детали о репликации. Slave-сервер будет копировать все изменения, зарегистрированные в журнале. В данном случае нужно просто раскомментировать строку log_bin:
В завершение укажите базу данных, которую нужно копировать на slave-сервер. Можно вносить более одной базы данных, повторяя эту линию в конфигурациях каждой нужной базы.
Внеся все нужные изменения, сохраните их и закройте конфигурационный файл.
sudo service mysql restart
Остальные действия нужно выполнить в оболочке MySQL.
Откройте оболочку MySQL:
Передайте привилегии slave-серверу. Эту строку можно также использовать для того, чтобы указать имя и пароль slave-сервера. Команда имеет такой формат:
GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’%’ IDENTIFIED BY ‘password’;
Дальнейшие действия немного сложнее. Для реализации поставленной задачи нужно открыть новое окно или вкладку в дополнение к уже используемой.
В текущей вкладке откройте базу данных “newdatabase”.
После этого нужно заблокировать базу данных, чтобы предотвратить любые изменения:
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Должна появиться подобная таблица:
С этой позиции slave БД начнет репликацию. Запишите эти числа, они пригодится позже.
При внесении любых изменений в том же окне база данных будет автоматически разблокирована. Потому нужно открыть новую вкладку или окно и выполнить там следующие действия.
База данных все еще должна оставаться заблокированной. Экспортируйте базу данных в новое окно с помощью mysqldump (следующую команду нужно выполнить в оболочке bash, а не MySQL).
mysqldump -u root -p —opt newdatabase > newdatabase.sql
Теперь вернитесь в исходное окно и разблокируйте базу данных, снова разрешив вносить в нее изменения. Закройте оболочку.
UNLOCK TABLES;
QUIT;
Теперь master БД готова.
2: Настройка slave базы данных
Подготовив master БД, можно перейти к настройке slave БД.
Войдите на сервер, откройте оболочку MySQL и создайте новую базу данных, которая будет содержать реплицированные из master данные, затем закройте оболочку:
CREATE DATABASE newdatabase;
EXIT;
Импортируйте ранее экспортированную из master базу данных.
mysql -u root -p newdatabase < /path/to/newdatabase.sql
Теперь нужно настроить slave таким же образом, как это было с master:
sudo nano /etc/mysql/my.cnf
Следуя советам предыдущего раздела, установите некоторые важные конфигурации. Начните с server-id; как упоминалось ранее, этот номер должен быть уникальным. Так как в предыдущем разделе было установлено значение 1, теперь нужно установить другое:
Затем убедитесь, что следующие три критерия заполнены соответствующим образом:
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = newdatabase
Кроме того, нужно внести строку relay-log, которой нет по умолчанию. По завершении не забудьте сохранить и закрыть конфигурационный файл slave.
Снова перезапустите MySQL:
sudo service mysql restart
Далее нужно активировать репликацию в оболочке MySQL.
Откройте оболочку MySQL и внесите следующие детали, заменяя значения по умолчанию.
CHANGE MASTER TO MASTER_HOST=’12.34.56.789′,MASTER_USER=’slave_user’, MASTER_PASSWORD=’password’, MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS= 107;
Данная команда выполняет несколько действий:
- определяет текущий сервер как slave-сервер;
- предоставляет серверу правильные данные для входа;
- говорит slave-серверу, откуда начинать репликацию; журнал master-сервера и позиция, с которой нужно начинать репликацию, указываются с помощью чисел, которые были записаны ранее.
Готово! master- и slave-сервер настроены.
Просмотреть подробности репликации можно при помощи следующей команды. Параметр \G упорядочивает текст, что делает его более удобным для чтения.
SHOW SLAVE STATUS\G
При возникновении проблем со связью попробуйте запустить slave при помощи следующей команды:
Настройка репликации Master-Slave в MySQL
Термин репликация используется для обозначения механизма синхронизации нескольких копий данных, что повышает сохранность информации, отказоустойчивость и производительность системы. Ярким примером служит репликация базы данных между двумя серверами.
Master-Slave репликация MySQL
В терминологии Master-Slave мастером является первичный сервер с базой данных, на нем производится запись в базу, но чтение распределяется между мастером и слейвом в зависимости от нагрузки на систему, что повышает отказоустойчивость и производительность. Кроме того, благодаря такому подходу, копия базы данных всегда под рукой и ее можно восстановить в случае отказа одного из серверов.
В каких ситуациях может понадобится slave-сервер? Например, когда поступает большой массив данных для записи в базу и master-сервер просто не успевает выполнять чтение и клиенту приходится ждать окончания записи, чего можно избежать благодаря slave-серверу.
Возможны ситуации, когда мастер-сервер выходит из строя, в этом случае слейв-сервер подхватывает все функции мастера и работает в одиночку до его восстановления. Клиент скорее всего ничего не заметит, и уж точно не будет час-два-три ждать пока починят мастера.
Репликацию настроить совсем не сложно, благо механизм заложен в MySQL с самого начала.
Настройка на Master сервере
Начнем с редактирования файла конфигурации my.cnf , который чаще всего расположен по адресу /etc/mysql/my.cnf . Необходимо найти и раскомментировать(убрать #), либо прописать такие строки.
Важно! Если bind-address уже был прописан, его нужно поменять, иначе не получится установить подключение между серверами.
Сразу после этого рестартуем базу данных на сервере.
Теперь необходимо создать пользователя с правами на репликацию нашей базы данных, сделать это можно из-под рута в консоли MySQL с помощью команды
Где вместо «slave_user» и «slave_password» нужно написать логин и пароль для слейва.
Теперь посмотрим данные о мастере
SHOW MASTER STATUS;
Значения столбцов File и Position нужно запомнить, они будут использованы в настройке слейва, к чему мы сейчас и переходим.
Настройка на Slave сервере
Первым делом необходимо создать базу данных с таким же именем, как у той, которую мы собираемся реплицировать. Это важный шаг, нельзя им пренебрегать. Далее переходим в уже знакомый нам файл конфигурации my.cnf и пишем настройки.
Важно! В bin-log прописывается путь к бин-логу на местер сервере. Идентификатор сервера должен отличаться от айди мастера, удобно ставить его на 1 больше.
Далее необходимо настроить подключение к мастеру и включить slave-режим.
Где host — ip адрес мастер, логин и пароль соответствуют тем, что мы создали на мастере, master_log_file и master_log_pos заполняются информацией из последнего пункта настройки мастер-сервера.
С этого самого момента все изменения в базе данных будут передаваться с мастера на слейва.
Проверка статуса репликации
Кроме команды SHOW MASTER STATUS; есть аналогичная для слейва SHOW SLAVE STATUS; , которая выведет таблицу с информацией. Главный признак того, что сервера соединились и корректно работают — наличие таких строк