4.5 Параметры команд для MySQL Cluster

Все исполняемые модули в MySQL Cluster (кроме mysqld) понимают следующие параметры, начиная с версии 4.1.8. Если вы выполняете более раннюю версию, внимательно ознакомьтесь с текстом ниже, там указаны все отличия и проблемы. Обратите внимание также, что Вы можете использовать опцию -?, чтобы увидеть, что обеспечивается в Вашей версии.

-?, --usage, --help

Печатает короткое описание доступных параметров команды.

-V, --version

Печатает номер версии процесса ndbd. Это номер версии MySQL Cluster. Важно, потому что при запуске процессы MySQL Cluster проверяют, какие версии процессов могут сосуществовать в кластере. Это также важно для интерактивного программного обновления MySQL Cluster.

-c connect_string (не ndb_mgmd), --connect-string connect_string

Установить строку подключения к серверу управления как опцию команды (по причинам обратной совместимости ndb_mgmd до версии 5.0 опцию -c не обрабатывает, поскольку она в настоящее время определяет файл конфигурации). Доступно с ndb_mgm 4.1.8 и выше.

shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"

--debug[=options]

Это может использоваться только для версий с информацией отладки. Это используется, чтобы допустить вывод из вызовов отладки тем же самым способом, что и у процесса mysqld.

4.5.1 MySQL Cluster-специфичные параметры для mysqld

--ndbcluster

Если двоичный модуль включает поддержку для способа хранения NDB Cluster, эта опция активизирует данную поддержку, а она необходима для работы MySQL Cluster.

--skip-ndbcluster

Выключает поддержку NDB Cluster. По умолчанию поддержка и так выключена, так что эта опция нужна лишь на серверах, заранее сконфигурированных для кластерной работы.

--ndb-connectstring=connect_string

При использовании NDB, возможно подчеркнуть сервер управления, который распределяет конфигурацию кластера, устанавливая опцию строки подключения.

4.5.2 Опции для ndbd

5 Управление MySQL Cluster

Управление MySQL Cluster включает ряд действий. Первое действие должно конфигурировать и запустить MySQL Cluster.

Имеются по существу два способа активного управления выполнением MySQL Cluster. Первый: командами, введенными в клиенте управления, где состояние кластера может быть проверено. Второй метод состоит в том, чтобы исследовать вывод в файле регистрации кластера. Файл регистрации кластера направлен в ndb_2_cluster.log в каталоге DataDir сервера управления. Файл регистрации содержит отчеты о событиях, сгенерированные из процессов ndbd в кластере. Также возможно послать записи файла регистрации кластера файлу регистрации системы Unix.

5.1 Команды в клиенте управления

В дополнение к центральному файлу конфигурации, кластер может также управляться через интерфейс командной строки. Интерфейс командной строки доступен через отдельный процесс клиента управления. Это основной административный интерфейс к выполняющемуся кластеру.

Клиент управления имеет следующие базисные команды. Ниже <id> обозначает идентификатор узла базы данных (например, 21) или ключевое слово ALL, что указывает, что команда должна применяться ко всем узлам баз данных в кластере.

HELP

Печатает информацию о всех доступных командах.

SHOW

Печатает информацию относительно состояния кластера.

<id> START

Запустит узел базы данных, идентифицированный <id>, или все узлы баз данных.

<id> STOP

Выключит узел базы данных, идентифицированный <id>, или все узлы баз данных.

<id> RESTART [-N] [-I]

Перезапустит узел базы данных, идентифицированный <id>, или все узлы баз данных.

<id> STATUS

Информация состояния для узла базы данных, идентифицированного <id>, или для всех (ALL) узлов.

ENTER SINGLE USER MODE <id>

Вводит режим отдельного пользователя, где только API с идентификатором <id> позволяют обратиться к системе базы данных.

EXIT SINGLE USER MODE

Отменяет режим отдельного пользователя, позволяя всем API обратиться к системе базы данных.

QUIT

Завершает клиент управления..

SHUTDOWN

Завершает работу всех узлов кластера (за исключением серверов mysql) и выходит из клиента управления.

Команды для файлов регистрации событий даны в следующем разделе, команды для копирования и восстановления даны в отдельных разделах по этим темам.

5.2 Отчеты о событиях, сгенерированные в MySQL Cluster

MySQL Cluster имеет два файла регистрации событий: файл регистрации кластера и файл регистрации узла.

• Файл регистрации кластера ведет протокол работы целого кластера, и этот файл регистрации может иметь многократных адресатов (файл, консоль сервера управления или syslog).
• Файл регистрации узла является локальным для каждого узла базы данных и записан на консоль узла базы данных. Два файла регистрации могут быть установлены, чтобы регистрировать различные подмножества списка событий.

Примечание: файл регистрации кластера является рекомендуемым. Файл регистрации узла предназначен только, чтобы использоваться в течение разработки прикладной программы или для отладки кода прикладной программы.

Каждое событие имеет следующие реквизиты:

