WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 1. Обзор MySQL Cluster Manager Эта глава предоставляет обзор MySQL Cluster Manager, а также его архитектуру, цель и возможности. 1.1. Терминология MySQL Cluster Manager Эта секция обеспечивает определения ключевых условий в описании MySQL Cluster Manager в этом руководстве и в другой документации, касающейся MySQL Cluster Manager и MySQL NDB Cluster. Место. Набор хостов, на котором расположены процессы MySQL NDB Cluster, управляемые MySQL Cluster Manager. Место может включать один или более кластеров. Кластер. A MySQL NDB Cluster. Кластер одержит множество процессов MySQL NDB Cluster на одном или более хостах. Минимальный кластер включает один узел управления, два узла данных и один узел SQL. У типичной производственной группы могут быть один или два узла управления, несколько узлов SQL и 4 или больше узла данных. Точные числа данных и узлов SQL могут измениться согласно размеру данных, типу и рейтингу аппаратных средств, используемых на хостах, ожидаемой пропускной способности, сетевых особенностях и других факторах. Подробные сведения выходят за рамки этого документа и необходимо консультироваться с документацией на MySQL NDB Cluster 7.5 and NDB Cluster 7.6. Хост. Компьютер. Точное значение зависит от контекста: Компьютер с одним или более процессами MySQL NDB Cluster. В этом контексте мы иногда обращаемся более определенно к хосту кластера. Количество процессов и число хостов кластера могут быть, но не обязательно, тем же самым. Компьютер, где работает экземпляр агента MySQL Cluster Manager. Чтобы управлять использованием MySQL NDB Cluster, используя MySQL Cluster Manager, агент MySQL Cluster Manager должен работать на каждом хосте, где процессами группы нужно управлять. Другими словами, используя MySQL Cluster Manager, все хосты кластера должны также быть хостами агента MySQL Cluster Manager (хотя обратное не обязательно верно). Поэтому необходимо понять, что каждый раз, когда мы используем термин хост, мы обращаемся к компьютеру в обоих из смыслов. Процесс. В контексте MySQL NDB Cluster процесс (более определенно, процесс кластера) это узел MySQL NDB Cluster, одного из следующих 3 типов: узел управления (ndb_mgmd), узел данных (ndbd или ndbmtd), или узел SQL (mysqld). См. NDB Cluster Core Concepts и NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions. Пакет. Копия программного обеспечения MySQL NDB Cluster. Это включает исполняемые файлы для выполнения процессов кластера желаемых типов на данном хосте. Самый простой способ удостовериться, что это сделано, состоит в том, чтобы поместить копию всего дистрибутива MySQL NDB Cluster на каждом компьютере, который вы намереваетесь использовать в качестве хоста группы. Атрибут конфигурации. Значение, влияющее на кластер ясно определенным и измеримым способом. Когда MySQL NDB Cluster запускается вручную, конфигурация достигается, используя параметры кластерной конфигурации, варианты сервера MySQL, систему MySQL и переменные статуса, MySQL Cluster Manager маскирует различия между ними, обеспечивая объединенное представление о них, посмотрите здесь. Агент. Процесс MySQL Cluster Manager, работающий на каждом хосте кластера, ответственный за управление процессами кластера на том хосте. Клиент. Клиент MySQL Cluster Manager является приложением, которое позволяет пользователю соединяться с MySQL Cluster Manager и выполнять задачи администрирования, такие как создание, запуск и остановку кластеров, отчеты о состоянии, получение информации кластерной конфигурации и урегулирование признаков кластерной конфигурации. 1.2. Архитектура MySQL Cluster Manager Эта секция предоставляет обзор архитектуры MySQL Cluster Manager. MySQL Cluster Manager это распределенное применение клиент-сервер, состоящее из двух главных компонентов. Агент MySQL Cluster Manager это набор из одного или большего количества процессов агента, которые управляют узлами NDB Cluster, и клиент MySQL Cluster Manager, который предоставляет интерфейс командной строки к функциям управления агента. Агент. Агент MySQL Cluster Manager состоит из набора всех агентских процессов MySQL Cluster Manager на хостах, составляющих данное место управления. Процесс агента MySQL Cluster Manager это процесс демона, который работает на каждом хосте, чтобы использоваться в кластере. В MySQL Cluster Manager нет никакого единственного центрального сервера или процесса: все агенты сотрудничают в управлении кластером в целом. Это означает, что любой связанный агент может использоваться, чтобы выполнить задачи, которые влияют на кластер. Каждый процесс агента ответственен за управление узлами MySQL NDB Cluster на хосте, где агент расположен. Узлы управления MySQL NDB Cluster и SQL управляются непосредственно агент MySQL Cluster Manager, узлы данных управляются косвенно, используя узлы управления кластерами. Управленческие функции, обработанные агентом MySQL Cluster Manager, включают следующее: Старт, остановку и перезапуск узлов. Изменения кластерной конфигурации. Обновления программного обеспечения. Создание отчетов о состоянии узла. Восстановление сбойных узлов. Создание, выполнение начальной конфигурации или старт кластера требуют, чтобы процессы агента работали на всех хостах группы. Как только кластер запущен, он продолжает работать, даже если один или несколько процессов агента терпят неудачу. Однако, любые отвалившиеся процессы агента должны быть перезапущены прежде, чем можно будет выполнить дополнительные функции управления. Клиент. Клиент MySQL Cluster Manager это приложение, используемое для доступа к агенту MySQL Cluster Manager. В MySQL Cluster Manager клиент на самом деле не что иное, как командно-строчный клиент mysql, запущенный с опциями, которые необходимы, чтобы соединиться с агентом MySQL Cluster Manager. MySQL Cluster Manager 1.4.8 и более поздних выпусков включают клиент mcm для простоты использования, он состоит из скрипта, который действует как обертка для клиента mysql. Как пример, мы показываем, как MySQL Cluster Manager был бы использован для использования с MySQL NDB Cluster из 4 хостов: Рис. 1.1. Развертывание MySQL Cluster Manager В этом кластере два хоста являются хостами для сервера управления (ndb_mgmd) и узла SQL (mysqld), другие два хоста нужны для двух узлов данных (ndbd). Однако, независимо от распределения узлов кластера по хостам, процесс агента MySQL Cluster Manager должен работать на каждом хосте. Клиент MySQL Cluster Manager может использоваться, чтобы получить доступ к агенту с любого из хостов, составляющих место управления, которому принадлежит кластер. Кроме того, клиент может использоваться на любом компьютере, у которого есть сетевое соединение с по крайней мере 1 из хостов, где работает процесс агента. Компьютер, где работает сам клиент, не обязан быть одним из этих хостов. Клиент может соединиться и использовать различные процессы агента на различных хостах в месте управления в разное время, чтобы выполнить функции управления. 1.3. Основные эксплуатационные понятия для MySQL Cluster Manager Эта секция объясняет некоторые основные эксплуатационные понятия для MySQL Cluster Manager. 1.3.1. Возможная последовательность MySQL Cluster Manager гарантирует возможную последовательность среди агентов, подразумевая что: Любое сообщение, сообщенное среди агентов, передается или не поставляется ВСЕМ агентам (вместо поставленного некоторым, но отсутствующим у других). Порядок доставки для любой последовательности сообщений всегда идентичен для всех агентов (то есть, сообщения не могут поступить не в том порядке для некоторых агентов). Кроме того, нет никакой гарантии синхронизации сообщения: сообщение, как гарантируют, не будет получено и выполнено в определенном окне времени для всех агентов. Результат состоит в том, что любой агент может отстать в обработке сообщений по любым причинам, таким как сетевой трафик, нагрузка на систему или планирование потоков. Могли бы произойти разные ситуации: в то время, как агент C отстает от Агентов А и B, эти два агента закончили некоторую реконфигурацию кластера, которая не включает локальных действий для Агента C, клиент, связанный с Агентом A или B, возможно, получил сообщение успеха для реконфигурации в то время, как клиенту, запрашивающему Агента C говорят, что реконфигурация все еще находится в процессе, так как сообщение завершения еще не достигло Агента C. Такое временное несоответствие среди агентов не должно быть проблемой. В то время, как агент мог бы отставать, гарантируемая возможная последовательность означает, что, если это не предотвращено сетевой ошибкой или некоторыми другими проблемами, любой отставший агент в конечном счете догонит других агентов, и все агенты в конечном счете получат последовательное состояние места.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.