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

3 Настройка MySQL Cluster Сервер MySQL, который является частью кластера, отличается от обычного только одним: он использует тип хранения NDBCLUSTER. Этот тип хранения также упоминается просто как NDB, и эти две формы имени являются синонимами. Чтобы избегать ненужного распределения ресурсов, сервер конфигурирован по умолчанию с заблокированным NDB. Чтобы его включить, Вы должны будете изменить файл конфигурации сервера my.cnf. Так как сервер MySQL является частью кластера, также надо знать, как обратиться к MGM-узлу, чтобы получить данные конфигурации кластера. Заданное по умолчанию поведение: искать MGM-узел на localhost. Однако, если надо определить расположение в другом месте, это может быть выполнено в my.cnf или в командной строке сервера MySQL. Прежде, чем NDB сможет использоваться, по крайней мере один MGM-узел должен быть запущен, также как любые желательные DB-узлы. 3.1 Построение из исходного текста 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, чтобы исключить это требование. Конечно, Вы можете также только следовать стандартным командам для компилирования Вашего собственного пакета, затем выполнить обычные тесты и процедуру установки. 3.2 Установка готового пакета В следующих разделах предполагается, что Вы уже знакомы с установкой MySQL, и здесь рассматриваются только различия между конфигурированием MySQL Cluster и MySQL без кластеризации. Вы найдете конфигурацию кластера самой простой, если уже имеете все узлы MGM и DB в рабочем виде изначально, полагаю, это будет самым длительным этапом настройки. Редактирование файла my.cnf довольно просто, и этот раздел рассматривает только отличия от конфигурирования MySQL без кластеризации. 3.3 Быстрая установка и тестирование MySQL Cluster Чтобы ознакомить Вас с основами, опишем самую простую возможную конфигурацию для функционального кластера. После этого Вы должны быть способны разработать Вашу желательную конфигурацию, исходя из информации, обеспеченной в других релевантных разделах этой главы. Сначала Вы должны создать каталог конфигураций, например, /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. 3.4 Файл настройки Конфигурирование кластера MySQL требует работы с двумя файлами: my.cnf: Определяет параметры для всех выполнимых программ кластера MySQL. Этот файл, с которым Вы должны быть знакомы с предыдущей работы с MySQL, должен быть доступен каждой программе, выполняющейся на кластере. config.ini: Этот файл доступен только для чтения серверу управления кластером MySQL, который затем распределяет информацию, содержащуюся в этом файле, по всем процессам, участвующим в кластере. Файл config.ini содержит описание каждого узла, включаемого в кластере. Это включает параметры конфигурации для узлов памяти и параметры конфигурации подключений между всеми узлами в кластере. Разработчики пакета непрерывно делают усовершенствования конфигурации кластера и пытаются упрощать этот процесс. Несмотря на то, что они стараются поддерживать совместимость в обратном направлении, могут иметься моменты, когда появляется несовместимое изменение. В таких случаях пользователям предоставляется информация о проблеме, если изменение не совместимо в обратном направлении. Если Вы находите такое изменение, которое не зарегистрировано, пожалуйста, используйте базу данных ошибок (http://bugs.mysql.com), чтобы сообщить авторам об этом. 3.4.1 Пример конфигурации для кластера MySQL Чтобы поддерживать кластер 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, все имена параметров нечувствительны к регистру. 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.

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