• Категория (STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT, NODERESTART, CONNECTION, ERROR, INFO).
• Приоритет (1-15, где 1 наиболее важный, 15 наименее важный).
• Серьезность (ALERT, CRITICAL, ERROR, WARNING, INFO, DEBUG).

Два файла регистрации (файл регистрации кластера и файл регистрации узла) могут быть фильтрованы, основываясь на этих реквизитах.

5.2.1 Команды управления протоколированием

Следующие команды управления связаны с файлом регистрации кластера:

CLUSTERLOG ON

Включить протоколирование кластера.

CLUSTERLOG OFF

Выключить протоколирование кластера.

CLUSTERLOG INFO

Информация относительно параметров настройки протоколирования.

<id> CLUSTERLOG <category>=<threshold>

События категории category с приоритетом меньше, чем или равным threshold отмечаются в файле регистрации кластера.

CLUSTERLOG FILTER <severity>

Регистрация событий кластера определенного типа серьезности вкл\выкл.

Следующая таблица описывает настройку по умолчанию (для всех узлов базы данных) порога категории файла регистрации кластера. Если событие имеет приоритет со значением ниже, чем или равным порогу приоритета, то это будет обязательно сообщено в файле регистрации кластера.

Обратите внимание, что события сообщены узлом базы данных, и что пороги могут быть установлены по-разному на различных узлах.

Порог используется, чтобы фильтровать события внутри каждой категории. Например: событие STARTUP с приоритетом 3 никогда не будет послано, если порог для STARTUP не установлен в 3 или ниже. Только события с приоритетом 3 или ниже будут посланы, если порог равен 3. Теперь о серьезности событий (она соответствует уровням UNIX syslog):

Коды LOG_EMERG и LOG_NOTICE из syslog здесь не применяются и не поддерживаются.

Серьезность событий (event severity) может быть включена или выключена. От этого зависит, будут ли регистрироваться события соответствующей серьезности. Если серьезность включена, регистрируются все события с приоритетом меньше, чем или равным порогу категории. Если серьезность выключена, не будет отмечено никаких событий, принадлежащих к этой серьезности.

5.2.2 Сообщения в протоколах событий

Все регистрируемые события перечислены ниже.

Отчет события имеет следующий формат в файлах регистрации:

<Дата & время в GMT> [<строка>]
<серьезность события> -- <сообщение файла регистрации>

Пример отчета о событии:

09:19:30 2003-04-24 [NDB] INFO -- Node 4 Start phase 4 completed

5.3 Однопользовательский режим работы

Режим отдельного пользователя (он же однопользовательский) позволяет администратору базы данных ограничивать доступ к системе базы данных только одной прикладной программой (узлом API). При вводе режима отдельного пользователя все подключения всех API будут элегантно закрыты, и никакие транзакции не могут быть начаты (но могут быть завершены).

Когда кластер вошел в режим отдельного пользователя, доступ к базе данных предоставлен только определенному узлу API. Пример:

ENTER SINGLE USER MODE 5

После выполнения этой команды, узел API с идентификатором узла 5 становится единственным пользователем кластера.

Узел, определенный в команде, выше должен быть узлом сервера MySQL. Любая попытка определять любой другой тип узла будет отклонена.

Обратите внимание: если узел с идентификатором 5 выполняется, когда выполнена команда ENTER SINGLE USER MODE 5, все транзакции, выполняющиеся на узле 5, будут прерваны, подключение закрыто, а сервер должен быть перезапущен.

Команда EXIT SINGLE USER MODE изменяет состояние кластера на многопользовательский режим работы. Серверам MySQL, ждущим подключения, теперь разрешают соединиться. Сервер MySQL, обозначенный как отдельный пользователь, продолжает выполняться, если он подключен к кластеру в течение и после изменения его состояния. Пример:

EXIT SINGLE USER MODE

Лучше всего в случае сбоев узла при выполнении в режиме отдельного пользователя:

1. Закончить все транзакции режима отдельного пользователя.
2. Выйти из режима отдельного пользователя.
3. Перезапустить узлы базы данных.

Или перезапустите узлы базы данных до ввода режима отдельного пользователя.

5.4 Резервирование MySQL Cluster

Этот раздел описывает, как создать резервную копию и позже восстановить из нее базу данных.

5.4.1 Концепция резервирования кластера

Копия представляет собой снимок (образ) базы данных в данное время. Копия содержит три основных части:

1. Метаданные (какие таблицы существуют и т. п.).
2. Записи таблиц (данные в таблицах).
3. Файл регистрации совершенных транзакций.

Каждая из этих частей сохранена на всех узлах, участвующих в копировании.

В течение резервирования каждый узел сохраняет эти три части на диск в три файла:

BACKUP-<BackupId>.<NodeId>.ctl

Управляющий файл, который содержат управляющую информацию и метаданные.

BACKUP-<BackupId>-0.<NodeId>.data

Файл данных, который содержат записи таблиц.

BACKUP-<BackupId>.<NodeId>.log

Журнал, которые содержат совершенные транзакции.

Выше <BackupId> задает идентификатор для копии, и <NodeId> идентификатор узла, создающего файл.

Метаданные

Метаданные состоят из определений таблицы. Все узлы имеют точно те же самые определения таблицы, сохраненные на диске.

Записи таблицы

Записи таблицы сохранены пофрагментно. Каждый фрагмент содержит заголовок, который описывает, которой таблице принадлежат записи. После списка записей имеется хвост, который содержит контрольную сумму для записей. Различные узлы сохраняют различные фрагменты в ходе изготовления копии.

Совершенные транзакции

Перечень совершенных транзакций содержит все транзакции, сделанные в ходе копирования. Только транзакции на таблицах, сохраненных в копии, будут сохранены в файле регистрации. Различные узлы в копии сохраняют различные записи файла регистрации, поскольку они ведут разные фрагменты базы данных.

5.4.2 Использование сервера управления, чтобы создать копию

Прежде чем начать, удостоверьтесь, что кластер правильно сконфигурирован для резервного копирования.

1. Запустите уцправляющий сервер.
2. Выполните команду START BACKUP.
3. Сервер управления ответит ``Start of backup ordered''. Это означает, что сервер управления представил на рассмотрение запрос к кластеру, но еще не получил никакого ответа.
4. Сервер управления ответит ``Backup <BackupId> started'', где <BackupId> задает уникальный идентификатор для этой специфической копии. Это будет также сохранено в файле регистрации кластера (если он не сконфигурирован иначе). Это означает, что кластер получил и обработал запрос. Это не означает, что копия уже завершена.
5. Сервер управления сообщит ``Backup <BackupId> completed'', когда копия закончена.

Использование сервера управления, чтобы прервать копию:

1. Запустите уцправляющий сервер.
2. Выполните команду ABORT BACKUP <BACKUPID>. Здесь <BackupId> задает идентификатор копии, который был включен в ответ серверу управления, когда копия начата, то есть в сообщение ``Backup <BackupId> started''. Идентификатор также сохранен в файле регистрации кластера (cluster.log).
3. Сервер управления ответит ``Abort of backup <BackupId> ordered''. Это означает, что он представил на рассмотрение запрос кластеру, но не получил никакого ответа.
4. Сервер управления ответит ``Backup <BackupId> has been aborted reason XYZ''. Это означает, что кластер прервал копию и удалил все к ней относящееся, включая файлы в файловой системе.

Обратите внимание, что, если не имеется копии с идентификатором <BackupId>, выполняющейся на момент попытки прерывания, сервер управления не будет отвечать ничего.

5.4.3 Восстановление из резервной копии

Программа восстановления выполнена как отдельная утилита командной строки. Она читает файлы, созданные из копии, и вставляет сохраненную информацию в базу данных. Программа восстановления должна быть выполнена один раз для каждого набора файлов с резервной копией, то есть столько, сколько работало узлов базы данных, когда копия создавалась.

Первый раз, когда Вы выполняете программу восстановления, Вы также должны восстановить метаданные, то есть создать таблицы. Действия программы восстановления рассматриваются как обращение API к кластеру и, следовательно, нуждаются в свободном подключении, чтобы соединиться с кластером. Это может быть проверено через ndb_mgm командой SHOW. Переключатель -c <connectstring> может использоваться, чтобы указать узел MGM. Файлы с резервной копией должны присутствовать в каталоге, заданном как параметр программы восстановления. Копия может быть восстановлена в базу данных с иной конфигурацией, чем та, из которой резервировались данные. Например, допустим, что копия (с идентификатором 12) создана на кластере с двумя узлами базы данных (с идентификаторами узлов 2 и 3), а должна быть восстановлена на кластере с четырьмя узлами. Программа восстановления должна быть выполнена два раза (по одному для каждого узла базы данных в кластере, где копия создавалась, как описано ниже.

Обратите внимание: для быстрого восстановления, данные могут быть восстановлены паралелльно (если имеется достаточно свободных подключений API). Обратите внимание, однако, что файлы данных должны всегда обрабатываться перед файлами регистрации!

Еще обратите внимание: кластер должен иметь пустую базу данных перед началом процесса восстановления.

5.4.4 Конфигурации для резервирования

Имеются четыре параметра конфигурации для резервирования:

BackupDataBufferSize

Объем памяти (из общей памяти) используемый, чтобы буферизовать данные прежде, чем они будут записаны на диск.

BackupLogBufferSize

Объем памяти (из общей памяти) используемый, чтобы буферизовать записи файла регистрации прежде, чем они будут записаны на диск.

BackupMemory

Общая память, распределенная в узле базы данных для изготовления копии. Это должно быть суммой памяти, распределенной для двух буферов.

BackupWriteSize

Размер блоков, записанных на диск. Это совместно применяется к буферам данных и файлов регистрации.

5.4.5 Проблемы резервирования

Если при выдаче запроса на резервирование возвращен код ошибки, то проверьте, что имеется достаточно памяти, распределенной для копирования (то есть, параметры конфигурации). Также проверьте, что имеется достаточно пространства в разделе жесткого диска-адресате.

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.

7 Ограничения MySQL Cluster в версии 4.1