Имеются четыре процесса, которые важны при использовании MySQL Cluster. Мы
здесь разберемся, как работать с этими процессами, какие параметры
использовать при старте и т. д.
Чтобы включить поддержку NDB Cluster имеются два способа. Или
использование опции --ndbcluster
при запуске
mysqld
, встраивание строки ndbcluster
в секцию
[mysqld]
Вашего файла my.cnf. Простой способ проверить,
что Ваш сервер выполняется с поддержкой для NDB Cluster
состоит
в том, чтобы выдать команду SHOW ENGINES
из клиента
mysql
. Вы должны видеть YES
для строки
NDBCLUSTER
. Если Вы видите NO
, Вы не выполняете
mysqld
, который компилируется с допускаемой поддержкой
NDB Cluster
. Если Вы видите DISABLED
, то Вы должны
активизировать поддержку в файле my.cnf.
Сервер MySQL должен знать, как получить конфигурацию кластера. Чтобы
обращаться к этой конфигурации, требуется знать три вещи
ID узла может быть пропущен в MySQL 4.1.5, потому что ID может
быть динамически распределен.
С этой установкой сервер MySQL станет нормальным членом кластера и будет
полностью знать все узлы памяти в кластере и их состояния. Сервер создаст
связи со всеми узлами памяти и будет способен использовать любой узел памяти
как координатор транзакции и обращаться к их данным
для чтения и модифицирования.
В MySQL 4.1.5 это было изменено так, что файлы помещены в каталог,
определенный DataDir
в файле конфигурации. Таким образом,
ndbd
может быть запущен отовсюду.
Рекомендуется не использовать каталог, доступный через NFS, потому что в
некоторых средах могут быть проблемы с блокировкой pid-файла, остающегося
даже после завершения процесса.
Процесс выполнения использует один поток для всех действий чтения, записи,
просмотра данных и всех других действий. Этот поток разработан с асинхронным
программированием, так что это может легко обрабатывать тысячи параллельных
задач. Кроме того, имеется поток сторожа, контролирующий поток выполнения,
чтобы гарантировать, что он не останавливается в вечном цикле или другой
проблеме. Имеется пул потоков для обслуживания файлового ввода-вывода. Каждый
из этих потоков может обрабатывать один открытый файл. Кроме того, потоки
могут использоваться для действий подключения транспортеров в процессе
ndbd
. Таким образом, в системе, которая выполняет большое
количество действий, включая действия модификации, процесс ndbd
потребит приблизительно до 2 CPU, если это позволено. Таким образом, в
большом SMP-блоке со многими CPU рекомендуется использовать несколько
процессов ndbd
, которые сконфигурированы так, чтобы быть частью
различных групп узлов.
Сервер управления представляет собой процесс, который читает файл
конфигурации кластера и распределяет эту информацию по всем узлам в кластере,
запрашивающих ее. Это также поддерживает файл регистрации действий кластера.
Клиентура управления может соединяться с сервером управления и использовать
команды, чтобы проверить состояние кластера в различных аспектах.
Начиная с MySQL 4.1.5, нет надобности определять строку подключения при
запуске управляющего сервера. Однако, если Вы используете несколько серверов
управления, нужно обеспечить эту строку, а каждый узел в кластере должен
определить свой nodeid явно.
Последний важный процесс, о котором надо знать, клиент управления. Этот
процесс не так уж необходим, чтобы выполнить кластер. Он позволяет управлять
кластером через сервер управления с помощью ряда команд.
Фактически клиент управления использует C API, который используется, чтобы
обратиться к серверу управления, так что для продвинутых пользователей также
возможно написать свою программу для управления кластером.
При старте управляющего клиента, необходимо установить имя хоста и порт
для связи с сервером управления как в примере ниже. Значение по умолчанию:
localhost и порт 1186 (был 2200 до версии 4.1.8).
Порог используется, чтобы фильтровать события внутри каждой категории.
Например: событие STARTUP
с приоритетом 3 никогда не будет
послано, если порог для STARTUP
не установлен в 3 или ниже.
Только события с приоритетом 3 или ниже будут посланы, если порог равен 3.
Теперь о серьезности событий (она соответствует уровням UNIX syslog):
Серьезность событий (event severity) может быть включена или выключена. От
этого зависит, будут ли регистрироваться события соответствующей серьезности.
Если серьезность включена, регистрируются все события с приоритетом меньше,
чем или равным порогу категории. Если серьезность выключена, не будет
отмечено никаких событий, принадлежащих к этой серьезности.
Все регистрируемые события перечислены ниже.
Событие |
Категория (Category) |
Приоритет (Priority) |
Серьезность (Severity) |
Описание |
DB nodes connected | CONNECTION | 8 | INFO |
Узел базы данных подключился |
DB nodes disconnected | CONNECTION | 8 | INFO |
Узел базы данных отключился |
Communication closed | CONNECTION | 8 | INFO |
Соединение узлов API & DB закрыто |
Communication opened | CONNECTION | 8 | INFO |
Соединение узлов API & DB открыто |
Global checkpoint started | CHECKPOINT | 9 |
INFO | Начало GCP, то есть REDO-протокол записан на диск |
Global checkpoint completed | CHECKPOINT | 10 |
INFO | GCP завершена |
Local checkpoint started | CHECKPOINT | 7 |
INFO | Начало локальной контрольной точки, то есть данные записаны
на диск. LCP Id и GCI Id хранятся и восстанавливается самый старый |
Local checkpoint completed | CHECKPOINT | 8 |
INFO | LCP завершена |
LCP stopped in calc keep GCI | CHECKPOINT | 0 |
ALERT | LCP прервана! |
Local checkpoint fragment completed | CHECKPOINT |
11 | INFO | LCP на фрагменте завершена |
Report undo log blocked | CHECKPOINT | 7 |
INFO | Буфер протоколирования отмен (undo) скоро переполнится |
DB node start phases initiated | STARTUP | 1 |
INFO | Инициализирован NDB Cluster |
DB node all start phases completed | STARTUP | 1 |
INFO | Запущен NDB Cluster |
Internal start signal received STTORRY | STARTUP |
15 | INFO | Внутренний стартовый сигнал блокам
после законченного рестарта |
DB node start phase X completed | STARTUP | 4 |
INFO | Стартовая фаза завершена |
Node has been successfully included into the cluster |
STARTUP | 3 | INFO | Узел успешно включен в кластер
|
Node has been refused to be included into the cluster |
STARTUP | 8 | INFO | Узел не удалось включить в кластер
|
DB node neighbours | STARTUP | 8 | INFO |
Показывает соседние узлы базы данных |
DB node shutdown initiated | STARTUP | 1 |
INFO | Инициализировано закрытие системы узла |
DB node shutdown aborted | STARTUP | 1 |
INFO | Прервано закрытие системы узла |
New REDO log started | STARTUP | 10 | INFO |
GCI хранит X, самый новый восстанавливаемый GCI Y |
New log started | STARTUP | 10 | INFO |
Часть файла регистрации X, начата MB Y, завершена MB Z |
Undo records executed | STARTUP | 15 | INFO |
Выполнение записи отмены (Undo) |
Completed copying of dictionary information | NODERESTART |
8 | INFO | Завершено копирование информации словаря |
Completed copying distribution information | NODERESTART |
8 | INFO | Завершено копирование информации распределения
|
Starting to copy fragments | NODERESTART | 8 |
INFO | Начало копирования фрагментов |
Completed copying a fragment | NODERESTART | 10 |
INFO | Завершение копирования фрагментов |
Completed copying all fragments | NODERESTART | 8 |
INFO | Завершение копирования ВСЕХ фрагментов |
Node failure phase completed | NODERESTART | 8 |
ALERT | Завершена ситуация сбоя узла |
Node has failed, node state was X | NODERESTART | 8 |
ALERT | Узел начал сбоить |
Report whether an arbitrator is found or not | NODERESTART |
6 | INFO | 7 различных ситуаций |
| | | | - Координатор перезапускает поток
арбитража [состояние=X] |
| | | | - Подготовка узла арбитратора X
[ticket=Y] |
| | | | - Принять узел арбитратора X
[ticket=Y] |
| | | | - Запустить узел арбитратора X
[ticket=Y] |
| | | | - Потерян узел арбитратора
X: обрабатывает сбой [состояние=Y] |
| | | | - Потерян узел арбитратора
X: обрабатывает выход [состояние=Y] |
| | | | - Потерян узел арбитратора
X <сообщение_об_ошибке>[состояние=Y] |
Report arbitrator results | NODERESTART | 2 |
ALERT | 8 разных результатов |
| | | | - Потерянная проверка арбитража:
меньше половины узлов доступны |
| | | | - Проверка арбитража: узлы
сгруппированы как надо |
| | | | - Потерянная проверка Арбитража:
отсутствующая группа узла |
| | | | - Выделение разделов сети по
требованию арбитража |
| | | | - Положительный ответ из узла X
|
| | | | - Арбитраж потерян: отрицательный
ответ из узла X |
| | | | - Разрыв сети: никакой арбитратор
сейчас не доступен |
| | | | - Разрыв сети: нет
конфигурации для арбитратора |
GCP take over started | NODERESTART | 7 |
INFO | GCP запущен |
GCP take over completed | NODERESTART | 7 |
INFO | GCP завершен |
LCP take over started | NODERESTART | 7 |
INFO | LCP запущен |
LCP take completed (state = X) | NODERESTART | 7 |
INFO | LCP завершен с состоянием X |
Report transaction statistics | STATISTICS | 8 |
INFO | Количество транзакций, завершений транзакции, чтений,
простых чтений, записей, параллельных операций, работ с информацией
атрибутов, аварийных прекращений работы |
Report operations | STATISTICS | 8 | INFO |
Число проделанных операций |
Report table create | STATISTICS | 7 |
INFO | Создана таблица отчета |
Report job scheduling statistics | STATISTICS | 9 |
INFO | Означает внутреннюю работу, планирующую статистику |
Sent # of bytes | STATISTICS | 9 | INFO |
Среднее количество байт, посланных узлу X |
Received # of bytes | STATISTICS | 9 |
INFO | Среднее количество байт, полученных от узла X |
Memory usage | STATISTICS | 5 | INFO |
Использование памяти данными и индексом (80%, 90% и 100%) |
Transporter errors | ERROR | 2 | ERROR |
Ошибки транспортера |
Transporter warnings | ERROR | 8 |
WARNING | Предупреждения транспортера |
Missed heartbeats | ERROR | 8 | WARNING |
Узел X пропустил синхронизацию Y |
Dead due to missed heartbeat | ERROR | 8 |
ALERT | Узел X объявлен зависшим по причине пропуска синхронизации
|
General warning events | ERROR | 2 | WARNING |
Общие события предупреждений |
Sent heartbeat | INFO | 12 | INFO |
Синхронизация послана узлу X |
Create log bytes | INFO | 11 | INFO |
Часть файла регистрации, имя файла, его размер в MB |
General info events | INFO | 2 | INFO |
Общие события информации |
Режим отдельного пользователя (он же однопользовательский) позволяет
администратору базы данных ограничивать доступ к системе базы данных только
одной прикладной программой (узлом API). При вводе режима отдельного
пользователя все подключения всех API будут элегантно закрыты, и никакие
транзакции не могут быть начаты (но могут быть завершены).
Когда кластер вошел в режим отдельного пользователя, доступ к базе данных
предоставлен только определенному узлу API. Пример:
После выполнения этой команды, узел API с идентификатором узла 5
становится единственным пользователем кластера.
Узел, определенный в команде, выше должен быть узлом сервера MySQL.
Любая попытка определять любой другой тип узла будет отклонена.
Обратите внимание: если узел с идентификатором 5 выполняется, когда
выполнена команда ENTER SINGLE USER MODE 5
, все транзакции,
выполняющиеся на узле 5, будут прерваны, подключение закрыто, а сервер
должен быть перезапущен.
Лучше всего в случае сбоев узла при выполнении в
режиме отдельного пользователя:
Или перезапустите узлы базы данных до ввода
режима отдельного пользователя.
Этот раздел описывает, как создать резервную копию и позже восстановить
из нее базу данных.
Копия представляет собой снимок (образ) базы данных в данное время.
Копия содержит три основных части:
В течение резервирования каждый узел сохраняет эти три части на
диск в три файла:
Выше <BackupId> задает идентификатор для копии, и <NodeId>
идентификатор узла, создающего файл.
Прежде чем начать, удостоверьтесь, что кластер правильно сконфигурирован
для резервного копирования.
Обратите внимание, что, если не имеется копии с идентификатором
<BackupId>, выполняющейся на момент попытки прерывания, сервер
управления не будет отвечать ничего.
Программа восстановления выполнена как отдельная утилита командной строки.
Она читает файлы, созданные из копии, и вставляет сохраненную информацию в
базу данных. Программа восстановления должна быть выполнена один раз для
каждого набора файлов с резервной копией, то есть столько, сколько работало
узлов базы данных, когда копия создавалась.
Первый раз, когда Вы выполняете программу восстановления, Вы также должны
восстановить метаданные, то есть создать таблицы. Действия программы
восстановления рассматриваются как обращение API к кластеру и, следовательно,
нуждаются в свободном подключении, чтобы соединиться с кластером. Это может
быть проверено через ndb_mgm
командой SHOW. Переключатель
-c <connectstring>
может использоваться, чтобы указать
узел MGM. Файлы с резервной копией должны присутствовать в каталоге, заданном
как параметр программы восстановления. Копия может быть восстановлена в базу
данных с иной конфигурацией, чем та, из которой резервировались данные.
Например, допустим, что копия (с идентификатором 12) создана на кластере с
двумя узлами базы данных (с идентификаторами узлов 2 и 3), а должна быть
восстановлена на кластере с четырьмя узлами. Программа восстановления должна
быть выполнена два раза (по одному для каждого узла базы данных в кластере,
где копия создавалась, как описано ниже.
Обратите внимание: для быстрого восстановления, данные могут быть
восстановлены паралелльно (если имеется достаточно свободных подключений
API). Обратите внимание, однако, что файлы данных должны всегда
обрабатываться перед файлами регистрации!
Еще обратите внимание: кластер должен иметь пустую базу данных перед
началом процесса восстановления.
Если при выдаче запроса на резервирование возвращен код ошибки, то
проверьте, что имеется достаточно памяти, распределенной для копирования (то
есть, параметры конфигурации). Также проверьте, что имеется достаточно
пространства в разделе жесткого диска-адресате.
6 Использование высокоскоростных
межсоединений в MySQL Cluster
Уже перед разработкой NDB Cluster в 1996 было очевидно, что одной из
главных проблем формирования параллельных баз данных является связь между
узлами в сети. Таким образом, с самого начала NDB Cluster был разработан с
концепцией транспортера, чтобы учесть различные сетевые среды.
В настоящее время основание кода включает 4 различных транспортера, где 3
из них в настоящее время работают. Большинство пользователей сегодня
использует TCP/IP через Ethernet, так как это существует на всех машинах. Это
также наиболее проверенный транспортер в MySQL Cluster.
Для пользователей, которые желают максимальной эффективности, возможно
использовать быстрые связи в кластере. Имеются два способа достигнуть этого:
может быть разработан транспортер, чтобы обработать этот случай, или можно
использовать реализации сокетов, которые обходят стек TCP/IP.
Авторы пакета сделали некоторые эксперименты с обоими вариантами,
использующими технологию SCI, разработанную Dolphin (www.dolphinics.no).
6.1 Настройка MySQL Cluster для использования сокетов SCI
В этом разделе мы покажем, как можно использовать кластер,
сконфигурированный для нормальной связи через TCP/IP, чтобы взамен
использовать сокеты SCI. Эта документация основана на сокетах SCI (они также
часто упоминаются как SCI Socket) версии 2.3.0 от 1 октября 2004.
Для использования сокетов SCI можно использовать любую версию MySQL
Cluster. Тесты выполнялись на версии 4.1.6. Никакой специальной версии не
компилируется, так как это использует нормальные обращения сокета, что
является нормальной установкой конфигураций для MySQL Cluster. SCI Sockets
в настоящее время обеспечиваются только ядрами Linux 2.4 и 2.6.
SCI-транспортеры работает на большем количестве OS, хотя
проверена только Linux 2.4.
Имеются по существу четыре вещи, необходимые, чтобы запустить сокеты SCI.
Сначала необходимо сформировать библиотеки SCI. Затем SCI-библиотеки ядра
должны быть установлены. Далее один или два файла конфигурации должны быть
установлены. Наконец, SCI-библиотека ядра должна быть включена для всей
машины или хотя бы для оболочки, где процессы запущены процессы MySQL
Cluster. Этот процесс должен быть повторен для каждой машины в кластере,
который будет использовать сокеты SCI.
Два пакета должны быть установлены, чтобы получить работающие сокеты SCI.
Первый пакет формирует библиотеки, которые собственно работают с сокетами, а
второй интерфейс сокетов с ОС. В настоящее время они доступны только в
формате исходного текста.
Последние версии этих пакетов в настоящее время могут быть найдены на
http://www.dolphinics.no/support/downloads.html.
Версии, описанные здесь:
http://www.dolphinics.no/ftp/source/DIS_GPL_2_5_0_SEP_10_2004.tar.gz
http://www.dolphinics.no/ftp/source/SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz
Следующий шаг должен распаковать архивы, SCI Sockets распакован ниже
уровня кода DIS. Затем основание кода компилируется. Пример ниже показывает
команды, используемые в Linux/x86, чтобы выполнить это.
shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz
shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/
shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz
shell> cd ../adm/bin/Linux_pkgs
shell> ./make_PSB_66_release
Если Вы используете AMD64, чтобы использовать 64-разрядные расширения,
надо использовать make_PSB_66_X86_64_release вместо make_PSB_66_release. При
работе на Itanium соответственно вызовите make_PSB_66_IA64_release.
Вариант X86-64 должен работать и на Intel EM64T, но никакие известные тесты
этого не проводились.
После формирования основания кода, он должен быть помещен в tar-архив с
именем, отражающим DIS, OS и дату. Теперь настало время, чтобы установить
пакет в соответствующее место. В этом примере мы поместим установку в каталог
/opt/DIS. Эти действия наиболее вероятно требуют, чтобы Вы вошли в систему
как пользователь root:
shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/
shell> cd /opt
shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz
shell> mv DIS_Linux_2.4.20-8_181004 DIS
Теперь, когда все библиотеки находятся в соответствующем месте, мы должны
гарантировать, что SCI-платы получают соответствующие идентификаторы внутри
адресного пространства SCI. Поскольку SCI работает с сетями на низком уровне,
сначала необходимо остановиться на сетевой структуре.
Имеются три типа сетевых структур. Первый простое одномерное кольцо,
второй использует коммутаторы SCI с одним кольцом на порт коммутатора и в
заключение имеется 2D/3D тор. Каждый вариант имеет свой стандарт
обеспечения идентификаторов узла.
Простое кольцо использует идентификаторы узла через 4:
4, 8, 12, ....
Следующая возможность использует коммутатор. SCI-коммутатор имеет 8
портов, причем каждый порт может обрабатывать кольцо. Здесь необходимо
гарантировать, что кольца на коммутаторе используют различные наборы
идентификатора узла. Так что первый порт использует идентификаторы узла ниже
64, следующие 64 идентификатора узла распределены для второго порта и т.д.:
4,8, 12, ... , 60 Кольцо на порте 1
68, 72, .... , 124 Кольцо на порте 2
132, 136, ..., 188 Кольцо на порте 3
..
452, 456, ..., 508 Кольцо на порте 8
2D/3D тор в сетевой структуре принимает во внимание, где каждый узел
находится в каждой размерности, добавляя 4 для каждого узла в первой
размерности, 64 во второй и 1024 в третьей размерности.
В нашем тестировании мы использовали коммутаторы. Большинство
действительно больших инсталляций кластера использует торы. Свойство
дополнительного пространства, которое обеспечивают коммутаторы в том, что с
двойными SCI-платами и соответственно коммутаторами можно легко сформировать
избыточную сеть, где потери времени в SCI-сети составят около 100
микросекунд. Это свойство обеспечивается SCI-транспортером и в настоящее
время также разработано для реализации сокетов SCI.
Потери времени для торов также возможны, поскольку эта схема сети требует
отправки новых индексов маршрутизации всем узлам. Задержка составляет около
100 миллисекунд, что обычно вполне допустимо.
Помещая NDB-узлы в соответствующих местах в архитектуре, возможно
использовать пару коммутаторов, чтобы формировать структуру, где 16
компьютеров могут быть взаимосвязаны, и никакой одиночный сбой не сможет
препятствовать больше, чем один компьютеру. С 32 компьютерами и 2
коммутаторами можно сконфигурировать кластер таким способом, что никакой
одиночный сбой не сможет препятствовать больше, чем двум узлам, и в этом
случае также известно, которая пара повреждена. Таким образом, помещая узлы
в отдельных группах NDB-узлов можно сформировать безопасную
установку MySQL Cluster.
Чтобы установить идентификатор узла SCI-платы, используйте следующую
команду, которая находится в каталоге /opt/DIS/sbin
. Здесь
-c 1 относится к количеству SCI-плат в машине, 1 применяется только, если
1 плата находится в машине. В этом случае всегда используйте адаптер 0 (-a
0). 68 задает идентификатор узла в этом примере:
shell> ./sciconfig -c 1 -a 0 -n 68
В случае, если Вы имеете несколько SCI-плат в вашей машине, надо понять,
какая плата соответствует каждому номеру адаптера. Для этого скомвндуйте:
shell> ./sciconfig -c 1 -gsn
Это даст серийный номер, который может быть найден на задней части
SCI-платы и на плате непосредственно. Повторите это затем для -c 2 и так
далее для всех плат. Это идентифицирует, какая карта какому id соответствует.
Затем установите идентификаторы узла для всех плат.
Теперь мы установили необходимые библиотеки и двоичные модули. Мы также
установили SCI-идентификаторы узла. Следующий шаг должен установить
отображение имен машин (или адресов IP) к SCI-идентификаторам узла.
Файл конфигурации для сокетов SCI должен быть помещен в
/etc/sci/scisock.conf
. Этот файл содержит отображение имен (или
IP) на SCI-идентификаторы узлов. SCI-идентификатор узла отобразится на имя,
чтобы связаться через соответствующую SCI-плату. Ниже показан очень простой
такой файл конфигурации:
#host #nodeId
alpha 8
beta 12
192.168.10.20 16
Также возможно ограничить эту конфигурацию, чтобы опрашивать только некое
подмножество портов этих машин. Чтобы сделать это, используется другая
конфигурация, которая помещена в /etc/sci/scisock_opt.conf
:
#-key -type -values
EnablePortsByDefault yes
EnablePort tcp 2200
DisablePort tcp 2201
EnablePortRange tcp 2202 2219
DisablePortRange tcp 2220 2231
Теперь мы готовы установить драйверы. Мы должны сначала установить
драйверы низкого уровня, а уж затем драйвер SCI-сокетов:
shell> cd DIS/sbin/
shell> ./drv-install add PSB66
shell> ./scisocket-install add
Если желательно, можно теперь проверить установку, вызывая скрипт, который
проверяет, что все узлы в файлах конфигурации сокетов SCI доступны:
shell> cd /opt/DIS/sbin/
shell> ./status.sh
Если Вы обнаруживаете ошибку и должны изменить файлы конфигурации SCI,
затем необходимо использовать программу ksocketconfig,
чтобы сменить конфигурацию.
shell> cd /opt/DIS/util
shell> ./ksocketconfig -f
Чтобы проверить, что сокеты SCI фактически используются, Вы можете
использовать программу latency_bench
, которая должна иметь
клиентский и серверный компоненты, чтобы проверить время ожидания. Прежде,
чем Вы используете эту программу, Вы также должны установить переменную
LD_PRELOAD, как показано ниже.
Установите сервер командой:
shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -server
Теперь запустите клиент:
shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -client hostname_of_server
Теперь конфигурация SCI завершена. MySQL Cluster готов использовать
совместно сокеты и транспортер SCI.
Следующий шаг к запуску MySQL Cluster. Чтобы включить использование
сокетов SCI, необходимо установить системную переменную LD_PRELOAD перед
стартом ndbd, mysqld и ndb_mgmd, чтобы те использовали сокеты SCI. Переменная
LD_PRELOAD должна указывать на ядерную библиотеку для SCI Sockets.
Например, запустим ndbd в оболочке bash.
bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.so
bash-shell> ndbd
Для tcsh команда чуть иная:
tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.so
tcsh-shell> ndbd
Заметьте, что MySQL Cluster может использовать только ядерный
вариант SCI Sockets.
6.2 Эталонные тесты низкого уровня, чтобы понять
воздействие связей в кластере
Процесс ndbd имеет ряд простых конструкций, которые используются, чтобы
обратиться к данным в MySQL Cluster. Есть очень простой эталонный тест, чтобы
проверить эффективность каждой такой инструкции и эффект, который различные
типы связи в кластере оказывают на их эффективность.
Имеются четыре метода доступа:
Primary key access
- Это простой доступ к одной записи через первичный ключ. В самом простом
случае одновременно обращаются только к одной записи. Это означает, что
полная стоимость установки TCP/IP-сообщения и ряд издержек для переключения
контекста принимается этим одиночным запросом. В пакетном случае, где,
например, 32 доступа к первичному ключу представлены одним пакетом, эти 32
доступа совместно используют стоимость установки TCP/IP-сообщений и
контекстных переключений (если TCP/IP для различных адресатов, естественно,
ряд TCP/IP-сообщений должен быть установлен).
Unique key access
- Доступ к уникальному ключу очень похож на доступ через первичный ключ за
исключением того, что он выполнен как чтение индексной таблицы,
сопровождаемым доступом через первичный ключ на таблице. Однако, только один
запрос будет послан серверу MySQL, чтение индексной таблицы обработано
процессом ndbd. Таким образом, эти запросы извлекают пользу
из пакетной обработки.
Full table scan
- Когда никакие индексы не существуют для поиска на таблице, выполняется
полный просмотр таблицы. Это один запрос к процессу ndbd, который делит
просмотр таблицы на набор параллельных просмотров на всех процессах ndbd в
кластере. В будущих версиях MySQL сервер сможет использовать фильтры
при таких просмотрах.
Range scan using ordered index
- Когда используется упорядоченный индекс, это выполнит просмотр тем же
самым способом, как полный просмотр таблицы за исключением того, что это
просмотрит только те записи, которые находятся в диапазоне, используемом
установкой запросов сервера MySQL. В будущих версиях специальная оптимизация
гарантирует, что, когда все связанные индексные атрибуты включают все
атрибуты в отдельный ключ, только один раздел будет просмотрен вместо всех
сразу в параллельном режиме.
Чтобы проверить основную эффективность этих методов доступа, разработан
набор эталонных тестов. Один такой эталонный тест, testReadPerf, использует
простые и пакетные доступы через первичный и уникальный ключи. Эталонный тест
также измеряет стоимость установки диапазона просмотра, возврат одиночной
записи и в заключение имеется вариант, который использует просмотр диапазона,
чтобы выбрать пакет записей.
Этим способом мы можем проверять стоимость выдачи одиночного доступа к
ключу, одиночного доступа для просмотра записи и измерять воздействие
реализации средств связи на эти основные методы доступа.
Мы выполнили тот основной эталонный тест, используя нормальный транспортер
через сокеты TCP/IP и повторили его через сокеты SCI. Ниже приведены
результаты для запроса 20 записей за доступ. Различие между последовательным
и пакетным доступами понижается коэффициентом 3-4 при использовании записей
2kB. SCI-сокеты не тестировались с записями в 2 kB. Тесты выполнялись на
кластере с 2 узлами с 2 CPU AMD MP1900+ на каждом.
Тип доступа: Сокеты TCP/IP Сокеты SCI
Serial pk access: 400 microseconds 160 microseconds
Batched pk access: 28 microseconds 22 microseconds
Serial uk access: 500 microseconds 250 microseconds
Batched uk access: 70 microseconds 36 microseconds
Indexed eq-bound: 1250 microseconds 750 microseconds
Index range: 24 microseconds 12 microseconds
Мы делали также другой набор тестов, чтобы проверить эффективность сокетов
SCI, сравниваемых с использованием SCI-транспортера, и все это в сравнении с
TCP/IP-транспортером. Все эти тесты использовали доступ через первичный ключ
последовательно, многопоточно, а также одновременно многопоточно и пакетно.
Более или менее все эти тесты показали, что сокеты SCI были приблизительно
на 100% быстрее TCP/IP. Транспортер SCI в большинстве случаев был быстрее
сокетов SCI. Один известный случай с многими потоками в программе теста
показал, что SCI-транспортер вел себя очень плохо, если
использовался в процессе mysqld.
Таким образом, для большинства эталонных тестов сокеты SCI улучшают
эффективность примерно вдвое, относительно TCP/IP за исключением редких
случаев, когда эффективность связи не (проблема типа того, когда фильтры
просмотра занимают большинство времени обработки, или когда нужны очень
большие пакеты доступа через первичные ключи. В таком случае обработка CPU в
процессах ndbd становится довольно большой частью стоимости.
Использование SCI-транспортера вместо SCI-сокетов представляет интерес
только в связи между процессами ndbd. Использование SCI-транспортера также
представляет интерес только, если CPU может быть выделен для процесса ndbd,
поскольку SCI-транспортер гарантирует, что ndbd никогда не будет
бездействовать. Также важно гарантировать, что ndbd имеет приоритет,
установлен таким способом, что процесс не теряет в приоритете из-за работы
длительное время (как может быть выполнено, блокируя процессы на CPU в Linux
2.6). Если это возможная конфигурация, процесс ndbd принесет пользы на 10-70%
больше по сравнению с использованием сокетов SCI при выполнении модификаций
и, вероятно, также на параллельных действиях просмотра.
Имеются несколько других реализаций оптимизированных вариантов сокетов для
кластеров, рассмотренных в различных статьях. Они включают оптимизированные
варианты для Myrinet, Gigabit Ethernet, Infiniband и VIA interface.
Разработчики пока проверили MySQL Cluster только на сокетах SCI.