| |
Сервер MySQL, который является частью кластера, отличается от обычного
только одним: он использует тип хранения NDBCLUSTER
. Этот тип
хранения также упоминается просто как NDB
, и эти две формы
имени являются синонимами.
Чтобы избегать ненужного распределения ресурсов, сервер конфигурирован по
умолчанию с заблокированным NDB
. Чтобы его включить, Вы должны
будете изменить файл конфигурации сервера my.cnf.
Так как сервер MySQL является частью кластера, также надо знать, как
обратиться к MGM-узлу, чтобы получить данные конфигурации кластера. Заданное
по умолчанию поведение: искать MGM-узел на localhost
. Однако,
если надо определить расположение в другом месте, это может быть выполнено в
my.cnf или в командной строке сервера MySQL. Прежде, чем
NDB
сможет использоваться, по крайней мере один MGM-узел должен
быть запущен, также как любые желательные DB-узлы.
NDB
доступен в двоичных дистрибутивах, начиная с MySQL-Max
4.1.3 для Linux, Mac OS X и Solaris. Это еще не поддерживается под Windows,
но предполагается сделать это доступным для платформы
win32 в ближайшем будущем.
Если Вы выбираете сборку из исходных текстов или дерева разработки 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 без кластеризации.
Чтобы ознакомить Вас с основами, опишем самую простую возможную конфигурацию для функционального кластера. После этого Вы должны быть способны разработать Вашу желательную конфигурацию, исходя из информации, обеспеченной в других релевантных разделах этой главы.
Сначала Вы должны создать каталог конфигураций, например,
/var/lib/mysql-cluster, выполняя следующую
команду как root
:
shell> mkdir /var/lib/mysql-cluster
В этом каталоге, создайте файл config.ini со следующей
информацией, заменяя соответствующими значениями параметры
HostName
и DataDir
по мере необходимости
для Вашей системы.
# file config.ini - showing minimal setup consisting of 1 DB node, # 1 management server, and 3 MySQL servers. # The empty default sections are not required, and are shown only for # the sake of completeness. # Storage nodes are required to provide a hostname but MySQL Servers # are not. # If you don't know the hostname for your machine, use localhost. # The DataDir parameter also has a default value, but it is recommended to # set it explicitly. # NDBD, MYSQLD, and NDB_MGMD are aliases for DB, API, and MGM respectively # [NDBD DEFAULT] NoOfReplicas= 1 [MYSQLD DEFAULT] [NDB_MGMD DEFAULT] [TCP DEFAULT] [NDB_MGMD] HostName= myhost.example.com [NDBD] HostName= myhost.example.com DataDir= /var/lib/mysql-cluster [MYSQLD] [MYSQLD] [MYSQLD]
Вы можете теперь запустить сервер управления следующим образом:
shell> cd /var/lib/mysql-cluster shell> ndb_mgmd
Затем запустите один DB-узел, выполняя ndbd
. При старте
ndbd
для данного DB-узла в самый первый раз, Вы должны
использовать опцию --initial
:
shell> ndbd --initial
Для последующих стартов ndbd
Вы уже не будете вообще
использовать опцию --initial
:
shell> ndbd
Это потому, что опция --initial
удалит все существующие
данные и журналы (также как и все метаданные таблицы) для этого узла
памяти и создаст новые.
По умолчанию ndbd
будет искать сервер управления в
localhost
на порте 1186 (до MySQL версии 4.1.8 заданный по
умолчанию порт был 2200).
Обратите внимание: если Вы установили MySQL из двоичного
жистрибутива, Вы должны будете определить путь к серверам
ndb_mgmd
и ndbd
явно. Обычно они будут найдены в
/usr/local/mysql/bin.
В заключение перейдите в каталог баз данных (обычно
/var/lib/mysql или /usr/local/mysql/data) и удостоверьтесь,
что файл my.cnf содержит опцию запуска NDB
:
[mysqld] ndbcluster
Вы можете теперь запустить сервер MySQL обычным порядком:
shell> mysqld_safe --user=mysql &
Подождите немного, чтобы удостовериться, что сервер MySQL выполняется
правильно. Если Вы видите сообщение mysql ended
, проверьте файл
.err сервера, чтобы выяснить то, что пошло неправильно. Если все
пока хорошо, Вы можете теперь запустить кластер:
shell> mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 to server version: 4.1.7 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> SHOW ENGINES; +------------+---------+-----------------------------------------------+ | Engine | Support | Comment | +------------+---------+-----------------------------------------------+ ... | NDBCLUSTER | DEFAULT | Clustered, fault-tolerant, memory-based tables| | NDB | YES | Alias for NDBCLUSTER | ... mysql> USE test; Database changed mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER; Query OK, 0 rows affected (0.09 sec) mysql> SHOW CREATE TABLE ctest \G *************************** 1. row *************************** Table: ctest Create Table: CREATE TABLE `ctest` ( `i` int(11) default NULL ) ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.00 sec)
Чтобы проверить, что Ваши узлы были установлены правильно, запустите клиент управления как показано:
shell> ndb_mgm
Вы можете затем использовать команду SHOW
из клиента
управления, чтобы получить отчет о состоянии кластера:
NDB> SHOW Cluster Configuration --------------------- [ndbd(NDB)] 1 node(s) id=2 @127.0.0.1 (Version: 3.5.3, Nodegroup: 0, Master) [ndb_mgmd(MGM)] 1 node(s) id=1 @127.0.0.1 (Version: 3.5.3) [mysqld(API)] 3 node(s) id=3 @127.0.0.1 (Version: 3.5.3) id=4 (not connected, accepting connect from any host) id=5 (not connected, accepting connect from any host)
Что ж, Вы успешно установили работающий кластер MySQL. Вы можете теперь
сохранять данные в кластере, используя любую таблицу, созданную с
ENGINE=NDBCLUSTER
или псевдонимом ENGINE=NDB
.
Конфигурирование кластера MySQL требует работы с двумя файлами:
Разработчики пакета непрерывно делают усовершенствования конфигурации кластера и пытаются упрощать этот процесс. Несмотря на то, что они стараются поддерживать совместимость в обратном направлении, могут иметься моменты, когда появляется несовместимое изменение. В таких случаях пользователям предоставляется информация о проблеме, если изменение не совместимо в обратном направлении. Если Вы находите такое изменение, которое не зарегистрировано, пожалуйста, используйте базу данных ошибок (http://bugs.mysql.com), чтобы сообщить авторам об этом.
Чтобы поддерживать кластер MySQL, Вы должны будете модифицировать файл my.cnf как показано в примере ниже.
Начиная с версии 4.1.8 в my.cnf были сделаны некоторые упрощения,
включая новые разделы для выполнимых программ ndbcluster
.
Однако, они не должны быть спутаны с встречающимися в файле
config.ini. Как всегда Вы можете определять эти параметры при вызове
тех выполнимых программ из командной строки.
# my.cnf # example additions to my.cnf for MySQL Cluster # (valid from 4.1.8) # enable ndbcluster storage engine, and provide connectstring for # management server host (default port is 1186) [mysqld] ndbcluster ndb-connectstring=ndb_mgmd.mysql.com # provide connectstring for management server host (default port: 1186) [ndbd] connect-string=ndb_mgmd.mysql.com # provide connectstring for management server host (default port: 1186) [ndb_mgm] connect-string=ndb_mgmd.mysql.com # provide location of cluster configuration file [ndb_mgmd] config-file=/etc/config.ini
Для получения подробной информации относительно connectstrings обратитесь
к разделу 3.4.2 MySQL Cluster connectstring
.
# my.cnf # example additions to my.cnf for MySQL Cluster # (will work on all versions) # enable ndbcluster storage engine, and provide connectstring # for management server host to the default port 2200 [mysqld] ndbcluster ndb-connectstring=ndb_mgmd.mysql.com:2200
Также для версии MySQL 4.1.8 и выше файл my.cnf поддерживает
отдельный раздел [mysql_cluster]
для параметров настройки,
которые нужно читать при воздействии на все выполнимые программы в кластере:
# cluster-specific settings [mysql_cluster] ndb-connectstring=ndb_mgmd.mysql.com:2200
В настоящее время файл конфигурации находится в формате 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, показывается ниже:
# file "config.ini" - 2 DB nodes and 2 mysqld # This file is placed in the startup directory of ndb_mgmd, # i.e., the management server. # The first MySQL Server can be started from any host and the second # can only be started at the host mysqld_5.mysql.com # NDBD, MYSQLD, and NDB_MGMD are aliases for DB, API, and MGM respectively [NDBD DEFAULT] NoOfReplicas=2 DataDir=/var/lib/mysql-cluster [NDB_MGMD] Hostname=ndb_mgmd.mysql.com DataDir=/var/lib/mysql-cluster [NDBD] HostName=ndbd_2.mysql.com [NDBD] HostName=ndbd_3.mysql.com [MYSQLD] HostName=mysqld_5.mysql.com
Имеется шесть различных разделов в этом файле конфигурации:
[COMPUTER]
: определяет компьютеры в кластере.
[DB|NDBD]
: определяет узлы памяти в кластере.
[API|MYSQLD]
: пределяет узлы серверов MySQL в кластере.
[MGM|NDB_MGMD]
: определяет узлы серверов управления.
[TCP]
: определяет TCP/IP подключения между узлами в кластере
с TCP/IP, являющимся заданным по умолчанию протоколом подключения.
[SHM]
: определяет подключения с общедоступной памятью между
узлами. Этот тип подключения доступен только в двоичных модулях, которые были
сформированы с опцией --with-ndb-shm
.Обратите внимание, что каждый узел имеет собственный раздел в
config.ini. Например, так как этот кластер имеет два узла памяти,
файл конфигурации содержит два раздела, определяющие эти узлы. В примере выше
эти разделы помечены [NDBD]
, но любой из них (или оба) могли бы
быть помечены как [DB]
.
Можно определять значения DEFAULT
для каждого раздела.
Начиная с MySQL 4.1.5, все имена параметров нечувствительны к регистру.
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:
connectstring
, который нужно использовать всем узлам в кластере,
помещая это в разделе [mysql-cluster]
в файле
my.cnf сервера управления.
NDB_CONNECTSTRING
в connectstring.
connectstring
для каждой программы в текстовый
файл Ndb.cfg и поместите этот файл в стартовый каталог программы.
Рекомендуемый метод для определения connectstring
состоит в
том, чтобы установить это в командной строке или в файле my.cnf для
каждой выполнимой программы.
Раздел [COMPUTER]
не имеет никакого реального значения,
кроме как способ избежать определения имен для каждого узла в системе. Все
параметры, упомянутые здесь, являются обязательными.
[COMPUTER]Id
[COMPUTER]HostName
Раздел [MGM]
(или его псевдоним [NDB_MGMD]
)
используется, чтобы конфигурировать поведение сервера управления. Хотя бы
один из параметров ExecuteOnComputer
или HostName
должен присутствовать. Все другие параметры могут быть опущены и, если это
так, примут значения по умолчанию.
[MGM]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
0
: этот узел никогда не будет
использоваться как арбитратор.
1
: узел имеет высокий приоритет, то есть он будет
предпочтен как арбитратор над низкоприоритетными узлами.
2
: указывает низкоприоритетный узел, который будет
использоваться как арбитратор только, если узел с более высоким приоритетом
недоступен для этой цели.ArbitrationRank
в 1 (значение по умолчанию) и
ArbitrationRank
в 0 на всех API и серверных узлах.
[MGM]ArbitrationDelay
[MGM]DataDir
FILE
для [MGM]LogDestination
).Раздел [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
[DB]ExecuteOnComputer
[DB]HostName
ExecuteOnComputer
требуется в обязательном порядке.
[DB]ServerPort
[DB]NoOfReplicas
[DB DEFAULT]
, потому что это глобальный параметр. Это определяет
число точных копий для каждой таблицы, сохраненной в кластере. Этот параметр
также определяет размер групп узлов. Группа представляет собой набор узлов,
хранящих ту же самую информацию. Группы сформированы неявно. Первая группа
сформирована узлами памяти с самыми низкими идентификаторами узла. Далее
берутся более высокие идентификаторы и так далее. Например, предположите, что
мы имеем 4 узла памяти, и NoOfReplicas
установлен в 2. Четыре
узла памяти имеют ID узла 2, 3, 4 и 5. Затем первая группа будет сформирована
узлами 2 и 3. Вторая группа узлов будет сформирована узлами 4 и 5. Важно
конфигурировать кластер таким способом, что узлы в тех же самых группах не
помещены в тот же самый компьютер. Это вызвало бы одиночный HW-сбой, который
может вызвать аварийный отказ кластера. Если никакие идентификаторы узлов не
обеспечиваются, порядок узлов памяти будет фактором определения группы узла.
Фактическая группа узла будет напечатана командой SHOW
в клиенте
управления. Не имеется никакого значения по умолчанию, максимальный номер 4.
[DB]DataDir
[DB]FileSystemPath
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
[DB]MaxNoOfConcurrentOperations
MaxNoOfConcurrentOperations
будет всегда использоваться, чтобы
вычислить число записей операции в части координатора транзакции узла. Также
важно иметь представление относительно требований памяти для тех записей
операции. В MySQL 4.1.5 записи операции потребляют около 1KB на запись. Это
планируется уменьшить в версиях 5.x.
[DB]MaxNoOfLocalOperations
MaxNoOfConcurrentOperations
, который удовлетворяет системы
с большим числом одновременных, не очень больших транзакций. Если
конфигурация должна обработать очень большие транзакции одновременно, и
имеется много узлов, стоит конфигурировать это отдельно.Следующий набор параметров используется для временной памяти посреди выполнения части запроса в кластере. Все эти записи будут освобождены, когда часть запроса завершена и идет ожидание подтверждения или отмены запроса.
Большинство значений по умолчанию для этих параметров будут нормальны для большинства пользователей. Некоторые высококачественные пользователи могут увеличивать их, чтобы добавить параллелизма в системе, а некоторые пользователи могут уменьшать их, чтобы сэкономить память.
[DB]MaxNoOfConcurrentIndexOperations
MaxNoOfConcurrentOperations
.
Значение по умолчанию для этого параметра: 8192. Только в редких случаях
чрезвычайно высокого параллелизма, использующего уникальные индексы, этот
параметр необходимо увеличить. Уменьшение сэкономит память, но делать это
можно только, если Вы уверены, что такой высокий параллелизм
не встречается в кластере.
[DB]MaxNoOfFiredTriggers
MaxNoOfFiredTriggers
равно 4000.
Обычно это значение должно быть достаточно для большинства систем. В
некоторых случаях это стоит уменьшить, если Вы чувствуете, что параллелизм в
кластере не так уж и высок. Эта запись используется, когда операция
выполняется, что воздействует на уникальный индекс. Модифицирование столбца,
который является частью уникального индекса или вставки/удаления записи в
таблице с уникальными индексами будет работать со вставками и удалениями
в индексной таблице. Эта запись используется, чтобы представить эту индексную
операцию таблицы, в то время как идет ожидание для первоначальной операции.
Таким образом, эта запись требуется ненадолго, но может занимать немало
места для временных ситуаций с многими параллельными операциями записи на
основной рабочей таблице, содержащей набор уникальных индексов.
[DB]TransactionBufferMemory
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
ScanBatchSize
, определенным в узлах API.
[DB]LongMessageBuffer
[DB]NoOfFragmentLogFiles
Out of log file space
temporarily
. Это условие будет преобладать, пока контрольная точка не
завершилтся, а хвост списка файла регистрации не будет продвинут вперед.
[DB]MaxNoOfSavedMessages
Следующий набор параметров определяет размеры пула для объектов метаданных. Необходимо определить максимальное число атрибутов, таблиц, индексов и триггерные объекты, используемые индексами, событиями и дублированием между кластерами.
[DB]MaxNoOfAttributes
[DB]MaxNoOfTables
BLOB
, используется дополнительная таблица, чтобы
сохранить большинство данных BLOB
. Эти таблицы также должны быть
приняты во внимание при определении числа таблиц. Значение по умолчанию для
этого параметра 128. Минимум 8, а максимум 1600. Каждый объект таблицы
потребляет примерно по 20KB в каждом узле.
[DB]MaxNoOfOrderedIndexes
[DB]MaxNoOfUniqueHashIndexes
USING HASH
на уникальном индексном
определении. Значение по умолчанию 64. Каждый индекс потребит около 15KB
памяти на узел.
[DB]MaxNoOfTriggers
[DB]MaxNoOfIndexes
MaxNoOfOrderedIndexes
и
MaxNoOfUniqueHashIndexes
. Этот параметр используется только
уникальными индексами. Должна иметься одна запись в этом пуле для каждого
уникального индекса, определенного в кластере. Значение по умолчанию для
этого параметра составляет 128.Имеется набор булевых параметров, воздействующих на поведение узлов памяти. Булевы параметры могут быть определены как истина, устанавливая их в Y или 1, либо как ложь, устанавливая их в N или 0.
[DB]LockPagesInMainMemory
[DB]StopOnError
[DB]Diskless
[DB]RestartOnErrorInsert
Имеются несколько параметров, определяющие времена ожидания и интервалы времени между различными действиями в узлах памяти. Большинство времен ожидания определено в миллисекундах с несколькими исключительными ситуациями, которые будут упомянуты ниже.
[DB]TimeBetweenWatchDogCheck
[DB]StartPartialTimeout
[DB]StartPartitionedTimeout
StartPartialTimeout
, но все еще возможно в разбитом на разделы
состоянии, он ждет, пока также и это время ожидания не выйдет. Заданное по
умолчанию время ожидания 60000 миллисекунд (60 секунд).
[DB]StartFailureTimeout
[DB]HeartbeatIntervalDbDb
[DB]HeartbeatIntervalDbApi
[DB]TimeBetweenLocalCheckpoints
[DB]TimeBetweenGlobalCheckpoints
[DB]TimeBetweenInactiveTransactionAbortCheck
[DB]TransactionInactiveTimeout
[DB]TransactionDeadlockDetectionTimeout
[DB]NoOfDiskPagesToDiskAfterRestartTUP
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
Ряд новых параметров конфигурации представлен в 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
NDB
выдает
внутренний код ошибки 1221, который будет транслироваться в "REDO
log buffers overloaded".Для управления кластером, важно управлять количеством сообщений файла регистрации, посланных на stdout, для различных типов событий. Возможные события будут перечислены в этом руководстве скоро. Имеются 16 уровней (от 0 до 15). Здесь 0 предписывает игнорировать категорию вообще, а 15 указывает выводить абсолютно все события из этой категории.
Причина, почему большинство значений по умолчанию установлено в 0 и таким образом не порождают никакого вывода на stdout в том, что то же самое сообщение послано входу сервера управления кластера. Только сообщение запуска по умолчанию сгенерировано на stdout.
Подобный набор уровней может быть установлен в клиенте управления, чтобы определить то, какие уровни записывать в протоколе работы кластера.
[DB]LogLevelStartup
[DB]LogLevelShutdown
[DB]LogLevelStatistic
[DB]LogLevelCheckpoint
[DB]LogLevelNodeRestart
[DB]LogLevelConnection
[DB]LogLevelError
[DB]LogLevelInfo
Имеется набор параметров, определяющих буфера памяти, которые отложены для интерактивного резервного копирования.
[DB]BackupDataBufferSize
BackupWriteSize
. При посылке данных на диск, копия может
продолжать заполнять этот буфер, пока не вылезет за его пределы. При
исчерпании пространства буфера, система просто остановит просмотр и будет
ждать, пока некоторые записи на диск не завершатся и таким образом не
освободят буфера памяти, чтобы использовать их для дальнейшего просмотра.
Значение по умолчанию 2MB.
[DB]BackupLogBufferSize
BackupDataBufferSize
за
исключением того, что, когда эта часть вылезет за пределы буфера, это
заставляет копию прерваться из-за недостатка резервных буферов. Таким
образом, размер этого буфера должен быть достаточно большим, чтобы обработать
нагрузку, вызванную действиями записи в течение резервного копирования.
Заданный по умолчанию размер должен быть достаточно большим. Фактически более
вероятно, что сбой резервирования вызван диском, не способным записывать так
быстро, как это хотелось бы. Если дисковая подсистема недостаточно быстрая
для нагрузки записи, вызванной прикладными программами, это создаст кластер,
который будет иметь большие трудности, чтобы выполнить желательные действия.
Значение по умолчанию 2MB.
[DB]BackupMemory
BackupDataBufferSize
и BackupLogBufferSize
.
Значение по умолчанию 4MB.
[DB]BackupWriteSize
Раздел [API]
(или, что то же самое, [MYSQLD]
)
определяет поведение сервера MySQL. Параметры необязательны. Если никакое имя
не обеспечивается, то любой компьютер может использовать API этого узла.
[API]Id
[API]ExecuteOnComputer
[API]ArbitrationRank
[API]ArbitrationDelay
[API]BatchByteSize
[API]BatchSize
[API]MaxScanBatchSize
TCP/IP представляет собой заданный по умолчанию транспортный механизм для установления подключений в кластере MySQL. Фактически нет надобности определять любое подключение, потому что будет иметься одно подключение между каждым из узлов памяти, каждым из узлов памяти и всеми серверами MySQL, а каждым из узлов памяти и сервером управления.
Нужно определить подключение только, если необходимо изменить значения по
умолчанию для подключения. В этом случае необходимо определить по крайней
мере NodeId1
, NodeId2
и изменяемые параметры.
Также возможно изменить значения по умолчанию, устанавливая параметры в
разделе [TCP DEFAULT]
.
[TCP]NodeId1
[TCP]NodeId2
NodeId1
и в NodeId2
.
[TCP]SendBufferMemory
[TCP]SendSignalId
[TCP]Checksum
[TCP]PortNumber
[TCP DEFAULT]
. Этот параметр больше не должен использоваться.
Используйте параметр на узлах памяти вместо этого.
[TCP]ReceiveBufferMemory
Общедоступные сегменты памяти в настоящее время обеспечиваются только для
специальных версий MySQL Cluster, собранных с применением параметра
--with-ndb-shm
скрипта configure
. Реализация
наиболее вероятно изменится. При определении общедоступной памяти как метода
подключения, необходимо определить по крайней мере NodeId1
,
NodeId2
и ShmKey
. Все другие параметры имеют
значения по умолчанию, которые будут прекрасно
работать в большинстве случаев.
[SHM]NodeId1
[SHM]NodeId2
NodeId1
и
NodeId2
, между которыми создается соединение.
[SHM]ShmKey
[SHM]ShmSize
[SHM]SendSignalId
[SHM]Checksum
[TCP]Checksum
, но для подключений с общей памятью.
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]Host1SciId1
[SCI]Host2SciId0
[SCI]Host2SciId1
[SCI]Host1SciId1
, но для второго узла.
[SCI]SharedBufferSize
[SCI]SendLimit
[SCI]SendSignalId
[SCI]Checksum
[TCP]Checksum
, но для подключений через SCI.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |