Сервер MySQL, который является частью кластера, отличается от обычного
только одним: он использует тип хранения NDBCLUSTER
. Этот тип
хранения также упоминается просто как NDB
, и эти две формы
имени являются синонимами.
Чтобы избегать ненужного распределения ресурсов, сервер конфигурирован по
умолчанию с заблокированным NDB
. Чтобы его включить, Вы должны
будете изменить файл конфигурации сервера my.cnf.
Так как сервер MySQL является частью кластера, также надо знать, как
обратиться к MGM-узлу, чтобы получить данные конфигурации кластера. Заданное
по умолчанию поведение: искать MGM-узел на localhost
. Однако,
если надо определить расположение в другом месте, это может быть выполнено в
my.cnf или в командной строке сервера MySQL. Прежде, чем
NDB
сможет использоваться, по крайней мере один MGM-узел должен
быть запущен, также как любые желательные DB-узлы.
Если Вы выбираете сборку из исходных текстов или дерева разработки MySQL
4.1 BitKeeper, убедитесь, что использовали опцию
--with-ndbcluster
при выполнении configure
. Вы
можете взамен использовать скрипт BUILD/compile-pentium-max
.
Обратите внимание, что этот скрипт включает OpenSSL, так что Вы должны иметь
или получить OpenSSL, чтобы все прошло нормально, иначе Вы должны будете
изменить compile-pentium-max
, чтобы исключить это требование.
Конечно, Вы можете также только следовать стандартным командам для
компилирования Вашего собственного пакета, затем выполнить обычные
тесты и процедуру установки.
В следующих разделах предполагается, что Вы уже знакомы с установкой
MySQL, и здесь рассматриваются только различия между конфигурированием
MySQL Cluster и MySQL без кластеризации.
Вы найдете конфигурацию кластера самой простой, если уже имеете все узлы
MGM и DB в рабочем виде изначально, полагаю, это будет самым длительным
этапом настройки. Редактирование файла my.cnf довольно просто, и
этот раздел рассматривает только отличия от конфигурирования
MySQL без кластеризации.
Чтобы ознакомить Вас с основами, опишем самую простую возможную
конфигурацию для функционального кластера. После этого Вы должны быть
способны разработать Вашу желательную конфигурацию, исходя из информации,
обеспеченной в других релевантных разделах этой главы.
Подождите немного, чтобы удостовериться, что сервер MySQL выполняется
правильно. Если Вы видите сообщение mysql ended
, проверьте файл
.err сервера, чтобы выяснить то, что пошло неправильно. Если все
пока хорошо, Вы можете теперь запустить кластер:
Чтобы проверить, что Ваши узлы были установлены правильно, запустите
клиент управления как показано:
Что ж, Вы успешно установили работающий кластер MySQL. Вы можете теперь
сохранять данные в кластере, используя любую таблицу, созданную с
ENGINE=NDBCLUSTER
или псевдонимом ENGINE=NDB
.
Разработчики пакета непрерывно делают усовершенствования конфигурации
кластера и пытаются упрощать этот процесс. Несмотря на то, что они стараются
поддерживать совместимость в обратном направлении, могут иметься моменты,
когда появляется несовместимое изменение. В таких случаях пользователям
предоставляется информация о проблеме, если изменение не совместимо в
обратном направлении. Если Вы находите такое изменение, которое не
зарегистрировано, пожалуйста, используйте базу данных ошибок
(http://bugs.mysql.com), чтобы сообщить
авторам об этом.
В настоящее время файл конфигурации находится в формате INI и именован
по умолчанию config.ini. Это читается ndb_mgmd
при
запуске, и это может быть помещено где угодно. Расположение и имя определено,
используя опцию --config-file=[<path>]<filename>
в командной строке ndb_mgmd
. Если файл конфигурации не
определен, ndb_mgmd
по умолчанию пробует читать
config.ini, размещенный в текущем рабочем каталоге.
Значения по умолчанию определены для большинства параметров, и также могут
быть определены в config.ini. Чтобы создать раздел значений по
умолчанию, просто добавьте слово DEFAULT
к имени раздела.
Например, DB-узлы конфигурированы, используя раздел [DB]
.
Если все DB-узлы используют тот же самый размер памяти данных, и он не тот же
самый, какой задан по умолчанию, создайте раздел [DB DEFAULT]
,
содержащий строку DataMemory
, чтобы определить заданный по
умолчанию размер памяти данных для всех DB-узлов.
Формат INI состоит из разделов, которым предшествуют заголовки раздела
(окруженные квадратными скобками), сопровождаемые соответствующими именами
параметров и значениями. Одно отклонение из стандартного формата в том, что
имя параметра и значение может отделяться двоеточием (`:'),
так же, как и знаком равенства (`='). Другое состоит в том, что
разделы не идентифицированы уникальным именем. Вместо этого, уникальные
записи (типа двух различных узлов того же самого типа) идентифицированы
уникальным идентификатором (ID).
Как минимум, файл конфигурации должен определить компьютеры и узлы,
включаемые в кластер, и на которых компьютерах эти узлы размещены. Пример
простого файла конфигурации для кластера, состоящего из одного сервера
управления, двух узлов памяти и двух серверов MySQL, показывается ниже:
3.4.2 MySQL Cluster connectstring
За исключением сервера управления кластера (ndb_mgmd
),
каждый узел, составляющий кластер MySQL, требует connectstring
,
которая указывает на расположение сервера управления. Это используется при
установлении подключения к серверу управления так же, как в выполнении других
задач, в зависимости от роли узла в кластере.
Синтаксис для connectstring
следующий:
<connectstring> := [<nodeid-specification>,]<host-specification>[,<host-specification>]
<nodeid-specification> := nodeid=<id>
<host-specification> := <host>[:<port>]
Здесь <id> целое число больше, чем 1. Определяет узел в
config.ini, <port> целое число указывает на unix-порт, а
<host> является строкой, которая задает адрес хоста в любом,
допустимом в Интернете формате.
Пример первый (длинный):
"nodeid=2, myhost1:1100, myhost2:1100, 192.168.0.3:1200"
Пример второй (короткий):
"myhost1"
Все узлы используют localhost:1186
как значение по умолчанию
connectstring
, если оно не задано. Если
<port>
пропущен, по умолчанию будет задан порт 1186.
Примечание: до MySQL 4.1.8 это был порт 2200. Этот порт
всегда должен быть доступен по сети, так как это было назначено IANA для этой
цели (см.
http://www.iana.org/assignments/port-numbers).
Используя много значений <host-specification>
, можно
обозначить несколько избыточных серверов управления. Узел кластера будет
пытаться входить в контакт с сервером управления на каждом компьютере в
определенном порядке, пока успешное подключение не было установлено.
Имеется ряд различных способов определить connectstring:
- Каждая выполнимая программа имеет собственную опцию командной строки,
которая допускает определение сервера управления при запуске.
- Начиная с MySQL 4.1.8, также возможно установить
connectstring
, который нужно использовать всем узлам в кластере,
помещая это в разделе [mysql-cluster]
в файле
my.cnf сервера управления.
- Для совместимости в обратном направлении, два других параметра доступны,
используя тот же самый синтаксис:
- Установите системную переменную
NDB_CONNECTSTRING
в connectstring.
- Запишите
connectstring
для каждой программы в текстовый
файл Ndb.cfg и поместите этот файл в стартовый каталог программы.
Рекомендуемый метод для определения connectstring
состоит в
том, чтобы установить это в командной строке или в файле my.cnf для
каждой выполнимой программы.
3.4.3 Определение компьютеров, составляющих кластер MySQL
Раздел [COMPUTER]
не имеет никакого реального значения,
кроме как способ избежать определения имен для каждого узла в системе. Все
параметры, упомянутые здесь, являются обязательными.
[COMPUTER]Id
- Это внутренний идентификатор в файле конфигурации. Позже в файле всн
обращается к этому компьютеру по этому ID. Это целое число.
[COMPUTER]HostName
- Это имя компьютера. Также возможно использовать IP-адрес.
3.4.4 Определение сервера управления MySQL Cluster
Раздел [MGM]
(или его псевдоним [NDB_MGMD]
)
используется, чтобы конфигурировать поведение сервера управления. Хотя бы
один из параметров ExecuteOnComputer
или HostName
должен присутствовать. Все другие параметры могут быть опущены и, если это
так, примут значения по умолчанию.
[MGM]Id
- Каждый узел в кластере имеет уникальный идентификатор, представляемый
целочисленным значением между 1 и 63 включая границы. Этот ID используется
для адресации узла в соответствии со всеми внутренними сообщениями кластера.
[MGM]ExecuteOnComputer
- Это относится к одному из компьютеров,
определенных в разделе
[COMPUTER]
.
[MGM]PortNumber
- Это номер порта, на котором сервер ждет запросов
конфигурации и команд управления.
[MGM]LogDestination
- Этот параметр определяет, куда послать регистрирующую информацию с
кластера. Имеются три параметра в этом отношении:
CONSOLE
,
SYSLOG
и FILE
.
CONSOLE
выводит файл регистрации на stdout
:
CONSOLE
SYSLOG
посылает файл регистрации средству
syslog
, возможны дополнительные значения: auth
,
authpriv
, cron
, daemon
,
ftp
, kern
, lpr
, mail
,
news
, syslog
, user
, uucp
,
local0
, local1
, local2
,
local3
, local4
, local5
,
local6
или local7
. Примечание: не
каждое средство обязательно обеспечивается любой операционной системой.
SYSLOG:facility=syslog
FILE
направляет вывод в регулярный файл на той же самой
машине. Следующие значения могут быть определены:
filename
: имя этого файла.
maxsize
: максимальный размер, до которого файл может расти.
Как только дорастет, будет создан новый файл с этим именем, а к имени старого
добавится .x, здесь это самое x
представляет собой
следующий номер, еще не использованный с этим именем.
maxfiles
: максимальное количество файлов.
FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
Возможно определить несколько адресатов как показано здесь, при использовании
разграниченной точкой с запятой строки:
CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
Значение по умолчанию для параметра FILE
:
FILE:filename=ndb_<id>_cluster.log, maxsize=1000000,
maxfiles=6
, здесь <id>
задает ID узла.
[MGM]ArbitrationRank
- Этот параметр используется, чтобы определить, которые узлы могут
действовать как арбитраторы. Только MGM и API-узлы могут быть арбитраторами,
и параметр может принимать одно из следующих значений:
0
: этот узел никогда не будет
использоваться как арбитратор.
1
: узел имеет высокий приоритет, то есть он будет
предпочтен как арбитратор над низкоприоритетными узлами.
2
: указывает низкоприоритетный узел, который будет
использоваться как арбитратор только, если узел с более высоким приоритетом
недоступен для этой цели.
Обычно сервер управления должен быть конфигурирован как арбитратор,
устанавливая ArbitrationRank
в 1 (значение по умолчанию) и
ArbitrationRank
в 0 на всех API и серверных узлах.
[MGM]ArbitrationDelay
- Целочисленное значение, которое предписывает серверу управления до
запросов арбитража отсрочить ответы на соответствующее число миллисекунд. По
умолчанию это значение 0, это обычно не надо менять.
[MGM]DataDir
- Это устанавливает каталог, где выходные файлы с сервера управления будут
помещены. Эти файлы включают журналы кластера, обрабатываемые выходные файлы
и pid-файл сервера (для журналов это может быть отменено, устанавливая
параметр
FILE
для [MGM]LogDestination
).
3.4.5 Определение узлов памяти MySQL Cluster
Раздел [DB]
(или [NDBD]
, что то же самое)
используется, чтобы конфигурировать поведение узлов памяти. Имеется много
параметров, определяющих всякие настройки. Единственные обязательные
параметры: ExecuteOnComputer
или HostName
и
параметр NoOfReplicas
, которые должны быть определены в разделе
[DB DEFAULT]
. Большинство параметров должно быть установлено
именно в разделе [DB DEFAULT]
. Параметры HostName
,
Id
и ExecuteOnComputer
должны быть определены в
локальном разделе [DB]
.
Значение Id
(то есть идентификация узла памяти) может быть
распределено, когда узел запускается. Все еще возможно назначить ID
узла в файле конфигурации.
Для каждого параметра возможно использовать как суффикс k, M или G, чтобы
указать 1024, 1024*1024 или 1024*1024*1024. Например, 100k означает 102400.
Параметры и значения в настоящее время чувствительны к регистру.
[DB]Id
- Это ID узла, используемый как адрес узла во всем кластере. Это целое
число между 1 и 63. Каждый узел в кластере имеет уникальный ID.
[DB]ExecuteOnComputer
- Это ссылка на один из компьютеров, определенных в разделе computer.
[DB]HostName
- Этот параметр подобен определению компьютера. Это определяет имя
компьютера, на котором постоянно дислоцируется узел памяти. Этот параметр или
запись
ExecuteOnComputer
требуется в обязательном порядке.
[DB]ServerPort
- Каждый узел в кластере использует один порт, чтобы подключить узлы друг к
другу. Этот порт используется также для не-TCP связи в фазе установки
подключения. Заданный по умолчанию порт будет вычислен, чтобы гарантировать,
что никакие узлы на том же самом компьютере не получают тот же
самый номер порта.
[DB]NoOfReplicas
- Этот параметр может быть установлен только в разделе
[DB DEFAULT]
, потому что это глобальный параметр. Это определяет
число точных копий для каждой таблицы, сохраненной в кластере. Этот параметр
также определяет размер групп узлов. Группа представляет собой набор узлов,
хранящих ту же самую информацию. Группы сформированы неявно. Первая группа
сформирована узлами памяти с самыми низкими идентификаторами узла. Далее
берутся более высокие идентификаторы и так далее. Например, предположите, что
мы имеем 4 узла памяти, и NoOfReplicas
установлен в 2. Четыре
узла памяти имеют ID узла 2, 3, 4 и 5. Затем первая группа будет сформирована
узлами 2 и 3. Вторая группа узлов будет сформирована узлами 4 и 5. Важно
конфигурировать кластер таким способом, что узлы в тех же самых группах не
помещены в тот же самый компьютер. Это вызвало бы одиночный HW-сбой, который
может вызвать аварийный отказ кластера. Если никакие идентификаторы узлов не
обеспечиваются, порядок узлов памяти будет фактором определения группы узла.
Фактическая группа узла будет напечатана командой SHOW
в клиенте
управления. Не имеется никакого значения по умолчанию, максимальный номер 4.
[DB]DataDir
- Этот параметр определяет каталог, где помещены служебные файлы
(трассировка, протоколы, журналы ошибок и pid-файл).
[DB]FileSystemPath
- Этот параметр определяет каталог, где размещаются все файлы, созданные
для метаданных, протоколов REDO и UNDO, а также файлы данных. Значение по
умолчанию должно использовать тот же самый каталог, что и
DataDir
. Каталог должен быть создан перед запуском процесса
ndbd
. Если Вы используете рекомендуемую иерархию каталога, Вы
используете каталог /var/lib/mysql-cluster. Под этим каталогом
будет создан каталог ndb_3_fs (если ID узла был 3), который будет
файловой системой для этого узла.
[DB]BackupDataDir
- Это определяет каталог, где копии будут помещены. По умолчанию это
каталог
FileSystemPath/
BACKUP.
Параметры DataMemory
и IndexMemory
, которые
определяют размер сегментов памяти, используемых, чтобы сохранить фактические
записи и их индексы. Важно понять, как DataMemory
и
IndexMemory
используются, чтобы понять, как установить эти
параметры. Для большинства использований, они должны модифицироваться, чтобы
отразить использование кластера.
[DB]DataMemory
- Этот параметр один из наиболее важных, потому что это определяет,
доступное, чтобы сохранить фактические записи в базе данных. Весь объем
DataMemory
будет распределен в памяти, так что важно, что машина
содержит достаточно памяти, чтобы обработать DataMemory
.
DataMemory
используется, чтобы сохранить две вещи. Это сохраняет
фактические записи. Каждая запись имеет в настоящее время фиксированный
размер. Столбцы типа VARCHAR
сохранены как столбцы
фиксированного размера. Имеются нпроизводительные затраты на каждой записи
(обычно 16 байт). Дополнительно каждая запись сохранена в странице размером
32KB с непроизводительными затратами страницы в 128 байт. Максимальный размер
записи для столбцов в настоящее время 8052 байт. DataMemory
также используется, чтобы сохранить упорядоченные индексы. Упорядоченные
индексы используют приблизительно 10 байт в соответствии с записью. Каждая
запись в таблице всегда представляется в упорядоченном индексе.
DataMemory
состоит из страниц длиной по 32KB. Эти страницы
распределены по разделам таблиц. Каждая таблица обычно разбита на разделы с
тем же самым числом разделов, сколько имеется узлов памяти в кластере. Таким
образом, для каждого узла имеется то же самое число разделов (= фрагменты),
сколько задано в параметре NoOfReplicas
. Другой важный аспект:
DataMemory
также хранит информацию UNDO для записей. Для каждой
модификации записи, копия изначальной записи распределена в
DataMemory
. Также каждая копия записи будет иметь элемент в
упорядоченных индексах таблицы. Уникальные индексы модифицируются только,
когда модифицируются уникальные индексные столбцы, в том случае вставлен
новый вход в индексной таблице, а старый вход удален. Таким образом,
необходимо также распределить память, чтобы обработать самые большие
транзакции, которые выполняются в кластере. Выполнение больших транзакций не
имеет никакого преимущества в кластере MySQL. Это не быстрее и потребляет
большие объемы памяти. Значение по умолчанию для DataMemory
:
80MB. Минимум: 1MB. Не имеется никакого максимального размера, но в
действительности максимальный размер должен адаптироваться так, чтобы процесс
не вызывал своп при использовании максимального размера памяти.
[DB]IndexMemory
IndexMemory
представляет собой параметр, который управляет
количеством памяти, используемой для индексов в MySQL Cluster. Индексы всегда
используются для первичных индексов ключа, уникальных индексов и уникальных
ограничений. Фактически при определении первичного ключа и уникального
индекса будут иметься два индекса, созданные в MySQL Cluster. Один индекс
используется для всех доступов, а также для обработки блокировки. Это также
используется, чтобы гарантировать уникальные ограничения. Размер индекса
составляет 25 байт плюс размер первичного ключа. Для первичных ключей,
больших, чем 32 байта, 8 байт добавлены для некоторых внутренних ссылок.
Таким образом, для таблицы, определенной как
CREATE TABLE example
(
a INT NOT NULL, b INT NOT NULL, c INT NOT NULL,
PRIMARY KEY(a), UNIQUE(b)
) ENGINE=NDBCLUSTER;
мы будем иметь 12 байт непроизводительных затрат (отсутствие столбцов со
значениями null экономит 4 байта) плюс 12 байт данных в соответствии с
записью. Кроме того мы будем иметь два упорядоченных индекса на a и b,
потребляющих приблизительно по 10 байт каждый в соответствии с записью. Мы
будем также иметь первичный индекс ключа в основной таблице грубо с 29
байтами в соответствии с записью. Уникальное ограничение выполнено отдельной
таблицей с b как первичный ключ, а с a как столбец. Эта таблица потребит
другие 29 байтов индексной памяти в соответствии с записью в таблице, а также
12 байт непроизводительных затрат плюс 8 байт данных в части записи. Таким
образом, для одного миллиона записей мы будем нуждаться в 58MB индексной
памяти, чтобы обработать индексы для первичного ключа и уникального
ограничения. Для части DataMemory
мы будем нуждаться в 64MB
памяти, чтобы обработать записи основной таблицы и уникальной индексной
таблицы плюс две упорядоченных индексных таблицы. Заключение: индексы
занимают немало памяти, но они обеспечивают очень быстрый доступ к данным.
Они также используются в MySQL Cluster, чтобы обработать ограничения
уникальности. В настоящее время единственный алгоритм разбиения хеширование,
и упорядоченные индексы локальны для каждого узла и не могут таким образом
использоваться, чтобы обработать ограничения уникальности в общем случае.
Важный момент для IndexMemory
и DataMemory
: то, что
общий размер базы данных является суммой DataMemory
и
IndexMemory
в каждой группе узлов. Каждая группа узлов
используется, чтобы сохранить скопированную информацию, так, если имеются
четыре узла с 2 точными копиями будут две группы узлов, и таким образом общее
количество DataMemory
составит 2*DataMemory
в
каждом из узлов. Другой важный момент относительно изменений
DataMemory
и IndexMemory
. Прежде всего, строго
рекомендуется иметь тоже самое количество DataMemory
и
IndexMemory
во всех узлах. Так как данные распределены
равномерно по всем узлам в кластере, размер лимитируется самым маленьким
размером на узле в кластере. Размер DataMemory
и
IndexMemory
может быть изменен, но опасно уменьшить их, потому
что это может легко привести к узлу, который не будет способен
перезапуститься, или даже к невозможности перезапуска кластера, если не
имеется достаточно пространства памяти для таблиц, необходимых, чтобы
работать со стартовым узлом. Увеличение их должно быть безопасно, но
рекомендуется, чтобы такие обновления выполнились тем же самым способом, как
программное обновление, где сначала модифицируется файл конфигурации, затем
перезапускается сервер управления, а уж потом один узел памяти одновременно
перезапускается. Большее количество IndexMemory
не используется
при модификациях, но вставки будут вставлены немедленно, а удаления не будут
удалены, пока транзакция не завершена. Значение по умолчанию размера
IndexMemory
составляет 18MB. Минимальное равно 1MB.
Следующие три параметра важны, потому что они воздействуют на число
параллельных транзакций и размеров транзакций, которые могут быть обработаны
системой. MaxNoOfConcurrentTransactions
устанавливает число
параллельных транзакций, возможных в узле, а
MaxNoOfConcurrentOperations
устанавливает число записей, которые
могут быть в фазе модификации или блокированы одновременно.
Оба эти параметра (особенно MaxNoOfConcurrentOperations
)
вероятные адресаты для пользователей, устанавливающих специфические значения.
Значение по умолчанию установлено для систем, использующих маленькие
транзакции и гарантируют использование не слишком много памяти в заданном
по умолчанию случае.
[DB]MaxNoOfConcurrentTransactions
- Для каждой активной транзакции в кластере должна иметься также запись
транзакции в одном из узлов в кластере. Роль координации транзакции
распространена среди узлов и таким образом общее число записей транзакций в
кластере равно количеству узлов в кластере. Фактически записи транзакции
распределены сервером MySQL, обычно имеется по крайней мере одна запись
транзакции, распределенная в кластере, на подключение, которая использует или
использовала таблицу в кластере. Таким образом, нужно гарантировать, что
имеется большее количество записей транзакции в кластере, чем параллельных
соединений с серверами в кластере. Этот параметр должен быть тем же самым на
всех узлах в кластере. Изменение этого параметра никогда не безопасно и может
вызывать аварийный отказ кластера. Дело в том, что в случае сбоя одного из
узлов, нагрузку примут остальные, а это означает, что у них должно хватить
записей транзакций, чтобы обработать транзакции с временно вышедшего из строя
узла. Если не хватит, узлы начнут вылетать по одному, что выведет из строя
кластер в целом. Значение по умолчанию для этого параметра: 4096.
[DB]MaxNoOfConcurrentOperations
- Этот параметр, вероятно, будет изменен пользователями. Пользователи,
выполняющие только короткие, маленькие транзакции, не должны устаналивать
этот параметр очень высоко. Прикладные программы, желающие выполнять довольно
большие транзакции, включающие много записей, должны установить этот параметр
выше. Для каждой транзакции, которая модифицирует данные в кластере требуется
иметь записи операции. Имеются записи операции в координаторе транзакции и в
узлах, где выполняются фактические модификации. Записи операции содержат
информацию о состоянии, необходимую, чтобы найти записи UNDO для обратной
перемотки, очередей блокировок и много другой информации о состоянии. Для
кластера, обрабатывающего транзакции, где модифицируется один миллион записей
одновременно, надлежит установить этот параметр в один миллион поделенный на
число узлов. Таким образом, для кластера с четырьмя узлами памяти нужно
установить этот параметр в 250000. Также запросы чтения, которые
устанавливают блокировки, исчерпывают записи операции. Некоторое
дополнительное количество распределено в локальных узлах, чтобы обслужить
случаи, в которых распределение по узлам не совершенно. Когда запросы
транслируют в использование уникального индекса фактически будет две записи
операции, используемые в соответствии с записью в транзакции. Первая
представляет чтение индексной таблицы, а вторая обрабатывает операцию на
основной таблице. Значение по умолчанию для этого параметра: 32768. Этот
параметр фактически обрабатывает две части, которые могут быть
сконфигурированы отдельно. Первая часть определяет, сколько записей операции
должны быть помещены в часть координатора транзакции. Вторая часть
определяет, сколько записей операции должны использоваться в локальной части
базы данных. Если очень большая транзакция выполняется на кластере с 8
узлами, то понадобится столько записей операции в координаторе транзакции,
сколько будет чтений, удалений и обновлений в транзакции. Транзакция, однако,
распределит записи операции между всеми восьмью узлами. Таким образом, если
необходимо конфигурировать систему для одной очень большой транзакции,
хорошая идея конфигурировать их порознь.
MaxNoOfConcurrentOperations
будет всегда использоваться, чтобы
вычислить число записей операции в части координатора транзакции узла. Также
важно иметь представление относительно требований памяти для тех записей
операции. В MySQL 4.1.5 записи операции потребляют около 1KB на запись. Это
планируется уменьшить в версиях 5.x.
[DB]MaxNoOfLocalOperations
- По умолчанию этот параметр вычислен как
1.1*
MaxNoOfConcurrentOperations
, который удовлетворяет системы
с большим числом одновременных, не очень больших транзакций. Если
конфигурация должна обработать очень большие транзакции одновременно, и
имеется много узлов, стоит конфигурировать это отдельно.
Следующий набор параметров используется для временной памяти посреди
выполнения части запроса в кластере. Все эти записи будут освобождены, когда
часть запроса завершена и идет ожидание подтверждения или отмены запроса.
Большинство значений по умолчанию для этих параметров будут нормальны для
большинства пользователей. Некоторые высококачественные пользователи могут
увеличивать их, чтобы добавить параллелизма в системе, а некоторые
пользователи могут уменьшать их, чтобы сэкономить память.
[DB]MaxNoOfConcurrentIndexOperations
- Для запросов, использующих уникальный индекс, другой набор записей
операции временно используются в фазе выполнения запроса. Этот параметр
устанавливает размер этого пула. Таким образом, эта запись распределена
только при выполнении части запроса, как только эта часть была выполнена,
запись освобождается немедленно. Обработка аварийных прекращений работы и
тому подобное выполнена в соответствии с нормальными записями операции, где
размер пула установлен параметром
MaxNoOfConcurrentOperations
.
Значение по умолчанию для этого параметра: 8192. Только в редких случаях
чрезвычайно высокого параллелизма, использующего уникальные индексы, этот
параметр необходимо увеличить. Уменьшение сэкономит память, но делать это
можно только, если Вы уверены, что такой высокий параллелизм
не встречается в кластере.
[DB]MaxNoOfFiredTriggers
- Значение по умолчанию для
MaxNoOfFiredTriggers
равно 4000.
Обычно это значение должно быть достаточно для большинства систем. В
некоторых случаях это стоит уменьшить, если Вы чувствуете, что параллелизм в
кластере не так уж и высок. Эта запись используется, когда операция
выполняется, что воздействует на уникальный индекс. Модифицирование столбца,
который является частью уникального индекса или вставки/удаления записи в
таблице с уникальными индексами будет работать со вставками и удалениями
в индексной таблице. Эта запись используется, чтобы представить эту индексную
операцию таблицы, в то время как идет ожидание для первоначальной операции.
Таким образом, эта запись требуется ненадолго, но может занимать немало
места для временных ситуаций с многими параллельными операциями записи на
основной рабочей таблице, содержащей набор уникальных индексов.
[DB]TransactionBufferMemory
- Этот параметр также используется для хранения операций, чтобы
модифицировать индексные таблицы. Эта часть хранит ключ и информацию столбца
для операций. Этот параметр меняется очень редко. Также нормальное чтение и
операции записи использует подобный буфер. Этот буфер во время компиляции
выставлен в 4000*128 байт (500KB), что определено через
ZATTRBUF_FILESIZE
в Dbtc.hpp. Существует подобный
буфер для информации ключа, который содержит 4000*16 байт, 62.5KB. Параметр в
этом случае: ZDATABUF_FILESIZE
в Dbtc.hpp.
Dbtc
представляет собой модуль для обработки координации
транзакций. Подобные параметры существуют в модуле Dblqh
, где
данные размещены. В Dblqh.hpp с ZATTRINBUF_FILESIZE
,
установленным в 10000*128 байт (1250KB), установите
ZDATABUF_FILE_SIZE
в 10000*16 байт (примерно 156KB). Заданный по
умолчанию размер TransactionBufferMemory
составляет 1MB.
[DB]MaxNoOfConcurrentScans
- Этот параметр используется, чтобы управлять количеством параллельных
просмотров, которые могут выполняться в кластере. Каждый координатор
транзакции может обрабатывать количество параллельных просмотров,
определенное этим параметром. Каждый запрос просмотра выполняется,
просматривая все разделы параллельно. Каждый просмотр раздела использует
запись просмотра в узле, где раздел размещен. Просмотр выполняется в двух
случаях. Первый случай: не существует никакого упорядоченного индекса, чтобы
обработать запрос. В этом случае запрос обрабатывается, выполняя полный
просмотр таблицы (очень долго и неоптимально!). Второй вариант: не имеется
никакого индекса, чтобы поддерживать запрос, но имеется упорядоченный индекс.
Тогда происходит использование упорядоченных индексных средств, выполняющих
параллельный просмотр диапазона. Так как индекс только продолжает локальные
разделы, необходимо выполнить индексный просмотр на всех разделах. Значение
по умолчанию для
MaxNoOfConcurrentScans
равно 256. Максимальное
допустимое значение составляет 500. Этот параметр будет всегда определять
количество возможных просмотров в координаторе транзакций. Если число
локальных записей просмотров не задано явно, это вычислено как произведение
MaxNoOfConcurrentScans
на число узлов памяти в системе.
[DB]MaxNoOfLocalScans
- Возможно определять число локальных записей просмотра, если многие
просмотры не полностью параллелизируемы.
[DB]BatchSizePerLocalScan
- Этот параметр используется, чтобы вычислить число записей блокировки,
требуемых, чтобы обработать много параллельных операций просмотра. Значение
по умолчанию составляет 64, и оно сильно связано с
ScanBatchSize
, определенным в узлах API.
[DB]LongMessageBuffer
- Это внутренний буфер, используемый для передачи сообщений в узле и для
сообщений между узлами в системе. Вряд ли его вообще понадобится менять, но
на всякий случай такая возможность существует. По умолчанию это 1MB.
[DB]NoOfFragmentLogFiles
- Это важный параметр, который заявляет размер REDO журналов в узле. REDO
журналы организованы в кольцо, так что важно, чтобы хвост и голова списка не
встречались. Если они перекроются, узел запустит прерывание всех транзакций
модифицирования, потому что не имеется никакого участка памяти для записи
файла регистрации. REDO записи файла регистрации не удалены, пока три
локальных контрольных точки не завершатся после того, как запись файла
регистрации была вставлена. Быстродействие контрольной точки управляется
набором других параметров, так что эти параметры взаимосвязаны. Заданное по
умолчанию значение параметра: 8, что означает 8 наборов по 4 файла в 16MB
каждый. Таким образом, в общем получаем 512MB. Единицей места для файла
регистрации REDO является 64MB. В случае больших количеств модификаций этот
параметр должен быть установлен очень высоким. Известны случаи, где было
необходимо установить его к более, чем 300. Если введение контрольных точек
медленно, и имеется так много записей в базе данных, что журналы заполнились,
а хвост списка файла регистрации не может быть вырезан по причинам
восстановления, то все транзакции модифицирования будут прерваны с внутренним
кодом ошибки 410, который будет транслироваться в
Out of log file space
temporarily
. Это условие будет преобладать, пока контрольная точка не
завершилтся, а хвост списка файла регистрации не будет продвинут вперед.
[DB]MaxNoOfSavedMessages
- Этот параметр устанавливает максимальное число файлов трассировки,
которые будут сохраняться перед перезаписью старых файлов трассировки. Файлы
трассировки сгенерированы, когда узел терпит крах по некоторым причинам.
Значение по умолчанию: 25 файлов трассировки.
Следующий набор параметров определяет размеры пула для объектов
метаданных. Необходимо определить максимальное число атрибутов, таблиц,
индексов и триггерные объекты, используемые индексами, событиями и
дублированием между кластерами.
[DB]MaxNoOfAttributes
- Этот параметр определяет число атрибутов, которые могут быть определены
в кластере. Значение по умолчанию для этого параметра: 1000. Минимальное
значение: 32, но не имеется никакого максимума. Каждый атрибут потребляет
около 200 байт памяти в каждом узле, потому что метаданные полностью
скопируются на серверы.
[DB]MaxNoOfTables
- Объект таблицы распределен для каждой таблицы, для каждого уникального
индекса и для каждого упорядоченного индекса. Этот параметр устанавливает
максимальное число объектов таблицы в кластере. Для каждого атрибута, который
имеет тип
BLOB
, используется дополнительная таблица, чтобы
сохранить большинство данных BLOB
. Эти таблицы также должны быть
приняты во внимание при определении числа таблиц. Значение по умолчанию для
этого параметра 128. Минимум 8, а максимум 1600. Каждый объект таблицы
потребляет примерно по 20KB в каждом узле.
[DB]MaxNoOfOrderedIndexes
- Для каждого упорядоченного индекса в кластере, будут распределены
объекты, чтобы описать то, что он индексирует и части памяти. По умолчанию
каждый определенный индекс будет иметь упорядоченный индекс. Уникальные
индексы и индексы первичных ключей имеют сразу упорядоченный индекс и
хэш-индекс, то есть им нужно по два объекта. Значение по умолчанию этого
параметра 128. Каждый объект потребляет примерно по 10KB данных на узел.
[DB]MaxNoOfUniqueHashIndexes
- Для каждого уникального индекса (не для первичных ключей) распределена
специальная таблица, которая отображает уникальный ключ на первичный ключ
индексированной таблицы. По умолчанию будет иметься упорядоченный индекс,
также определенный для каждого уникального индекса. Чтобы избежать этого, Вы
должны использовать опцию
USING HASH
на уникальном индексном
определении. Значение по умолчанию 64. Каждый индекс потребит около 15KB
памяти на узел.
[DB]MaxNoOfTriggers
- Для каждого уникального индекса распределяются триггеры, контролирующие
внутренние вставки, обновления и удаления. Таким образом, получается по три
триггера на уникальный индекс. Упорядоченные индексы используют только
единственный триггерный объект на индекс. Резервирование также требует по
три объекта для каждой нормальной таблицы в кластере. Когда между кластерами
обеспечивается репликация, это также использует внутренние триггеры. Этот
параметр устанавливает максимальное число триггерных объектов в кластере.
Значение по умолчанию этого параметра 768.
[DB]MaxNoOfIndexes
- Этот параметр устарел в MySQL 4.1.5. Теперь Вы должны использовать вместо
этого
MaxNoOfOrderedIndexes
и
MaxNoOfUniqueHashIndexes
. Этот параметр используется только
уникальными индексами. Должна иметься одна запись в этом пуле для каждого
уникального индекса, определенного в кластере. Значение по умолчанию для
этого параметра составляет 128.
Имеется набор булевых параметров, воздействующих на поведение узлов
памяти. Булевы параметры могут быть определены как истина, устанавливая их в
Y или 1, либо как ложь, устанавливая их в N или 0.
[DB]LockPagesInMainMemory
- Для ряда операционных систем типа Solaris и Linux возможно блокировать
процесс в памяти и избегать уймы проблем со свопом. Это важное свойство,
чтобы обеспечить характеристики работы кластера в реальном масштабе времени.
Значение по умолчанию: это выключено.
[DB]StopOnError
- Этот параметр заявляет, должен ли процесс завершиться с сообщением об
ошибке или выполнить автоматический рестарт. Значение по умолчанию: включено.
[DB]Diskless
- Во внутренних интерфейсах возможно установить таблицы как таблицы без
диска, означающие, что таблицы не сбрасываются на диск, и никакая регистрация
не происходит. Они существуют только в оперативной памяти. Таблицы (но не
записи в таблице!) будут существовать после аварийного отказа. Это свойство
делает весь кластер бездисковым, в этом случае даже таблицы не существуют
больше после аварийного отказа. Включение этого свойства может быть выполнено
установкой его в Y или в 1. Когда это свойство активно, копии будут
выполняться, но не будут сохранены, потому что формально не имеется никакого
диска. В будущих выпусках это, вероятно, будет делать копию без диска
отдельным параметром с перестраиваемой конфигурацией. Значение по умолчанию
для этого параметра: выключено.
[DB]RestartOnErrorInsert
- Это свойство доступно только при формировании отладочной версии, где
возможно вставить ошибки в выполнение различных частей кода, чтобы проверить
случаи сбоя. Значение по умолчанию: это свойство выключено.
Имеются несколько параметров, определяющие времена ожидания и интервалы
времени между различными действиями в узлах памяти. Большинство времен
ожидания определено в миллисекундах с несколькими исключительными ситуациями,
которые будут упомянуты ниже.
[DB]TimeBetweenWatchDogCheck
- Чтобы гарантировать, что основной поток не эастревает в вечном цикле
где-нибудь, имеется сторожевой поток, который проверяет основной поток. Этот
параметр заявляет число миллисекунд между проверками. После трех проверок,
все еще находящийся в том же самом состоянии процесс будет остановлен
процессом-сторожем. Этот параметр легко может быть изменен и отличен в узлах,
хотя имеются лишь немногие причины для такого различия. Заданное по умолчанию
время ожидания составляет 4000 миллисекунд (4 секунды).
[DB]StartPartialTimeout
- Этот параметр определяет время, которое кластер будет ждать запуска всех
узлов памяти прежде, чем запустить собственно кластерный алгоритм. Это
используется, чтобы избежать запуска только частичного кластера, если
возможно. Значение по умолчанию 30000 миллисекунд (30 секунд). 0 указывает
вечное время. Таким образом, кластер запустится только, если
все узлы доступны.
[DB]StartPartitionedTimeout
- Если кластер готов к пуску после ожидания
StartPartialTimeout
, но все еще возможно в разбитом на разделы
состоянии, он ждет, пока также и это время ожидания не выйдет. Заданное по
умолчанию время ожидания 60000 миллисекунд (60 секунд).
[DB]StartFailureTimeout
- Если старт не выполнен в рамках времени, определенного этим параметром,
попытка пуска узла будет терпеть неудачу. При установке этого параметра в 0
никакой таймаут не применяется, чтобы запустить кластер. Значение по
умолчанию: 60000 миллисекунд (60 секунд). Для узлов памяти, содержащих
большие наборы данных, этот параметр должен быть увеличен, поскольку может
требоваться по 10-15 минут, чтобы выполнить рестарт узла памяти с
несколькими гигабайтами данных.
[DB]HeartbeatIntervalDbDb
- Один из основных методов обнаружения неудачных узлов. Этот параметр
заявляет, как часто сигналы проверки будут посланы, и как часто ожидать их
получения. После отсутствия сигналов три интервала подряд узел будет объявлен
вышедшим из строя. Таким образом максимальное время обнаружения сбоя через
этот механизм составляет четыре интервала. Заданный по умолчанию интервал
1500 миллисекунд (1,5 секунды). Этот параметр почти никогда не должен быть
изменен на большую величину. Если один узел использует 5000 миллисекунд, а
другой узел, наблюдая это, использует 1000 миллисекунд, очевидно, что узел
будет объявлен сбойным очень быстро. Так что этот параметр может быть изменен
очень маленькими порциями в течение интерактивного программного обновления.
[DB]HeartbeatIntervalDbApi
- Подобным способом каждый узел памяти посылает сигналы каждому из
связанных серверов MySQL, чтобы гарантировать, что они ведут себя правильно.
Если сервер MySQL не посылает сигналов (тот же самый алгоритм, что касается
узла памяти) три интервала подряд, он считается сбойным, все продолжающиеся
транзакции будут завершены, все ресурсы будут освобождены, а сервер MySQL
не сможет повторно соединяться, пока завершение всех действий, начатых
предыдущим экземпляром MySQL, не будет завершено. Заданный по умолчанию
интервал 1500 миллисекунд. Этот интервал может быть отличен в узле памяти,
потому что каждый узел памяти независимо от всех других узлов памяти
наблюдает серверы MySQL, связанные с ним.
[DB]TimeBetweenLocalCheckpoints
- Этот параметр исключительная ситуация, в которой не устанавливает время,
чтобы ждать перед стартом новой локальной контрольной точки. Этот параметр
используется, чтобы гарантировать, что не выполняются локальные контрольные
точки в кластере, где происходит не так много модификаций. В большинстве
кластеров с высокими периодами обновления вероятно, что новая локальная
контрольная точка начата немедленно после завершения предыдущей. Размер всех
операций записи, выполненных начиная с начала предыдущих локальных
контрольных точек добавлен. Этот параметр определен как логарифм числа слов.
Так значение по умолчанию 20 означает 4MB операций записи, 21 задает 8MB и
и так далее вплоть до максимального значения, которое означает 8GB операций
записи. Все операции записи в кластере добавлены вместе. Установка этого в 6
или более низкое значение означает, что локальные контрольные точки
выполняются без паузы между ними, независимо от рабочей нагрузки в кластере.
[DB]TimeBetweenGlobalCheckpoints
- Когда транзакция совершена, это передано в оперативной памяти во всех
узлах, где существовали зеркала данных. Записи файла регистрации транзакции
не переданы на диск как часть совершающегося. Рассуждение здесь состоит в
том, что раз уж транзакция безопасно совершена, по крайней мере два
независимых компьютера должны хранить данные о ней. В то же самое время также
важно гарантировать, что даже самый плохой из случаев, когда кластер
полностью терпит крах, обработан правильно. Чтобы гарантировать это, все
транзакции в некотором интервале помещены в глобальную контрольную точку.
Глобальная контрольная точка очень похожа на групповое завершение транзакций.
Вся группа транзакций послана на диск сразу. Таким образом, как часть
совершающегося транзакция была помещена в глобальную группу контрольной
точки. Позже это сгруппирует записи файла регистрации для сброса на диск, а
затем вся группа транзакции безопасно совершена. Этот параметр заявляет
интервал между глобальными контрольными точками. Заданное по умолчанию время
паузы составляет 2000 миллисекунд.
[DB]TimeBetweenInactiveTransactionAbortCheck
- Обработка блокировки времени выполняется, проверяя каждый таймер на
каждой транзакции каждый период времени в соответствии с этим параметром.
Таким образом, если этот параметр установлен в 1000 миллисекунд, то каждая
транзакция будет проверена один раз в секунду. Значение по умолчанию для
этого параметра как раз и составляет 1000 миллисекунд.
[DB]TransactionInactiveTimeout
- Если транзакция в настоящее время не выполняет никаких запросов, но ждет
дальнейший ввод пользователя, этот параметр заявляет максимальное время,
которое можно ждать перед тем, как прервать транзакцию. Значение по умолчанию
для этого параметра отсутствует. Для базы данных в реальном масштабе времени,
никакая транзакция не хранит блокировки в течение длительного времени, так
что этот параметр должен быть установлен к намного меньшему значению.
[DB]TransactionDeadlockDetectionTimeout
- Когда транзакция включается в выполнение запроса, это ждет других узлов.
Если другие узлы не отвечают, это может зависеть от трех вещей. Первое (и
самое очевидное): узел сдох, второе: операция может ввести очередь
блокировок, а третье узел, необходимый, чтобы выполнить действие, может быть
просто конкретно перегружен. Этот параметр времени ожидания заявляет, как
долго координатор транзакций будет ждать, пока не прервет транзакцию при
ожидании выполнения запроса другим узлом. Таким образом, этот параметр важен
для обработки сбоя узла и для обнаружения тупика. Установка этого параметра
слишком высоким вызвала бы нежелательное поведение при сбоях узла и тупиках.
Заданное по умолчанию время составляет 1200 миллисекунд (1,2 секунды).
[DB]NoOfDiskPagesToDiskAfterRestartTUP
- При выполнении локальной контрольной точки алгоритм посылает все данные
страницы на диск в течение локальной контрольной точки. Увы, это частенько
приводит к нежелательным перегрузкам оборудования, а, следовательно, и
замедлению работы кластера в целом. Таким образом, чтобы управлять записью,
этот параметр определяет, сколько страниц за 100 миллисекунд должны быть
записаны. Страница здесь определена как 8KB. Единица, в которой этот параметр
определен, равна 80KB в секунду. Так установка этого в 20 означает запись
1,6MB данных страницы на диск в секунду в течение локальной контрольной
точки. Также сброс записей файла регистрации UNDO для данных страницы
является частью этой суммы. Запись страниц индексов и их записей файла
регистрации UNDO обработана параметром
NoOfDiskPagesToDiskAfterRestartACC
. Этот параметр обрабатывает
ограничение записей из DataMemory
. Этот параметр определяет, как
быстро локальные контрольные точки будут выполнены. Этот параметр важен в
связке с NoOfFragmentLogFiles
, DataMemory
и
IndexMemory
. Значение по умолчанию 40 (3,2MB данных страницы).
[DB]NoOfDiskPagesToDiskAfterRestartACC
- Этот параметр имеет те же самые величины измерения, что и
NoOfDiskPagesToDiskAfterRestartTUP
, но ограничивает
быстродействие записи страниц индексов из IndexMemory
. Значение
по умолчанию этого параметра: 20 (1,6MB в секунду).
[DB]NoOfDiskPagesToDiskDuringRestartTUP
- Этот параметр определяет те же самые вещи, что и
NoOfDiskPagesToDiskAfterRestartTUP
(и NoOfDiskPagesToDiskAfterRestartACC
), только это делается для
локальных контрольных точек, выполненных в узле как часть локальной
контрольной точки, когда узел перезапускается. Поскольку перезапускается
часть всех узлов, локальная контрольная точка всегда выполняется. С тех пор в
течение рестарта узла возможно использовать более высокое быстродействие
записи на диск, потому что меньшее количество действий выполняется в узле
из-за фазы рестарта. Этот параметр обрабатывает часть
DataMemory
. Значение по умолчанию 40 (3,2MB в секунду).
[DB]NoOfDiskPagesToDiskDuringRestartACC
- В течение рестарта для части
IndexMemory
локальной
контрольной точки задается быстродействие именно здесь. Значение по умолчанию
составляет 20 (1,6 MB в секунду).
[DB]ArbitrationTimeout
- Этот параметр определяет время, которое узел памяти будет ждать ответ
арбитратора при посылке сообщения арбитража в случае проблем в сети. Значение
по умолчанию 1000 миллисекунд.
Ряд новых параметров конфигурации представлен в MySQL 4.1.5. Они
соответствуют значениям, которые предварительно были параметрами времени
компиляции. Основная причина для этого состоит в том, чтобы дать возможность
продвинутому пользователю иметь большее управление размером процесса и
скорректировать различные буферные размеры согласно его потребностям.
Все эти буфера используются как внешние интерфейсы для файловой системы
при сохранении записей файла регистрации различных видов на диск. Если узел
выполняется в бездисковом режиме, эти параметры могут быть наиболее
определенно установленны к их минимальным значениям, потому что все записи на
диск в данном случае фальшивы.
[DB]UndoIndexBuffer
- Этот буфер используется в течении обработки локальных контрольных точек.
Движок
NDB
использует схему восстановления, основанную на
непротиворечивой контрольной точке вместе с операционным протоколом REDO.
Чтобы производить непротиворечивую контрольную точку без того, чтобы
блокировать всю систему для записи, регистрация UNDO сделана при выполнении
локальной контрольной точки. Регистрация UNDO активизирована одновременно
только на одном фрагменте одной таблицы. Эта оптимизация возможна, потому что
таблицы полностью сохранены в оперативной памяти. Этот буфер используется для
модификаций на первичном индексе ключа. Вставки и удаления реорганизуют
индекс и записи файла регистрации UNDO, которые отображают все физические
изменения для страницы индексов так, что они могут быть уничтожены при
рестарте системы. Это также регистрирует все активные операции вставки в
начале локальной контрольной точки для фрагмента. Чтения и обновления только
устанавливают бит блокировки и меняют заголовок в элементе указателя. Эти
изменения обработаны алгоритмом записи страницы, чтобы гарантировать, что эти
операции не нуждаются ни в какой регистрации UNDO. Этот буфер по умолчанию
2MB. Минимальное значение 1MB. Для большинства прикладных программ это
достаточно хорошо. Прикладные программы, делающие чрезвычайно тяжелые вставки
и удаления вместе с большими транзакциями, использующими большие первичные
ключи, должны расширить этот буфер. Если этот буфер слишком маленький, движок
NDB
выдает внутренний код ошибки 677, который будет
транслироваться в "Index UNDO buffers overloaded".
[DB]UndoDataBuffer
- Этот буфер имеет точно ту же самую роль, что и
UndoIndexBuffer
, но используется для части данных. Этот буфер
используется в течение локальной контрольной точки фрагмента, его задействуют
вставки, модификации и удаления. Так как эти записи файла регистрации UNDO
имеют тенденцию быть большими, и большее количество вещей регистрируется,
буфер также больший по умолчанию. Это установлено в 16MB. Для некоторых
прикладных программ это слишком много, и они могли бы уменьшать этот размер,
минимальный размер 1MB. Редко но бывает, что прикладные программы должны
увеличить этот буферный размер. Если имеется потребность в этом, стоит
проверить, могут ли диски фактически обрабатывать загрузку, которую вызывает
действие модификации в базе данных. Если они этого не могут, никакой размер
этого буфера не будет достаточно большим. Если этот буфер слишком маленький и
становится переполненным, NDB
выдает внутренний код ошибки 891,
который будет транслироваться в "Data UNDO buffers overloaded".
[DB]RedoBuffer
- Все действия модификации также должны регистрироваться. Это допускает
повтор этих модификаций при рестарте системы. Алгоритм восстановления
использует непротиворечивую контрольную точку, произведенную "размытой"
контрольной точкой данных вместе с UNDO-регистрацией страниц. Затем это
применяет REDO-журнал, чтобы воспроизвести все изменения вплоть до времени,
когда был выполнен рестарт системы. Этот буфер по умолчанию 8MB. Минимальное
значение 1MB. Если этот буфер слишком маленький,
NDB
выдает
внутренний код ошибки 1221, который будет транслироваться в "REDO
log buffers overloaded".
Для управления кластером, важно управлять количеством сообщений файла
регистрации, посланных на stdout, для различных типов событий. Возможные
события будут перечислены в этом руководстве скоро. Имеются 16 уровней (от 0
до 15). Здесь 0 предписывает игнорировать категорию вообще, а 15 указывает
выводить абсолютно все события из этой категории.
Причина, почему большинство значений по умолчанию установлено в 0 и таким
образом не порождают никакого вывода на stdout в том, что то же самое
сообщение послано входу сервера управления кластера. Только сообщение запуска
по умолчанию сгенерировано на stdout.
Подобный набор уровней может быть установлен в клиенте управления, чтобы
определить то, какие уровни записывать в протоколе работы кластера.
[DB]LogLevelStartup
- События, сгенерированные в течение процесса запуска. Заданный
по умолчанию уровень 1.
[DB]LogLevelShutdown
- События, сгенерированные как часть нормального завершения системы узла.
Заданный по умолчанию уровень 0.
[DB]LogLevelStatistic
- Статистические события типа того, сколько первичных ключей читается,
модифицируется, вставляется и много другой статистической информации по
применению буферов. Заданный по умолчанию уровень информативности 0.
[DB]LogLevelCheckpoint
- События, сгенерированные локальными и глобальными контрольными точками.
Заданный по умолчанию уровень 0.
[DB]LogLevelNodeRestart
- События, сгенерированные в течение рестарта узла. Заданный
по умолчанию уровень 0.
[DB]LogLevelConnection
- События, сгенерированные подключениями между узлами в кластере. Заданный
по умолчанию уровень 0.
[DB]LogLevelError
- События, сгенерированные ошибками и предупреждениями в кластере. Это
ошибки, не вызывающие сбой узла, но все еще рассматриваемые, как стоящие
сообщения о них. Заданный по умолчанию уровень 0.
[DB]LogLevelInfo
- События, сгенерированные для информации относительно состояния кластера и
т. д. Заданный по умолчанию уровень 0.
Имеется набор параметров, определяющих буфера памяти, которые отложены для
интерактивного резервного копирования.
[DB]BackupDataBufferSize
- При выполнении копии имеются два буфера, используемые для посылки данных
на диск. Этот буфер используется в записи данных, выполненном сканированием
таблиц узла. При заполнении этого буфера до некоторого уровня, страницы
посланы на диск. Этот уровень определен параметром
BackupWriteSize
. При посылке данных на диск, копия может
продолжать заполнять этот буфер, пока не вылезет за его пределы. При
исчерпании пространства буфера, система просто остановит просмотр и будет
ждать, пока некоторые записи на диск не завершатся и таким образом не
освободят буфера памяти, чтобы использовать их для дальнейшего просмотра.
Значение по умолчанию 2MB.
[DB]BackupLogBufferSize
- Этот параметр имеет подобную роль, но используется для записи протокола
всех записей в таблицы в течение выполнения копии. Те же самые принципы
применяются для записи страниц, что и в
BackupDataBufferSize
за
исключением того, что, когда эта часть вылезет за пределы буфера, это
заставляет копию прерваться из-за недостатка резервных буферов. Таким
образом, размер этого буфера должен быть достаточно большим, чтобы обработать
нагрузку, вызванную действиями записи в течение резервного копирования.
Заданный по умолчанию размер должен быть достаточно большим. Фактически более
вероятно, что сбой резервирования вызван диском, не способным записывать так
быстро, как это хотелось бы. Если дисковая подсистема недостаточно быстрая
для нагрузки записи, вызванной прикладными программами, это создаст кластер,
который будет иметь большие трудности, чтобы выполнить желательные действия.
Значение по умолчанию 2MB.
[DB]BackupMemory
- Этот параметр просто сумма из двух предыдущих,
BackupDataBufferSize
и BackupLogBufferSize
.
Значение по умолчанию 4MB.
[DB]BackupWriteSize
- Этот параметр определяет размер сообщений, записываемых на диск для файла
регистрации, и буфера данных, используемого для копий. Значение, заданное по
умолчанию, составляет 32KB.
3.4.6 Определение серверов MySQL в MySQL Cluster
Раздел [API]
(или, что то же самое, [MYSQLD]
)
определяет поведение сервера MySQL. Параметры необязательны. Если никакое имя
не обеспечивается, то любой компьютер может использовать API этого узла.
[API]Id
- Это ID узла, используемый как адрес узла во всем кластере. Это целое
число между 1 и 63. Каждый узел в кластере должен иметь уникальный ID.
[API]ExecuteOnComputer
- Это ссылка на один из компьютеров, определенных в разделе computer.
[API]ArbitrationRank
- Этот параметр используется, чтобы определить, которые узлы могут
действовать как арбитраторы. MGM-узлы и узлы API могут быть арбитраторами. 0
указывает, что этот не используется как арбитратор, 1 задает высокий
приоритет, а 2 определяет низкий приоритет узла. Нормальная конфигурация
использует сервер управления как арбитратор, устанавливая ArbitrationRank в
1 (значение по умолчанию) и устанавливая все API в 0.
[API]ArbitrationDelay
- При установке этого к чему-нибудь, кроме 0 это означает, что сервер
управления задержит ответы на запросы арбитража. Значение по умолчанию:
отсутствие задержек, и нет особой надобности это менять.
[API]BatchByteSize
- Для запросов, которые просматривают всю таблицу или диапазон на индексах,
это важно для самой лучшей эффективности, чтобы выбрать записи в правильно
установленных по размеру пакетах. Возможно установить соответствующий размер
в терминах числа записей или в терминах байтов. Реальный пакетный размер
будет ограничен обоими параметрами. Эффективность запросов может измениться
больше, чем на 40% из-за того, как этот параметр установлен. В будущих
выпусках MySQL сервер будет делать обучаемые предположения о том, как
установить эти параметры, основываясь на типе запроса. Этот параметр
измеряется в байтах и по умолчанию равен 32KB.
[API]BatchSize
- Этот параметр измеряется в числе записей и по умолчанию установлен в
Максимальный размер составляет 992.
[API]MaxScanBatchSize
- Пакетный размер представляет собой размер каждого пакета, посланного из
каждого узла памяти. Больше всего просмотров выполняются в параллельном
режиме, по причине чего необходимо защитить сервер MySQL от получения слишком
большого количества данных из многих узлов в параллельном режиме. Этот
параметр устанавливает ограничение общего пакетного размера всем узлам.
Значение по умолчанию этого параметра установлено в 256KB. Максимальный
размер составляет 16MB.
3.4.7 TCP/IP-соединения в MySQL Cluster
TCP/IP представляет собой заданный по умолчанию транспортный механизм для
установления подключений в кластере MySQL. Фактически нет надобности
определять любое подключение, потому что будет иметься одно подключение между
каждым из узлов памяти, каждым из узлов памяти и всеми серверами MySQL, а
каждым из узлов памяти и сервером управления.
Нужно определить подключение только, если необходимо изменить значения по
умолчанию для подключения. В этом случае необходимо определить по крайней
мере NodeId1
, NodeId2
и изменяемые параметры.
Также возможно изменить значения по умолчанию, устанавливая параметры в
разделе [TCP DEFAULT]
.
[TCP]NodeId1
-
[TCP]NodeId2
- Чтобы идентифицировать подключение между двумя узлами, необходимо
обеспечить идентификатор узла для обоих из них в
NodeId1
и в NodeId2
.
[TCP]SendBufferMemory
- TCP-транспорт использует буферизацию всех сообщений перед выполнением
посылающего обращения к операционной системе. Когда этот буфер достигает
64KB, он будет послан. Система пошлет его также, если выполняется кольцо
сообщений. Чтобы обрабатывать временные ситуации перегрузки, также возможно
определить больший буфер. Заданный по умолчанию размер буфера 256KB.
[TCP]SendSignalId
- Чтобы отследить диаграмму распространения сообщений, надо
идентифицировать каждое сообщение. Устанавливая этот параметр Y, Вы
указываете, что идентификатор отправителя сообщения также транспортируется
через сеть. Это свойство не допускается по умолчанию.
[TCP]Checksum
- Этот параметр также Y/N, который не допускается по умолчанию. Когда он
включен все сообщения проверены контрольным суммированием прежде, чем
помещены в посылающий буфер. Это свойство позволяет контролировать, что
сообщения не разрушены при ожидании в посылающем буфере. Это также двойная
проверка того, что транспортный механизм не разрушил данные.
[TCP]PortNumber
- Это номер порта, чтобы использовать для слушания подключений из других
узлов. Этот номер порта обычно должен быть определен в разделе
[TCP DEFAULT]
. Этот параметр больше не должен использоваться.
Используйте параметр на узлах памяти вместо этого.
[TCP]ReceiveBufferMemory
- Этот параметр определяет размер буфера, используемого при получении
данных из сокета TCP/IP. Редко возникает потребность изменить этот параметр.
Значение по умолчанию 64KB.
3.4.8 Подключения с общедоступной памятью в MySQL Cluster
Общедоступные сегменты памяти в настоящее время обеспечиваются только для
специальных версий MySQL Cluster, собранных с применением параметра
--with-ndb-shm
скрипта configure
. Реализация
наиболее вероятно изменится. При определении общедоступной памяти как метода
подключения, необходимо определить по крайней мере NodeId1
,
NodeId2
и ShmKey
. Все другие параметры имеют
значения по умолчанию, которые будут прекрасно
работать в большинстве случаев.
[SHM]NodeId1
[SHM]NodeId2
- Это определяет идентификаторы узлов
NodeId1
и
NodeId2
, между которыми создается соединение.
[SHM]ShmKey
- При установке общедоступных сегментов памяти используется идентификатор,
чтобы уникально идентифицировать общедоступный сегмент памяти для связи.
Это целое число, которое не имеет значения по умолчанию.
[SHM]ShmSize
- Каждое подключение имеет общедоступный сегмент памяти, где сообщения
между узлами откладываются отправителем и читаются получателем. Сегмент имеет
размер, определенный этим параметром. Значение по умолчанию 1MB.
[SHM]SendSignalId
- Передавать в сообщении идентификатор отправителя. По умолчанию выключено.
[SHM]Checksum
- Аналог
[TCP]Checksum
, но для подключений с общей памятью.
3.4.9 Транспортные подключения SCI в MySQL Cluster
SCI-транспорт между узлами в кластере MySQL поддерживается только для
специальных версий, собранных с параметром
--with-ndb-sci=/your/path/to/SCI
скрипта configure
.
Путь должен указать на каталог, который содержит по крайней мере каталоги lib
и include, где дислоцируются библиотека SISCI и файлы заголовков.
Настоятельно рекомендуется использовать только SCI для связи между
процессами ndbd. Также использование SCI будет означать, что процесс ndbd
никогда не будет бездействовать, поскольку применение SCI разумно только для
машин с по крайней мере 2 CPU, которые выделены для использования процессом
ndbd. Должен иметься по крайней мере 1 CPU на процесс ndbd в этом случае и по
крайней мере еще один необходим, чтобы также обработать действия OS.
[SCI]NodeId1
-
[SCI]NodeId2
- Идентификаторы узлов
NodeId1
и NodeId2
, между
которыми устанавливается связь.
[SCI]Host1SciId0
- Это определяет SCI-идентификатор узла на первом узле (NodeId1).
[SCI]Host1SciId1
- Это позволяет определить SCI-транспорт между парой SCI-карт, которые
затем должны использовать отдельные сети между узлами. Это определяет
идентификатор узла и второй SCI-карты, которую нужно использовать
на первом узле.
[SCI]Host2SciId0
- Это определяет SCI-идентификатор узла на втором узле (NodeId2).
[SCI]Host2SciId1
- Аналогично
[SCI]Host1SciId1
, но для второго узла.
[SCI]SharedBufferSize
- Каждый SCI-транспорт имеет общедоступный сегмент памяти между двумя
узлами. Обычно его размер составляет 1MB, что устраивает основную массу
прикладных программ. Меньшие размеры (типа 256kB) имеют проблемы при
выполнении многих параллельных вставок. Если буфер слишком маленький, это
может вызвать сбои процесса ndbd.
[SCI]SendLimit
- Маленький буфер перед SCI буферизует сообщения перед посылкой их в
SCI-сеть. По умолчанию это установлено 8kB. Большинство эталонных тестов
показывают, что лучше всего 64 kB, но 16kB лишь на несколько процентов хуже.
Для всех эталонных тестов кластера MySQL, не было отмечено никакого
измеримого различия в увеличении этого параметра выше 8kB.
[SCI]SendSignalId
- Если выставлено в Y, то в передаваемые по сети данные помещается метка их
отправителя. По умолчанию выключено.
[SCI]Checksum
- Аналог
[TCP]Checksum
, но для подключений через SCI.