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

Глава 7. Управление NDB Cluster Управление NDB Cluster включает много задач, первая из которых должна сформировать и запустить NDB Cluster. См. главы 5 и 6. Следующие несколько секций покрывают управление NDB Cluster. Для получения информации о проблемах безопасности, касающихся управления и развертывания кластера NDB, посмотрите раздел 7.12. Есть по существу два метода активного управления NDB Cluster. Первый из них с помощью команд клиента управления, посредством чего статус кластера может быть проверен, изменены уровни регистрации, резервные копии начаты и остановлены и запущены или остановлены узлы. Второй метод включает изучение содержания регистрации кластера ndb_node_id _cluster.log, это обычно находится в каталоге DataDir сервера управления, но это местоположение может быть отвергнуто, используя опцию LogDestination. Вспомните, что node_id представляет уникальный идентификатор узла, деятельность которого регистрируется. Регистрация кластера содержит отчеты событий, произведенные ndbd. Также возможно послать записи в журнале кластера в системную регистрацию Unix. Некоторые аспекты действия кластера могут также быть проверены от узла SQL, используя SHOW ENGINE NDB STATUS. Более подробная информация об операциях по кластеру NDB доступна в режиме реального времени через интерфейс SQL, используя базу данных ndbinfo, см. раздел 7.10. Счетчики статистики NDB обеспечивают улучшенный контроль, используя клиент mysql. Эти счетчики, осуществленные в ядре NDB, касаются операций, выполненных объектами Ndb, такие как старт, закрытие и прерывание транзакций, первичный ключ и операции по уникальному ключу, диапазон и сокращенные просмотры, заблокированные потоки, ждущие различных операций, данные и события, посланные и полученные кластером NDB. С четчики увеличены ядром NDB каждый раз, когда вызовы API NDB сделаны или узлы посылают или получают данные. mysqld выставляет счетчики статистики API NDB как переменные состояния системы, которые могут быть определены по префиксу, характерному для всех их имен (Ndb_api_). Значения этих переменных могут быть прочитаны в клиенте mysql из выводе SHOW STATUS или запрашивая таблицу SESSION_STATUS или GLOBAL_STATUS (в БД INFORMATION_SCHEMA). Сравнивая значения переменных статуса прежде и после выполнения SQL-оператора, который действует на таблицы NDB, можно наблюдать действия уровня NDB API, которые соответствуют этому запросу для контрольной и исполнительной настройки кластера NDB. MySQL Cluster Manager обеспечивает современный интерфейс командной строки, который упрощает многое в других отношениях сложных задач управления кластером NDB, таких как старт, остановка или перезапуск кластера NDB с большим количеством узлов. Клиент MySQL Cluster Manager также поддерживает команды для того, чтобы получить и установить значения большинства параметров конфигурации узла, а также опции и переменные сервера mysqld, касающиеся кластера NDB. Посмотрите MySQL Cluster Manager 1.4.8 User Manual. 7.1. Резюме фаз запуска кластера NDB Эта секция обеспечивает упрощенную схему шагов, когда узлы данных NDB Cluster начаты. Более полная информация может быть найдена в NDB Cluster Start Phases в NDB Internals Guide. Эти фазы совпадают с теми, о которых сообщают в выводе node_id STATUS в клиенте управления (см. раздел 7.2). Об этих фазах начала также сообщают в столбце start_phase таблицы ndbinfo.nodes. Типы запуска. Есть несколько различных типов запуска, как показано в следующем списке: Начальный запуск. Кластер начинается с чистой файловой системой на всех узлах данных. Это происходит когда кластер впервые стартует или когда все узлы данных перезапущены, используя опцию --initial. Дисковые файлы данных не удалены, перезапуская с использованием опции --initial. Системный перезапуск. Кластер читает данные, хранимые в узлах данных. Это происходит, когда кластер был закрыт, чтобы возобновить операции от пункта, где был перезапуск. Перезапуск узла. Это перезапуск узла кластера в то время, как сам кластер работает. Начальный перезапуск узла. Это совпадает с перезапуском узла за исключением того, что узел повторно инициализирован и начат с чистой файловой системой. Установка и инициализация (фаза -1). До запуска должен быть инициализирован каждый узел данных (процесс ndbd). Инициализация состоит из следующих шагов: Получите ID узла Получите данные конфигурации Ассигнуйте порты, которые будут использоваться для коммуникаций междоузлия Ассигнуйте память согласно параметрам настройки, полученным из конфигурационного файла Когда узел данных или узел SQL сначала соединяются с узлом управления, это резервирует ID узла кластера. Чтобы удостовериться, что никакой другой узел не ассигнует тот же самый ID, он сохраняется, пока узлу не удалось соединиться с кластером, и по крайней мере один ndbd не сообщит, что этот узел связан. Это задержание ID охраняется связью между рассматриваемым узлом и ndb_mgmd. После того, как каждый узел данных был инициализирован, процесс запуска кластера может продолжиться. Стадии, которые кластер проходит во время этого процесса, перечисляются здесь: Фаза 0. Блоки NDBFS и NDBCNTR стартуют (см. NDB Kernel Blocks). Файловые системы узла данных очищены на тех узлах данных, которые были начаты с опцией --initial. Фаза 1. На этой стадии, все остающиеся ядерные блоки начаты. Связи кластера NDB настраиваются, межблоковые коммуникации устанавливаются и начата синхронизация. В случае перезапуска узла также проверяются связи узла API. Когда один или несколько узлов висят в Фазе 1 в то время, как остающийся узел или узлы висят в Фазе 2, это часто указывает на сетевые проблемы. Одна возможная причина таких проблем это один или несколько хостов кластера, имеющих много сетевых интерфейсов. Другой общий источник проблем, вызывающих эту ситуацию, является блокированием портов TCP/IP, необходимых для связей между узлами кластера. В последнем случае это часто происходит из-за неправильно сконфигурированного брандмауэра. Фаза 2. Блок NDBCNTR проверяет статусы всех существующих узлов. Главный узел выбран, и файл схемы кластера инициализируется. Фаза 3. Блоки DBLQH и DBTC настраивают связи между ними. Тип запуска определяется: если это перезапуск, блок DBDIH получает разрешение выполнить перезапуск. Фаза 4. Для начального запуска или начального перезапуска узла создаются файлы журнала отката. Количество этих файлов равно NoOfFragmentLogFiles. Для системного перезапуска: Прочитайте схему или схемы. Прочитайте данные из местной контрольной точки. Примените всю информацию наката, пока последняя восстанавливаемая глобальная контрольная точка не была достигнута. Для перезапуска узла найдите хвост журнала отката. Фаза 5. Большая часть связанной с базой данных части начала узла данных выполняется во время этой фазы. Для начального запуска или системного перезапуска местная контрольная точка выполняется, сопровождаемая глобальной контрольной точкой. Периодические проверки использования памяти начинаются во время этой фазы, и выполняются любые необходимые поглощения узла. Фаза 6. В этой фазе узлы кластера определены и созданы. Фаза 7. Узел арбитра отобран и начинает функционировать. Следующий резервный ID установлен, как скорость диска с резервной копией. Узлы, достигающие этой фазы начала, отмечены как Started. Для узлов API (включая узлы SQL) теперь возможно соединиться с кластером. Фаза 8. Если это системный перезапуск, все индексы восстановлены (DBDIH). Фаза 9. Внутренние переменные узла перезагружаются. Фаза 100 (OBSOLETE). Раньше в этом пункте во время перезапуска узлы API могли соединиться с узлом и начать получать события. В настоящее время эта фаза пуста. Фаза 101. В этом пункте в перезапуске узла доставка событий передана узлу, присоединяющемуся к кластеру. Недавно присоединенный узел берет на себя ответственность за поставку основных данных подписчикам. Эта фаза также упоминается как SUMA. После того, как этот процесс закончен для начального или системного перезапуска, операционная обработка позволена. Для перезапуска узла или начального перезапуска узла завершение процесса запуска означает, что узел может теперь действовать как операционный координатор. 7.2. Команды в клиенте управления кластером NDB В дополнение к центральному конфигурационному файлу кластером можно также управлять через интерфейс командной строки, доступный через клиент управления ndb_mgm. Это основной интерфейс администрирования. Команды для журналов событий даны в разделе 7.6, команды для создания резервных копий и восстановления обеспечиваются в разделе 7.3. Применение ndb_mgm с MySQL Cluster Manager. MySQL Cluster Manager обращается со стартом и остановкой процессов и отслеживает их статусы внутренне, таким образом, не надо использовать ndb_mgm для этих задач для кластера NDB, который находится под управлением MySQL Cluster Manager. Рекомендуется не использовать клиент командной строки not to use the ndb_mgm, который идет в комплекте с дистрибутивом NDB Cluster, чтобы выполнить операции, которые включают старт или остановку узлов. Они включают, но не ограничиваются командами START, STOP, RESTART и SHUTDOWN, см. MySQL Cluster Manager Process Commands. У клиента управления есть следующие основные команды. В листинге, который следует, node_id обозначает ID узла данных или ключевое слово ALL, которое указывает, что команда должна быть применена ко всем узлам данных кластера. HELP Информация обо всех доступных командах. CONNECT connection-string Соединяется с сервером управления, обозначенным строкой подключения. Если клиент уже связан с этим сервером, клиент снова соединяется. SHOW Информация о статусе кластера. Возможные значения статуса узла включают UNKNOWN, NO_CONTACT, NOT_STARTED, STARTING, STARTED, SHUTTING_DOWN и RESTARTING. Вывод этой команды также указывает, когда кластер находится в однопользовательском режиме (статус SINGLE USER MODE). node_id START Получает онлайн узел данных, определенный node_id (или все сразу). ALL START работает только со всеми узлами данных и не затрагивает узлы управления. Чтобы использовать эту команду, чтобы получить узел данных онлайн, узел данных должен быть запущен, используя опцию --nostart или -n. node_id STOP [-a] [-f] Останавливает узел данных или управления, определенный node_id. ALL STOP работает только со всеми узлами данных и не затрагивает узлы управления. Узел, затронутый этой командой, отсоединяется от кластера, а связанный процесс ndbd или ndb_mgmd прерывается. Опция -a заставляет узел быть немедленно остановленным, не ожидая завершения никаких отложенных транзакций. Обычно STOP терпит неудачу, если результат вызвал бы неполный кластер. Опция -f вынуждает узел закрыться, не проверяя на это. Если этот выбор используется и результат неполный кластер, то весь кластер немедленно закрывается. Использование опции -a также отключает проверку безопасности, иначе выполненную, когда вызвана STOP, чтобы гарантировать, что остановка узла не вызывает неполный кластер. Другими словами, необходимо соблюдать осторожность, используя опцию -a с командой STOP вследствие того, что этот выбор позволяет кластеру подвергнуться принудительному закрытию, потому что у этого больше нет полной копии всех данных в NDB. node_id RESTART [-n] [-i] [-a] [-f] Перезапускает узел данных, определенный node_id (или все узлы данных). Использование опции -i с RESTART заставляет узел данных выполнять начальный перезапуск, то есть, файловая система узла удалена и воссоздана. Эффект совпадает с остановкой процесса узла данных и затем его запуском, используя ndbd --initial. Резервные файлы и дисковые файлы данных не удалены, когда этот выбор используется. Применение -n заставляет процесс узла данных быть перезапущенным, но узел данных на самом деле не будет онлайн до соответствующей команды START. Эффект этого выбора совпадает с остановкой узла данных и затем запуском его снова, используя опцию ndbd --nostart или ndbd -n. Использование -a заставляет прерваться все текущие транзакции, полагающиеся на этот узел. Никакая проверка GCP не сделана, когда узел воссоединяется с кластером. Обычно RESTART терпит неудачу, если выведение из эксплуатации узла привело бы к неполному кластеру. Опция -f вынуждает узел перезапуститься, не проверяя на это. Если этот выбор используется и результат неполный кластер, то весь кластер перезапущен. node_idSTATUS Информация о статусе для узла данных, определенного node_id (или для всех). Вывод этой команды также указывает, когда кластер находится в однопользовательском режиме. node_id REPORT report-type Показывает сообщение о типе report-type для узла данных, определенного node_id, или для всех узлов данных при использовании ALL. В настоящее время есть три принятых значения для report-type: BackupStatus предоставляет отчет о состоянии относительно происходящей резервной копии кластера MemoryUsage показывает, сколько памяти памяти данных и индекса используется каждым узлом данных, как показано в этом примере: ndb_mgm> ALL REPORT MEMORY Node 1: Data usage is 5%(177 32K pages of total 3200) Node 1: Index usage is 0%(108 8K pages of total 12832) Node 2: Data usage is 5%(177 32K pages of total 3200) Node 2: Index usage is 0%(108 8K pages of total 12832) Эта информация также доступна из таблицы ndbinfo.memoryusage. EventLog сообщает о событиях из буферов журнала событий одного или более узлов данных. report-type нечувствителен к регистру и нечеткий, для for MemoryUsage можно использовать MEMORY, memory или MEM (mem). Можно сократить BackupStatus подобным способом. ENTER SINGLE USER MODE node_id Входит в однопользовательский режим, посредством чего только сервер MySQL, определенный ID node_id, может получить доступ к базе данных. EXIT SINGLE USER MODE Выход из однопользовательского режима, позволяя всем узлам SQL (то есть, всем процессам mysqld) получить доступ к базе данных. Возможно использовать EXIT SINGLE USER MODE даже когда кластер не в однопользовательском режиме, хотя команда не имеет никакого эффекта в этом случае. QUIT, EXIT Завершает клиент управления. Эта команда не затрагивает узлов, связанных с кластером. SHUTDOWN Закрывает все узлы данных и узлы управления. Чтобы выйти из клиента управления после этого, надо использовать EXIT или QUIT. Эта команда не закрывает узлов SQL или узлов API, которые связаны с кластером. CREATE NODEGROUP nodeid[, nodeid, ...] Создает новую группу узлов NDB Cluster и заставляет узлы данных присоединяться к ней. Эта команда используется после добавления новых узлов данных онлайн к кластеру NDB и заставляет их присоединяться к новой группе узлов и таким образом начинать участвовать полностью в кластере. Команда берет в качестве параметра список разделенных запятой значений ID узлов, добавленных и запущенных, которые должны присоединиться к новой группе узлов. Количество узлов должно совпасть с количеством узлов в каждой группе, которая уже является частью кластера (у каждой группы узлов кластера NDB должно быть то же самое количество узлов). Другими словами, если у кластера NDB есть 2 группы из 2 узлов данных каждая, то у новой группы должно также быть 2 узла данных. ID новой группы, созданной этой командой, определяется автоматически, и это всегда следующая самый большой неиспользованный ID, невозможно установить его вручную. См. раздел 7.15 . DROP NODEGROUP nodegroup_id Удаляет группу узлов NDB Cluster с данным nodegroup_id. Эта команда может использоваться, чтобы исключить группу узлов из NDB Cluster. DROP NODEGROUP берет в качестве аргумента ID группы узлов. DROP NODEGROUP действует только, чтобы удалить узлы данных в группе. Это не останавливает узлы данных, не назначает им другую узла и не удаляет их из конфигурации кластера. Узел данных, который не принадлежит группе узлов, обозначается в выводе клиента управления SHOW как no nodegroup вместо ID группы: id=3@10.100.2.67 (5.7.29-ndb-7.5.17, no nodegroup) DROP NODEGROUP работает только, когда все узлы данных в группе, которая будет удалена, абсолютно пусты от любых данных и определений таблицы. В настоящее время нет никакого способа использовать ndb_mgm или клиент mysql, чтобы удалить все данные из определенного узла данных или группы узлов, это означает, что команда имеет успех только в двух случаях: После CREATE NODEGROUP в ndb_mgm, но до ALTER TABLE ... REORGANIZE PARTITION в клиенте mysql. После удаления всех таблиц NDBCLUSTER через DROP TABLE. TRUNCATE TABLE не работает с этой целью, потому что это удаляет только данные, узлы данных продолжают хранить определение таблицы NDBCLUSTER до DROP TABLE. См. раздел 7.15 . PROMPT [prompt] Изменяет приглашение в ndb_mgm на строку prompt. prompt не должна быть цитирована (если вы не хотите, чтобы она включала кавычки). В отличие от случая с mysql, не признаны последовательности специального символа и экранировка. Если вызвана без аргумента, команда перезагружает приглашение к значению по умолчанию (ndb_mgm>). Некоторые примеры показывают здесь: ndb_mgm> PROMPT mgm#1: mgm#1: SHOW Cluster Configuration ... mgm#1: PROMPT mymgm > mymgm > PROMPT 'mymgm:' 'mymgm:' PROMPTmymgm: mymgm: PROMPT ndb_mgm> EXIT jon@valhaj:~/bin> Отметьте что лидирующие пробелы и пробелы в середине строки prompt не урезаны. Конечные пробелы удалены. PROMPT добавлена в NDB 7.5.0. node_id NODELOG DEBUG {ON|OFF} Переключает отладку в регистрации узла, как будто узел данных или узлы были запущены с --verbose. NODELOG DEBUG ON включает отладку, NODELOG DEBUG OFF выключает. Команда добавлена в NDB 7.6.4. Дополнительные команды. Много других команд доступны в ndb_mgm, но описаны в другом месте, как показано в следующем списке: START BACKUP используется, чтобы выполнить резервную копию онлайн в ndb_mgm, ABORT BACKUP используется, чтобы отменить уже происходящую резервную копию. Для получения дополнительной информации посмотрите раздел 7.3. CLUSTERLOG используется, чтобы выполнить различные функции регистрации. Посмотрите раздел 7.6. NDB 7.6.4 добавила NODELOG DEBUG, чтобы активировать или дезактивировать распечатки отладки в регистрациях узла, как описано ранее в этой секции. Для тестирования и работы диагностики клиент поддерживает DUMP, которая может использоваться, чтобы выполнить внутренние команды в кластере. Это никогда не должно использоваться в производственной среде, если не предписано сделать так поддержкой MySQL. Для получения дополнительной информации см. MySQL NDB Cluster Internals Manual. 7.3. Резервная копия NDB Cluster Следующие несколько секций описывают, как подготовиться и затем создать резервную копию кластера NDB с использованием функциональности, с этой целью найденной в клиенте управления ndb_mgm. Чтобы отличить этот тип резервной копии от резервной копии сделанной, используя mysqldump, мы иногда именуем ее как native резервную копию кластера NDB Cluster. Для получения информации о создании резервных копий с помощью mysqldump см. mysqldump A Database Backup Program. Восстановление резервных копий кластера NDB сделано, используя утилиту ndb_restore, которую предоставляет дистрибутив NDB Cluster, см. ndb_restore. О ее использовании в восстановлении резервных копий кластера NDB посмотрите раздел 6.24. 7.3.1. Понятия резервной копии кластера NDB Резервная копия это снимок базы данных в установленный срок. Резервная копия состоит из трех главных частей: Метаданные. Имена и определения всех таблиц базы данных Записи таблицы. Данные, сохраненные в таблицах базы данных в то время, когда резервная копия была сделана Журнал транзакций. Последовательный отчет, говорящий, как и когда данные хранились в базе данных Каждая из этих частей сохранена на всех узлах, участвующих в резервной копии. Во время резервной копии каждый узел пишет эти три части в три файла на диске: BACKUP- backup_id.node_id .ctl Файл контроля, содержащий управляющую информацию и метаданные. Каждый узел сохраняет те же самые определения таблицы (для всех таблиц в кластере) в собственной версии этого файла. BACKUP- backup_id-0.node_id .data Файл данных, содержащий записи таблицы, которые сохраняются на основе фрагментов. Таким образом, различные узлы хранят различные фрагменты во время резервной копии. Файл, сохраненный каждым узлом, начинается с заголовка, который указывает таблицы, к которым принадлежат записи. После списка записей есть нижняя сноска, содержащая контрольную сумму для всех записей. BACKUP- backup_id.node_id .log Файл журнала, содержащий записи переданных транзакций. Только транзакции на таблицах, хранимых в резервной копии сохранены в регистрации. Узлы, вовлеченные в резервную копию, сохраняют различные записи, потому что различные узлы принимают различные фрагменты базы данных. В листинге ниже backup_id обозначает резервный идентификатор и node_id это уникальный идентификатор для узла, создающего файл. Местоположение резервных файлов определяется параметром BackupDataDir. 7.3.2. Использование клиента управления NDB Cluster, чтобы создать резервную копию Прежде, чем начать резервную копию, удостоверьтесь, что кластер правильно формируется для выполнения этого. См. раздел 7.3.3. Команда START BACKUP используется, чтобы создать резервную копию: START BACKUP [backup_id] [wait_option] [snapshot_option] wait_option: WAIT {STARTED | COMPLETED} | NOWAIT snapshot_option: SNAPSHOTSTART | SNAPSHOTEND Последовательные резервные копии автоматически определяются последовательно, таким образом, backup_id это целое число, больше или равное 1. Если это опущено, следующее доступное значение используется. Если существующий backup_id используется, резервная копия терпит неудачу с ошибкой Backup failed: file already exists. Если используется, backup_id должен следовать за START BACKUP немедленно, прежде чем любые другие опции используются. wait_option может использоваться, чтобы определить, когда контроль возвращен клиенту управления после команды START BACKUP, как показано в следующем списке: Если указано NOWAIT, клиент управления покажет приглашение немедленно: ndb_mgm> START BACKUP NOWAIT ndb_mgm> В этом случае клиент управления может использоваться даже в то время, когда печатает информацию о прогрессе процесса резервного копирования. С WAIT STARTED клиент управления ждет, пока резервная копия не начнется перед возвращением контроля пользователю, как показано здесь: ndb_mgm> START BACKUP WAIT STARTED Waiting for started, this may take several minutes Node 2: Backup 3 started from node 1 ndb_mgm> WAIT COMPLETED предписывает клиенту управления ждать, пока процесс резервного копирования не будет завершен перед возвращением контроля пользователю. По умолчанию WAIT COMPLETED. snapshot_option может использоваться, чтобы определить, соответствует ли резервная копия статусу кластера, когда выполняется START BACKUP или когда это было закончено. SNAPSHOTSTART заставляет резервную копию соответствовать статусу кластера, когда резервная копия началась, SNAPSHOTEND заставляет резервную копию отражать статус кластера, когда резервная копия была закончена. SNAPSHOTEND это умолчание и соответствует поведению предыдущих выпусков кластера NDB. При использовании SNAPSHOTSTART с START BACKUP и включении CompressedBackup только данные и файлы контроля сжаты, файл журнала не сжат. Если использованы wait_option и snapshot_option, они могут быть определены в любом порядке. Например, все следующие команды действительны, предполагая, что нет никакой существующей резервной копии, имеющей ID 4: START BACKUP WAIT STARTED SNAPSHOTSTART START BACKUP SNAPSHOTSTART WAIT STARTED START BACKUP 4 WAIT COMPLETED SNAPSHOTSTART START BACKUP SNAPSHOTEND WAIT COMPLETED START BACKUP 4 NOWAIT SNAPSHOTSTART Процедура создания резервной копии состоит из следующих шагов: Запустите клиент управления ( ndb_mgm). Выполните START BACKUP. Это производит несколько строк, указывающих на прогресс резервной копии, как показано здесь: ndb_mgm> START BACKUP Waiting for completed, this may take several minutes Node 2: Backup 1 started from node 1 Node 2: Backup 1 started from node 1 completed StartGCP: 177 StopGCP: 180 #Records: 7362 #LogRecords: 0 Data: 453648 bytes Log: 0 bytes ndb_mgm> Когда резервная копия началась, клиент управления покажет это сообщение: Backup backup_id started from node node_id backup_id это уникальный идентификатор для этой конкретной резервной копии. Этот идентификатор соханен в журнале кластера, если не настроено иначе. node_id это идентификатор сервера управления, который координирует резервную копию с узлами данных. В этом пункте в процессе резервного копирования кластер получил и обработал запрос. Это не означает, что резервная копия закончилась. Пример этого запроса: Node 2: Backup 1 started from node 1 Клиент управления указывает в сообщении, что резервная копия началась: Backup backup_id started from node node_id completed backup_id это уникальный идентификатор для этой конкретной резервной копии, а node_id это ID узла сервера управления, который координирует резервную копию с узлами данных. Этот вывод сопровождается дополнительной информацией, включая соответствующие глобальные контрольные точки, количество записей и размер данных: Node 2: Backup 1 started from node 1 completed StartGCP: 177 StopGCP: 180 #Records: 7362 #LogRecords: 0 Data: 453648 bytes Log: 0 bytes Также возможно выполнить резервную копию от системной оболочки, вызвав ndb_mgm с -e или --execute: shell> ndb_mgm -e "START BACKUP 6 WAIT COMPLETED SNAPSHOTSTART" Используя START BACKUP таким образом необходимо определить резервный ID. Резервные копии кластера создаются по умолчанию в подкаталоге BACKUP каталога DataDir на каждом узле данных. Это может быть отвергнуто для одного или более узлов данных индивидуально или для всех узлов данных в файле config.ini, используя BackupDataDir. Резервные файлы создаются для резервной копии с данным backup_id в подкаталоге BACKUP- backup_id в резервном каталоге. Отмена резервных копий. Чтобы отменить или прервать резервную копию, которая уже происходит, выполните следующие шаги: Запустите клиент управления. Выполните эту команду: ndb_mgm> ABORT BACKUP backup_id backup_id это идентификатор резервной копии, который был включен в ответ клиента управления, когда резервная копия была начата (в сообщении Backup backup_id started from node management_node_id). Клиент управления подтвердит запрос аварийного прекращения работы с Abort of backup backup_id ordered. В этом пункте клиент управления еще не получил ответ от узлов данных, и резервная копия еще не была на самом деле прервана. После того, как резервная копия была прервана, клиент управления сообщит об этом факте способом, подобным тому, что показывают здесь: Node 1: Backup 3 started from 5 has been aborted. Error: 1321 - Backup aborted by user request: Permanent error: User defined error Node 3: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error Node 2: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error Node 4: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error В этом примере мы показали типовой вывод для кластера с 4 узлами данных, где порядковый номер резервной копии, которая будет прервана, 3, и у узла управления, с которым связан клиент управления кластером, есть ID узла 5. Первый узел, который закончит свою часть в прерывании резервной копии, сообщает, что причина аварийного прекращения работы происходила из-за запроса пользователя. Остающиеся узлы сообщают, что резервная копия была прервана из-за неуказанной внутренней ошибки. Нет никакой гарантии, что узлы кластера отвечают на команду ABORT BACKUP в каком-то конкретном порядке. Сообщения Backup backup_id started from node management_node_id aborted означают, что резервная копия была закончена и что все файлы, касающиеся этой резервной копии, были удалены из файловой системы кластера. Также возможно прервать происходящую резервную копию от системной оболочки, используя эту команду: shell> ndb_mgm -e "ABORT BACKUP backup_id" Если нет никакой резервной копии, имеющей ID backup_id, когда отдана команда ABORT BACKUP, клиент управления не делает ответа, и при этом это не обозначает в регистрации кластера, что послали недействительную команду аварийного прекращения работы. 7.3.3. Конфигурация для резервных копий NDB Cluster Пять параметров конфигурации важны для резервной копии: BackupDataBufferSize Объем памяти для буферизации данных, прежде чем они будут записаны на диск. BackupLogBufferSize Объем памяти для буферизации записей журнала, прежде чем они будут записаны на диск. BackupMemory Общая память ассигнуется в узле данных для резервных копий. Это должно быть суммой памяти, ассигнованной для буфера данных резервного копирования и буфера журнала резервного копирования. BackupWriteSize Размер по умолчанию блоков записи на диск. Это применяется к буферу данных резервного копирования и буферу журнала резервного копирования. BackupMaxWriteSize Максимальный размер блока записи на диск. Это применяется к буферу данных резервного копирования и буферу журнала резервного копирования. См. подробности здесь. Можно также установить местоположение для резервных файлов, используя BackupDataDir. По умолчанию FileSystemPath/BACKUP/BACKUP- backup_id. 7.3.4. Поиск неисправностей резервной копии NDB Cluster Если код ошибки возвращен в ответ на запрос, наиболее вероятная причина в том, что недостаточно памяти или дискового пространства. Необходимо проверить, что есть достаточно памяти, ассигнованной для резервной копии. Если вы установили BackupDataBufferSize, BackupLogBufferSize и их сумму в больше, чем 4MB, необходимо также установить BackupMemory. Необходимо также удостовериться, что есть достаточное пространство на разделе жесткого диска. NDB не поддерживает повторяемое чтение, что может вызвать проблемы с процессом восстановления. Хотя процесс резервного копирования горячий, восстановление NDB Cluster из резервной копии не является 100% горячим . Это вследствие того, что на время восстановления транзакции получают неповторяемые чтения от восстановленных данных. Это означает, что статус данных непоследовательный в то время, как происходит восстановление. 7.4. Использование сервера MySQL для NDB Cluster mysqld традиционный серверный процесс MySQL. Чтобы использоваться с кластером NDB, mysqld должен быть построен с поддержкой NDB как это сделано в предварительно собранных дистрибутиваах с https://dev.mysql.com/downloads/. Если вы строите MySQL из исходных текстов, необходимо вызвать CMake с опцией -DWITH_NDBCLUSTER=1, чтобы включить поддержку NDB. Для получения дополнительной информации о компилировании кластера NDB см. разделы 4.3.4 и 4.4.2. Для получения информации об опциях и параметрах mysqld в дополнение к обсужденным в этой секции, которые относятся к кластеру NDB, посмотрите раздел 5.3.9. Если mysqld был построен с поддержкой кластера, NDBCLUSTER все еще отключен по умолчанию. Можно использовать любой из двух возможных вариантов, чтобы позволить этот механизм: Использовать опцию --ndbcluster в командной строке, начиная mysqld. Вставьте строку, содержащую ndbcluster в раздел [mysqld] файла my.cnf. Легкий способ проверить, что ваш сервер работает с NDBCLUSTER это запрос SHOW ENGINES в MySQL Monitor (mysql). Необходимо видеть YES как значение Support в строке NDBCLUSTER. Если вы видите NO или если нет такой строки, вы не работаете с NDB -версией MySQL. Если вы видите DISABLED, необходимо включить поддержку. Чтобы прочитать данные о кластерной конфигурации, сервер MySQL требует как минимум трех сведений: Собственный ID узла кластера сервера MySQL Имя хоста или IP-адрес для сервера управления (узел MGM) Номер порта TCP/IP, на котором это может соединиться с сервером управления ID узла могут быть ассигнованы динамично, таким образом, не строго необходимо определить их явно. Параметр ndb-connectstring используется, чтобы определить строку подключения в командной строке, начиная mysqld, или в файле my.cnf. Строка подключения содержит имя хоста или IP-адрес, где сервер управления может быть найден, а также порт TCP/IP, который это использует. В следующем примере ndb_mgmd.mysql.com это хост где сервер управления находится, сервер управления слушает сообщения кластера на порте 1186: shell> mysqld --ndbcluster --ndb-connectstring=ndb_mgmd.mysql.com:1186 См. раздел 5.3.3. Учитывая эту информацию, сервер MySQL будет полноправным участником кластера. Мы часто обращаемся к процессу mysqld, работающим этим способом как к узлу SQL. Это будет полностью осведомлено обо всех узлах данных, а также их статусе, и установит связи со всеми узлами данных. В этом случае это в состоянии использовать любой узел данных в качестве операционного координатора и прочитать и обновить данные об узле. Вы видите в клиенте mysql связан ли сервер MySQL с кластером, используя SHOW PROCESSLIST. Если сервер MySQL связан с кластером, и вы имеете привилегию PROCESS, тогда первая строка вывода: mysql> SHOW PROCESSLIST \G *************************** 1. row *************************** Id: 1 User: system user Host: db: Command: Daemon Time: 1 State: Waiting for event from ndbcluster Info: NULL Чтобы участвовать в кластере NDB, процесс mysqld должен быть начат с опциями --ndbcluster и --ndb-connectstring (или их эквивалентами в my.cnf). Если mysqld запущен только с --ndbcluster или если это неспособно связаться с кластером, невозможно работать с таблицами NDB и при этом невозможно составить любые новые таблицы независимо от механизма хранения. Последнее ограничение это меры по обеспечению безопасности, предназначенные, чтобы предотвратить создание таблиц, имеющих те же самые имена, как таблицы NDB в то время как узел SQL не связан с кластером. Если вы хотите составить таблицы, используя другой механизм хранения, в то время как процесс mysqld не участвует в кластеру NDB, необходимо перезапустить сервер без опции --ndbcluster. 7.5. Выполнение катящегося перезапуска NDB Cluster Эта секция обсуждает, как выполнить катящийся перезапуск NDB Cluster, именуемый так потому, что он включает остановку и старт (или перезапуск) каждого узла в свою очередь, чтобы сам кластер остался готовым к эксплуатации. Это часто делается как часть катящейся модернизации, где высокая доступность кластера обязательна, и никакое время простоя кластера в целом недопустимо. Есть много причин, почему катящийся перезапуск мог бы быть желательным. Они описаны в следующих нескольких параграфах. Изменение конфигурации. Чтобы вносить изменение в конфигурации кластера, такое как добавление узла SQL к кластеру или урегулирование параметра конфигурации к новому значению. Обновление программного обеспечения кластера NDB. Чтобы модернизировать кластер до более новой версии программного обеспечения NDB Cluster (или понизить его до более старой версии). Это обычно упоминается как катящаяся модернизация). Изменение на хосте узла. Чтобы вносить изменения в аппаратной или операционной системе, на которой работает процессы узла кластера NDB. Системный перезапуск. Чтобы перезапустить кластер, потому что это достигло нежелательного статуса. В таких случаях часто желательно перезагрузить данные и метаданные одного или более узлов данных. Это может быть сделано любым из трех способов: Начните каждый процесс узла данных ( ndbd или ndbmtd) с опцией --initial, которая вынуждает узел данных очистить свою файловую систему и перезагрузить все данные и метаданные от других узлов данных. Создайте резервную копию, используя в клиенте ndb_mgm команду START BACKUP до выполнения перезапуска. После модернизации восстановите узел или узлы, используя ndb_restore. См. разделы 7.3 и 6.24. Используйте команду mysqldump , чтобы создать резервную копию до модернизации, позже восстановите дамп с использованием LOAD DATA. Восстановление ресурса. Чтобы восстановить память, ранее ассигнованную таблице последовательными INSERT и DELETE, для повторного использования другими таблицыми кластера NDB. Процесс для выполнения катящегося перезапуска может быть обобщен следующим образом: Остановите все узлы управления кластером (процессы ndb_mgmd), повторно формируйте, затем перезапустите их. Остановите, повторно формируйте, затем перезапустите каждый узел данных (процесс ndbd) в свою очередь. Некоторые параметры конфигурации узла могут быть обновлены, командой RESTART для каждого из узлов данных в клиенте ndb_mgm, выполняющем предыдущий шаг, другие требуют, чтобы узел данных был остановлен полностью, используя команду оболочки kill в большинстве Unix) или в клиенте управления команду STOP, затем начался снова из системной оболочки, вызвав the ndbd или ndbmtd. В Windows можно также использовать команды SC STOP и SC START, NET STOP и NET START или Windows Service Manager, чтобы остановить и запустить узлы, которые были установлены как службы Windows (см. раздел 4.4.4). Тип требуемого перезапуска обозначается в документации для каждого параметра конфигурации узла. Посмотрите раздел 5.3. Остановите, повторно формируйте, затем перезапустите каждый узел SQL (процесс mysqld). NDB Cluster поддерживает несколько гибкий порядок модернизации узлов. Модернизируя NDB Cluster, можно модернизировать узлы API (включая узлы SQL) прежде, чем модернизировать узлы управления, узлы данных или обоих. Другими словами, вам разрешают модернизировать API и узлы SQL в любом порядке. Это подвергается следующим условиям: Эта функциональность предназначается для использования в качестве части только модернизации онлайн. Соединение объектов узла от различных выпусков кластера NDB не предназначается и не поддерживается для непрерывного, долгосрочного использования в производственном окружении. Все узлы управления должны быть модернизированы прежде, чем любые узлы данных модернизированы. Это остается верным независимо от порядка, в котором вы модернизируете API кластера и узлы SQL. Функции, определенные для новой версии, не должны быть использованы, пока все узлы управления и узлы данных не были модернизированы. Это также относится к любому изменению версии сервера MySQL, которое может примениться в дополнение к изменению версии NDB, поэтому не забывайте принимать это во внимание, планируя модернизацию. Это верно для модернизаций онлайн кластера NDB в целом. Ни для какого узла API невозможно выполнить операции по схеме (такие, как запрос определения данных) во время перезапуска узла. Частично благодаря этому ограничению, операции по схеме также не поддерживаются во время модернизации онлайн или снижения. Катящийся перезапуск с многими серверами управления. Выполняя катящийся перезапуск кластера NDB с многими узлами управления, необходимо иметь в виду, что ndb_mgmd проверяет, чтобы видеть, управляет ли какой-либо другой узел управления, и если так, пытается использовать данные конфигурации того узла. Чтобы помешать этому и заставить ndb_mgmd перечитать свой конфигурационный файл, выполняют следующие шаги: Остановите все процессы ndb_mgmd. Обновите все файлы config.ini. Запустите единственный процесс ndb_mgmd с опциями --reload и/или --initial. Если вы начали первый ndb_mgmd с опцией --initial, необходимо также начать любой остающийся ndb_mgmd с опцией --initial. Независимо от любых других вариантов, используемых, начиная первый ndb_mgmd, вы не должны начинать никакой другой ndb_mgmd после первого использования --reload. Закончите катящиеся перезапуски узлов данных и узлов API. Выполняя катящийся перезапуск, чтобы обновить конфигурацию кластера, можно использовать столбец config_generation таблицы ndbinfo.nodes, чтобы отслеживать, которые узлы данных были успешно перезапущены с новой конфигурацией. Посмотрите раздел 7.10.28. 7.6. Записи событий, произведенные в кластере NDB В этой секции мы обсуждаем типы журналов событий, предоставленных кластером NDB, и типы событий, которые зарегистрированы. NDB Cluster обеспечивает два типа журнала событий: Регистрация кластера, которая включает события, произведенные всеми узлами кластера. Регистрация кластера это регистрация, рекомендуемая для большей части использования, потому что это предоставляет информацию для всего кластера в единственном месте. По умолчанию регистрация кластера сохранена в файле ndb_node_id _cluster.log, (где node_id ID узла сервера управления) в каталоге DataDir сервера управления. Информацию о регистрации кластера можно также послать в stdout или syslog в дополнение или вместо того, чтобы писать данные в файл, как определено набором значений для DataDir и LogDestination. См. раздел 5.3.5. Регистрации узла локальна для каждого узла. Вывод, произведенный регистрацией событий узла, написан в файл ndb_node_id _out.log (где node_id это ID узла) в каталоге DataDir узла. Журналы событий узла произведены для узлов управления и для узлов данных. Регистрации узла предназначаются, чтобы использоваться только во время разработки приложений или для отладки кода приложения. Оба типа журналов событий могут зарегистрировать различные подмножества событий. Каждое заслуживающее публикации событие можно отличить согласно трем различным критериям: Категория: Это может быть любое из следующих значений: STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT, NODERESTART, CONNECTION, ERROR или INFO. Приоритет: Это представляется одним из чисел от 0 до 15, где 0 указывает самый важный, а 15 наименее важный. Уровень серьезности: это может быть любое из следующих значений: ALERT, CRITICAL, ERROR, WARNING, INFO или DEBUG. Регистрация кластера и регистрация узла могут быть фильтрованы на этих свойствах. Формат, используемый в регистрации кластера: 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Data usage is 2%(60 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Index usage is 1%(24 8K pages of total 2336) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Resource 0 min: 0 max: 639 curr: 0 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 2: Data usage is 2%(76 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 2: Index usage is 1%(24 8K pages of total 2336) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 2: Resource 0 min: 0 max: 639 curr: 0 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 3: Data usage is 2%(58 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 3: Index usage is 1%(25 8K pages of total 2336) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 3: Resource 0 min: 0 max: 639 curr: 0 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 4: Data usage is 2%(74 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 4: Index usage is 1%(25 8K pages of total 2336) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 4: Resource 0 min: 0 max: 639 curr: 0 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 4: Node 9 Connected 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 1: Node 9 Connected 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 1: Node 9: API 5.7.29-ndb-7.5.17 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 2: Node 9 Connected 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 2: Node 9: API 5.7.29-ndb-7.5.17 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 3: Node 9 Connected 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 3: Node 9: API 5.7.29-ndb-7.5.17 2007-01-26 19:39:42 [MgmSrvr] INFO -- Node 4: Node 9: API 5.7.29-ndb-7.5.17 2007-01-26 19:59:22 [MgmSrvr] ALERT-- Node 2: Node 7 Disconnected 2007-01-26 19:59:22 [MgmSrvr] ALERT-- Node 2: Node 7 Disconnected Каждая строка в регистрации кластера содержит следующую информацию: Метка времени в формате YYYY -MM- DD HH: MM:SS. Тип узла, который выполняет регистрацию. В регистрации кластера это всегда [MgmSrvr]. Серьезность события. ID узла, сообщающего о событии. Описание события. Наиболее распространенные типы событий, чтобы появиться в регистрации являются связями и разъединениями между различными узлами в кластере, и когда контрольные точки происходят. В некоторых случаях описание может содержать информацию о статусе. 7.6.1. Команды управления регистрацией NDB Cluster ndb_mgm поддерживает много команд управления, связанных с регистрацией кластера и регистрациями узла. В листинге ниже node_id обозначает ID узла хранения или ключевое слово ALL, которое указывает, что команда должна быть применена ко всем узлам данных кластера. CLUSTERLOG ON Включает журналирование кластера. CLUSTERLOG OFF Выключает журналирование кластера. CLUSTERLOG INFO Предоставляет информацию о параметрах настройки кластера регистрации. node_id CLUSTERLOG category= threshold Регистрирует category событий с приоритетом меньше или равным threshold в журнал кластера. CLUSTERLOG FILTER severity_level Переключает регистрацию событий указанного severity_level. Следующая таблица описывает настройку по умолчанию (для всех узлов данных) порога категории регистрации кластера. Если у события есть приоритет со значениею ниже или равный приоритетному порогу, о нем сообщают в регистрации кластера. О событиях сообщают по узлу данных, так что порог может быть установлен к различным значениям на различных узлах. Таблица 7.1. Категории регистрации с пороговым урегулированием по умолчанию Категория Порог по умолчанию (все узлы данных) STARTUP 7 SHUTDOWN 7 STATISTICS 7 CHECKPOINT 7 NODERESTART 7 CONNECTION 7 ERROR 15 INFO 7 Категория STATISTICS может обеспечить много полезных данных. Посмотрите раздел 7.6.3. Пороги используются, чтобы отфильтровать события в каждой категории. Например, событие STARTUP с приоритетом 3 не зарегистрировано, если порог для STARTUP установлен в 3 или выше. Только события с приоритетом 3 или ниже посылают, если порог равняется 3. Следующая таблица показывает уровни серьезности событий. Они соответствуют уровням Unix syslog, кроме LOG_EMERG и LOG_NOTICE, которые не используются. Таблица 7.2. Уровни серьезности Уровень серьезности Важность Описание 1 ALERT Условие, которое должно быть немедленно исправлено, такие как испорченная системная база данных 2 CRITICAL Критические состояния, такие как ошибки устройства или недостаточные ресурсы 3 ERROR Условия, которые должны быть исправлены, такие как ошибки конфигурации 4 WARNING Условия, которые не являются ошибками, но это могло бы потребовать специальной обработки 5 INFO Информационные сообщения 6 DEBUG Сообщения отладки, используемые для разработки NDBCLUSTER Уровни серьезности событий могут быть включены или выключены через CLUSTERLOG FILTER. Если уровень серьезности включен, то все события с приоритетом меньше или равным порогам категории зарегистрированы. Если уровень серьезности выключен, никакие события, принадлежащие тому уровню серьезности, не зарегистрированы. Уровни кластера регистрации установлены на основе ndb_mgmd для каждого подписчика. Это означает, что в кластере NDB с многими серверами управления использование команды CLUSTERLOG в ndb_mgm, связанного с одним сервером управления, затрагивает только регистрации, произведенные тем сервером управления, но не любыми другими. 7.6.2. События регистрации NDB Cluster Отчет событий, о котором сообщают в конечном счете, имеет следующий формат: datetime [string] severity -- message Например: 09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed Эта секция обсуждает все заслуживающие публикации события, упорядоченные по категориям и уровню серьезности в каждой категории. В описании GCP и LCP означают Global Checkpoint и Local Checkpoint. События CONNECTION Эти события связаны со связями между узлами кластера. Таблица 7.3. События, связанные со связями между узлами кластера Событие Приоритет Важность Описание Connected 8 INFO Узлы данных связаны Disconnected 8 ALERT Узлы данных разъединены CommunicationClosed 8 INFO Узел SQL или данных закрыл связь CommunicationOpened 8 INFO Узел SQL или данных открыл связь ConnectedApiVersion 8 INFO Связь использует версию API События CHECKPOINT Регистрирующиеся сообщения, показанные здесь, связаны с контрольными точками. Таблица 7.4. События с контрольными точками Событие Приоритет Важность Описание GlobalCheckpointStarted 9 INFO Начало GCP: журнал REDO записан на диск GlobalCheckpointCompleted 10 INFO GCP закончена LocalCheckpointStarted 7 INFO Начало LCP: данные записаны на диск LocalCheckpointCompleted 7 INFO LCP успешно завершена LCPStoppedInCalcKeepGci 0 ALERT LCP остановлена LCPFragmentCompleted 11 INFO LCP на фрагменте была закончена UndoLogBlocked 7 INFO Регистрация UNDO заблокирована, буфер почти переполнен RedoStatus 7 INFO Статус Redo События STARTUP Следующие события произведены в ответ на запуск узла или кластера и его успешности или неуспешности. Они также предоставляют информацию, касающуюся прогресса процесса запуска, включая информацию относительно регистрирующихся действий. Таблица 7.5. События, касающиеся запуска узла или кластера Событие Приоритет Важность Описание NDBStartStarted 1 INFO Узел данных начинает фазы инициализации (все узлы запускаются) NDBStartCompleted 1 INFO Стартовые фазы закончены, все узлы данных STTORRYRecieved 15 INFO Блоки, полученные после завершения перезапуска StartPhaseCompleted 4 INFO Узел данных закончил фазу X CM_REGCONF 3 INFO Узел был успешно включен в группу, показывает узел, руководящий узел и динамический ID CM_REGREF 8 INFO Узлу отказали во включении в группу, не может быть включен в группу из-за неверной конфигурации, неспособности установить коммуникацию или другой проблемы FIND_NEIGHBOURS 8 INFO Показывает соседние узлы данных NDBStopStarted 1 INFO Закрытие узла данных начинается NDBStopCompleted 1 INFO Завершено закрытие узла данных NDBStopForced 1 ALERT Принудительное закрытие узла данных NDBStopAborted 1 INFO Не получилось обычно закрыть узел данных StartREDOLog 4 INFO Новый журнал отката начат, GCI хранит X, новейший восстанавливаемый GCI Y StartLog 10 INFO Новая регистрация начата, часть регистрации X, начало MB Y, окончание MB Z UNDORecordsExecuted 15 INFO Отмените выполненные записи StartReport 4 INFO Отчет начат LogFileInitStatus 7 INFO Статус инициализации файла журнала LogFileInitCompStatus 7 INFO Статус завершения файла журнала StartReadLCP 10 INFO Начато чтение для местной контрольной точки ReadLCPComplete 10 INFO Закончено чтение для местной контрольной точки RunRedo 8 INFO Управление журналом отката RebuildIndex 10 INFO Восстановление индексов События NODERESTART Следующие события произведены, перезапуская узел и касаются успешности или неуспешности процесса перезапуска узла. Таблица 7.6. События, касающиеся перезапуска узла Событие Приоритет Важность Описание NR_CopyDict 7 INFO Закончено копирование информации словаря NR_CopyDistr 7 INFO Закончено копирование информации о распределении NR_CopyFragsStarted 7 INFO Старт копирования фрагментов NR_CopyFragDone 10 INFO Окончание копирования фрагментов NR_CopyFragsCompleted 7 INFO Окончание копирования всех фрагментов NodeFailCompleted 8 ALERT Фаза неудачи узла закончена NODE_FAILREP 8 ALERT Сообщает, что узел потерпел неудачу ArbitState 6 INFO Отчет, найден ли арбитр или нет, есть семь различных возможных исходов, ища арбитра, перечисленные здесь: Сервер управления перезапускает арбитражный поток [state=X] Подготовьте узел арбитра X [ticket=Y] Получите узел арбитра X [ticket=Y] Начат узел арбитра X [ticket=Y] Потерянный узел арбитра X - неудача процесса [state=Y] Потерянный узел арбитра X - процесс завершен [state=Y] Потерянный узел арбитра X <error msg> [state=Y] ArbitResult 2 ALERT Сообщите о результатах арбитра, есть восемь различных возможных результатов для арбитражных попыток, перечисленные здесь: Арбитражная проверка потерпела неудачу: меньше 1/2 узлов работают Арбитражная проверка имела успех: большинство узлов в норме Арбитражная проверка потерпела неудачу: пропавший узел Сетевое разделение: арбитраж требуется Арбитраж добился успеха: утвердительный ответ от узла X Арбитраж потерпел неудачу: отрицательный ответ от узла X Сетевое разделение: никакой доступный арбитр не найден Сетевое разделение: никакой арбитр не формируется GCP_TakeoverStarted 7 INFO Поглощение GCP начато GCP_TakeoverCompleted 7 INFO Полное поглощение GCP выполнено LCP_TakeoverStarted 7 INFO Поглощение LCP начато LCP_TakeoverCompleted 7 INFO Поглощение LCP выполнено (state = X ) ConnectCheckStarted 6 INFO Проверка связи начата ConnectCheckCompleted 6 INFO Проверка связи закончена NodeFailRejected 6 ALERT Фаза неудачи узла потерпела неудачу События STATISTICS Следующие события имеют статистическую природу. Они предоставляют информацию, такую как числа транзакций и других операций, объем данных, посланный или полученный отдельными узлами, и использование памяти. Таблица 7.7. События статистической природы Событие Приоритет Важность Описание TransReportCounters 8 INFO Операционная статистика отчета, включая число транзакций, чтений, записей, параллельных операций, информацию атрибута и аварийные прекращения работы OperationReportCounters 8 INFO Количество операций TableCreated 7 INFO Количество созданных таблиц JobStatistic 9 INFO Следует иметь в виду внутреннюю статистику планирования работы ThreadConfigLoop 9 INFO Количество циклов конфигурации потоков SendBytesStatistic 9 INFO Среднее число байтов послано в узел X ReceiveBytesStatistic 9 INFO Среднее число байтов получено от узла X MemoryUsage 5 INFO Использование памяти индекса и данных (80%, 90% и 100%) MTSignalStatistics 9 INFO Многопоточные сигналы События SCHEMA Эти события касаются операций по схеме кластера NDB. Таблица 7.8. События, касающиеся операций по схеме кластера NDB Событие Приоритет Важность Описание CreateSchemaObject 8 INFO Схема создана AlterSchemaObject 8 INFO Объект схемы обновляется DropSchemaObject 8 INFO Объект схемы удален События ERROR Эти события касаются ошибок кластера и предупреждений. Присутствие одного или больше из них обычно указывает, что произошел сбой. Таблица 7.9. События, касающиеся ошибок кластера и предупреждений синхроимпульсов Событие Приоритет Важность Описание TransporterError 2 ERROR Ошибка транспортера TransporterWarning 8 WARNING Предупреждение транспортера MissedHeartbeat 8 WARNING Узел X пропустил Y DeadDueToHeartbeat 8 ALERT Узел X объявлен мертвым из-за пропущенного синхроимпульса WarningEvent 2 WARNING Общее событие предупреждения SubscriptionStatus 4 WARNING Изменение в подписном статусе События INFO Эти события предоставляют общую информацию о статусе кластера и действий, связанных с обслуживанием кластера, таких как передача регистрации и синхроимпульсов. Таблица 7.10. События информации Событие Приоритет Важность Описание SentHeartbeat 12 INFO Послан синхроимпульс CreateLogBytes 11 INFO Создана журнал, часть регистрации, файл журнала, размер в MB InfoEvent 2 INFO Общее информационное событие EventBufferStatus 7 INFO Статус буфера событий EventBufferStatus2 7 INFO Улучшенная информация о статусе буфера событий, добавлено в NDB 7.5.1 События SentHeartbeat доступны, только если кластер NDB был собран с поддержкой VM_TRACE. События SINGLEUSER Эти события связаны с входом и выходом из однопользовательского режима. Таблица 7.11. События, касающиеся однопользовательского режима Событие Приоритет Важность Описание SingleUser 7 INFO Вход или выход из однопользовательского режима События BACKUP Эти события предоставляют информацию о резервных копиях, создаваемых или восстановленных. Таблица 7.12. События резервной копии Событие Приоритет Важность Описание BackupStarted 7 INFO Резервная копия начата BackupStatus 7 INFO Резервный статус BackupCompleted 7 INFO Резервная копия закончена BackupFailedToStart 7 ALERT Резервная копия не началась BackupAborted 7 ALERT Резервная копия прерывается пользователем RestoreStarted 7 INFO Начато восстановление из резервной копии RestoreMetaData 7 INFO Восстановление метаданных RestoreData 7 INFO Восстановление данных RestoreLog 7 INFO Восстановление файлов журнала RestoreCompleted 7 INFO Закончено восстановление из резервной копии SavedEvent 7 INFO Событие сохранено 7.6.3. CLUSTERLOG STATISTICS в клиенте управления NDB Cluster Клиент управления NDB имеет команду CLUSTERLOG STATISTICS, которая может обеспечить много полезных статистических данных в своем выводе. Счетчики, предоставляющие информацию о статусе кластера, обновлены в 5 секундных интервалах сообщения операционным координатором (TC) и укладчиком локального запроса (LQH), после чего написаны в журнал кластера. Операционный координатор статистики. У каждой транзакции есть один операционный координатор, который выбран одним из следующих методов: Циклическим способом Коммуникационной близостью Поставляя размещение данных, когда транзакция начата Можно определить, который метод выбора TC используется для транзакций, начатых с данного узла SQL, используя переменную ndb_optimized_node_selection. Все операции в той же самой транзакции используют того же самого операционного координатора, который сообщает о следующей статистике: Количество транзакций. Это число транзакций, начатых в последнем интервале, используя этот TC в качестве операционного координатора. Любая из этих транзакций, возможно, передана, была прервана или остается нейтральной в конце интервала. Транзакции не мигрируют между TC. Количество передач. Это количество транзакций, используя этот TC в качестве операционного координатора, которые были переданы в последнем интервале сообщения. Поскольку некоторые транзакции, переданные в этом интервале сообщения, возможно, начались в предыдущем интервале сообщения, возможно для Commit count быть больше Trans count. Количество чтений. Это количество операций чтения первичного ключа, используя этот TC в качестве операционного координатора, которые были начаты в последнем интервале сообщения, включая простое чтение. Это количество также включает чтение, выполненное как часть операций по уникальному индексу. Операция чтения уникального индекса производит 2 операции чтения первичного ключа: 1 для скрытой таблицы уникального индекса и 1 для таблицы, на которой происходит чтение. Счетчик простых чтений. Это количество простых операций чтения, используя этот TC в качестве операционного координатора, которые были начаты в последнем интервале сообщения. Счетчик записей. Это количество операций записи первичного ключа, используя этот TC в качестве операционного координатора, которые были начаты в последнем интервале сообщения. Это включает все вставки, обновления, записи и удаления, а также записи, выполненные как часть операций по уникальному индексу. Операция по обновлению уникального индекса может произвести много чтений и записей на таблице индекса и на базовой таблице. AttrInfoCount. Это количество 32-битных слов данных, полученных в последнем интервале сообщения для операций по первичному ключу, используя этот TC в качестве операционного координатора. Для чтений это пропорционально количеству колонок, которые запрошены. Для вставок и обновлений, это пропорционально количеству записанных колонок и размеру их данных. Для удалений это обычно ноль. Операции по уникальному индексу производят многократные операции PK и так увеличивают это количество. Однако, слова данных, посланные, чтобы описать саму операцию PK и ключевую посланную информацию, не посчитаны здесь. Информация атрибута, посланная, чтобы описать столбцы, чтобы читать для просмотров или описать ScanFilters, также не включены в AttrInfoCount. Параллельные операции. Это количество операций первичного ключа или по просмотру, используя этот TC в качестве операционного координатора, которые были начаты во время последнего интервала сообщения, но не были закончены. Операции увеличивают этот счетчик, когда они начаты и уменьшают его, когда закончены, это происходит после того, как транзакция передается. Грязные чтения и записи, а также неудачные операции уменьшают этот счетчик. Максимальное значение, которое Concurrent Operations может иметь, это максимальное количество операций, которые может поддержать блок TC, в настоящее время это (2 * MaxNoOfConcurrentOperations) + 16 + MaxNoOfConcurrentTransactions. Для получения дополнительной информации об этих параметрах конфигурации посмотрите раздел 5.3.6 . Количество аварийного прекращения работы. Это количество транзакций, используя этот TC в качестве операционного координатора, которые были прерваны во время последнего интервала сообщения. Поскольку некоторые транзакции, которые были прерваны в последнем интервале сообщения, возможно, начались в предыдущем интервале сообщения, Abort count может иногда быть больше Trans count. Просмотры. Это количество сканирования таблицы, используя этот TC в качестве операционного координатора, которые были начаты во время последнего интервала сообщения. Это не включает просмотры диапазона (то есть, упорядоченные просмотры индекса). Просмотры диапазона. Это количество упорядоченных просмотров индекса, используя этот TC в качестве операционного координатора, которые были начаты в последнем интервале сообщения. Местные чтения Это количество операций чтения первичного ключа, выполненных, используя операционного координатора на узле, который также содержит основную точную копию отчета. Это количество может также быть получено из LOCAL_READS в таблице ndbinfo.counters. Местные записи. Это содержит количество операций чтения первичного ключа, которые были выполнены, используя операционного координатора на узле, который также содержит основную точную копию отчета. Это количество может также быть получено из LOCAL_WRITES в таблице ndbinfo.counters. Статистика укладчика локального запроса (операции). Есть 1 событие кластера на блок укладчика локального запроса (то есть, 1 на процесс узла данных). Операции зарегистрированы в LQH, где данные, на которые они воздействуют, находятся. Единственная транзакция может воздействовать на данные многих блоках LQH. Operations статистическая величина обеспечивает количество местных операций, выполненных этим блоком LQH в последнем интервале сообщения, и включает все типы операций чтения и записи (вставка, обновление, запись и удаление). Это также включает операции, используемые, чтобы реплицировать записи. Например, в кластере с 2 точными копиями запись основной точной копии зарегистрирована в основном LQH, а запись резервной копии будет зарегистрирована в резервном LQH. Операции по уникальному ключу могут привести к многократным местным операциям, однако, это не включает местные операции, произведенные в результате сканирования таблицы или упорядоченного просмотра индекса, которые не посчитаны. Статистика планировщика процесса. В дополнение к статистике, о которой сообщает операционный координатор и укладчик локального запроса, у каждого процесса ndbd есть планировщик, который также обеспечивает полезные метрики, касающиеся исполнения кластера NDB. Этот планировщик работает в бесконечном цикле, во время каждого цикла планировщик выполняет следующие задачи: Читает любые входящие сообщения от сокетов в буфер. Проверяет, есть ли какие-либо просроченные сообщения, которые будут выполнены, если так, помещает их в буфер. Выполняет (в цикле) любые сообщения в буфере. Посылает любые распределенные сообщения, которые были произведены, выполнив сообщения в буфере. Ждет любых новых входящих сообщений. Статистические данные планировщика процесса включают следующее: Mean Loop Counter. Это количество циклов, выполненных в третьем шаге предыдущего списка. Эта статистическая величина увеличена для улучшения использования буфера TCP/IP. Можно использовать это, чтобы наблюдать изменения в работе, когда вы добавляете новые процессы узла данных. Mean send size and Mean receive size. Эти статистические данные позволяют вам измерить эффективность, соответственно записи и чтения между узлами. значения даны в байтах. Более высокие значения означают более низкую цену за байт, посланный или полученный, максимальное значение 64K. Чтобы вызвать всю статистику, которая будет зарегистрирована, можно использовать следующую команду в клиенте NDB: ndb_mgm> ALL CLUSTERLOG STATISTICS=15 Установка порога для STATISTICS = 15 предписывает регистрации кластера стать очень многословной и вырасти быстро в размере, в прямой пропорции к количеству узлов кластера и объему деятельности в кластере NDB. Для получения дополнительной информации о командах клиента управления кластером NDB, касающихся регистрации и сообщения, посмотрите раздел 7.6.1. 7.7. Сообщения журнала NDB Cluster Эта секция содержит информацию о сообщениях, написанных регистрации кластера в ответ на различные события кластера. Это предоставляет дополнительную более определенную информацию об ошибках транспортера NDB. 7.7.1. NDB Cluster: сообщения в регистрации кластера В следующей таблице перечислены наиболее распространенные сообщения кластера. Для получения информации о регистрации кластера, событиях регистрации и типах событий см. раздел 7.6. Эти сообщения регистрации также соответствуют типам событий регистрации в MGM API, посмотрите The Ndb_logevent_type Type. Таблица 7.13. Общие сообщения регистрации NDB cluster Сообщение Описание Событие Тип Приоритет Важность Node mgm_node_id: Node data_node_id Connected Узел данных, имеющий ID узла node_id, соединился с сервером управления (узел mgm_node_id). Connected Connection 8 INFO Node mgm_node_id: Node data_node_id Disconnected Узел данных, имеющий ID узла data_node_id, разъединился от сервера управления (узел mgm_node_id). Disconnected Connection 8 ALERT Node data_node_id: Communication to Node api_node_id closed Узел API или узел SQL, имеющий ID узла api_node_id больше не общается с узлом данных data_node_id. CommunicationClosed Connection 8 INFO Node data_node_id: Communication to Node api_node_id opened Узел API или узел SQL, имеющий ID узла api_node_id теперь общается с узлом данных data_node_id. CommunicationOpened Connection 8 INFO Node mgm_node_id: Node api_node_id: API version Узел API, имеющий ID узла api_node_id соединился с узлом управления mgm_node_id через NDB API версии version (обычно то же самое, как номер версии MySQL). ConnectedApiVersion Connection 8 INFO Node node_id: Global checkpoint gci started Глобальная контрольная точка с ID gci была начата, узел node_id отвечает за эту глобальную контрольную точку. GlobalCheckpointStarted Checkpoint 9 INFO Node node_id: Global checkpoint gci completed Глобальная контрольная точка, имеющая ID gci была закончена, узел node_id отвечал за эту глобальную контрольную точку. GlobalCheckpointCompleted Checkpoint 10 INFO Node node_id: Local checkpoint lcp started. Keep GCI = current_gci oldest restorable GCI = old_gci Местная контрольная точка, имеющая ID lcp начата на узле node_id. У нового GCI, который может использоваться, есть индекс current_gci и у самого старого GCI, от которого может быть восстановлен кластер, есть индекс old_gci. LocalCheckpointStarted Checkpoint 7 INFO Node node_id: Local checkpoint lcp completed Местная контрольная точка, имеющая ID lcp на узле node_id успешно закончена. LocalCheckpointCompleted Checkpoint 8 INFO Node node_id: Local Checkpoint stopped in CALCULATED_KEEP_GCI Узел был неспособен определить новый применимый GCI. LCPStoppedInCalcKeepGci Checkpoint 0 ALERT Node node_id: Table ID = table_id, fragment ID = fragment_id has completed LCP on Node node_id maxGciStarted: started_gci maxGciCompleted: completed_gci Фрагмент таблицы был сброшен на диск на узле node_id. У происходящего GCI есть индекс started_gci и у нового GCI, который был закончен, есть индекс completed_gci. LCPFragmentCompleted Checkpoint 11 INFO Node node_id: ACC Blocked num_1 and TUP Blocked num_2 times last second Регистрация отмен заблокирована, потому что буфер регистрации близок к переполнению. UndoLogBlocked Checkpoint 7 INFO Node node_id: Start initiated version Узел данных node_id, работающий с NDB версии version, начал запуск. NDBStartStarted StartUp 1 INFO Node node_id: Started version Узел данных node_id, работающий с NDB версии version, успешно запущен. NDBStartCompleted StartUp 1 INFO Node node_id: STTORRY received after restart finished Узел получил сигнал, указывающий, что перезапуск кластера закончен. STTORRYRecieved StartUp 15 INFO Node node_id: Start phase phase completed (type) Узел закончил фазу запуска phase из type. Для списка фаз посмотрите раздел 7.1. (type одно из initial, system, node, initial node, или <Unknown>). StartPhaseCompleted StartUp 4 INFO Node node_id: CM_REGCONF president = president_id, own Node = own_id, our dynamic id = dynamic_id Узел president_id был отобран как president. own_id и dynamic_id должны всегда совпадать с ID (node_id) узла сообщения. CM_REGCONF StartUp 3 INFO Node node_id: CM_REGREF from Node president_id to our Node node_id. Cause = cause Узел сообщения (ID node_id) был неспособен принять узел president_id как president. Причина проблемы дана как одно из Busy, Election with wait = false, Not president, Election without selecting new candidate, or No such cause. CM_REGREF StartUp 8 INFO Node node_id: We are Node own_id with dynamic ID dynamic_id, our left neighbor is Node id_1, our right is Node id_2 Узел обнаружил свои соседние узлы в кластере (узлы id_1 и id_2). node_id, own_id и dynamic_id должны всегда быть теми же самыми, если это не так, это указывает на серьезную неверную конфигурацию узлов кластера. FIND_NEIGHBOURS StartUp 8 INFO Node node_id: type shutdown initiated Узел получил сигнал закрытия. type закрытия также Cluster или Node. NDBStopStarted StartUp 1 INFO Node node_id: Node shutdown completed [, action] [Initiated by signal signal.] Узел был закрыт. Этот доклад может включать в себя action, который, если существует, один из restarting, no start или initial. Доклад может также включать в себя ссылку на NDB Protocol signal, см. Operations and Signals. NDBStopCompleted StartUp 1 INFO Node node_id: Forced node shutdown completed [, action]. [Occurred during startphase start_phase.] [ Initiated by signal.] [Caused by error error_code: 'error_message (error_classification). error_status'. [(extra info extra_code)]] Узел был принудительно закрыт. action (одно из restarting, no start, or initial) также указан, если есть. Если закрытие произошло в то время, как узел запускался, доклад включает в себя start_phase во время которой потерпел неудачу узел. Если это было результатом отправки узлу сигнала signal, эта информация также предоставляется (см. Operations and Signals). Если ошибка, вызвавшая сбой, известна, это также включено, см. NDB Cluster API Errors. NDBStopForced StartUp 1 ALERT Node node_id: Node shutdown aborted Процесс закрытия узла был прерван пользователем. NDBStopAborted StartUp 1 INFO Node node_id: StartLog: [GCI Keep: keep_pos LastCompleted: last_pos NewestRestorable: restore_pos] Это сообщает о глобальных контрольных точках, на которые ссылаются во время запуска узла. Журнал отката до keep_pos удален. last_pos это последняя глобальная контрольная точка, в которой узел данных участвовал, restore_pos это глобальная контрольная точка, которая на самом деле используется, чтобы восстановить все узлы данных. StartREDOLog StartUp 4 INFO startup_message [Listed separately; see below.] Есть много возможных сообщений запуска, которые могут быть зарегистрированы при различных обстоятельствах. Они перечисляются отдельно, см. раздел 7.7.2. StartReport StartUp 4 INFO Node node_id: Node restart completed copy of dictionary information Копирование информации словаря данных перезапущенному узлу было закончено. NR_CopyDict NodeRestart 8 INFO Node node_id: Node restart completed copy of distribution information Копирование информации о распределении данных перезапущенному узлу было закончено. NR_CopyDistr NodeRestart 8 INFO Node node_id: Node restart starting to copy the fragments to Node node_id Копирование фрагментов к запускаемому узлу данных node_id началось NR_CopyFragsStarted NodeRestart 8 INFO Node node_id: Table ID = table_id, fragment ID = fragment_id have been copied to Node node_id Фрагмент fragment_id таблицы table_id скопирован узлу данных node_id NR_CopyFragDone NodeRestart 10 INFO Node node_id: Node restart completed copying the fragments to Node node_id Копирование всех фрагментов таблицы перезапускаемому узлу данных node_id завершено NR_CopyFragsCompleted NodeRestart 8 INFO Node node_id: Node node1_id completed failure of Node node2_id Узел данных node1_id обнаружил сбой узла данных node2_id NodeFailCompleted NodeRestart 8 ALERT All nodes completed failure of Node node_id Все (остающиеся) узлы данных обнаружили сбой узла данных node_id NodeFailCompleted NodeRestart 8 ALERT Node failure of node_id block completed Сбой узла данных node_id был обнаружен в ядерном блоке block NDB, где block это 1 из DBTC, DBDICT, DBDIH или DBLQH, см. NDB Kernel Blocks NodeFailCompleted NodeRestart 8 ALERT Node mgm_node_id: Node data_node_id has failed. The Node state at failure was state_code Узел данных потерпел неудачу. Его статус во время неудачи описан арбитражным кодом статуса state_code, возможные статусные кодовые обозначения могут быть найдены в файле include/kernel/signaldata/ArbitSignalData.hpp. NODE_FAILREP NodeRestart 8 ALERT President restarts arbitration thread [state=state_code] or Prepare arbitrator node node_id [ticket=ticket_id] or Receive arbitrator node node_id [ticket=ticket_id] or Started arbitrator node node_id [ticket=ticket_id] or Lost arbitrator node node_id - process failure [state=state_code] or Lost arbitrator node node_id - process exit [state=state_code] or Lost arbitrator node node_id - error_message [state=state_code] Это отчет о текущем состоянии и прогрессе арбитража в кластере. node_id это ID узла управления или SQL, выбранного как арбитр. state_code это арбитражный код, см. include/kernel/signaldata/ArbitSignalData.hpp. Когда ошибка произошла, error_message, также определенное в ArbitSignalData.hpp, предоставлено. ticket_id это уникальный идентификатор, созданный арбитром, когда он выбран всеми узлами, которые участвовали в его выборе, это используется, чтобы гарантировать, что каждый узел, запрашивающий арбитраж, был одним из узлов, которые приняли участие в процессе выбора. ArbitState NodeRestart 6 INFO Arbitration check lost - less than 1/2 nodes left or Arbitration check won - all node groups and more than 1/2 nodes left or Arbitration check won - node group majority or Arbitration check lost - missing node group or Network partitioning - arbitration required or Arbitration won - positive reply from node node_id or Arbitration lost - negative reply from node node_id or Network partitioning - no arbitrator available or Network partitioning - no arbitrator configured or Arbitration failure - error_message [state=state_code] Это сообщение сообщает относительно результата арбитража. В случае арбитражной неудачи error_message и арбитражный state_code предоставлены, определения для обоих из них найдены в include/kernel/signaldata/ArbitSignalData.hpp. ArbitResult NodeRestart 2 ALERT Node node_id: GCP Take over started Этот узел пытается принять на себя ответственность за следующую глобальную контрольную точку (то есть, это становится главным узлом) GCP_TakeoverStarted NodeRestart 7 INFO Node node_id: GCP Take over completed Этот узел стал ведущим и принял на себя ответственность за следующую глобальную контрольную точку GCP_TakeoverCompleted NodeRestart 7 INFO Node node_id: LCP Take over started Этот узел пытается принять на себя ответственность за следующий набор местных контрольных точек (то есть, это становится главным узлом) LCP_TakeoverStarted NodeRestart 7 INFO Node node_id: LCP Take over completed Этот узел стал ведущим и принял на себя ответственность за следующий набор местных контрольных точек LCP_TakeoverCompleted NodeRestart 7 INFO Node node_id: Trans. Count = transactions, Commit Count = commits, Read Count = reads, Simple Read Count = simple_reads, Write Count = writes, AttrInfo Count = AttrInfo_objects, Concurrent Operations = concurrent_operations, Abort Count = aborts, Scans = scans, Range scans = range_scans Это сообщение о действии транзакций дано приблизительно один раз в 10 секунд TransReportCounters Statistic 8 INFO Node node_id: Operations=operations Количество операций, выполняемых этим узлом, дано приблизительно один раз в 10 секунд OperationReportCounters Statistic 8 INFO Node node_id: Table with ID = table_id created Таблица, имеющая этот ID, была составлена TableCreated Statistic 7 INFO Node node_id: Mean loop Counter in doJob last 8192 times = count JobStatistic Statistic 9 INFO Mean send size to Node = node_id last 4096 sends = bytes bytes Этот узел посылает в среднем bytes байт за передачу узлу node_id SendBytesStatistic Statistic 9 INFO Mean receive size to Node = node_id last 4096 sends = bytes bytes Этот узел получает в среднем bytes байт данных каждый раз, когда получает данные от узла node_id ReceiveBytesStatistic Statistic 9 INFO Node node_id: Data usage is data_memory_percentage% (data_pages_used 32K pages of total data_pages_total) / Node node_id: Index usage is index_memory_percentage% (index_pages_used 8K pages of total index_pages_total) Этот отчет произведен, когда DUMP 1000 выдается в клиенте управления кластером MemoryUsage Statistic 5 INFO Node node1_id: Transporter to node node2_id reported error error_code: error_message Ошибка транспортера произошла, общаясь с узлом node2_id, для списка кодов ошибок транспортера и сообщений см. NDB Transporter Errors в MySQL NDB Cluster Internals Manual TransporterError Error 2 ERROR Node node1_id: Transporter to node node2_id reported error error_code: error_message Предупреждение потенциальной проблемы транспортера, общаясь с узлом node2_id, для списка кодов ошибок транспортера и сообщений см. NDB Transporter Errors TransporterWarning Error 8 WARNING Node node1_id: Node node2_id missed heartbeat heartbeat_id Этот узел пропустил синхроимпульс от узла node2_id MissedHeartbeat Error 8 WARNING Node node1_id: Node node2_id declared dead due to missed heartbeat Этот узел пропустил по крайней мере 3 синхроимпульса от узла node2_id и объявлен мертвым DeadDueToHeartbeat Error 8 ALERT Node node1_id: Node Sent Heartbeat to node = node2_id Этот узел послал синхроимпульс в узел node2_id SentHeartbeat Info 12 INFO (NDB 7.5.0 и ранее) Node node_id: Event buffer status: used=bytes_used (percent_used%) alloc=bytes_allocated (percent_available%) max=bytes_available apply_epoch=latest_restorable_epoch latest_epoch=latest_epoch Этот отчет создается во время тяжелого использования буфера событий, например, когда много обновлений применяются за относительно короткий период времени, отчет показывает число байтов и процент используемой буферной памяти событий, ассигнованные байты и проценты все еще доступной памяти и последние восстанавливаемые эпохи EventBufferStatus Info 7 INFO (NDB 7.5.1 и позэе) Node node_id: Event buffer status (object_id): used=bytes_used (percent_used% of alloc) alloc=bytes_allocated max=bytes_available latest_consumed_epoch=latest_consumed_epoch latest_buffered_epoch=latest_buffered_epoch report_reason=report_reason Этот отчет создается во время тяжелого использования буфера событий, например, когда много обновлений применяются за относительно короткий период времени, отчет показывает число байтов и процент используемой буферной памяти событий, ассигнованные байты и проценты все еще доступной памяти и потребляемые эпохи, для получения дополнительной информации посмотрите раздел 7.7.3 EventBufferStatus2 Info 7 INFO Node node_id: Entering single user mode, Node node_id: Entered single user mode Node API_node_id has exclusive access, Node node_id: Entering single user mode Эти записи написаны к регистрации кластера, входя и выходя из однопользовательского режима, API_node_id это ID API или SQL, имеющего эксклюзивный доступ к кластеру (для получения дополнительной информации см. раздел 7.8), сообщение Unknown single user report API_node_id указывает, что ошибка произошла и никогда не должна возникать при нормальном функционировании SingleUser Info 7 INFO Node node_id: Backup backup_id started from node mgm_node_id Резервная копия была начата, используя наличие узла управления mgm_node_id, это сообщение также показано в клиенте управления кластером, когда выполняется команда START BACKUP, см. раздел 7.3.2 BackupStarted Backup 7 INFO Node node_id: Backup backup_id started from node mgm_node_id completed. StartGCP: start_gcp StopGCP: stop_gcp #Records: records #LogRecords: log_records Data: data_bytes bytes Log: log_bytes bytes Резервная копия, имеющая ID backup_id , закончена, для получения дополнительной информации посмотрите раздел 7.3.2 BackupCompleted Backup 7 INFO Node node_id: Backup request from mgm_node_id failed to start. Error: error_code Резервная копия не началась, для кодов ошибок посмотрите MGM API Errors BackupFailedToStart Backup 7 ALERT Node node_id: Backup backup_id started from mgm_node_id has been aborted. Error: error_code Резервная копия была закончена после старта, возможно из-за вмешательства пользователя BackupAborted Backup 7 ALERT 7.7.2. Сообщения запуска NDB Cluster Возможные сообщения запуска с описаниями предоставлены в следующем списке: Initial start, waiting for %s to connect, nodes [all: %s connected: %s no-wait: %s] Waiting until nodes: %s connects, nodes [all: %s connected: %s no-wait: %s] Waiting %u sec for nodes %s to connect, nodes [all: %s connected: %s no-wait: %s] Waiting for non partitioned start, nodes [all: %s connected: %s missing: %s no-wait: %s] Waiting %u sec for non partitioned start, nodes [all: %s connected: %s missing: %s no-wait: %s] Initial start with nodes %s [missing: %s no-wait: %s] Start with all nodes %s Start with nodes %s [missing: %s no-wait: %s] Start potentially partitioned with nodes %s [missing: %s no-wait: %s] Unknown startreport: 0x%x [%s %s %s %s] 7.7.3. Сообщения о буфере событий NDB применяет один или несколько буферов памяти для событий от узлов данных. Есть один такой буфер для каждого объекта Ndb, подписывающегося на события таблицы, что означает, что обычно есть два буфера для каждого mysqld (один буфер для событий схемы, и один для событий данных). Каждый буфер содержит эпохи, составленные из событий. Эти события состоят из операционных типов (вставка, обновление, удаление) и данных о строке (перед и после изменений плюс метаданные). NDB производит сообщения в регистрации кластера, чтобы описать статус этих буферов. Хотя эти записи появляются в регистрации кластера, они обращаются к буферам на узлах API (в отличие от большинства других сообщений кластера, которые произведены узлами данных). Эти сообщения и структуры данных, лежащие в основе их, были изменены значительно в NDB 7.5.1 с добавлением типа NDB_LE_EventBufferStatus2 и структуры ndb_logevent_EventBufferStatus2 (см. The Ndb_logevent_type Type). Остаток от этого обсуждения сосредотачивается на внедрении на основе NDB_LE_EventBufferStatus2. Записи о буфере событий в регистрации кластера используют формат, показанный здесь: Node node_id: Event buffer status (object_id): used=bytes_used (percent_used% of alloc) alloc=bytes_allocated (percent_alloc% of max) max=bytes_available latest_consumed_epoch=latest_consumed_epoch latest_buffered_epoch=latest_buffered_epoch report_reason=report_reason Области, составляющие этот отчет, перечисляются здесь с описаниями: node_id: ID узла, где порожден отчет. object_id: ID объекта Ndb где порожден отчет. bytes_used: Число байтов используется буфером. percent_used: Процент задействования ассигнованных байтов. bytes_allocated: Число байтов ассигнуется этому буферу. percent_alloc: Процент использования доступных байтов, не напечатано, если ndb_eventbuffer_max_alloc = 0 (unlimited). bytes_available: Число доступных байтов, это 0, если ndb_eventbuffer_max_alloc = 0 (unlimited). latest_consumed_epoch: Эпоха, которая в последний раз была предназначена для завершения. В приложениях API NDB это сделано, вызывая nextEvent(). latest_buffered_epoch: Эпоха, последний раз буферизованная (полностью) в буфере событий. report_reason: Причина отчета. Возможные причины показывают позже в этой секции. latest_consumed_epoch и latest_buffered_epoch соответствуют apply_gci и latest_gci в старинном стиле сообщений, используемых до NDB 7.5.1. Возможные причины для сообщения описаны в следующем списке: ENOUGH_FREE_EVENTBUFFER: У буфера событий есть достаточно места. LOW_FREE_EVENTBUFFER: Буфер событий испытывает нехватку свободного места. Порог процента свободного места, вызывающий эти записи, может быть приспособлен, установив переменную ndb_report_thresh_binlog_mem_usage. BUFFERED_EPOCHS_OVER_THRESHOLD: Превысило ли число буферизированных эпох формируемый порог. Это число различие между последней эпохой, которая была получена в целом, и эпохой, которая последний раз потреблялась (в приложениях API NDB это сделано, вызывая nextEvent() или nextEvent2()). Отчет производится каждую секунду, пока число буферизированных эпох не понижается до порога, который может быть приспособлен, установив переменную ndb_report_thresh_binlog_epoch_slip. Можно также приспособить порог в приложениях API NDB, вызвав setEventBufferQueueEmptyEpoch() . PARTIALLY_DISCARDING: Буферная память событий исчерпана, то есть использовано 100% ndb_eventbuffer_max_alloc. Любая частично буферизированная эпоха буферизована до конца, даже если использование превышает 100%, но от любых новых полученных эпох отказываются. Это означает, что промежуток произошел в потоке событий. COMPLETELY_DISCARDING: Никакие эпохи не буферизованы. PARTIALLY_BUFFERING: Буферный свободный процент после промежутка повысился до порога, который может быть установлен в клиенте mysql через переменную ndb_eventbuffer_free_percent или в приложениях API NDB, вызывая set_eventbuffer_free_percent(). Буферизованы новые эпохи. Отказываются от эпох, которые не могли быть закончены из-за промежутка. COMPLETELY_BUFFERING: Все полученные эпохи буферизуются, что означает, что есть достаточная буферная память событий. Разрыв в потоке событий был преодолен. 7.7.4. NDB Cluster: ошибки транспортера NDB Эта секция перечисляет коды ошибок, имена и сообщения, которые написаны регистрации кластера в случае ошибок транспортера. 0x00 TE_NO_ERROR No error 0x01 TE_ERROR_CLOSING_SOCKET Error found during closing of socket 0x02 TE_ERROR_IN_SELECT_BEFORE_ACCEPT Error found before accept. The transporter will retry 0x03 TE_INVALID_MESSAGE_LENGTH Error found in message (invalid message length) 0x04 TE_INVALID_CHECKSUM Error found in message (checksum) 0x05 TE_COULD_NOT_CREATE_SOCKET Error found while creating socket (can't create socket) 0x06 TE_COULD_NOT_BIND_SOCKET Error found while binding server socket 0x07 TE_LISTEN_FAILED Error found while listening to server socket 0x08 TE_ACCEPT_RETURN_ERROR Error found during accept (accept return error) 0x0b TE_SHM_DISCONNECT The remote node has disconnected 0x0c TE_SHM_IPC_STAT Unable to check shm segment 0x0d TE_SHM_UNABLE_TO_CREATE_SEGMENT Unable to create shm segment 0x0e TE_SHM_UNABLE_TO_ATTACH_SEGMENT Unable to attach shm segment 0x0f TE_SHM_UNABLE_TO_REMOVE_SEGMENT Unable to remove shm segment 0x10 TE_TOO_SMALL_SIGID Sig ID too small 0x11 TE_TOO_LARGE_SIGID Sig ID too large 0x12 TE_WAIT_STACK_FULL Wait stack was full 0x13 TE_RECEIVE_BUFFER_FULL Receive buffer was full 0x14 TE_SIGNAL_LOST_SEND_BUFFER_FULL Send buffer was full, and trying to force send fails 0x15 TE_SIGNAL_LOST Send failed for unknown reason (signal lost) 0x16 TE_SEND_BUFFER_FULL The send buffer was full, but sleeping for a while solved 0x21 TE_SHM_IPC_PERMANENT Shm ipc Permanent error Коды ошибок транспортера с 0x17 по 0x20 и 0x22 резервируются для связей SCI, которые не поддерживаются в этой версии кластера NDB, и не включены здесь. 7.8. NDB Cluster Single User Mode Single user mode позволяет администратору базы данных ограничить доступ к системе баз данных к единственному узлу API, такому как сервер MySQL (узел SQL) или ndb_restore. Входя в однопользовательский режим, связи со всеми другими узлами API закрываются правильно и прерываются все работающие транзакции. Никаким новым транзакциям не разрешают начаться. Как только кластер вошел в однопользовательский режим, только определяемому узлу API предоставляют доступ к базе данных. Можно использовать ALL STATUS в клиенте ndb_mgm, чтобы видеть, когда кластер вошел в однопользовательский режим. Можно также проверить столбец status таблицы ndbinfo.nodes (см. раздел 7.10.28). Например: ndb_mgm> ENTER SINGLE USER MODE 5 После того, как эта команда выполнилась, кластер вошел в однопользовательский режим, узел API, узел которого ID 5 становится единственным разрешенным пользователем кластера. Узел, определенный в предыдущей команде, должен быть узлом API, попытка определить любой другой тип узла будет отклонена. Когда предыдущая команда вызвана, все транзакции, работающие на определяемом узле, прерываются, связь закрывается, и сервер должен быть перезапущен. Команда EXIT SINGLE USER MODE изменяет статус узлов данных кластера от однопользовательского режима до нормального. Узлы API, такие как MySQL Server, ждущие связи (то есть, ожидая доступности кластера), снова могут соединиться. Узел API, обозначенный как однопользовательский узел, продолжает работать (если все еще подключен) в течение и после изменения состояния. Например: ndb_mgm> EXIT SINGLE USER MODE Есть два рекомендуемых способа обращаться со сбоем узла, работая в однопользовательском режиме: Метод 1: Закончите все транзакции однопользовательского режима Выполните EXIT SINGLE USER MODE Перезапустите узлы данных кластера Метод 2: Перезапустите узлы хранения до входа в однопользовательский режим. 7.9. SQL-операторы NDB Cluster Эта секция обсуждает несколько SQL-операторов, которые могут оказаться полезными в управлении и контроле сервера MySQL, который связан с кластером NDB, и в некоторых случаях предоставляют информацию о самом кластере. SHOW ENGINE NDB STATUS, SHOW ENGINE NDBCLUSTER STATUS. Вывод этого запроса содержит информацию о связи сервера с кластером, создании и использовании объектов кластера NDB и двоичной регистрации для репликации кластера NDB. См. SHOW ENGINE Statement. SHOW ENGINES Этот запрос может использоваться, чтобы определить, позволено ли объединение в кластеры в сервере MySQL, и если так, активно ли это. См. SHOW ENGINES Statement. Этот запрос не поддерживает LIKE. Однако, можно использовать LIKE, чтобы отфильтровать запросы по таблице INFORMATION_SCHEMA.ENGINES . SELECT * FROM INFORMATION_SCHEMA.ENGINES [WHERE ENGINE LIKE 'NDB%'] Аналог SHOW ENGINES, но использует таблицу ENGINES БД INFORMATION_SCHEMA. В отличие от случая с SHOW ENGINES, возможно отфильтровать результаты, используя LIKE, и выбрать определенные столбцы, чтобы получить информацию, которая может быть полезной в скриптах. Например, следующий запрос показывает, был ли сервер построен с поддержкой NDB и, если так, позволено ли это: mysql> SELECT SUPPORT FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE LIKE 'NDB%'; +---------+ | support | +---------+ | ENABLED | +---------+ См. The INFORMATION_SCHEMA ENGINES Table. SHOW VARIABLES LIKE 'NDB%' Этот запрос предоставляет список большинства системных переменных сервера, касающихся NDB и их значения, как показано здесь, используя NDB 7.6: mysql> SHOW VARIABLES LIKE 'NDB%'; +--------------------------------------+---------------------------------------+ | Variable_name | Value | +--------------------------------------+---------------------------------------+ | ndb_allow_copying_alter_table | ON | | ndb_autoincrement_prefetch_sz | 1 | | ndb_batch_size | 32768 | | ndb_blob_read_batch_bytes | 65536 | | ndb_blob_write_batch_bytes | 65536 | | ndb_cache_check_time | 0 | | ndb_clear_apply_status | ON | | ndb_cluster_connection_pool | 1 | | ndb_cluster_connection_pool_nodeids | | | ndb_connectstring | 127.0.0.1 | | ndb_data_node_neighbour | 0 | | ndb_default_column_format | FIXED | | ndb_deferred_constraints | 0 | | ndb_distribution | KEYHASH | | ndb_eventbuffer_free_percent | 20 | | ndb_eventbuffer_max_alloc | 0 | | ndb_extra_logging | 1 | | ndb_force_send | ON | | ndb_fully_replicated | OFF | | ndb_index_stat_enable | ON | | ndb_index_stat_option | loop_enable=1000ms,loop_idle=1000ms, loop_busy=100ms,update_batch=1,read_batch=4,idle_batch=32,check_batch=8, check_delay=10m,delete_batch=8,clean_delay=1m,error_batch=4,error_delay=1m, evict_batch=8,evict_delay=1m,cache_limit=32M,cache_lowpct=90,zero_total=0| | ndb_join_pushdown | ON | | ndb_log_apply_status | OFF | | ndb_log_bin | ON | | ndb_log_binlog_index | ON | | ndb_log_empty_epochs | OFF | | ndb_log_empty_update | OFF | | ndb_log_exclusive_reads | OFF | | ndb_log_orig | OFF | | ndb_log_transaction_id | OFF | | ndb_log_update_as_write | ON | | ndb_log_update_minimal | OFF | | ndb_log_updated_only | ON | | ndb_mgmd_host | 127.0.0.1 | | ndb_nodeid | 0 | | ndb_optimization_delay | 10 | | ndb_optimized_node_selection | 3 | | ndb_read_backup | OFF | | ndb_recv_thread_activation_threshold | 8 | | ndb_recv_thread_cpu_mask | | | ndb_report_thresh_binlog_epoch_slip | 10 | | ndb_report_thresh_binlog_mem_usage | 10 | | ndb_row_checksum | 1 | | ndb_show_foreign_key_mock_tables | OFF | | ndb_slave_conflict_role | NONE | | ndb_table_no_logging | OFF | | ndb_table_temporary | OFF | | ndb_use_copying_alter_table | OFF | | ndb_use_exact_count | OFF | | ndb_use_transactions | ON | | ndb_version | 460301 | | ndb_version_string | ndb-7.6.13 | | ndb_wait_connected | 30 | | ndb_wait_setup | 30 | | ndbinfo_database | ndbinfo | | ndbinfo_max_bytes | 0 | | ndbinfo_max_rows | 10 | | ndbinfo_offline | OFF | | ndbinfo_show_hidden | OFF | | ndbinfo_table_prefix | ndb$ | | ndbinfo_version | 460301 | +--------------------------------------+---------------------------------------+ 61 rows in set (0.02 sec) См. Server System Variables. SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE VARIABLE_NAME LIKE 'NDB%'; Хотя это устарело в NDB 7.5 и NDB 7.6, можно использовать этот запрос (и другие, получающие доступ к таблице INFORMATION_SCHEMA.GLOBAL_VARIABLES), если включено show_compatibility_56. Запрос к таблице performance_schema.global_variables предпочтен, см. ниже. Это аналог SHOW VARIABLES и вывод дает такой же: mysql> SET @@global.show_compatibility_56=ON; Query OK, 0 rows affected (0.00 sec) mysql> SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE VARIABLE_NAME LIKE 'NDB%'; mysql> SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE VARIABLE_NAME LIKE 'NDB%'; +--------------------------------------+---------------------------------------+ | VARIABLE_NAME | VARIABLE_VALUE | +--------------------------------------+---------------------------------------+ | NDB_CLUSTER_CONNECTION_POOL_NODEIDS | | | NDB_LOG_BINLOG_INDEX | ON | | NDB_WAIT_SETUP | 30 | | NDB_ROW_CHECKSUM | 1 | | NDB_WAIT_CONNECTED | 30 | | NDB_USE_EXACT_COUNT | OFF | | NDB_RECV_THREAD_ACTIVATION_THRESHOLD | 8 | | NDB_READ_BACKUP | OFF | | NDB_EVENTBUFFER_MAX_ALLOC | 0 | | NDBINFO_DATABASE | ndbinfo | | NDB_LOG_APPLY_STATUS | OFF | | NDB_JOIN_PUSHDOWN | ON | | NDB_RECV_THREAD_CPU_MASK | | | NDBINFO_VERSION | 460301 | | NDB_CONNECTSTRING | 127.0.0.1 | | NDB_TABLE_NO_LOGGING | OFF | | NDB_LOG_UPDATED_ONLY | ON | | NDB_VERSION | 460301 | | NDB_LOG_UPDATE_MINIMAL | OFF | | NDB_OPTIMIZATION_DELAY | 10 | | NDB_DEFAULT_COLUMN_FORMAT | FIXED | | NDB_LOG_UPDATE_AS_WRITE | ON | | NDB_SHOW_FOREIGN_KEY_MOCK_TABLES | OFF | | NDB_VERSION_STRING | ndb-7.6.13 | | NDBINFO_OFFLINE | OFF | | NDB_INDEX_STAT_OPTION | loop_enable=1000ms,loop_idle=1000ms, loop_busy=100ms,update_batch=1,read_batch=4,idle_batch=32,check_batch=8, check_delay=10m,delete_batch=8,clean_delay=1m,error_batch=4,error_delay=1m, evict_batch=8,evict_delay=1m,cache_limit=32M,cache_lowpct=90,zero_total=0 | | NDBINFO_MAX_ROWS | 10 | | NDB_BATCH_SIZE | 32768 | | NDB_USE_TRANSACTIONS | ON | | NDB_NODEID | 0 | | NDB_ALLOW_COPYING_ALTER_TABLE | ON | | NDB_SLAVE_CONFLICT_ROLE | NONE | | NDB_REPORT_THRESH_BINLOG_MEM_USAGE | 10 | | NDB_FULLY_REPLICATED | OFF | | NDB_MGMD_HOST | 127.0.0.1 | | NDB_REPORT_THRESH_BINLOG_EPOCH_SLIP | 10 | | NDBINFO_MAX_BYTES | 0 | | NDB_LOG_BIN | ON | | NDBINFO_TABLE_PREFIX | ndb$ | | NDB_LOG_EMPTY_EPOCHS | OFF | | NDB_LOG_ORIG | OFF | | NDB_LOG_EXCLUSIVE_READS | OFF | | NDB_LOG_TRANSACTION_ID | OFF | | NDB_DATA_NODE_NEIGHBOUR | 0 | | NDB_CLEAR_APPLY_STATUS | ON | | NDBINFO_SHOW_HIDDEN | OFF | | NDB_INDEX_STAT_ENABLE | ON | | NDB_DISTRIBUTION | KEYHASH | | NDB_BLOB_WRITE_BATCH_BYTES | 65536 | | NDB_DEFERRED_CONSTRAINTS | 0 | | NDB_TABLE_TEMPORARY | OFF | | NDB_EXTRA_LOGGING | 1 | | NDB_AUTOINCREMENT_PREFETCH_SZ | 1 | | NDB_FORCE_SEND | ON | | NDB_OPTIMIZED_NODE_SELECTION | 3 | | NDB_CLUSTER_CONNECTION_POOL | 1 | | NDB_EVENTBUFFER_FREE_PERCENT | 20 | | NDB_USE_COPYING_ALTER_TABLE | OFF | | NDB_CACHE_CHECK_TIME | 0 | | NDB_BLOB_READ_BATCH_BYTES | 65536 | | NDB_LOG_EMPTY_UPDATE | OFF | +--------------------------------------+---------------------------------------+ 61 rows in set, 1 warning (0.00 sec) mysql> SHOW WARNINGS; +---------+------+-------------------------------------------------------------+ | Level | Code | Message | +---------+------+-------------------------------------------------------------+ | Warning | 1287 | 'INFORMATION_SCHEMA.GLOBAL_VARIABLES' is deprecated and will be removed in a future release. Please use performance_schema.global_variables instead | +---------+------+-------------------------------------------------------------+ В отличие от случая с SHOW VARIABLES, возможно выбрать отдельные столбцы. Например: mysql> SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE VARIABLE_NAME = 'ndb_force_send'; +----------------+ | VARIABLE_VALUE | +----------------+ | ON | +----------------+ См. The INFORMATION_SCHEMA GLOBAL_VARIABLES and SESSION_VARIABLES Tables и Server System Variables, см. также Migrating to Performance Schema System and Status Variable Tables. SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME LIKE 'NDB%' Этот запрос эквивалент SHOW VARIABLES из предыдущего пункта и предпочтен в NDB 7.5 и NDB 7.6 для запроса к таблице INFORMATION_SCHEMA.GLOBAL_VARIABLES (устарело, посмотрите предыдущий пункт). Это обеспечивает вывод, почти идентичный произведенному SHOW VARIABLES: mysql> SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME LIKE 'NDB%'; +--------------------------------------+---------------------------------------+ | VARIABLE_NAME | VARIABLE_VALUE | +--------------------------------------+---------------------------------------+ | ndb_allow_copying_alter_table | ON | | ndb_autoincrement_prefetch_sz | 1 | | ndb_batch_size | 32768 | | ndb_blob_read_batch_bytes | 65536 | | ndb_blob_write_batch_bytes | 65536 | | ndb_cache_check_time | 0 | | ndb_clear_apply_status | ON | | ndb_cluster_connection_pool | 1 | | ndb_cluster_connection_pool_nodeids | | | ndb_connectstring | 127.0.0.1 | | ndb_data_node_neighbour | 0 | | ndb_default_column_format | FIXED | | ndb_deferred_constraints | 0 | | ndb_distribution | KEYHASH | | ndb_eventbuffer_free_percent | 20 | | ndb_eventbuffer_max_alloc | 0 | | ndb_extra_logging | 1 | | ndb_force_send | ON | | ndb_fully_replicated | OFF | | ndb_index_stat_enable | ON | | ndb_index_stat_option | loop_enable=1000ms,loop_idle=1000ms, loop_busy=100ms,update_batch=1,read_batch=4,idle_batch=32,check_batch=8, check_delay=10m,delete_batch=8,clean_delay=1m,error_batch=4,error_delay=1m, evict_batch=8,evict_delay=1m,cache_limit=32M,cache_lowpct=90,zero_total=0 | | ndb_join_pushdown | ON | | ndb_log_apply_status | OFF | | ndb_log_bin | ON | | ndb_log_binlog_index | ON | | ndb_log_empty_epochs | OFF | | ndb_log_empty_update | OFF | | ndb_log_exclusive_reads | OFF | | ndb_log_orig | OFF | | ndb_log_transaction_id | OFF | | ndb_log_update_as_write | ON | | ndb_log_update_minimal | OFF | | ndb_log_updated_only | ON | | ndb_mgmd_host | 127.0.0.1 | | ndb_nodeid | 0 | | ndb_optimization_delay | 10 | | ndb_optimized_node_selection | 3 | | ndb_read_backup | OFF | | ndb_recv_thread_activation_threshold | 8 | | ndb_recv_thread_cpu_mask | | | ndb_report_thresh_binlog_epoch_slip | 10 | | ndb_report_thresh_binlog_mem_usage | 10 | | ndb_row_checksum | 1 | | ndb_show_foreign_key_mock_tables | OFF | | ndb_slave_conflict_role | NONE | | ndb_table_no_logging | OFF | | ndb_table_temporary | OFF | | ndb_use_copying_alter_table | OFF | | ndb_use_exact_count | OFF | | ndb_use_transactions | ON | | ndb_version | 460301 | | ndb_version_string | ndb-7.6.13 | | ndb_wait_connected | 30 | | ndb_wait_setup | 30 | | ndbinfo_database | ndbinfo | | ndbinfo_max_bytes | 0 | | ndbinfo_max_rows | 10 | | ndbinfo_offline | OFF | | ndbinfo_show_hidden | OFF | | ndbinfo_table_prefix | ndb$ | | ndbinfo_version | 460301 | +--------------------------------------+---------------------------------------+ В отличие от случая с SHOW VARIABLES, возможно выбрать отдельные столбцы. Например: mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'ndb_force_send'; +----------------+ | VARIABLE_VALUE | +----------------+ | ON | +----------------+ Более полезный запрос показывают здесь: mysql> SELECT VARIABLE_NAME AS Name, VARIABLE_VALUE AS Value FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('version', 'ndb_version', 'ndb_version_string', 'ndbinfo_version'); +--------------------+-------------------+ | Name | Value | +--------------------+-------------------+ | ndb_version | 460301 | | ndb_version_string | ndb-7.6.13 | | ndbinfo_version | 460301 | | version | 5.7.29-ndb-7.6.13 | +--------------------+-------------------+ См. Performance Schema System Variable Tables и Server System Variables. SHOW STATUS LIKE 'NDB%' Это запрос показывает, действует ли сервер MySQL как кластерный узел SQL, и если так, это предоставляет узлу кластера сервера MySQL ID, имя хоста и порт для сервера управления кластера, с которым это связано, и количество узлов данных в кластере, как показано здесь: mysql> SHOW STATUS LIKE 'NDB%'; +----------------------------------------------+-------------------------------+ | Variable_name | Value | +----------------------------------------------+-------------------------------+ | Ndb_api_wait_exec_complete_count | 2 | | Ndb_api_wait_scan_result_count | 5 | | Ndb_api_wait_meta_request_count | 54 | | Ndb_api_wait_nanos_count | 1849442202547 | | Ndb_api_bytes_sent_count | 2044 | | Ndb_api_bytes_received_count | 81384 | | Ndb_api_trans_start_count | 2 | | Ndb_api_trans_commit_count | 1 | | Ndb_api_trans_abort_count | 0 | | Ndb_api_trans_close_count | 2 | | Ndb_api_pk_op_count | 1 | | Ndb_api_uk_op_count | 0 | | Ndb_api_table_scan_count | 1 | | Ndb_api_range_scan_count | 0 | | Ndb_api_pruned_scan_count | 0 | | Ndb_api_scan_batch_count | 2 | | Ndb_api_read_row_count | 4 | | Ndb_api_trans_local_read_row_count | 2 | | Ndb_api_adaptive_send_forced_count | 0 | | Ndb_api_adaptive_send_unforced_count | 3 | | Ndb_api_adaptive_send_deferred_count | 0 | | Ndb_api_event_data_count | 0 | | Ndb_api_event_nondata_count | 0 | | Ndb_api_event_bytes_count | 0 | | Ndb_api_wait_exec_complete_count_slave | 0 | | Ndb_api_wait_scan_result_count_slave | 0 | | Ndb_api_wait_meta_request_count_slave | 0 | | Ndb_api_wait_nanos_count_slave | 0 | | Ndb_api_bytes_sent_count_slave | 0 | | Ndb_api_bytes_received_count_slave | 0 | | Ndb_api_trans_start_count_slave | 0 | | Ndb_api_trans_commit_count_slave | 0 | | Ndb_api_trans_abort_count_slave | 0 | | Ndb_api_trans_close_count_slave | 0 | | Ndb_api_pk_op_count_slave | 0 | | Ndb_api_uk_op_count_slave | 0 | | Ndb_api_table_scan_count_slave | 0 | | Ndb_api_range_scan_count_slave | 0 | | Ndb_api_pruned_scan_count_slave | 0 | | Ndb_api_scan_batch_count_slave | 0 | | Ndb_api_read_row_count_slave | 0 | | Ndb_api_trans_local_read_row_count_slave | 0 | | Ndb_api_adaptive_send_forced_count_slave | 0 | | Ndb_api_adaptive_send_unforced_count_slave | 0 | | Ndb_api_adaptive_send_deferred_count_slave | 0 | | Ndb_slave_max_replicated_epoch | 0 | | Ndb_api_event_data_count_injector | 0 | | Ndb_api_event_nondata_count_injector | 0 | | Ndb_api_event_bytes_count_injector | 0 | | Ndb_cluster_node_id | 100 | | Ndb_config_from_host | 127.0.0.1 | | Ndb_config_from_port | 1186 | | Ndb_number_of_data_nodes | 2 | | Ndb_number_of_ready_data_nodes | 2 | | Ndb_connect_count | 0 | | Ndb_execute_count | 0 | | Ndb_scan_count | 0 | | Ndb_pruned_scan_count | 0 | | Ndb_schema_locks_count | 0 | | Ndb_api_wait_exec_complete_count_session | 0 | | Ndb_api_wait_scan_result_count_session | 0 | | Ndb_api_wait_meta_request_count_session | 0 | | Ndb_api_wait_nanos_count_session | 0 | | Ndb_api_bytes_sent_count_session | 0 | | Ndb_api_bytes_received_count_session | 0 | | Ndb_api_trans_start_count_session | 0 | | Ndb_api_trans_commit_count_session | 0 | | Ndb_api_trans_abort_count_session | 0 | | Ndb_api_trans_close_count_session | 0 | | Ndb_api_pk_op_count_session | 0 | | Ndb_api_uk_op_count_session | 0 | | Ndb_api_table_scan_count_session | 0 | | Ndb_api_range_scan_count_session | 0 | | Ndb_api_pruned_scan_count_session | 0 | | Ndb_api_scan_batch_count_session | 0 | | Ndb_api_read_row_count_session | 0 | | Ndb_api_trans_local_read_row_count_session | 0 | | Ndb_api_adaptive_send_forced_count_session | 0 | | Ndb_api_adaptive_send_unforced_count_session | 0 | | Ndb_api_adaptive_send_deferred_count_session | 0 | | Ndb_sorted_scan_count | 0 | | Ndb_pushed_queries_defined | 0 | | Ndb_pushed_queries_dropped | 0 | | Ndb_pushed_queries_executed | 0 | | Ndb_pushed_reads | 0 | | Ndb_last_commit_epoch_server | 29347511533580 | | Ndb_last_commit_epoch_session | 0 | | Ndb_system_name | MC_20191209172820 | | Ndb_conflict_fn_max | 0 | | Ndb_conflict_fn_old | 0 | | Ndb_conflict_fn_max_del_win | 0 | | Ndb_conflict_fn_epoch | 0 | | Ndb_conflict_fn_epoch_trans | 0 | | Ndb_conflict_fn_epoch2 | 0 | | Ndb_conflict_fn_epoch2_trans | 0 | | Ndb_conflict_trans_row_conflict_count | 0 | | Ndb_conflict_trans_row_reject_count | 0 | | Ndb_conflict_trans_reject_count | 0 | | Ndb_conflict_trans_detect_iter_count | 0 | | Ndb_conflict_trans_conflict_commit_count | 0 | | Ndb_conflict_epoch_delete_delete_count | 0 | | Ndb_conflict_reflected_op_prepare_count | 0 | | Ndb_conflict_reflected_op_discard_count | 0 | | Ndb_conflict_refresh_op_count | 0 | | Ndb_conflict_last_conflict_epoch | 0 | | Ndb_conflict_last_stable_epoch | 0 | | Ndb_index_stat_status | allow:1,enable:1,busy:0, loop:1000,list:(new:0,update:0,read:0,idle:0,check:0,delete:0,error:0,total:0), analyze:(queue:0,wait:0),stats:(nostats:0,wait:0),total:(analyze: (all:0,error:0),query:(all:0,nostats:0,error:0),event:(act:0,skip:0,miss:0), cache:(refresh:0,clean:0,pinned:0,drop:0,evict:0)), cache:(query:0,clean:0,drop:0,evict:0,usedpct:0.00,highpct:0.00) | | Ndb_index_stat_cache_query | 0 | | Ndb_index_stat_cache_clean | 0 | +----------------------------------------------+-------------------------------+ Если сервер MySQL был построен с поддержкой кластера, но это не связано с кластером, все строки в выводе этого запроса содержат ноль или пустую строку. См. SHOW STATUS Statement. SELECT * FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME LIKE 'NDB%'; Этот запрос, хотя устарел в NDB 7.5 и NDB 7.6, может быть использован, если включена show_compatibility_56, чтобы получить вывод, подобный SHOW STATUS из предыдущего пункта, предпочтительный метод состоит в том, чтобы запросить таблицу performance_schema.global_status . В отличие от случая с SHOW STATUS, возможно использование SELECT, чтобы извлечь значения в SQL для использования в скриптах в целях контроля и автоматизации. См. The INFORMATION_SCHEMA GLOBAL_STATUS and SESSION_STATUS Tables , а также Migrating to Performance Schema System and Status Variable Tables. SELECT * FROM performance_schema.global_status WHERE VARIABLE_NAME LIKE 'NDB%' Этот запрос предоставляет вывод, аналогичный SHOW STATUS. В отличие от случая с SHOW STATUS, возможно использование SELECT, чтобы извлечь значения в SQL для использования в скриптах в целях контроля и автоматизации. См. Performance Schema Status Variable Tables. SELECT * FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'NDB%' Этот запрос показывает информацию из таблицы INFORMATION_SCHEMA.PLUGINS о плагинах, связанных с кластером NDB, такую как версия, автор и лицензия, как показано здесь: mysql> SELECT * FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'NDB%'\G *************************** 1. row *************************** PLUGIN_NAME: ndbcluster PLUGIN_VERSION: 1.0 PLUGIN_STATUS: ACTIVE PLUGIN_TYPE: STORAGE ENGINE PLUGIN_TYPE_VERSION: 50729.0 PLUGIN_LIBRARY: NULL PLUGIN_LIBRARY_VERSION: NULL PLUGIN_AUTHOR: MySQL AB PLUGIN_DESCRIPTION: Clustered, fault-tolerant tables PLUGIN_LICENSE: GPL LOAD_OPTION: ON *************************** 2. row *************************** PLUGIN_NAME: ndbinfo PLUGIN_VERSION: 0.1 PLUGIN_STATUS: ACTIVE PLUGIN_TYPE: STORAGE ENGINE PLUGIN_TYPE_VERSION: 50729.0 PLUGIN_LIBRARY: NULL PLUGIN_LIBRARY_VERSION: NULL PLUGIN_AUTHOR: Sun Microsystems Inc. PLUGIN_DESCRIPTION: MySQL Cluster system information storage engine PLUGIN_LICENSE: GPL LOAD_OPTION: ON *************************** 3. row *************************** PLUGIN_NAME: ndb_transid_mysql_connection_map PLUGIN_VERSION: 0.1 PLUGIN_STATUS: ACTIVE PLUGIN_TYPE: INFORMATION SCHEMA PLUGIN_TYPE_VERSION: 50729.0 PLUGIN_LIBRARY: NULL PLUGIN_LIBRARY_VERSION: NULL PLUGIN_AUTHOR: Oracle Corporation PLUGIN_DESCRIPTION: Map between mysql connection id and ndb transaction id PLUGIN_LICENSE: GPL LOAD_OPTION: ON Можно также использовать SHOW PLUGINS, чтобы показать эту информацию, но вывод из того запроса не может быть легко отфильтрован. См. также The MySQL Plugin API, который описывает где и как получена информация в таблице PLUGINS. Можно также запросить таблицы в информационной базе данных ndbinfo для данных реального времени о многих операциях по кластеру NDB. Посмотрите раздел 7.10. 7.10. ndbinfo: База данных информации о NDB Cluster ndbinfo это база данных, содержащая информацию, определенную для кластера NDB. Эта база данных содержит много таблиц, обеспечивающих различный вид данных о статусе узла кластера NDB, использовании ресурсов и операциях. Можно найти более подробную информацию о каждом из этих таблиц в следующих нескольких секциях. ndbinfo включен с поддержкой кластера NDB в MySQL Server, никакая специальная компиляция или шаги конфигурации не требуются, таблицы составлены MySQL Server, когда он соединяется с кластером. Можно проверить, что поддержка ndbinfo активна в данном использовании MySQL Server с помощью SHOW PLUGINS. Если поддержка ndbinfo включена, необходимо видеть, что строка содержит ndbinfo в столбце Name и ACTIVE в столбце Status: mysql> SHOW PLUGINS; +----------------------------------+--------+--------------------+---------+---------+ | Name | Status | Type | Library | License | +----------------------------------+--------+--------------------+---------+---------+ | binlog | ACTIVE | STORAGE ENGINE | NULL | GPL | | mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL | | sha256_password | ACTIVE | AUTHENTICATION | NULL | GPL | | MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL | | CSV | ACTIVE | STORAGE ENGINE | NULL | GPL | | MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL | | INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_PER_INDEX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_PER_INDEX_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_PAGE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_PAGE_LRU | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_POOL_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_TEMP_TABLE_INFO | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_METRICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_DEFAULT_STOPWORD | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_BEING_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_CONFIG | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_INDEX_CACHE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_INDEX_TABLE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLESTATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_COLUMNS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FIELDS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FOREIGN | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FOREIGN_COLS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLESPACES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_DATAFILES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_VIRTUAL | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL | | ndbCluster | ACTIVE | STORAGE ENGINE | NULL | GPL | | ndbinfo | ACTIVE | STORAGE ENGINE | NULL | GPL | | ndb_transid_mysql_connection_map | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | BLACKHOLE | ACTIVE | STORAGE ENGINE | NULL | GPL | | ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL | | partition | ACTIVE | STORAGE ENGINE | NULL | GPL | | ngram | ACTIVE | FTPARSER | NULL | GPL | +----------------------------------+--------+--------------------+---------+---------+ 46 rows in set (0.00 sec) Можно также сделать это, проверив вывод SHOW ENGINES на строку, включающую ndbinfo в столбце Engine и YES в столбце Support: mysql> SHOW ENGINES\G *************************** 1. row *************************** Engine: ndbcluster Support: YES Comment: Clustered, fault-tolerant tables Transactions: YES XA: NO Savepoints: NO *************************** 2. row *************************** Engine: CSV Support: YES Comment: CSV storage engine Transactions: NO XA: NO Savepoints: NO *************************** 3. row *************************** Engine: InnoDB Support: DEFAULT Comment: Supports transactions, row-level locking, and foreign keys Transactions: YES XA: YES Savepoints: YES *************************** 4. row *************************** Engine: BLACKHOLE Support: YES Comment: /dev/null storage engine (anything you write to it disappears) Transactions: NO XA: NO Savepoints: NO *************************** 5. row *************************** Engine: MyISAM Support: YES Comment: MyISAM storage engine Transactions: NO XA: NO Savepoints: NO *************************** 6. row *************************** Engine: MRG_MYISAM Support: YES Comment: Collection of identical MyISAM tables Transactions: NO XA: NO Savepoints: NO *************************** 7. row *************************** Engine: ARCHIVE Support: YES Comment: Archive storage engine Transactions: NO XA: NO Savepoints: NO *************************** 8. row *************************** Engine: ndbinfo Support: YES Comment: NDB Cluster system information storage engine Transactions: NO XA: NO Savepoints: NO *************************** 9. row *************************** Engine: PERFORMANCE_SCHEMA Support: YES Comment: Performance Schema Transactions: NO XA: NO Savepoints: NO *************************** 10. row *************************** Engine: MEMORY Support: YES Comment: Hash based, stored in memory, useful for temporary tables Transactions: NO XA: NO Savepoints: NO 10 rows in set (0.00 sec) Если поддержка ndbinfo позволена, тогда можно получить доступ к ndbinfo в mysql или другом клиенте MySQL. Например, вы видите, что ndbinfo перечислен в выводе SHOW DATABASES: mysql> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | ndbinfo | | performance_schema | | sys | +--------------------+ 5 rows in set (0.04 sec) Если процесс mysqld не был начат с опцией --ndbcluster, ndbinfo недоступна и не показана SHOW DATABASES. Если mysqld был раньше связан с кластером NDB, но кластер становится недоступным (из-за таких событий, как закрытие кластера, потеря сетевого соединения и т.д.), ndbinfo и его таблицы остаются видимыми, но попытка получить доступ к любым таблицам (кроме blocks or config_params) отваливается с ошибкой Got error 157 'Connection to NDB failed' from NDBINFO. За исключением таблиц blocks и config_params, к чему мы обращаемся как к таблицам, ndbinfo на самом деле обзоры, произведенные от внутренних таблиц NDB. Все таблицы ndbinfo read-only и произведены по запросу. Поскольку многие из них произведены параллельно узлами данных в то время как другие определены для узлов SQL, они не обеспечивают последовательный образ. Кроме того, снижение соединений не поддерживается на таблицах ndbinfo, так большое присоединение таблиц ndbinfo может потребовать передачи большого объема данных к узлу API, даже когда запрос использует WHERE. ЬТаблицы ndbinfo не включены в кэш запроса (Bug #59831). Можно выбрать БД ndbinfo через USE и выполнить SHOW TABLES, чтобы получить список таблиц, как для любой другой базы данных: mysql> USE ndbinfo; Database changed mysql> SHOW TABLES; +---------------------------------+ | Tables_in_ndbinfo | +---------------------------------+ | arbitrator_validity_detail | | arbitrator_validity_summary | | blocks | | cluster_locks | | cluster_operations | | cluster_transactions | | config_nodes | | config_params | | config_values | | counters | | cpustat | | cpustat_1sec | | cpustat_20sec | | cpustat_50ms | | dict_obj_info | | dict_obj_types | | disk_write_speed_aggregate | | disk_write_speed_aggregate_node | | disk_write_speed_base | | diskpagebuffer | | error_messages | | locks_per_fragment | | logbuffers | | logspaces | | membership | | memory_per_fragment | | memoryusage | | nodes | | operations_per_fragment | | processes | | resources | | restart_info | | server_locks | | server_operations | | server_transactions | | table_distribution_status | | table_fragments | | table_info | | table_replicas | | tc_time_track_stats | | threadblocks | | threads | | threadstat | | transporters | +---------------------------------+ 44 rows in set (0.00 sec) В NDB 7.5.0 (и позже) все таблицы ndbinfo используют NDB, однако, вход ndbinfo все еще появляется в выводе SHOW ENGINES и SHOW PLUGINS. Таблица config_values добавлена в NDB 7.5.0. Таблицы cpustat, cpustat_50ms, cpustat_1sec, cpustat_20sec и threads добавлены в NDB 7.5.2. Таблицы cluster_locks, locks_per_fragment и server_locks добавлены в NDB 7.5.3. Таблицы dict_obj_info, table_distribution_status, table_fragments, table_info и table_replicas добавлены в NDB 7.5.4. Таблицы config_nodes и processes добавлены в NDB 7.5.7 и NDB 7.6.2. Таблица error_messages добавлена в NDB 7.6.4. Можно выполнить SELECT для этих таблиц как обычно: mysql> SELECT * FROM memoryusage; +---------+---------------------+--------+------------+------------+-------------+ | node_id | memory_type | used | used_pages | total | total_pages | +---------+---------------------+--------+------------+------------+-------------+ | 5 | Data memory | 753664 | 23 | 1073741824 | 32768 | | 5 | Index memory | 163840 | 20 | 1074003968 | 131104 | | 5 | Long message buffer | 2304 | 9 | 67108864 | 262144 | | 6 | Data memory | 753664 | 23 | 1073741824 | 32768 | | 6 | Index memory | 163840 | 20 | 1074003968 | 131104 | | 6 | Long message buffer | 2304 | 9 | 67108864 | 262144 | +---------+---------------------+--------+------------+------------+-------------+ 6 rows in set (0.02 sec) Более сложные запросы, такие как два следующих SELECT, используя таблицу memoryusage, возможны: mysql> SELECT SUM(used) as 'Data Memory Used, All Nodes' FROM memoryusage WHERE memory_type = 'Data memory'; +-----------------------------+ | Data Memory Used, All Nodes | +-----------------------------+ | 6460 | +-----------------------------+ 1 row in set (0.37 sec) mysql> SELECT SUM(max) as 'Total IndexMemory Available' FROM memoryusage WHERE memory_type = 'Index memory'; +-----------------------------+ | Total IndexMemory Available | +-----------------------------+ | 25664 | +-----------------------------+ 1 row in set (0.33 sec) Таблица ndbinfo и имена столбцов чувствительны к регистру (как само имя ndbinfo). Эти идентификаторы находятся в строчных буквах. Пытаясь использовать неправильный регистр, получите ошибку: mysql> SELECT * FROM nodes; +---------+--------+---------+-------------+ | node_id | uptime | status | start_phase | +---------+--------+---------+-------------+ | 1 | 13602 | STARTED | 0 | | 2 | 16 | STARTED | 0 | +---------+--------+---------+-------------+ 2 rows in set (0.04 sec) mysql> SELECT * FROM Nodes; ERROR 1146 (42S02): Table 'ndbinfo.Nodes' doesn't exist mysqldump игнорирует базу данных ndbinfo полностью и исключает из любого вывода. Это верно, используя опции --databases или --all-databases. NDB Cluster также поддерживает таблицы в INFORMATION_SCHEMA, включая таблицу FILES, которая содержит информацию о файлах, используемых для хранения данных кластерного диска NDB, и таблицу ndb_transid_mysql_connection_map , которая показывает отношения между транзакциями, операционными координаторами и узлами API. Для получения дополнительной информации см. описания таблиц или раздел 7.11. 7.10.1. Таблица arbitrator_validity_detail arbitrator_validity_detail показывает представление, что каждый узел данных в кластере имеет арбитра. Это подмножество таблицы membership. Следующая таблица предоставляет информацию о колонках в таблице arbitrator_validity_detail. Для каждой столбцы таблица показывает имя, тип данных и краткое описание. Дополнительная информация может быть найдена в примечаниях после таблицы. Таблица 7.14. Столбцы таблицы arbitrator_validity_detail Имя Тип Описание node_id integer ID узла arbitrator integer ID узла арбитра arb_ticket string Внутренний идентификатор отслеживания арбитража arb_connected Yes или No Связан ли этот узел с арбитром arb_state Enumeration Арбитражный статус ID узла совпадает с сообщаемым ndb_mgm -e "SHOW". Все узлы должны показать те же самые значения arbitrator и arb_ticket, а также то же самое arb_state. Возможные значения arb_state: ARBIT_NULL, ARBIT_INIT, ARBIT_FIND, ARBIT_PREP1, ARBIT_PREP2, ARBIT_START, ARBIT_RUN, ARBIT_CHOOSE, ARBIT_CRASH и UNKNOWN. arb_connected показывает, связан ли текущий узел с arbitrator. 7.10.2. Таблица arbitrator_validity_summary Таблица arbitrator_validity_summary обеспечивает сложную точку зрения арбитра относительно узлов данных кластера. Следующая таблица предоставляет информацию о колонках в таблице arbitrator_validity_summary. Для каждого столбца таблица показывает имя, тип данных и краткое описание. Дополнительная информация может быть найдена в примечаниях после таблицы. Таблица 7.15. Столбцы arbitrator_validity_summary Имя Тип Описание arbitrator integer ID узла арбитра arb_ticket string Внутренний идентификатор отслеживания арбитража arb_connected Yes или No Связан ли этот арбитр с кластером consensus_count integer Количество узлов данных, которые рассматривают этот узел как арбитра В нормальном функционировании у этой таблицы должна быть только 1 строка в течение любого заметного отрезка времени. Если у этого есть больше 1 строки дольше, чем несколько моментов, то не все узлы связаны с арбитром или все узлы связаны, но не договариваются о том же самом арбитре. Столбец arbitrator показывает ID узла арбитра. arb_ticket это внутренний идентификатор, используемый этим арбитром. arb_connected показывает, связан ли этот узел с кластером как арбитр. 7.10.3. Таблица ndbinfo blocks Таблица blocks это статическая таблица, которая просто содержит имена и внутренние ID всех ядерных блоков NDB (см. NDB Kernel Blocks). Это надо для использования другими таблицами ndbinfo (большинство которых являются на самом деле обзорами) в отображении номеров блоков к их именам для производства человекочитаемого вывода. Следующая таблица предоставляет информацию о колонках в таблице blocks. Для каждого столбца таблица показывает имя, тип данных и краткое описание. Дополнительная информация может быть найдена в примечаниях после таблицы. Таблица 7.16. Столбцы таблицы blocks Имя Тип Описание block_number integer Номер блока block_name string Имя блока Чтобы получить список всех имен блока, просто выполните SELECT block_name FROM ndbinfo.blocks. Хотя это статическая таблица, ее содержание может измениться между различными выпусками NDB Cluster. 7.10.4. Таблица cluster_locks Таблица cluster_locks предоставляет информацию о текущих запросах блокировки и ожиданиях блокировок на таблицах NDB в NDB Cluster и предназначается как сопутствующая таблица к cluster_operations. Информация получается из таблицы cluster_locks и может быть полезной в исследовании мертвых блокировок. Следующая таблица предоставляет информацию о колонках в таблице the cluster_locks. Для каждого столбца таблица показывает имя, тип данных и краткое описание. Дополнительная информация может быть найдена в примечаниях после таблицы. Таблица 7.17. Столбцы cluster_locks Имя Тип Описание node_id integer ID сообщения об узле block_instance integer ID сообщения о экземпляре LDM tableid integer ID таблицы, содержащей эту строку fragmentid integer ID фрагмента, содержащего заблокированную строку rowid integer ID заблокированной строки transid integer ID транзакции mode string Способ запроса блокировки state string Статус бокировки detail string Является ли это первым фиксатором в очереди блокировки строки op string Операционный тип duration_millis integer Миллисекунды, потраченные на ожидание или блокировку lock_num integer ID объекта блокирования waiting_for integer Ожидание блокировки с этим ID ID таблицы (столбец tableid) назначен внутренне и совпадает с используемым в других таблицах ndbinfo. Это также показывают в выводе ndb_show_tables. ID транзакции (столбец transid) это идентификатор, произведенный API NDB для операционного требования или удерживания текущей блокировки. Столбец mode показывает способ блокировки, это всегда одно из S (коллективная блокировка) или X (монопольная блокировка). Если транзакция держит монопольную блокировку на данной строке, все другие блокировки на этой строке имеют тот же самый ID транзакции. Столбец state показывает статус блокировки. Его значение всегда одно из H (удерживание) или W (ожидание). Запрос блокировки ожидания ждет блокировки, проводимой другой транзакцией. Когда столбец detail содержит * (звездочку), это означает, что эта блокировка это первый фиксатор в очереди блокировок затронутой строки, иначе эта колонка пуста. Эта информация может использоваться, чтобы помочь определить уникальные записи в списке запросов блокировки. Столбец op показывает тип операции, просящей блокировку. Это всегда одно из значений READ, INSERT, UPDATE, DELETE, SCAN или REFRESH. Столбец duration_millis показывает количество миллисекунд, которые этот запрос блокировки ждал или держал блокировку. Это перезагружается к 0, когда блокировку предоставляют для ждущего запроса. ID блокировки (столбец lockid) уникален для этого узла и экземпляра блока. Cтатус блокировки показывают в столбце lock_state, если это W, блокировка ждет, чтобы быть предоставленной, а waiting_for показывает ID объекта блокирования, которого ждет этот запрос. Иначе waiting_for пуст. waiting_for может относиться только к блокировкам той же самой строки, как сказано node_id, block_instance, tableid, fragmentid и rowid. Таблица cluster_locks добавлена в NDB 7.5.3. 7.10.5. Таблица cluster_operations Таблица cluster_operations обеспечивает представление по операциям (первичный ключ с фиксацией состояния op) обо всей деятельности в NDB Cluster с точки зрения местного управления данными (блок LQH) (см. The DBLQH Block). Следующая таблица предоставляет информацию о колонках в the cluster_operations. Для каждого столбца таблица показывает имя, тип данных и краткое описание. Дополнительная информация может быть найдена в примечаниях после таблицы. Таблица 7.18. Столбцы cluster_operations Имя Тип Описание node_id integer ID узла сообщения о блоке LQH block_instance integer Экземпляр блока LQH transid integer ID транзакции operation_type string Тип операции state string Статус операции tableid integer ID таблицы fragmentid integer ID фрагмента client_node_id integer Узел клиента ID client_block_ref integer Ссылка блока клиента tc_node_id integer ID узла операционного координатора tc_block_no integer Операционный координатор: номер блока tc_block_instance integer Операционный координатор: экземпляр блока ID транзакции это уникальное 64-битное число, которое может быть получено, используя метод NDB API getTransactionId(). В настоящее время MySQL Server не выставляет ID транзакции API NDB для продолжающейся транзакции. Столбец operation_type может взять любое из значений READ, READ-SH, READ-EX, INSERT, UPDATE, DELETE, WRITE, UNLOCK, REFRESH, SCAN, SCAN-SH, SCAN-EX или <unknown>. Столбец state имеет одно из значений ABORT_QUEUED, ABORT_STOPPED, COMMITTED, COMMIT_QUEUED, COMMIT_STOPPED, COPY_CLOSE_STOPPED, COPY_FIRST_STOPPED, COPY_STOPPED, COPY_TUPKEY, IDLE, LOG_ABORT_QUEUED, LOG_COMMIT_QUEUED, LOG_COMMIT_QUEUED_WAIT_SIGNAL, LOG_COMMIT_WRITTEN, LOG_COMMIT_WRITTEN_WAIT_SIGNAL, LOG_QUEUED, PREPARED, PREPARED_RECEIVED_COMMIT, SCAN_CHECK_STOPPED, SCAN_CLOSE_STOPPED, SCAN_FIRST_STOPPED, SCAN_RELEASE_STOPPED, SCAN_STATE_USED, SCAN_STOPPED, SCAN_TUPKEY, STOPPED, TC_NOT_CONNECTED, WAIT_ACC, WAIT_ACC_ABORT, WAIT_AI_AFTER_ABORT, WAIT_ATTR, WAIT_SCAN_AI, WAIT_TUP, WAIT_TUPKEYINFO, WAIT_TUP_COMMIT или WAIT_TUP_TO_ABORT. Если MySQL Server работает с включенной опцией ndbinfo_show_hidden, можно смотреть этот список, выбрав из таблицы ndb$dblqh_tcconnect_state, которая обычно скрыта. Можно получить название таблицы NDB из ID таблицы, проверяя вывод ndb_show_tables. fragid совпадает с числом разделов в выводе ndb_desc --extra-partition-info (краткая форма -p). В client_node_id и client_block_ref client отсылает к узлу API или SQL (то есть, клиенту NDB API или MySQL Server, подсоединенный к кластеру). Столбец block_instance и tc_block_instance предоставляют номера экземпляров блоков DBLQH и DBTC. Можно использовать их наряду с именами блоков, чтобы получить информацию об определенных потоках из таблицы threadblocks. 7.10.6. Таблица cluster_transactions Таблица cluster_transactions показывает информацию обо всех продолжающихся транзакциях в кластере NDB. Следующая таблица предоставляет информацию о колонках в таблице cluster_transactions. Для каждого столбца таблица показывает имя, тип данных и краткое описание. Дополнительная информация может быть найдена в примечаниях после таблицы. Таблица 7.19. Столбцы cluster_transactions Имя Тип Описание node_id integer ID узла операционного координатора block_instance integer Экземпляр блока TC transid integer ID транзакции state string Операционное состояние count_operations integer Количество операций по первичному ключу с фиксацией состояния в транзакции (включает чтение с блокировкой, а также операции DML) outstanding_operations integer Операции, все еще выполняемые в местных блоках управления данными inactive_seconds integer Время ожидания API client_node_id integer Узел клиента ID client_block_ref integer Ссылка блока клиента ID транзакции это уникальное 64-битное число, которое может быть получено, используя метод NDB API getTransactionId(). block_instance относится к экземпляру ядерного блока. Вместе с именем блока, это число может использоваться, чтобы искать приведенный экземпляр в таблице threadblocks. Столбец state может иметь любое из значений CS_ABORTING, CS_COMMITTING, CS_COMMIT_SENT, CS_COMPLETE_SENT, CS_COMPLETING, CS_CONNECTED, CS_DISCONNECTED, CS_FAIL_ABORTED, CS_FAIL_ABORTING, CS_FAIL_COMMITTED, CS_FAIL_COMMITTING, CS_FAIL_COMPLETED, CS_FAIL_PREPARED, CS_PREPARE_TO_COMMIT, CS_RECEIVING, CS_REC_COMMITTING, CS_RESTART, CS_SEND_FIRE_TRIG_REQ, CS_STARTED, CS_START_COMMITTING, CS_START_SCAN, CS_WAIT_ABORT_CONF, CS_WAIT_COMMIT_CONF, CS_WAIT_COMPLETE_CONF, CS_WAIT_FIRE_TRIG_REQ. Если MySQL Server работает с опцией ndbinfo_show_hidden, можно смотреть этот список, выбрав из обычно скрытой таблицы ndb$dbtc_apiconnect_state. В client_node_id и client_block_ref client отсылает к узлу API или SQL (то есть клиенту NDB API или MySQL Server, подключенному к этому кластеру). Столбец tc_block_instance предоставляет номер экземпляра блока DBTC. Можно использовать это наряду с именем блока, чтобы получить информацию об определенных потоках из таблицы threadblocks. 7.10.7. Таблица config_nodes Таблица config_nodes показывает узлы, формируемые в файле config.ini. Для каждого узла таблица показывает строку, содержащую ID узла, тип узла (узел управления, узел данных или узел API) и имя или IP-адрес хоста, на котором узел формируется. Эта таблица не показывает, работает ли данный узел на самом деле или связывается ли это в настоящее время с кластером. Информация об узлах, связанных с кластером NDB, может быть получена из таблиц nodes и processes. Таблица 7.20. Столбцы config_params Имя Тип Описание node_id integer ID узла node_type string Тип узла node_hostname string Имя или IP-адрес хоста, на котором находится узел Столбец node_id показывает ID узла, используемый в файле the config.ini для него, если ни один не определяется, ID узла, который был назначен автоматически на этот узел, показан. node_type это одно из следующих трех значений: MGM: Узел управления. NDB: Узел данных. API: Узел API, это включает узлы SQL. node_hostname показывает хост узла, как определено в файле config.ini. Это может быть пусто для узла API, если HostName не был установлен в файле кластерной конфигурации. Если HostName не был установлен для узла данных в конфигурационном файле, localhost используется. localhost также применен, если HostName не был определен для узла управления. Таблица config_nodes добавлена в NDB 7.5.7 и NDB 7.6.2. 7.10.8. Таблица config_params Таблица config_params это статическая таблица, который обеспечивает имена, внутренние идентификационные номера и другую информацию о параметрах кластерной конфигурации NDB Cluster. Следующая таблица предоставляет информацию о колонках в the config_params. Для каждого столбца таблица показывает имя, тип данных и краткое описание. Дополнительная информация может быть найдена в примечаниях после таблицы. Эта таблица может также использоваться вместе с config_values для получения информации в реальном времени о параметрах конфигурации узла. Таблица 7.21. Столбцы config_params Имя Тип Описание param_number integer Внутренний идентификационный номер параметра param_name string Название параметра param_description string Краткое описание параметра param_type string Тип данных параметра param_default string Значение по умолчанию параметра, если есть param_min string Максимальное значение параметра, если есть param_max string Минимальное значение параметра, если есть param_mandatory integer 1, если параметр нужен, иначе 0 param_status string Пока не используется В NDB Cluster 7.5 (и позже) таблица read-only. Столбцы param_description, param_type, param_default, param_min, param_max, param_mandatory и param_status добавлены в NDB 7.5.0. Хотя это статическая таблица, ее содержание может измениться между установками кластера NDB, так как поддержанные параметры могут измениться из-за различий между выпусками программного обеспечения, аппаратными конфигурациями кластера и другими факторами. 7.10.9. Таблица config_values Таблица config_values добавлена в NDB 7.5.0, предоставляет информацию о текущем состоянии значений параметров конфигурации узла. Каждая строка соответствует текущему значению параметра на данном узле. Таблица 7.22. Столбцы config_params Имя Тип Описание node_id integer ID узла config_param integer Внутренний идентификационный номер параметра config_value string Текущее значение параметра Столбец config_param и столбец config_params таблицы param_number используют те же самые идентификаторы параметра. Присоединяясь к этим двум таблицам на этих колонках, можно получить подробную информацию о желаемых параметрах конфигурации узла. Запрос, показанный здесь, обеспечивает текущее значение для всех параметров на каждом узле данных в кластере, упорядоченное по ID узла и названию параметра: SELECT v.node_id AS 'Node Id', p.param_name AS 'Parameter', v.config_value AS 'Value' FROM config_values v JOIN config_params p ON v.config_param=p.param_number WHERE p.param_name NOT LIKE '\_\_%' ORDER BY v.node_id, p.param_name; Частичный вывод в качестве примера для простого тестирования: +---------+------------------------------------------+----------------+ | Node Id | Parameter | Value | +---------+------------------------------------------+----------------+ | 2 | Arbitration | 1 | | 2 | ArbitrationTimeout | 7500 | | 2 | BackupDataBufferSize | 16777216 | | 2 | BackupDataDir | /home/jon/data | | 2 | BackupDiskWriteSpeedPct | 50 | | 2 | BackupLogBufferSize | 16777216 | ... | 3 | TotalSendBufferMemory | 0 | | 3 | TransactionBufferMemory | 1048576 | | 3 | TransactionDeadlockDetectionTimeout | 1200 | | 3 | TransactionInactiveTimeout | 4294967039 | | 3 | TwoPassInitialNodeRestartCopy | 0 | | 3 | UndoDataBuffer | 16777216 | | 3 | UndoIndexBuffer | 2097152 | +---------+------------------------------------------+----------------+ 248 rows in set (0.02 sec) WHERE отфильтровывает параметры, имена которых начинаются с двойного подчеркивания (__), эти параметры резервируются для тестирования и других внутренних использований разработчиками NDB и не предназначаются для использования в производстве. Можно получить вывод, который является более определенным, создавая надлежащие запросы. Этот пример обеспечивает все типы доступной информации о параметрах NodeId, NoOfReplicas, HostName, DataMemory, IndexMemory и TotalSendBufferMemory, как в настоящее время установлено для всех узлов данных в кластере: SELECT p.param_name AS Name, v.node_id AS Node, p.param_type AS Type, p.param_default AS 'Default', p.param_min AS Minimum, p.param_max AS Maximum, CASE p.param_mandatory WHEN 1 THEN 'Y' ELSE 'N' END AS 'Required', v.config_value AS Current FROM config_params p JOIN config_values v ON p.param_number = v.config_param WHERE p. param_name IN ('NodeId', 'NoOfReplicas', 'HostName', 'DataMemory', 'IndexMemory', 'TotalSendBufferMemory')\G Вывод от этого запроса, когда работает на кластере с 2 узлами данных, используемыми для простого тестирования: *************************** 1. row *************************** Name: NodeId Node: 2 Type: unsigned Default: Minimum: 1 Maximum: 48 Required: Y Current: 2 *************************** 2. row *************************** Name: HostName Node: 2 Type: string Default: localhost Minimum: Maximum: Required: N Current: 127.0.0.1 *************************** 3. row *************************** Name: TotalSendBufferMemory Node: 2 Type: unsigned Default: 0 Minimum: 262144 Maximum: 4294967039 Required: N Current: 0 *************************** 4. row *************************** Name: NoOfReplicas Node: 2 Type: unsigned Default: 2 Minimum: 1 Maximum: 4 Required: N Current: 2 *************************** 5. row *************************** Name: DataMemory Node: 2 Type: unsigned Default: 102760448 Minimum: 1048576 Maximum: 1099511627776 Required: N Current: 524288000 *************************** 6. row *************************** Name: NodeId Node: 3 Type: unsigned Default: Minimum: 1 Maximum: 48 Required: Y Current: 3 *************************** 7. row *************************** Name: HostName Node: 3 Type: string Default: localhost Minimum: Maximum: Required: N Current: 127.0.0.1 *************************** 8. row *************************** Name: TotalSendBufferMemory Node: 3 Type: unsigned Default: 0 Minimum: 262144 Maximum: 4294967039 Required: N Current: 0 *************************** 9. row *************************** Name: NoOfReplicas Node: 3 Type: unsigned Default: 2 Minimum: 1 Maximum: 4 Required: N Current: 2 *************************** 10. row *************************** Name: DataMemory Node: 3 Type: unsigned Default: 102760448 Minimum: 1048576 Maximum: 1099511627776 Required: N Current: 524288000 10 rows in set (0.01 sec) 7.10.10. Таблица ndbinfo counters Таблица counters обеспечивает работающие общие количества событий для определенных ядерных блоков и узлов данных. Подсчет проведен с нового запуска или перезапуска узла, запуск или перезапуск узла перезагружает все счетчики на том узле. Не у всех ядерных блоков есть все типы счетчиков. Следующая таблица предоставляет информацию о колонках в the counters. Таблица 7.23. Столбцы таблицы counters Название счетчика. Имя Тип Описание node_id integer ID узла данных block_name string Название связанного ядерного блока NDB (см. NDB Kernel Blocks). block_instance integer Экземпляр блока counter_id integer Внутренний идентификационный номер счетчика, обычно целое число между 1 и 10, включительно counter_name string val integer Значение счетчика Каждый счетчик связан с конкретным ядерным блоком NDB. Счетчик OPERATIONS связан с блоком DBLQH (укладчик локального запроса), см. The DBLQH Block. Чтение первичного ключа считается как одна операция, как делает обновление первичного ключа. Для чтений есть одна операция в DBLQH на операцию в DBTC. Для записи есть одна операция на реплику. Счетчики ATTRINFO, TRANSACTIONS, COMMITS, READS, LOCAL_READS, SIMPLE_READS, WRITES, LOCAL_WRITES, ABORTS, TABLE_SCANS и RANGE_SCANS связаны с ядерным блоком DBTC (операционный координатор), см. The DBTC Block). LOCAL_WRITES и LOCAL_READS это операции первичного ключа, используя операционного координатора в узле, который также держит основную точную копию. Счетчик READS включает все чтения, LOCAL_READS включает только чтения основной точной копии на том же самом узле, где этот операционный координатор. SIMPLE_READS включает только те чтения, в которых операция чтения это начало и окончание для данной транзакции. Простое чтение не держит блокировку, но это часть транзакции, в которой есть нейтральные изменения, внесенные транзакцией, содержащей их, но не любых других нейтральных транзакций. Такое чтение простое с точки зрения блока TC, так как оно не держит блокировок, оно не длительно, однажды DBTC назначил его к соответствующему блоку LQH и не держит статусы для него. ATTRINFO проводит подсчет числа раз, которое интерпретируемую программу посылают в узел данных. См. NDB Protocol Messages. Счетчики LOCAL_TABLE_SCANS_SENT, READS_RECEIVED, PRUNED_RANGE_SCANS_RECEIVED, RANGE_SCANS_RECEIVED, LOCAL_READS_SENT, CONST_PRUNED_RANGE_SCANS_RECEIVED, LOCAL_RANGE_SCANS_SENT, REMOTE_READS_SENT, REMOTE_RANGE_SCANS_SENT, READS_NOT_FOUND, SCAN_BATCHES_RETURNED, TABLE_SCANS_RECEIVED и SCAN_ROWS_RETURNED связаны с блоком DBSPJ (select push-down join) (см. The DBSPJ Block). Столбцы block_name и block_instance обеспечивают, соответственно, применимое ядерное имя блока NDB и номер экземпляра. Можно использовать их, чтобы получить информацию об определенных потоках из таблицы threadblocks. Много счетчиков предоставляют информацию о перегрузке транспортера и посылают калибровку буфера, расследуя такие проблемы. Для каждого случая LQH есть один экземпляр каждого счетчика в следующем списке: LQHKEY_OVERLOAD: Количество запросов первичного ключа, отклоненных в экземпляре LQH из-за перегрузки транспортера LQHKEY_OVERLOAD_TC: Граф случаев LQHKEY_OVERLOAD, где транспортер узла TC был перегружен LQHKEY_OVERLOAD_READER: Граф случаев LQHKEY_OVERLOAD, где узел-читатель API (только чтение) был перегружен. LQHKEY_OVERLOAD_NODE_PEER: Граф случаев LQHKEY_OVERLOAD, где следующий узел данных резервного копирования (только запись) был перегружен. LQHKEY_OVERLOAD_SUBSCRIBER: Граф случаев LQHKEY_OVERLOAD, где подписчик событий (только запись) был перегружен. LQHSCAN_SLOWDOWNS: Граф случаев, где пакетный размер просмотра фрагмента был уменьшен из-за перегрузки транспортера API. 7.10.11. Таблица ndbinfo cpustat Таблица cpustat обеспечивает статистику CPU за поток, собираемую каждую секунду для каждого потока в ядре NDB. Таблица 7.24. Столбцы таблицы cpustat Имя Тип Описание node_id integer ID узла thr_no integer ID потока (в пределах узла) OS_user integer Пользовательское время OS OS_system integer Системное время OS OS_idle integer Время простоя OS thread_exec integer Время выполнения потока thread_sleeping integer Время сна потока thread_spinning integer Время вращения потока thread_send integer Время передачи потока thread_buffer_full integer Время заполнения буфера потока elapsed_time integer Прошедшее время Таблица добавлена в NDB 7.5.2. 7.10.12. Таблица cpustat_50ms Ааналогично cpustat_1sec и cpustat_20sec, эта таблица показывает 20 наборов измерения на поток каждый ссылающийся на период названной продолжительности. Таким образом, cpsustat_50ms обеспечивает 1 секунду истории. Таблица 7.25. Столбцы cpustat_50ms Имя Тип Описание node_id integer ID узла thr_no integer ID потока (в пределах узла) OS_user_time integer Пользовательское время OS OS_system_time integer Системное время OS OS_idle_time integer Время простоя OS exec_time integer Время выполнения потока sleep_time integer Время сна потока spin_time integer Время ротации потока send_time integer Время передачи потока buffer_full_time integer Время наполнения буфера потока elapsed_time integer Прошло времени Таблица добавлена в NDB 7.5.2. 7.10.13. Таблица cpustat_1sec Как cpustat_50ms и cpustat_20sec, таблица эта таблица показывает 20 наборов измерения на поток, каждый ссылающийся на период названной продолжительности. Таким образом, cpsustat_1sec обеспечивает 20 секунд истории. Таблица 7.26. Столбцы cpustat_1sec Имя Тип Описание node_id integer ID узла thr_no integer ID потока (в пределах узла) OS_user_time integer Пользовательское время OS OS_system_time integer Системное время OS OS_idle_time integer Время простоя OS exec_time integer Время выполнения потока sleep_time integer Время сна потока spin_time integer Время ротации потока send_time integer Время передачи потока buffer_full_time integer Время наполнения буфера потока elapsed_time integer Прошло времени Таблица добавлена в NDB 7.5.2. 7.10.14. Таблица ndbinfo cpustat_20sec Таблица cpustat_20sec обеспечивает сырые данные CPU по потокам, получаемые каждые 20 секунд для каждого потока в ядре NDB. Как cpustat_50ms и cpustat_1sec, эта таблица показывает 20 наборов измерения на поток, каждый ссылающийся на период названной продолжительности. Таким образом, cpsustat_20sec обеспечивает 400 секунд истории. Таблица 7.27. Столбцы cpustat_20sec Имя Тип Описание node_id integer ID узла thr_no integer ID потока (в пределах узла) OS_user_time integer Пользовательское время OS OS_system_time integer Системное время OS OS_idle_time integer Время простоя OS exec_time integer Время выполнения потока sleep_time integer Время сна потока spin_time integer Время ротации потока send_time integer Время передачи потока buffer_full_time integer Время наполнения буфера потока elapsed_time integer Прошло времени Таблица добавлена в NDB 7.5.2. 7.10.15. Таблица dict_obj_info Таблица dict_obj_info предоставляет информацию об объектах словаря данных NDB (DICT), таких как таблицы и индексы. Таблица dict_obj_types может быть запрошена для списка всех типов. Эта информация включает тип объекта, статус, родительский объект (если таковые имеются) и полностью определенное имя. Таблица 7.28. Столбцы dict_obj_info Имя Тип Описание type integer Тип объекта DICT, соединение на dict_obj_types, чтобы получить имя id integer Идентификатор объекта version integer Версия объекта state integer Статус объекта parent_obj_type integer Тип родительского объекта (dict_obj_types type ID), 0 указывает, что у объекта нет родителя parent_obj_id integer ID родительского объекта (такого, как базовая таблица), 0 указывает, что у объекта нет родителя fq_name string Полностью компетентное имя объекта, для таблицы у этого есть форма database_name/def/table_name , для первичного ключа форма sys/def/table_id /PRIMARY, для уникального ключа это sys/def/table_id /uk_name$unique Таблица добавлена в NDB 7.5.4. 7.10.16. Таблица dict_obj_types Таблица dict_obj_types это статическая таблица, перечисляющая возможные типы объектов словаря, используемые в ядре NDB. Это те же самые типы, определенные Object::Type в NDB API. Таблица 7.29. Столбцы dict_obj_types Имя Тип Описание type_id integer Идентификатор типа для этого типа type_name string Название этого типа 7.10.17. Таблица disk_write_speed_base Таблица disk_write_speed_base предоставляет основную информацию о скорости записей на диск во время LCP, резервной копии и восстановления. Таблица 7.30. Столбцы disk_write_speed_base Имя Тип Описание node_id integer ID узла thr_no integer ID этого потока LDM millis_ago integer Миллисекунды с этого законченного отчетного периода millis_passed integer Миллисекунды, прошедшие в этот отчетный период backup_lcp_bytes_written integer Число байтов, написанных на диск местными контрольными точками и процессами резервного копирования в этот период redo_bytes_written integer Число байтов, написанных журналу отката в этот период target_disk_write_speed integer Фактическая скорость записей на диск для потока LDM (базовые данные) 7.10.18. Таблица disk_write_speed_aggregate Таблица disk_write_speed_aggregate предоставляет соединенную информацию о скорости записей на диск во время LCP, резервной копии и восстановления. Таблица 7.31. Столбцы disk_write_speed_aggregate Число байтов, написанных на диск журналу отката в секунду, усредненно за прошлые 60 секунд Имя Тип Описание node_id integer ID узла thr_no integer ID потока LDM backup_lcp_speed_last_sec integer Число байтов, написанных на диск резервной копией и LCP в прошлую секунду redo_speed_last_sec integer Число байтов, написанных журналу отката в прошлую секунду backup_lcp_speed_last_10sec integer Число байтов, написанных на диск резервной копией и LCP в секунду, усредненно за прошлые 10 секунд redo_speed_last_10sec integer Число байтов, написанных журналу отката в секунду, усредненно за прошлые 10 секунд std_dev_backup_lcp_speed_last_10sec integer Стандартное отклонение в числе байтов, написанных на диск резервной копией и LCP в секунду, усредненно за прошлые 10 секунд std_dev_redo_speed_last_10sec integer Стандартное отклонение в числе байтов, написанных журналу отката в секунду, усредненно за прошлые 10 секунд backup_lcp_speed_last_60sec integer Число байтов, написанных на диск резервной копией и LCP в секунду, усредненно за прошлые 60 секунд redo_speed_last_60sec integer std_dev_backup_lcp_speed_last_60sec integer Стандартное отклонение в числе байтов, написанных на диск резервной копией и LCP в секунду, усредненно за прошлые 60 секунд std_dev_redo_speed_last_60sec integer Стандартное отклонение в числе байтов, написанных на диск журналу отката в секунду, усредненно за прошлые 60 секунд slowdowns_due_to_io_lag integer Число секунд начиная с последнего старта узла, в течение которых записи на диск замедлились из-за задержки I/O журнала отката slowdowns_due_to_high_cpu integer Число секунд начиная с последнего старта узла, которое записи на диск замедлились из-за высокого использования CPU disk_write_speed_set_to_min integer Число секунд начиная с последнего старта узла, которые скорость записи на диск была установлена в минимум current_target_disk_write_speed integer Фактическая скорость записей на диск поток LDM 7.10.19. Таблица disk_write_speed_aggregate_node Таблица disk_write_speed_aggregate_node предоставляет соединенную информацию за узел о скорости записей на диск во время LCP, резервной копии и восстановления. Таблица 7.32. Столбцы disk_write_speed_aggregate_node Имя Тип Описание node_id integer ID узла backup_lcp_speed_last_sec integer Число байтов, написанных на диск резервной копией и LCP в прошлую секунду redo_speed_last_sec integer Число байтов, написанных журналу отката в прошлую секунду backup_lcp_speed_last_10sec integer Число байтов, написанных на диск резервной копией и LCP в секунду, усредненно за прошлые 10 секунд redo_speed_last_10sec integer Число байтов, написанных журналу отката в секунду, усредненно за прошлые 10 секунд backup_lcp_speed_last_60sec integer Число байтов, написанных на диск резервной копией и LCP в секунду, усредненно за прошлые 60 секунд redo_speed_last_60sec integer Число байтов, написанных журналу отката в секунду, усредненно за прошлые 60 секунд 7.10.20. Таблица diskpagebuffer Таблица diskpagebuffer обеспечивает статистику о дисковом использовании буфера страницы таблицами данных кластерного диска NDB. Таблица 7.33. Столбцы diskpagebuffer Сколько страниц написано на диск Имя Тип Описание node_id integer ID узла block_instance integer Экземпляр блока pages_written integer pages_written_lcp integer Сколько страниц написано местными контрольными точками pages_read integer Сколько страниц прочитано с диска log_waits integer Сколько страниц ждут записи журнала на диск page_requests_direct_return integer Количество запросов о страницах, которые были доступны в буфере page_requests_wait_queue integer Количество запросов, которые должны были ждать страницы в буфере page_requests_wait_io integer Количество запросов, которые должны были быть прочитаны из страниц на диске (страницы были недоступны в буфере) Можно использовать эту таблицу с таблицами NDB Cluster Disk Data, чтобы определить, достаточно ли DiskPageBufferMemory большое, чтобы позволить данным быть прочитанными из буфера, а не с диска. Уменьшение поиска на диске может помочь улучшить исполнение таких таблиц. Можно определить пропорцию чтений от DiskPageBufferMemory к общему количеству чтений, используя такой запрос, который получает это отношение как процент: SELECT node_id, 100 * page_requests_direct_return / (page_requests_direct_return + page_requests_wait_io) AS hit_ratio FROM ndbinfo.diskpagebuffer; Вывод этого запроса должен быть подобен тому, что показывают здесь с одной строкой для каждого узла данных в кластере (в этом примере у кластера есть 4 узла данных): +---------+-----------+ | node_id | hit_ratio | +---------+-----------+ | 5 | 97.6744 | | 6 | 97.6879 | | 7 | 98.1776 | | 8 | 98.1343 | +---------+-----------+ 4 rows in set (0.00 sec) hit_ratio приближающееся к 100% указывает, что только очень небольшое количество чтений делается с диска, а не из буфера, что означает, что дисковая производительность чтения данных приближается к оптимальному уровню. Если какое-либо из этих значений составляет меньше 95%, это сильный индикатор что надо увеличить DiskPageBufferMemory в файле config.ini. Изменение в DiskPageBufferMemory требует катящегося перезапуска всех узлов данных кластера, прежде чем оно вступит в силу. block_instance относится к случаю ядерного блока. Вместе с именем блока это число может использоваться, чтобы искать приведенный пример в таблице threadblocks. Используя эту информацию, можно получить информацию о дисковых метриках буфера страницы, касающихся отдельных потоков, использование запроса в качестве примера LIMIT 1, чтобы ограничить вывод единственным потоком, показывают здесь: mysql> SELECT node_id, thr_no, block_name, thread_name, pages_written, \ pages_written_lcp, pages_read, log_waits, \ page_requests_direct_return, page_requests_wait_queue, \ page_requests_wait_io FROM ndbinfo.diskpagebuffer \ INNER JOIN ndbinfo.threadblocks \ USING (node_id, block_instance) INNER JOIN ndbinfo.threads \ USING (node_id, thr_no) WHERE block_name = 'PGMAN' LIMIT 1\G *************************** 1. row *************************** node_id: 1 thr_no: 1 block_name: PGMAN thread_name: rep pages_written: 0 pages_written_lcp: 0 pages_read: 1 log_waits: 0 page_requests_direct_return: 4 page_requests_wait_queue: 0 page_requests_wait_io: 1 1 row in set (0.01 sec) 7.10.21. Таблица error_messages Таблица 7.34. Столбцы error_messages Имя Тип Описание error_code integer Числовой код ошибки error_description string Описание ошибки error_status string Код статуса ошибки error_classification integer Ошибочный классификационный код error_code это числовой код ошибки NDB. Это тот же самый код ошибки, который может поставляться ndb_perror или perror --ndb. error_description предоставляет основное описание условия, вызывающего ошибку. Столбец error_status обеспечивает информацию о статусе, касающуюся ошибки. Возможные значения для этого столбца перечисляются здесь: No error Illegal connect string Illegal server handle Illegal reply from server Illegal number of nodes Illegal node status Out of memory Management server not connected Could not connect to socket Start failed Stop failed Restart failed Could not start backup Could not abort backup Could not enter single user mode Could not exit single user mode Failed to complete configuration change Failed to get configuration Usage error Success Permanent error Temporary error Unknown result Temporary error, restart node Permanent error, external action needed Ndbd file system error, restart node initial Unknown Колонка error_classification показывает классификацию ошибок. См. See NDB Error Classifications. Таблица error_messages добавлена в NDB 7.6.4. 7.10.22. Таблица locks_per_fragment Таблица locks_per_fragment предоставляет информацию о счетчиках блокировок в запросах требования блокировки и результатах этих запросов на основе фрагмента, служа сопутствующей таблицей к operations_per_fragment и memory_per_fragment. Эта таблица также показывает полное время ожидания блокировок, начиная с создания таблицы или фрагмента или с нового перезапуска. Таблица 7.35. Столбцы locks_per_fragment Имя Тип Описание fq_name string Полностью компетентное имя таблицы parent_fq_name string Полностью определенное имя родительского объекта type string Тип таблицы table_id integer ID таблицы node_id integer ID узла block_instance integer LDM ID fragment_num integer Идентификатор фрагмента ex_req integer Запросы монопольной блокировки начаты ex_imm_ok integer Монопольная блокировка немедленно просит предоставления ex_wait_ok integer Запросы монопольной блокировки ждут ex_wait_fail integer Запросы монопольной блокировки не предоставлены sh_req integer Запросы коллективной блокировки начаты sh_imm_ok integer Коллективная блокировка немедленно предоставлена sh_wait_ok integer Запросы коллективной блокировки ждут sh_wait_fail integer Запросы коллективной блокировки не предоставлены wait_ok_millis integer Время, потраченное на ожидание запросов блокировки, которые предоставлены, в миллисекундах wait_fail_millis integer Время, потраченное на ожидание запросов блокировки, которые не предоставлены, в миллисекундах block_instance относится к случаю ядерного блока. Вместе с именем блока это число может использоваться, чтобы искать приведенный пример в таблице threadblocks. fq_name полностью компетентное имя объекта базы данных в формате database/ schema/name, например, test/def/t1 или sys/def/10/b$unique. parent_fq_name полностью определенное имя родительского объекта этого объекта (таблицы). table_id это внутренний ID таблицы, произведенный NDB. Это тот же самый внутренний ID таблицы, показанный в других таблицах ndbinfo, это также видимо в выводе ndb_show_tables. Столбец type показывает тип таблицы. Это всегда одно из System table, User table, Unique hash index, Hash index, Unique ordered index, Ordered index, Hash index trigger, Subscription trigger, Read only constraint, Index trigger, Reorganize trigger, Tablespace, Log file group, Data file, Undo file, Hash map, Foreign key definition, Foreign key parent trigger, Foreign key child trigger или Schema transaction. Значения, показанные во всех колонках ex_req, ex_req_imm_ok, ex_wait_ok, ex_wait_fail, sh_req, sh_req_imm_ok, sh_wait_ok и sh_wait_fail представляют совокупные числа запросов, начиная с создания таблицы или фрагмента или начиная с последнего перезапуска этого узла, смотря что было позже. Это также верно для временных значений в столбцах wait_ok_millis и wait_fail_millis. Каждый запрос блокировки происходит, или заканчивается в некотором роде (то есть, имеет успех или терпит неудачу). Это означает, что следующие отношения верны: ex_req >= (ex_req_imm_ok + ex_wait_ok + ex_wait_fail) sh_req >= (sh_req_imm_ok + sh_wait_ok + sh_wait_fail) Количество в настоящее время происходящих запросов это текущее количество неполных запросов, которые могут быть найдены, как показано здесь: [exclusive lock requests in progress] = ex_req - (ex_req_imm_ok + ex_wait_ok + ex_wait_fail) [shared lock requests in progress] = sh_req - (sh_req_imm_ok + sh_wait_ok + sh_wait_fail) Неудавшееся ожидание указывает на прерванную транзакцию, но аварийное прекращение работы может или не может быть вызвано тайм-аутом блокировки. Можно получить общее количество аварийных прекращений работы, ожидая блокировки, как показано здесь: [aborts while waiting for locks] = ex_wait_fail + sh_wait_fail Таблица locks_per_fragment добавлена в NDB 7.5.3. 7.10.23. Таблица logbuffers Таблица logbuffer предоставляет информацию об использовании буфера регистрации кластера NDB. Таблица 7.36. Столбцы logbuffers Имя Тип Описание node_id integer ID узла данных log_type string Тип журнала. До NDB 7.6.6 одно из REDO или DD-UNDO. В NDB 7.6.6 или позже одно из REDO, DD-UNDO, BACKUP-DATA или BACKUP-LOG. log_id integer ID журнала log_part integer Номер части журнала total integer Место, доступное этому журналу used integer Место, занятое журналом Начиная с NDB 7.6.6, строки в logbuffers отражающие два дополнительных типа регистрации, доступны, выполняя резервную копию NDB. У одной из этих строк есть тип регистрации BACKUP-DATA, который показывает буфер объема данных, используемый во время резервной копии, чтобы скопировать фрагменты к резервным файлам. У другой строки есть тип регистрации BACKUP-LOG, который показывает сумму буфера регистрации, используемого во время резервной копии, чтобы сделать запись изменений, внесенных после того, как резервная копия началась. Каждая из них показана в таблице logbuffers для каждого узла данных в кластере. Эти строки не присутствуют, если резервная копия NDB в настоящее время не выполняется (Bug #25822988). 7.10.24. Таблица logspaces Таблица предоставляет информацию об использовании пространства регистрации кластера NDB. Таблица 7.37. Столбцы logspaces Имя Тип Описание node_id integer ID узла данных log_type string Тип журнала, одно из: REDO или DD-UNDO. log_id integer ID журнала log_part integer Номер части журнала total integer Место, доступное этому журналу used integer Место, занятое журналом 7.10.25. Таблица membership Таблица membership описывает представление, что у каждого узла данных есть вся информация о кластере. Таблица 7.38. Столбцы membership Имя Тип Описание node_id integer ID узла group_id integer Группа узлов, которой принадлежит этот узел left node integer ID предыдущего узла right_node integer ID следующего узла president integer ID президент-узла successor integer ID преемника президента succession_order integer Порядок, в котором этот узел наследует президентство Conf_HB_order integer - arbitrator integer ID арбитра arb_ticket string Внутренний идентификатор отслеживания арбитража arb_state Enumeration (see text) Арбитражный статус arb_connected Yes или No Связан ли этот узел с арбитром connected_rank1_arbs Список ID узлов Связанные арбитры уровня 1 connected_rank2_arbs Список ID узлов Связанные арбитры уровня 2 ID узла и ID группы узла совпадают с сообщаемыми ndb_mgm -e "SHOW". left_node и right_node определяются с точки зрения модели, которая соединяет все узлы данных в порядке их ID узлов, подобно порядку чисел на дисках часов, как показано здесь: Рис. 7.1. Расположение узлов NDB Cluster Nodes В этом примере у нас есть 8 узлов данных, пронумерованных 5, 6, 7, 8, 12, 13, 14 и 15, упорядоченных по часовой стрелке. Мы определяем left и right из интерьера круга. Узел налево от узла 5 является узлом 15, узел направо от узла 5 является узлом 6. Вы видите все эти отношения, управляя следующим запросом и наблюдая вывод: mysql> SELECT node_id,left_node,right_node FROM ndbinfo.membership; +---------+-----------+------------+ | node_id | left_node | right_node | +---------+-----------+------------+ | 5 | 15 | 6 | | 6 | 5 | 7 | | 7 | 6 | 8 | | 8 | 7 | 12 | | 12 | 8 | 13 | | 13 | 12 | 14 | | 14 | 13 | 15 | | 15 | 14 | 5 | +---------+-----------+------------+ 8 rows in set (0.00 sec) Обозначения left и right используются в регистрации событий таким же образом. Узел president это узел, рассматриваемый текущим узлом как ответственный за урегулирование арбитра (см. NDB Cluster Start Phases). Если он отвалится, текущий узел ожидает, что его заменит узел, ID которого показывают в столбце successor. Столбец succession_order показывает место в очереди последовательности. В нормальном NDB Cluster все узлы данных должны видеть тот же самый узел как president и тот же самый узел (кроме президента) как преемник . Кроме того, действующий президент должен видеть себя как 1 в порядке последовательности, преемник должен видеть себя как 2 и т.д. Все узлы должны показать то же самое значение arb_ticket, а также то же самое arb_state. Возможные значения arb_state это ARBIT_NULL, ARBIT_INIT, ARBIT_FIND, ARBIT_PREP1, ARBIT_PREP2, ARBIT_START, ARBIT_RUN, ARBIT_CHOOSE, ARBIT_CRASH и UNKNOWN. arb_connected показывает, связан ли этот узел с узлом, показанным как этот узел arbitrator. Столбцы connected_rank1_arbs и connected_rank2_arbs каждый показывают список из 0 или больше арбитров, имеющих ArbitrationRank = 1 или 2, соответственно. Узлы управления и узлы API имеют право стать арбитрами. 7.10.26. Таблица memoryusage Запрос этой таблицы предоставляет информацию, подобную обеспеченной командой ALL REPORT MemoryUsage в клиенте ndb_mgm или ALL DUMP 1000. Таблица 7.39. Столбцы memoryusage Имя Тип Описание node_id integer ID узла. memory_type string Одно из Data memory, Index memory или Long message buffer. used integer Число байтов, которое в настоящее время используется для памяти данных или памяти индекса этим узлом данных used_pages integer Число страниц, которое в настоящее время используется для памяти данных или памяти индекса этим узлом данных total integer Общее количество байтов памяти данных или памяти индекса, доступной для этого узла данных total_pages integer Общее количество страниц памяти, доступных для памяти данных или памяти индекса на этом узле данных Столбец total представляет общую сумму памяти в байтах, доступных для данного ресурса (память данных или память индекса) на конкретном узле данных. Это число должно быть приблизительно равно соответствующему параметру конфигурации в файле config.ini. Предположим, что у кластера есть 2 узла данных, имеющие ID узла 5 и 6, и файл config.ini: [ndbd default] DataMemory = 1G IndexMemory = 1G Предположим также, что LongMessageBuffer позволяют принять его умолчание (64 МБ). Следующий запрос показывает приблизительно те же самые значения: mysql> SELECT node_id, memory_type, total FROM ndbinfo.memoryusage; +---------+---------------------+------------+ | node_id | memory_type | total | +---------+---------------------+------------+ | 5 | Data memory | 1073741824 | | 5 | Index memory | 1074003968 | | 5 | Long message buffer | 67108864 | | 6 | Data memory | 1073741824 | | 6 | Index memory | 1074003968 | | 6 | Long message buffer | 67108864 | +---------+---------------------+------------+ 6 rows in set (0.00 sec) В этом случае значения столбцов total для памяти индекса немного выше, чем значение IndexMemory из-за внутреннего округления. Для столбцов used_pages и total_pages ресурсы измерены в страницах, которые являются по 32K размером для DataMemory и по 8K для IndexMemory. Для длинной буферной памяти сообщения размер страницы составляет 256 байтов. 7.10.27. Таблица memory_per_fragment Таблица memory_per_fragment предоставляет информацию об использовании памяти отдельными фрагментами. Таблица 7.40. Столбцы memory_per_fragment Имя Тип Описание fq_name string Название этого фрагмента parent_fq_name string Имя родителя этого фрагмента type string Тип объекта table_id integer ID для этой таблицы node_id integer ID узла block_instance integer ID экземпляра блока ядра fragment_num integer ID фрагмента (число) fixed_elem_alloc_bytes integer Число байтов ассигнуется для элементов фиксированного размера fixed_elem_free_bytes integer Свободные байты, остающиеся на страницах, ассигнованных элементам фиксированного размера fixed_elem_size_bytes integer Длина каждого элемента фиксированного размера в байтах fixed_elem_count integer Количество элементов фиксированного размера fixed_elem_free_count decimal Количество свободных строк для элементов фиксированного размера var_elem_alloc_bytes integer Число байтов ассигнуется для элементов переменного размера var_elem_free_bytes integer Свободные байты, остающиеся на страницах, ассигнованных элементам переменного размера var_elem_count integer Количество элементов переменного размера hash_index_alloc_bytes integer Число байтов ассигнуется хэш-индексам Столбец type показывает тип объекта словаря, используемый для этого фрагмента (Object::Type в NDB API) и может взять любое из этих значений: System table User table Unique hash index Hash index Unique ordered index Ordered index Hash index trigger Subscription trigger Read only constraint Index trigger Reorganize trigger Tablespace Log file group Data file Undo file Hash map Foreign key definition Foreign key parent trigger Foreign key child trigger Schema transaction Можно также получить этот список, выполнив SELECT * FROM ndbinfo.dict_obj_types в клиенте mysql. Столбец block_instance обеспечивает номер экземпляра ядерного блока NDB. Можно использовать это, чтобы получить информацию об определенных потоках из таблицы threadblocks. 7.10.28. Таблица nodes Эта таблица содержит информацию о статусе узлов данных. Для каждого узла данных, который работает в кластере, соответствующая строка в этой таблице предоставляет ID узла, статус и продолжительность работы. Для узлов, которые стартуют, это также показывает текущую фазу начала. Таблица 7.41. Столбцы nodes Имя Тип Описание node_id integer Уникальный ID узла данных в кластере. uptime integer Время, начиная с последнего старта узла, в секундах. status string Текущий статус узла данных. start_phase integer Если узел данных стартует, текущая фаза начала. config_generation integer Версия файла кластерной конфигурации в использовании на этом узле данных. Столбец uptime показывает время в секундах, которое этот узел работал. Это BIGINT. Это число включает время, нужное для запуска узла, другими словами, это считает запуском момент вызова ndbd или ndbmtd. Таким образом, даже для узла, который еще не закончил запуск, uptime может показать ненулевое значение. status показывает текущий статус узла. Это одно из: NOTHING, CMVMI, STARTING, STARTED, SINGLEUSER, STOPPING_1, STOPPING_2, STOPPING_3 или STOPPING_4. Если это STARTING, вы видите текущую фазу старта в start_phase. SINGLEUSER показано в status для всех узлов данных, когда кластер будет в однопользовательском режиме (см. раздел 7.8). Наблюдение одного из статусов STOPPING необязательно означает, что узел закрывается, это может означать, что узел входит в новый статус. Например, если вы помещаете кластер в однопользовательский режим, можно иногда видеть, что узлы данных сообщают о своем статусе STOPPING_2 перед статусом SINGLEUSER. start_phase использует тот же самый диапазон значений как используемые в выводе node_idSTATUS (см. раздел 7.2). Если узел в настоящее время не начинается, то эта колонка показывает 0. Для списка фаз старта кластера NDB с описаниями посмотрите раздел 7.1. config_generation показывает, какая версия кластерной конфигурации находится в действительности на каждом узле данных. Это может быть полезно, выполняя катящийся перезапуск кластера, чтобы внести изменения в параметрах конфигурации. Например, из вывода SELECT вы видите, что узел 3 еще не использует последнюю версию кластерной конфигурации (6), хотя узлы 1, 2, и 4 это делают: mysql> USE ndbinfo; Database changed mysql> SELECT * FROM nodes; +---------+--------+---------+-------------+-------------------+ | node_id | uptime | status | start_phase | config_generation | +---------+--------+---------+-------------+-------------------+ | 1 | 10462 | STARTED | 0 | 6 | | 2 | 10460 | STARTED | 0 | 6 | | 3 | 10457 | STARTED | 0 | 5 | | 4 | 10455 | STARTED | 0 | 6 | +---------+--------+---------+-------------+-------------------+ 2 rows in set (0.04 sec) Поэтому для показанного случая необходимо перезапустить узел 3, чтобы закончить катящийся перезапуск кластера. Узлы, которые остановлены, не составляются в этой таблице. Предположим, что у вас есть кластер NDB с 4 узлами данных (ID узлов 1, 2, 3 и 4), все узлы работают обычно, тогда эта таблица содержит 4 строки, 1 для каждого узла данных: mysql> USE ndbinfo; Database changed mysql> SELECT * FROM nodes; +---------+--------+---------+-------------+-------------------+ | node_id | uptime | status | start_phase | config_generation | +---------+--------+---------+-------------+-------------------+ | 1 | 11776 | STARTED | 0 | 6 | | 2 | 11774 | STARTED | 0 | 6 | | 3 | 11771 | STARTED | 0 | 6 | | 4 | 11769 | STARTED | 0 | 6 | +---------+--------+---------+-------------+-------------------+ 4 rows in set (0.04 sec) Если вы закрываете один из узлов, только узлы, которые все еще работают, представляются в выводе этого SELECT: ndb_mgm> 2 STOP Node 2: Node shutdown initiated Node 2: Node shutdown completed. Node 2 has shutdown. mysql> SELECT * FROM nodes; +---------+--------+---------+-------------+-------------------+ | node_id | uptime | status | start_phase | config_generation | +---------+--------+---------+-------------+-------------------+ | 1 | 11807 | STARTED | 0 | 6 | | 3 | 11802 | STARTED | 0 | 6 | | 4 | 11800 | STARTED | 0 | 6 | +---------+--------+---------+-------------+-------------------+ 3 rows in set (0.02 sec) 7.10.29. Таблица operations_per_fragment Таблица operations_per_fragment предоставляет информацию об операциях, выполненных на отдельных фрагментах и точных копиях фрагмента, а также о некоторых следствиях этих операций. Таблица 7.42. Столбцы operations_per_fragment Имя Тип Описание fq_name string Имя фрагмента parent_fq_name string Имя родителя этого фрагмента type string Тип объекта table_id integer ID таблицы node_id integer ID узла block_instance integer ID экземпляра ядерного блока fragment_num integer ID фрагмента tot_key_reads integer Общее количество чтений ключа для этой точной копии фрагмента tot_key_inserts integer Общее количество ключевых вставок для этой точной копии фрагмента tot_key_updates integer Общее количество ключевых обновлений для этой точной копии фрагмента tot_key_writes integer Общее количество записей ключа для этой точной копии фрагмента tot_key_deletes integer Общее количество удалений ключа для этой точной копии фрагмента tot_key_refs integer Количество отклоненных ключевых операций tot_key_attrinfo_bytes integer Полный размер всех признаков attrinfo tot_key_keyinfo_bytes integer Полный размер всех признаков keyinfo tot_key_prog_bytes integer Полный размер всех интерпретируемых программ, которые несут признаки attrinfo tot_key_inst_exec integer Общее количество инструкций, выполняемых интерпретируемыми программами за ключевые операции tot_key_bytes_returned integer Полный размер всех данных и метаданных, возвращенных из ключевых операций чтения tot_frag_scans integer Общее количество просмотров на этой точной копии фрагмента tot_scan_rows_examined integer Общее количество строк исследовано просмотрами tot_scan_rows_returned integer Общее количество строк возвращено клиенту tot_scan_bytes_returned integer Полный размер данных и метаданных, возвращенных клиенту tot_scan_prog_bytes integer Полный размер интерпретируемых программ для операций по просмотру tot_scan_bound_bytes integer Полный размер всех границ в упорядоченных просмотрах индекса tot_scan_inst_exec integer Общее количество инструкций за просмотры tot_qd_frag_scans integer Сколько раз просмотры этой точной копии фрагмента стояли в очереди conc_frag_scans integer Количество просмотров, в настоящее время активных на этой точной копии фрагмента (исключая просмотры с очередями) conc_qd_frag_scans integer Количество просмотров в настоящее время в очереди за этой точной копией фрагмента tot_commits integer Общее количество переданных изменений строки на эту точную копию фрагмента fq_name содержит полностью определенное имя объекта схемы, которому принадлежит эта точная копия фрагмента. У этого в настоящее время есть следующие форматы: Базовая таблица: DbName/def/TblName Таблица BLOB: DbName /def/NDB$BLOB_BaseTblId_ ColNo Упорядоченный индекс: sys/def/ BaseTblId/ IndexName Уникальный индекс: sys/def/ BaseTblId/ IndexName$unique Сцффикс $unique, показанный для уникальных индексов, добавляется mysqld, для индекса, созданного иным клиентским приложением API NDB, это может отличаться или не присутствовать. Синтаксис, показанный для полностью компетентных имен объектов, является внутренним интерфейсом, который подвержен изменениям в будущих выпусках. Рассмотрите таблицу t1, созданную и измененную следующими SQL-операторами: CREATE DATABASE mydb; USE mydb; CREATE TABLE t1 (a INT NOT NULL, b INT NOT NULL, t TEXT NOT NULL, PRIMARY KEY (b)) ENGINE=ndbcluster; CREATE UNIQUE INDEX ix1 ON t1(b) USING HASH; Если t1 назначен таблице ID 11, зщначения fq_name такие: Базовая таблица: mydb/def/t1 Таблица BLOB: mydb/def/NDB$BLOB_11_2 Упорядоченный индекс (первичный ключ): sys/def/11/PRIMARY Уникальный индекс: sys/def/11/ix1$unique Для индексов или таблиц BLOB столбец parent_fq_name содержит fq_name из соответствующей базовой таблицы. Для базовых таблиц эта колонка всегда NULL. Столбец type показывает тип объекта схемы, используемый для этого фрагмента, который может взять любое из значений System table, User table, Unique hash index или Ordered index. Таблицы BLOB показывают как User table. Значение столбца table_id уникально в любой момент времени, но может быть снова использовано, если соответствующий объект был удален. Тот же самый ID может быть замечен, используя ndb_show_tables. Столбец block_instance показывает столбцы, которым принадлежит экземпляр LDM этой точной копии фрагмента. Можно использовать это, чтобы получить информацию об определенных потоках из таблицы threadblocks. Первый такой экземпляр всегда нумеруется 0. С тех пор, как правило, есть две точных копии и предполагая, что это так, каждое значение fragment_num должно появиться дважды в таблице на двух различных узлах данных той же самой группы узлов. С тех пор, как NDB не использует одно-ключевой доступ для упорядоченных индексов, счетчики для tot_key_reads, tot_key_inserts, tot_key_updates, tot_key_writes и tot_key_deletes не увеличены операциями по индексу. Используя tot_key_writes, необходимо иметь в виду, что операция записи в этом контексте обновляет строку, если ключ существует и вставляет новую строку иначе. Одно использование этого находится в реализации NDB SQL-запроса REPLACE. Столбец tot_key_refs показывает количество ключевых операций, которым отказывает LDM. Обычно такой отказ должен сделать дубликаты ключа (вставки), Key not found ошибки (обновления, удаления и чтения) или операция была отклонена интерпретируемой программой, используемой в качестве предиката на строке, соответствующей ключу. The attrinfo и keyinfo, посчитанные столбцами tot_key_attrinfo_bytes и tot_key_keyinfo_bytes это признаки сигнала LQHKEYREQ (см. The NDB Communication Protocol), используемого для инициализации ключевой операции LDM. attrinfo, как правило, содержит значения полей кортежа (вставки и обновления) или технические требования проектирования (для чтения), keyinfo содержит первичный или уникальный ключ, который должен был определить местонахождение данного кортежа в этом объекте схемы. Значение, показанное tot_frag_scans, включает оба полных просмотра (которые исследуют каждую строку) и просмотры подмножеств. Уникальные индексы и таблицы BLOB никогда не просматриваются, таким образом, эта значение, как другое, связанное с просмотром количество, 0 для точных копий их фрагмента. tot_scan_rows_examined может показать меньше, чем общее количество строк в данной точной копии фрагмента, так как упорядоченный просмотр индекса может быть ограничен границами. Кроме того, клиент может закончить просмотр, прежде чем все потенциально соответствующие строки были исследованы, это происходит, используя SQL-оператор, содержащий LIMIT или EXISTS, например. tot_scan_rows_returned всегда меньше или равно equal to tot_scan_rows_examined. tot_scan_bytes_returned включает, в случае сдвинутых соединений, прогнозы, возвращенные блоку DBSPJ ядра NDB. tot_qd_frag_scans может быть произведен урегулированием MaxParallelScansPerFragment, который ограничивает количество просмотров, которые можно выполнить одновременно на единственной точной копии фрагмента. 7.10.30. Таблица ndbinfo processes Эта таблица содержит информацию о процессах узла кластера NDB, каждый узел представляется строкой в таблице. Только узлы, которые связаны с кластером, показывают в этой таблице. Можно получить информацию об узлах, которые формируются, но не связываются с кластером, из таблиц nodes и config_nodes. Таблица 7.43. Столбцы nodes Имя Тип Описание node_id integer Уникальный ID узла node_type string Тип узла (management, data или API) node_version string Версия NDB на этом узле process_id integer ID процесса узла angel_process_id integer ID процесса ангела process_name string Название исполняемого файла service_URI string URI этого узла node_id это ID, назначенный на этот узел в кластере. node_type это одно из следующих трех значений: MGM: узел управления. NDB: узел данных. API: узел API или SQL. Для исполняемого файла, отправленного с дистрибутивом NDB Cluster, node_version показывает строку версии MySQL NDB кластера с двумя частями, например, 5.7.29-ndb-7.5.17 или 5.7.29-ndb-7.6.13. Посмотрите подробности. process_id это ID процесса исполняемого файла узла, как показано хостовой операционной системой, используя приложение показа процесса, такое как top в Linux или Task Manager в Windows. angel_process_id это системный процесс ID для процесса ангела узла, который гарантирует, что узел данных или SQL автоматически перезапущены в случаях неудач. Для узлов управления и узлов API, кроме узлов SQL, значение этого столбца всегда NULL. process_name показывает название работающего исполняемого файла. Для узлов управления это ndb_mgmd. Для узлов данных это ndbd или ndbmtd. Для узлов SQL это mysqld. Для других типов узлов API это название исполняемой программы, связанной с кластером, приложение NDB API может установить свое значение для этого через Ndb_cluster_connection::set_name() . service_URI показывает сервисный адрес сети. Для узлов управления и узлов данных, используемая схема ndb://. Для узлов SQL это mysql://. По умолчанию узлы API, кроме узлов SQL, применяют ndb://, приложения NDB API могут установить свое значение через Ndb_cluster_connection::set_service_uri(). Независимо от типа узла схема сопровождается IP-адресом, используемым транспортером NDB для рассматриваемого узла. Для узлов управления и узлов SQL этот адрес включает номер порта (обычно 1186 для узлов управления и 3306 для узлов SQL). Если узел SQL был начат с установленной переменной bind_address, этот адрес используется вместо адреса транспортера, если адрес не установлен в *, 0.0.0.0 или ::. Дополнительная информация о пути может быть включена в service_URI для узла SQL, отражающего различные параметры конфигурации. Например, mysql://198.51.100.3/tmp/mysql.sock указывает, что узел SQL был начат с включенной переменной skip_networking, а mysql://198.51.100.3:3306/?server-id=1 показывает, которые репликации позволены для этого узла SQL. Таблица processes добавлена в NDB 7.5.7 и NDB 7.6.2. 7.10.31. Таблица ndbinfo resources Этот таблица предоставляет информацию о доступности ресурса узла данных и использовании. Эти ресурсы иногда известны как суперпул. Таблица 7.44. Столбцы resources Имя Тип Описание node_id integer ID узла. resource_name string Имя ресурса. reserved integer Сумма зарезервирована для этого ресурса. used integer Сумма на самом деле используется этим ресурсом. max integer Максимальная сумма этого используемого ресурса, начиная с последнего запуска узла. resource_name может быть одним из имен, показанных в следующей таблице: Таблица 7.45. ndbinfo.resources: имена ресурса таблицы и описания Имя Описание RESERVED Зарезервировано системой, не может быть отвергнуто. DISK_OPERATIONS Если группа файла журнала ассигнуется, размер буфера отмены регистрации используется, чтобы установить размер этого ресурса. Этот ресурс используется только, чтобы ассигновать буфер отмен регистрации для группы файла журнала отмен, может только быть одна такая группа. Сверхраспределение происходит по мере необходимости CREATE LOGFILE GROUP. DISK_RECORDS Записи ассигнуются для дисковых операций по данным. DATA_MEMORY Используемый для кортежей оперативной памяти, индексов и хэш-индексов. Сумма DataMemory и IndexMemory, плюс 8 страниц по 32 КБ каждая, если IndexMemory был установлен. Не может быть сверхассигнован. JOBBUFFER Используемый для распределения буферов работы планировщика NDB, не может быть сверхассигнован. Это приблизительно 2 МБ на поток плюс буфер на 1 МБ в обоих направлениях для всех потоков, которые могут общаться. Для больших конфигураций это потребляет несколько GB. FILE_BUFFERS Используемый укладчиком журнала отката в ядерном блоке DBLQH. Не может быть сверхассигнован. Размер NoOfFragmentLogParts * RedoBuffer плюс 1 МБ на каждую часть файла журнала. TRANSPORTER_BUFFERS Используемый для буфера передачи ndbmtd, сумма TotalSendBufferMemory и ExtraSendBufferMemory. Этот ресурс может быть сверхассигнован максимум на 25 процентов. TotalSendBufferMemory вычисляется, суммируя буферную память передачи на узел, значение по умолчанию составляет 2 МБ. Таким образом, в системе, имеющей четыре узла данных и восемь узлов API, узлы данных имеют 12*2 МБ буферной памяти передачи. ExtraSendBufferMemory используется ndbmtd и добавляет к дополнительной памяти по 2 МБ на поток. Таким образом, с 4 потоками LDM, 2 TC, 1 основным, 1 репликации и 2 получателями ExtraSendBufferMemory = 10*2 MB. Сверхраспределение этого ресурса может быть выполнено, установив SharedGlobalMemory. DISK_PAGE_BUFFER Используемый для дискового буфера страницы, определен DiskPageBufferMemory. Не может быть сверхассигнован. QUERY_MEMORY Применяется ядерным блоком DBSPJ. SCHEMA_TRANS_MEMORY Минимум составляет 2 МБ, может быть сверхассигнован, чтобы использовать любую остающуюся доступную память. 7.10.32. Таблица restart_info Таблица restart_info содержит информацию об операциях по перезапуску узла. Каждый вход в ней соответствует отчету о состоянии перезапуска узла в режиме реального времени от узла данных с данным ID узла. Только новый отчет для любого данного узла показывают. Таблица 7.46. Столбцы restart_info Код статуса узла. Имя Тип Описание node_id integer ID узла. node_restart_status VARCHAR(256) Статус узла. Каждое из них соответствует возможному значению node_restart_status_int. node_restart_status_int integer secs_to_complete_node_failure integer Время в секундах, чтобы закончить обработку неудачи узла. secs_to_allocate_node_id integer Время в секундах от завершения неудачи узла до распределения ID узла. secs_to_include_in_heartbeat_protocol integer Время в секундах от распределения ID узла до включения в протокол синхронизации. secs_until_wait_for_ndbcntr_master integer Время в секундах от того, чтобы быть включенным в протокол синхронизации до ожидания NDBCNTR. secs_wait_for_ndbcntr_master integer Время в секундах, проведенных, ожидая, чтобы быть принятым NDBCNTR для работы. secs_to_get_start_permitted integer Время в секундах от получения разрешения для начала от ведущего, пока все узлы не приняли запуск этого узла. secs_to_wait_for_lcp_for_copy_meta_data integer Время в секундах, проведенных, ожидая завершения LCP прежде, чем скопировать метаданные. secs_to_copy_meta_data integer Время в секундах, требуемое, чтобы скопировать метаданные от ведущего к недавно стартовавшему узлу. secs_to_include_node integer Время в секундах ожидания GCP и включения всех узлов в протоколы. secs_starting_node_to_request_local_recovery integer Время в секундах, которое стартующий узел потратил на ожидание, чтобы просить местное восстановление. secs_for_local_recovery integer Время в секундах, требуемое для местного восстановления стартующего узла. secs_restore_fragments integer Время в секундах, требуемое, чтобы восстановить фрагменты от файлов LCP. secs_undo_disk_data integer Время в секундах, требуемое, чтобы выполнять журнал отмен дисковой части данных записей. secs_exec_redo_log integer Время в секундах, требуемое, чтобы выполнить журнал отката на всех восстановленных фрагментах. secs_index_rebuild integer Время в секундах, требуемое, чтобы восстановить индексы на восстановленных фрагментах. secs_to_synchronize_starting_node integer Время в секундах, требуемое, чтобы синхронизировать стартовый узел от живых узлов. secs_wait_lcp_for_restart integer Время в секундах, требуемое для начала LCP и завершения перед перезапуском. secs_wait_subscription_handover integer Время в секундах, проведенное ожидая передачи подписок репликации. total_restart_secs integer Общее количество секунд от неудачи узла до повторного запуска. Определенные значения для node_restart_status_int, соответствующие имена статуса и сообщения (node_restart_status): Таблица 7.47. Коды статусов и сообщения в таблице restart_info Имя Тип Описание 0 ALLOCATED_NODE_ID Распределение id узла 1 INCLUDED_IN_HB_PROTOCOL Включение в проткол синхронизации 2 NDBCNTR_START_WAIT Ожидание разрешения NDBCNTR 3 NDBCNTR_STARTED NDBCNTR старт разрешил 4 START_PERMITTED Все узлы разрешили старт 5 WAIT_LCP_TO_COPY_DICT Ожидание завершения LCP для начала копирования метаданных 6 COPY_DICT_TO_STARTING_NODE Копирование метаданных в узел 7 INCLUDE_NODE_IN_LCP_AND_GCP Включение в протоколы LCP и GCP 8 LOCAL_RECOVERY_STARTED Восстановление фрагментов 9 COPY_FRAGMENTS_STARTED Синхронизация с другими узлами 10 WAIT_LCP_FOR_RESTART Ожидание LCP 11 WAIT_SUMA_HANDOVER Ожидание подписчиков 12 RESTART_COMPLETED Перезапуск выполнен 13 NODE_FAILED Узел отвалился и перезагружается 14 NODE_FAILURE_COMPLETED Обработка сбоя завершена 15 NODE_GETTING_PERMIT Все узлы разрешили запуск 16 NODE_GETTING_INCLUDED Включение в протоколы LCP и GCP 17 NODE_GETTING_SYNCHED Синхронизация с другими узлами 18 NODE_GETTING_LCP_WAITED [none] 19 NODE_ACTIVE Перезапуск выполнен 20 NOT_DEFINED_IN_CLUSTER [none] 21 NODE_NOT_RESTARTED_YET Состояние инициализации Числа статуса от 0 до 12 применяются только на главных узлах, остаток относится ко всем узлам данных. Статусные номера 13 и 14 определяют состояния неудачи узла, 20 и 21 происходят, когда никакая информация о перезапуске данного узла недоступна. См. также раздел 7.1. 7.10.33. Таблица server_locks Таблица server_locks подобна в структуре cluster_locks и обеспечивает подмножество информации, найденной в последней таблице, но которая является определенной для узла SQL (сервер MySQL). cluster_locks предоставляет информацию обо всех блокировких в кластере. Более точно, server_locks содержит информацию о блокировких, которые требуют потоки, принадлежащие текущему экземпляру mysqld, и служит сопутствующей таблицей server_operations. Это может быть полезно для корреляции образцов блокировки с определенными сеансами пользователя MySQL, запросами или вариантами использования. Таблица 7.48. Столбцы server_locks Имя Тип Описание mysql_connection_id integer ID соединения MySQL node_id integer ID узла block_instance integer ID сообщения о LDM tableid integer ID таблицы, содержащей эту строку fragmentid integer ID фрагмента, содержащего блокированную строку rowid integer ID блокированной строки transid integer ID транзакции mode string Способ запроса блокировки state string Статус блокировки detail string Является ли это первым фиксатором в очереди блокировки строки op string Операционный тип duration_millis integer Миллисекунды, потраченные на ожидание или блокировку lock_num integer ID объекта блокирования waiting_for integer Ожидание блокировки с этим ID mysql_connection_id показывает ID потока или подключения mysql, как показано SHOW PROCESSLIST. block_instance относится к экземпляру ядерного блока. Вместе с именем блока это число может использоваться, чтобы искать приведенный пример в таблице threadblocks. tableid назначен таблице NDB, тот же самый ID используется для этой таблицы в других таблицах ndbinfo, а также в выводе ndb_show_tables. ID транзщакции в столбце transid это идентификатор, произведенный API NDB для операционного требования или удерживания текущей блокировки. Столбец mode показывает способ блокировки, который всегда является одним из S (коллективная блокировка) или X (монопольная блокировка). Если у транзакции есть монопольная блокировка на данной строке, все другие блокировки этой строки имеют тот же самый ID транзакции. Столбец state показывает статус блокировки. Его значение всегда один из H (держит) или W (ждет). Запрос блокировки ожидания ждет блокировку, сделанную другой транзакцией. Столбец detail указывает, является ли эта блокировка первым фиксатором в очереди блокировки затронутой строки, в этом случае это содержит * (звездочка), иначе эта колонка пуста. Эта информация может использоваться, чтобы помочь определить уникальные записи в списке запросов блокировки. Столбец op показывает тип операции, просящей блокировку. Это всегда одно из значений READ, INSERT, UPDATE, DELETE, SCAN или REFRESH. duration_millis показывает количество миллисекунд, которые этот запрос блокировки ждал или держал блокировку. Это перезагружается к 0, когда блокировку предоставляют для запроса ожидания. lock ID (столбец lockid) уникально для этого узла и экземпляра блока. Если значение столбца lock_state = W, блокировка ждет, чтобы быть предоставленной, и столбец waiting_for показывает ID блокировки объекта блокирования, которого ждет этот запрос. Иначе waiting_for пуст. waiting_for может относиться только к блокировкам той же строки (как определяется node_id, block_instance, tableid, fragmentid и rowid). Таблица server_locks добавлена в NDB 7.5.3. 7.10.34. Таблица server_operations Таблица server_operations содержит записи для всех продолжающихся операций NDB, в которые в настоящее время вовлекается текущий узел SQL (MySQL Server). Это эффективно подмножество таблицы cluster_operations, в которой не показывают операции для другого SQL и узлов API. Таблица 7.49. Столбцы server_operations Имя Тип Описание mysql_connection_id integer ID соединения MySQL Server node_id integer ID узла block_instance integer Экземпляр блока transid integer ID транзакции operation_type string Операционное состояние state string Статус действия tableid integer ID таблицы fragmentid integer ID фрагмента client_node_id integer ID узла клиента client_block_ref integer Ссылка блока клиента tc_node_id integer Координатор транзакции: ID узла tc_block_no integer Координатор транзакции: номер блока tc_block_instance integer Координатор транзакции: экземпляр блока mysql_connection_id совпадает со связью или сессией ID, показанным в выводе SHOW PROCESSLIST. Это получено из таблицы INFORMATION_SCHEMA NDB_TRANSID_MYSQL_CONNECTION_MAP . block_instance относится к экземпляру ядерного блока. Вместе с именем блока это число может использоваться, чтобы искать приведенный пример в таблице threadblocks. ID транзакции (transid) это уникальное 64-битное число, которое может быть получено, используя метод NDB API getTransactionId(). operation_type может взять любое из значений READ, READ-SH, READ-EX, INSERT, UPDATE, DELETE, WRITE, UNLOCK, REFRESH, SCAN, SCAN-SH, SCAN-EX или <unknown>. state может взять любое из значений ABORT_QUEUED, ABORT_STOPPED, COMMITTED, COMMIT_QUEUED, COMMIT_STOPPED, COPY_CLOSE_STOPPED, COPY_FIRST_STOPPED, COPY_STOPPED, COPY_TUPKEY, IDLE, LOG_ABORT_QUEUED, LOG_COMMIT_QUEUED, LOG_COMMIT_QUEUED_WAIT_SIGNAL, LOG_COMMIT_WRITTEN, LOG_COMMIT_WRITTEN_WAIT_SIGNAL, LOG_QUEUED, PREPARED, PREPARED_RECEIVED_COMMIT, SCAN_CHECK_STOPPED, SCAN_CLOSE_STOPPED, SCAN_FIRST_STOPPED, SCAN_RELEASE_STOPPED, SCAN_STATE_USED, SCAN_STOPPED, SCAN_TUPKEY, STOPPED, TC_NOT_CONNECTED, WAIT_ACC, WAIT_ACC_ABORT, WAIT_AI_AFTER_ABORT, WAIT_ATTR, WAIT_SCAN_AI, WAIT_TUP, WAIT_TUPKEYINFO, WAIT_TUP_COMMIT или WAIT_TUP_TO_ABORT. Если MySQL Server работает с включенной ndbinfo_show_hidden, можно смотреть этот список статусов, выбрав из обычно скрытой таблицы ndb$dblqh_tcconnect_state. Можно получить название таблицы NDB из ID таблицы, проверяя вывод ndb_show_tables. fragid совпадает с числом разделения в выводе ndb_desc --extra-partition-info (краткая форма -p). В client_node_id и client_block_ref client отсылает к кластеру NDB API или узлу SQL (то есть, клиент API NDB или MySQL Server, связанному с кластером). block_instance и tc_block_instance обеспечивает ядерные числа экземпляра блока NDB. Можно использовать их, чтобы получить информацию об определенных потоках из таблицы threadblocks. 7.10.35. Таблица server_transactions Таблица server_transactions это подмножество cluster_transactions, но включает только те транзакции, в которых текущий узел SQL является участником, включая соответствующую связь ID. Таблица 7.50. Столбцы server_transactions Количество операций с фиксацией состояния в транзакции Имя Тип Описание mysql_connection_id integer ID связи MySQL Server node_id integer Координатор транзакции: ID узла block_instance integer Координатор транзакции: экземпляр блока transid integer ID транзакции state string Статус действия count_operations integer outstanding_operations integer Операции, все еще выполняемые местным слоем управления данными (блоки LQH) inactive_seconds integer Время на ожидание API client_node_id integer ID узла клиента client_block_ref integer Ссылка блока клиента mysql_connection_id совпадает со связью или сессией ID в выводе SHOW PROCESSLIST. Он взят из таблицы INFORMATION_SCHEMA table NDB_TRANSID_MYSQL_CONNECTION_MAP . block_instance относится к экземпляру ядерного блока. Вместе с именем блока это число может использоваться, чтобы искать приведенный пример в таблице threadblocks. ID транзакции (transid) это уникальное 64-битное число, которое может быть получено, используя метод NDB API getTransactionId(). state может иметь любое из значений CS_ABORTING, CS_COMMITTING, CS_COMMIT_SENT, CS_COMPLETE_SENT, CS_COMPLETING, CS_CONNECTED, CS_DISCONNECTED, CS_FAIL_ABORTED, CS_FAIL_ABORTING, CS_FAIL_COMMITTED, CS_FAIL_COMMITTING, CS_FAIL_COMPLETED, CS_FAIL_PREPARED, CS_PREPARE_TO_COMMIT, CS_RECEIVING, CS_REC_COMMITTING, CS_RESTART, CS_SEND_FIRE_TRIG_REQ, CS_STARTED, CS_START_COMMITTING, CS_START_SCAN, CS_WAIT_ABORT_CONF, CS_WAIT_COMMIT_CONF, CS_WAIT_COMPLETE_CONF, CS_WAIT_FIRE_TRIG_REQ. Если MySQL Server работает с опцией ndbinfo_show_hidden, можно рассмотреть этот список статусов, выбрав из обычно скрытой таблицы ndb$dbtc_apiconnect_state. В client_node_id и client_block_ref client отсылает к кластеру NDB API или узлу SQL (то есть, клиенту API NDB или MySQL Server, связанному с кластером). block_instance обеспечивает ядерное число экземпляра блока DBTC. Можно использовать это, чтобы получить информацию об определенных потоках от таблицы threadblocks. 7.10.36. Таблица table_distribution_status Таблица table_distribution_status предоставляет информацию о прогрессе распределения таблицы для NDB. Таблица 7.51. Столбцы table_distribution_status Имя Тип Описание node_id integer ID узла table_id integer ID таблицы tab_copy_status string Статус копирования данных о распределении таблицы на диск, одно из IDLE, SR_PHASE1_READ_PAGES, SR_PHASE2_READ_TABLE, SR_PHASE3_COPY_TABLE, REMOVE_NODE, LCP_READ_TABLE, COPY_TAB_REQ, COPY_NODE_STATE, ADD_TABLE_MASTER, ADD_TABLE_SLAVE, INVALIDATE_NODE_LCP, ALTER_TABLE, COPY_TO_SAVE или GET_TABINFO tab_update_status string Статус обновления данных о распределении таблицы, одно из IDLE, LOCAL_CHECKPOINT, LOCAL_CHECKPOINT_QUEUED, REMOVE_NODE, COPY_TAB_REQ, ADD_TABLE_MASTER, ADD_TABLE_SLAVE, INVALIDATE_NODE_LCP или CALLBACK tab_lcp_status string Статус таблицы LCP, одно из ACTIVE (ждущий местной контрольной точки, которая будет выполнена), WRITING_TO_FILE (выполненная контрольная точка еще не написана на диск) или COMPLETED (контрольная точка выполнена и сохранена на диске) tab_status string Внутренний статус таблицы, одно из ACTIVE (существует), CREATING (создается) DROPPING (удалена) tab_storage string Восстанавливаемость таблицы, одно из NORMAL (полностью восстанавливаемая с журналом redo и контрольными точками), NOLOGGING (восстанавливаемая от сбоя узла, пустая при следующем сбое) или TEMPORARY (невосстанавливаемая) tab_partitions integer Количество разделов в таблице tab_fragments integer Количество фрагментов в таблице, обычно то же самое, как tab_partitions, поскольку полностью копируемые таблицы равняются tab_partitions * [число групп узлов] current_scan_count integer Текущее количество активных просмотров scan_count_wait integer Текущее количество просмотров, ждущих, чтобы быть выполненными до завершения ALTER TABLE. is_reorg_ongoing integer Реорганизовывается ли таблица в настоящее время (1, если true) Таблица table_distribution_status добавлена в NDB 7.5.4. 7.10.37. Таблица table_fragments Таблица table_fragments предоставляет информацию о фрагментации, разделении, распределении и (внутренней) репликации NDB. Таблица 7.52. Столбцы table_fragments Имя Тип Описание node_id integer ID узла (ведущий DIH ) table_id integer ID таблицы partition_id integer ID раздела fragment_id integer ID фрагмента (ID раздела, если таблица полностью не копируется) partition_order integer Порядок фрагмента в разделении log_part_id integer Часть регистрации ID фрагмента no_of_replicas integer Количество точных копий current_primary integer Текущий основной ID узла preferred_primary integer Предпочтительный основной ID узла current_first_backup integer Текущий первый резервный ID узла current_second_backup integer Текущий второй резервный ID узла current_third_backup integer Текущий третий резервный ID узла num_alive_replicas integer Текущее количество живых точных копий num_dead_replicas integer Текущее количество мертвых точных копий num_lcp_replicas integer Количество точных копий, остающихся для контрольных точек Таблица table_fragments добавлена в NDB 7.5.4. 7.10.38. Таблица table_info Таблица table_info предоставляет информацию о регистрации, распределении и возможностях хранения для таблиц NDB. Таблица 7.53. Столбцы table_info Имя Тип Описание table_id integer ID таблицы logged_table integer Зарегистрирована ли таблица (1) или нет (0) row_contains_gci integer Содержат ли строки таблицы GCI (1 true, 0 false) row_contains_checksum integer Содержат ли строки таблицы контрольную сумму (1 true, 0 false) read_backup integer Если резервные точные копии прочитаны, это 1, иначе 0 fully_replicated integer Если таблица полностью копируется, это 1, иначе 0 storage_type string Тип хранения таблицы, одно из MEMORY или DISK hashmap_id integer ID хэш-карты partition_balance string Баланс разделения (тип количества фрагментов), используемый для таблицы, одно из FOR_RP_BY_NODE, FOR_RA_BY_NODE, FOR_RP_BY_LDM или FOR_RA_BY_LDM create_gci integer GCI, в котором была составлена таблица Таблица table_info добавлена в NDB 7.5.4. 7.10.39. Таблица table_replicas Таблица table_replicas предоставляет информацию о копировании, распределении и точных копиях фрагментов таблицы NDB. Таблица 7.54. Столбцы table_replicas Имя Тип Описание node_id integer ID узла, от которого получены данные (ведущий DIH) table_id integer ID таблицы fragment_id integer ID фрагмента initial_gci integer Начальный GCI для таблицы replica_node_id integer ID узла, где точная копия сохранена is_lcp_ongoing integer 1, если LCP продолжается на этом фрагменте, 0 иначе num_crashed_replicas integer Количество сбойных экземпляров точной копии last_max_gci_started integer Самый высокий GCI, начатый в новом LCP last_max_gci_completed integer Самый высокий GCI, законченный в новом LCP last_lcp_id integer ID нового LCP prev_lcp_id integer ID предыдущего LCP prev_max_gci_started integer Самый высокий GCI, начатый в предыдущем LCP prev_max_gci_completed integer Самый высокий GCI, законченный в предыдущем LCP last_create_gci integer Последний Create GCI последней поврежденной реплики last_replica_gci integer Последний GCI последнего сбойного экземпляра точной копии is_replica_alive integer 1, если эта точная копия жива, 0 иначе Таблица table_replicas добавлена в NDB 7.5.4. 7.10.40. Таблица tc_time_track_stats Таблица tc_time_track_stats предоставляет отслеживающую время информацию, полученную из блока DBTC (TC) в узлах данных, через доступ узлов API NDB. Каждый экземпляр TC отслеживает времена ожидания для строки действий, которые это предпринимает от имени узлов API или других узлов данных, эти действия включают транзакции, операционные ошибки, чтение/запись ключа, операции по уникальному индексу, неудавшиеся ключевые операции любого типа, просмотры, сбои просмотра, просмотры фрагмента и ошибки просмотра фрагмента. Ряд счетчиков сохраняется для каждой деятельности, каждый счетчик, покрывающий диапазон времен ожидания, меньше равный верхней границе. В конце каждой деятельности определяется ее время ожидания, и соответствующий счетчик увеличен. tc_time_track_stats представляет эту информацию как строки, строкой для каждого экземпляра: Узел данных, используя его ID Экземпляр блока TC Другой узел данных о сообщении или узел API, используя его ID Значение верхней границы Каждая строка содержит значение для каждого типа деятельности. Это число раз, которое эта деятельность произошла за время ожидания в диапазоне, определенном строкой (то есть, где время ожидания не превышает верхнюю границу). Таблица 7.55. Столбцы tc_time_track_stats Имя Тип Описание node_id integer ID узла block_number integer TC: номер блока block_instance integer TC: номер экземпляра блока comm_node_id integer ID узла сообщения API или узла данных upper_bound integer Верхняя граница интервала (в микросекундах) scans integer На основе продолжительности успешных просмотров от открытия до закрытия, прослеженного против API или узлов данных scan_errors integer На основе продолжительности неудавшихся просмотров от открытия до закрытия, прослеженного против API или узлов данных scan_fragments integer На основе продолжительности успешного просмотра фрагмента от открытия до закрытия, прослеженного против узлов данных, выполняющих их scan_fragment_errors integer На основе продолжительности неудавшегося просмотра фрагмента от открытия до закрытия, прослеженного против узлов данных, выполняющих их transactions integer На основе продолжительности успешных транзакций с начала до отправки ACK, прослеженный против API или узлов данных. Не имеющие статуса транзакции не включены. transaction_errors integer На основе продолжительности провала транзакций от начала до пункта неудачи, прослеженной против API или узлов данных read_key_ops integer На основе продолжительности успешного чтения первичного ключа с блокировкими. Прослеженный против API или узла данных и против узла данных, выполняющего их write_key_ops integer На основе продолжительности успешной записи первичного ключа, прослеженный против API или узла данных и против узла данных, выполняющего их index_key_ops integer На основе продолжительности успешных операций по ключу уникального индекса, прослеженных против API или узла данных и против выполнения узла данных, читающего базовые таблицы key_op_errors integer На основе продолжительности всех неудачных чтений или записей ключа, прослеженные против API или узла данных и против узла данных, выполняющего их block_instance обеспечивает ядерный номер экземпляра блока DBTC. Можно использовать это вместе с именем блока, чтобы получить информацию об определенных потоках от таблицы threadblocks. Таблица tc_time_track_stats добавлена в NDB 4.7.9 (Bug #78533, Bug #21889652). 7.10.41. Таблица ndbinfo threadblocks Таблица threadblocks связывает узлы данных, потоки и экземпляры ядерных блоков NDB. Таблица 7.56. Столбцы threadblocks Имя Тип Описание node_id integer ID узла thr_no integer ID потока block_name string Имя блока block_instance integer Номер экземпляра блока Значение block_name это одно из значений, найденных в столбце block_name, выбирая из таблицы ndbinfo.blocks. Хотя список возможных значений статичен для данного выпуска кластера NDB, список может измениться между выпусками. block_instance обеспечивает ядерный номер экземпляра блока. 7.10.42. Таблица ndbinfo threads Таблица threads предоставляет информацию о потоках в ядре NDB kernel. Таблица 7.57. Столбцы threads Имя Тип Описание node_id integer ID узла thr_no integer ID потока (в пределах узла) thread_name string Имя (тип) потока thread_description string Описание потока (типа) Типовой вывод от кластера в качестве примера с 2 узлами, включая описания потоков, показывают здесь: mysql> SELECT * FROM threads; +---------+--------+-------------+------------------------------------------------------------------+ | node_id | thr_no | thread_name | thread_description | +---------+--------+-------------+------------------------------------------------------------------+ | 5 | 0 | main | main thread, schema and distribution handling | | 5 | 1 | rep | rep thread, asynch replication and proxy block handling | | 5 | 2 | ldm | ldm thread, handling a set of data partitions | | 5 | 3 | recv | receive thread, performing receive and polling for new receives | | 6 | 0 | main | main thread, schema and distribution handling | | 6 | 1 | rep | rep thread, asynch replication and proxy block handling | | 6 | 2 | ldm | ldm thread, handling a set of data partitions | | 6 | 3 | recv | receive thread, performing receive and polling for new receives | +---------+--------+-------------+------------------------------------------------------------------+ 8 rows in set (0.01 sec) Таблица добавлена в NDB 7.5.2. 7.10.43. Таблица ndbinfo threadstat Таблица threadstat обеспечивает грубый снимок статистики для потоков в ядре NDB. Таблица 7.58. Столбцы threadstat Имя Тип Описание node_id integer ID узла thr_no integer ID потока thr_nm string Имя потока c_loop string Количество циклов в основном цикле c_exec string Количество сигналов выполняется c_wait string Число раз ожидания дополнительного входа c_l_sent_prioa integer Количество приоритета сигналов A, посланных в собственный узел c_l_sent_priob integer Количество приоритета сигналов B, посланных в собственный узел c_r_sent_prioa integer Количество приоритета сигналов A, посланных в удаленный узел c_r_sent_priob integer Количество приоритета сигналов B, посланных в удаленный узел os_tid integer OS ID потока os_now integer Время OS (ms) os_ru_utime integer Пользовательское время OS CPU (s) os_ru_stime integer Ссистемное время OS CPU (s) os_ru_minflt integer Страниц OS исправлено (мягкие отсутствия страницы) os_ru_majflt integer Отсутствия страницы OS (жесткие отсутствия страницы) os_ru_nvcsw integer Добровольные контекстные переключения OS os_ru_nivcsw integer Ненамеренные контекстные переключения OS os_time использует системный вызов gettimeofday(). Значения столбцов os_ru_utime, os_ru_stime, os_ru_minflt, os_ru_majflt, os_ru_nvcsw и os_ru_nivcsw получены через системный вызов getrusage() или его аналог. Так как эта таблица содержит количество, взятое в определенный момент времени, для лучших результатов необходимо запросить ее периодически и сохранить результаты в промежуточной таблице. Планировщик событий MySQL Server может использоваться, чтобы автоматизировать такой контроль. Для получения дополнительной информации посмотрите Using the Event Scheduler. 7.10.44. Таблица ndbinfo transporters Эта таблица содержит информацию о транспортерах NDB. Таблица 7.59. Столбцы transporters Имя Тип Описание node_id integer ID узла remote_node_id integer ID удаленного узла status string Статус связи remote_address string Имя или IP-адрес удаленного хоста bytes_sent integer Число байтов, посланных, используя эту связь bytes_received integer Число байтов, полученных, используя эту связь connect_count integer Сколько раз связь устанавливается на этом транспортере overloaded boolean (0 или 1) 1, если этот транспортер в настоящее время перегружается, иначе 0 overload_count integer Сколько раз этот транспортер вошел в состояние перегрузки, начиная с соединения slowdown boolean (0 или 1) 1, если этот транспортер находится в состоянии замедления, иначе 0 slowdown_count integer Сколько раз этот транспортер вошел в состояние замедления, начиная с соединения Для каждого работающего узла данных в кластере таблица transporters показывает строку, показывая статус каждой из связей этого узла со всеми узлами в кластере, включая себя. Эту информацию показывают в столбце состояния таблицы, у которого может быть любое из следующих значений: CONNECTING, CONNECTED, DISCONNECTING или DISCONNECTED. Связи с API и узлами управления, которые формируются, но в настоящее время не связываются с кластером, показывают со статусом DISCONNECTED. Строки, где node_id из узла данных, который в настоящее время не связывается, не показаны в этой таблице. Это подобно упущению разъединенных узлов в таблице ndbinfo.nodes. remote_address это имя хоста или адрес для узла, ID которого показывают в remote_node_id. bytes_sent от этого узла и bytes_received этим узлом, это числа байтов, соответственно, посланных и полученных узлом, используя эту связь, так как это было установлено. Для узлов, статус которых CONNECTING или DISCONNECTED, эти столбцы всегда показывают 0. Предположите, что у вас есть кластер с 5 узлами, состоящий из 2 узлов данных, 2 узлов SQL и 1 узла управления, как показано в выводе SHOW в ndb_mgm: ndb_mgm> SHOW Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1@10.100.10.1(5.7.29-ndb-7.5.17, Nodegroup: 0, *) id=2@10.100.10.2(5.7.29-ndb-7.5.17, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=10 @10.100.10.10(5.7.29-ndb-7.5.17) [mysqld(API)] 2 node(s) id=20 @10.100.10.20(5.7.29-ndb-7.5.17) id=21 @10.100.10.21(5.7.29-ndb-7.5.17) Есть 10 строк в таблице transporters, по 5 для первого узла данных и 5 для второго, считая, что все узлы данных работают: mysql> SELECT node_id, remote_node_id, status FROM ndbinfo.transporters; +---------+----------------+---------------+ | node_id | remote_node_id | status | +---------+----------------+---------------+ | 1 | 1 | DISCONNECTED | | 1 | 2 | CONNECTED | | 1 | 10 | CONNECTED | | 1 | 20 | CONNECTED | | 1 | 21 | CONNECTED | | 2 | 1 | CONNECTED | | 2 | 2 | DISCONNECTED | | 2 | 10 | CONNECTED | | 2 | 20 | CONNECTED | | 2 | 21 | CONNECTED | +---------+----------------+---------------+ 10 rows in set (0.04 sec) Если вы закрываете один из узлов данных в этом кластере, используя команду 2 STOP в ndb_mgm, затем повторите предыдущий запрос (снова используя mysql), эта таблица теперь показывает только 5 строк, одну строку для каждой связи от остающегося узла управления до другого узла, включая его и узел данных, который является в настоящее время офлайновым, и показывает CONNECTING для статуса каждой остающейся связи с узлом данных, который является в настоящее время офлайновым, как показано здесь: mysql> SELECT node_id, remote_node_id, status FROM ndbinfo.transporters; +---------+----------------+---------------+ | node_id | remote_node_id | status | +---------+----------------+---------------+ | 1 | 1 | DISCONNECTED | | 1 | 2 | CONNECTING | | 1 | 10 | CONNECTED | | 1 | 20 | CONNECTED | | 1 | 21 | CONNECTED | +---------+----------------+---------------+ 5 rows in set (0.02 sec) Счетчики connect_count, overloaded, overload_count, slowdown и slowdown_count перезагружаются при связи и сохраняют свои значения после того, как удаленный узел разъединится. Счетчики bytes_sent и bytes_received также перезагружаются на связи, тем самым сохраняя их значения после разъединения (пока следующая связь не перезагружает их). Состояние перегрузки, упомянутое в столбцах overloaded и overload_count, происходит, когда буфер передачи этого транспортера содержит больше, чем OVerloadLimit байт (умолчание составляет 80% от SendBufferMemory, то есть 0.8*2097152 = 1677720 байт). Когда данный транспортер в состоянии перегрузки, любая новая транзакция, которая пытается использовать этот транспортер, отваливается с Error 1218 (Send Buffers overloaded in NDB kernel). Это затрагивает просмотры и операции по первичному ключу. Состояние замедления, на которое ссылаются столбцы slowdown и slowdown_count, происходит, когда буфер передачи транспортера содержит больше, чем 60% от предела перегрузки (то есть 0.6*2097152 = 1258290 байт по умолчанию). В этом статусе любому новому просмотру, использующему этот транспортер, уменьшают его пакетный размер, чтобы минимизировать нагрузку на транспортер. Частые причины замедления или перегрузки включают следующее: Размер данных, в особенности количество данных, в столбцах TEXT или BLOB. Наличие узла данных (ndbd или ndbmtd) на том же самом хосте, где узел SQL, который занят двоичным журналом. Большое количество строк за транзакцию или операционный пакет. Проблемы конфигурации, например, недостаточно SendBufferMemory. Аппаратные проблемы, такие как недостаточно RAM или слабое сетевое соединение. См. также раздел 5.3.13. 7.11. Таблицы INFORMATION_SCHEMA в NDB Cluster Две табицы INFORMATION_SCHEMA предоставляют информацию, которая имеет конкретное применение, управляя кластером NDB. Таблица FILES предоставляет информацию о файлах данных кластерного диска NDB. ndb_transid_mysql_connection_map обеспечивает отображение между транзакциями, операционными координаторами и узлами API. Дополнительные статистические и другие данные о транзакциях кластера NDB, операциях, потоках, блоках и других аспектах работы могут быть получены из таблиц в БД ndbinfo. См. раздел 7.10. 7.12. Проблемы безопасности в NDB Cluster Эта секция обсуждает соображения безопасности, чтобы принять во внимание, настраивая и управляя кластером NDB. Темы, затронутые в этой секции, включают следующее: NDB Cluster и проблемы сетевой безопасности Проблемы конфигурации, касающиеся управления кластером NDB NDB Cluster система привилегии MySQL Процедуры стандартной защиты MySQL, применимые к кластеру NDB 7.12.1. Безопасность кластера NDB и сетевые проблемы В этой секции мы обсуждаем основные запросы сетевой безопасности, поскольку они касаются кластера NDB. Чрезвычайно важно помнить, что кластер NDB из коробки далек от безопасности, вы или ваш сетевой администратор должны сделать надлежащие шаги, чтобы гарантировать, что ваш кластер не может подставиться под угрозу по сети. Протоколы связи кластера неотъемлемо небезопасны, и никакое шифрование или подобные меры безопасности не используются в связях между узлами. Поскольку сетевая скорость и время ожидания оказывает прямое влияние на эффективность кластера, также нежелательно использовать SSL или другое шифрование сетевых соединений между узлами, эти схемы как таковые эффективно замедлят коммуникации. Также верно, что никакая идентификация не используется для управления доступом узла API к кластеру NDB. Как с шифрованием, издержки требований идентификации оказали бы неблагоприятное влияние на работу кластера. Кроме того, нет никакой проверки исходного IP-адреса ни для одного из следующего, получая доступ к кластеру: Узлы SQL или API используют свободные слоты , созданные пустыми разделами [mysqld] или [api] в файле config.ini. Это означает, что если есть пустой раздел [mysqld] или [api] в config.ini, тогда любые узлы API (включая узлы SQL), которые знают имя хоста сервера управления (или IP-адрес) и порт, могут соединиться с кластером и получить доступ к своим данным без ограничения. (См. раздел 7.12.2. Можно осуществить некоторый контроль над SQL и доступом узла API к кластеру, определив HostName для всех [mysqld] и [api] в config.ini. Однако, это также означает, что если вы хотите соединить узел API с кластером от ранее неиспользованного хоста, необходимо добавить раздел [api], содержащий его имя хоста в config.ini. См. здесь о HostName. Также см. раздел 5.1. Любой клиент ndb_mgm. Это означает, что какой-либо клиент управления кластером, которому дают имя хоста сервера управления (или IP-адрес) и порт (если это не стандартный порт) может соединиться с кластером и выполнить какую-либо команду клиента управления. Это включает такие команды, как commands such as ALL STOP и SHUTDOWN. По этим причинам необходимо защитить кластер на сетевом уровне. Самая безопасная конфигурация сети для кластера это та, которая изолирует связи между узлами кластера от любых других сетевых коммуникаций. Это может быть достигнуто любым из следующих методов: Хранение узлов кластера в сети, которая является физически отдельной от любых общедоступных сетей. Этот выбор является самым надежным, однако, является и самым дорогим. Мы показываем пример установки кластера NDB, используя такую физически отдельную сеть здесь: Рис. 7.2. NDB Cluster с аппаратным Firewall У этой установки есть две сети, одна частная для серверов управления кластера и узлов данных и одна общая, где узлы SQL проживают. Мы показываем, что узлы данных и управления соединили с использованием гигабитного коммутатора, так как это обеспечивает лучшую работу. Обе сети защищены от внешней стороны аппаратным брандмауэром, иногда также известным как network-based firewall. Эта сетевая установка является самой безопасной, потому что никакие пакеты не могут достигнуть управления кластера или узлов данных снаружи сети, и ни один из внутренних контактов кластера не может достигнуть внешней стороны, не проходя узлы SQL, пока узлы SQL не разрешают никаким пакетам быть отправленными. Это означает, конечно, что все узлы SQL должны быть защищены против попыток взлома. Относительно потенциальных уязвимостей системы обеспечения безопасности узел SQL не отличается от любого другого сервера MySQL. Посмотрите Making MySQL Secure Against Attackers. Используя один или несколько программных брандмауэров (также известные как основанные на хосте брандмауэры), чтобы управлять, как пакеты проходят к кластеру от частей сети, которые не требуют доступа к нему. В этом типе установки программный брандмауэр должен быть установлен на каждом хосте в кластере, который мог бы иначе быть доступным снаружи местной сети. Основанный на хосте выбор является наименее дорогим, но полагается просто на программное обеспечение, чтобы обеспечить защиту, а также является самым трудным в поддержании. Этот тип сетевой установки для кластера NDB иллюстрирован здесь: Рис. 7.3. NDB Cluster с программными брандмауэрами Используя этот тип сетевых средств установки, есть две зоны хостов кластера NDB. Каждый хост кластера должен быть в состоянии общаться со всеми другими машинами в кластере, но только тем, которые используют узлы SQL, можно разрешить иметь любой контакт с внешней стороной, в то время, как машины в зоне, содержащей узлы данных и узлы управления, должны быть изолированы от любых машин, которые не являются частью кластера. Приложениям, использующим группу и пользователя оттуда, нельзя разрешить иметь прямой доступ к управлению и хостам узла данных. Чтобы достигнуть этого, необходимо настроить программные брандмауэры, которые ограничивают трафик типом или типами, показанными в следующей таблице, согласно типу узла, который работает на каждом хосте кластера: Таблица 7.60. Типы узлов в основанной на хосте кластерной конфигурации брандмауэра Тип узла Разрешенный трафик Узел SQL или API Это происходит из IP-адреса управления или узла данных (используя любой TCP или порт UDP). Это происходит из сети, в которой кластер проживает и находится на порте, который использует ваше приложение. Узел данных или управления Это происходит из IP-адреса управления или узла данных (используя любой TCP или порт UDP). Это происходит из IP-адреса узла API или SQL. Любой трафик кроме показанного в таблице для данного типа узла должен отрицаться. Специфические особенности формирования брандмауэра варьируются от применения брандмауэра и выходят за рамки этого руководства. iptables это очень общее и надежное приложение брандмауэра, которое часто используется с APF в качестве фронтэнда, чтобы сделать конфигурацию легче. Вы можете ознакомиться с документацией для программного брандмауэра, который вы используете, чтобы понять, должны ли вы принимать решение осуществить установку сети NDB Cluster этого или смешанного типа. Также возможно использовать комбинацию первых двух методов, используя оба аппаратных и программных обеспечения, чтобы обеспечить безопасность. Это между первыми двумя схемами и с точки зрения уровня безопасности и с точки зрения стоимости. Этот тип сетевой установки держит кластер позади аппаратного брандмауэра, но разрешает поступающим пакетам перемещаться вне маршрутизатора, соединяющего все хосты кластера, чтобы достигнуть узлов SQL. Одно возможное развертывание сети кластера NDB, используя аппаратные и программные брандмауэры в комбинации показывают здесь: Рис. 7.4. NDB Cluster с комбинацией аппаратных и программных брандмауэров В этом случае можно установить правила в аппаратном брандмауэре, чтобы отрицать любой внешниий трафик кроме как к узлам SQL и API, а затем разрешить трафик только на портах, требуемых приложениями. Безотносительно конфигурации сети, которую вы используете, помните, что ваша цель с точки зрения безопасности кластера остается той же самой: препятствовать тому, чтобы любой посторонний трафик достиг кластера, гарантируя самую эффективную связь между узлами в кластере. Поскольку кластер NDB требует большие количества открытых портов для связей между узлами, рекомендуемый выбор состоит в том, чтобы использовать отдельную сеть. Это представляет самый простой способ препятствовать тому, чтобы нежелательный трафик достиг кластера. Если вы хотите управлять кластером NDB удаленно (то есть, снаружи местной сети), рекомендуемый способ сделать это: использовать ssh или другую безопасную оболочку, чтобы получить доступ к хосту узла SQL. От этого хоста можно тогда управлять клиентом управления, чтобы получить доступ к серверу управления безопасно из собственной местной сети кластера. Даже при том, что возможно сделать так в теории, не рекомендуется использовать ndb_mgm, чтобы управлять кластером непосредственно снаружи местной сети, в которой работает кластер. Ни идентификация, ни шифрование не происходят между клиентом управления и сервером, это представляет чрезвычайно опасное средство управления кластером и почти наверняка поставится под угрозу рано или поздно. 7.12.2. NDB Cluster и привилегии MySQL В этой секции мы обсуждаем, как система привилегии MySQL работает относительно кластера NDB и последствия этого для безопасности NDB Cluster. Стандартные привилегии MySQL относятся к таблицам кластера NDB. Это включает все типы привилегии MySQL (SELECT, UPDATE, DELETE и т.д.), предоставленных на уровне базы данных, таблицы и столбца. Как с любым другим MySQL Server, пользователи и информация о привилегии сохранены в системной база данных mysql. SQL-операторы, которые раньше предоставляли и отменяли привилегии на таблицах NDB, базах данных, содержащие такие таблицы, и столбцах в таких таблицах, идентичны во всех отношениях с GRANT и REVOKE, используемыми в связи с объектами базы данных, включающими любой (другой) механизм хранения MySQL. То же самое верно относительно CREATE USER и DROP USER. Важно иметь в виду, что по умолчанию таблицы привилегий MySQL используют механизм MyISAM. Из-за этого те таблицы обычно не дублируются или разделяются среди серверов MySQL, действующих как узлы SQL в кластере NDB. Другими словами, изменения в пользователях и их привилегиях автоматически не размножаются между узлами SQL по умолчанию. При необходимости можно позволить автоматическое распределение пользователей MySQL и привилегий через узлы SQL в NDB Cluster, см. раздел 7.16. С другой стороны, потому что нет никакого пути в MySQL, чтобы отрицать привилегии (привилегии могут или отменяться или не предоставляться, но не отрицаться как таковые), нет никакой специальной защиты для таблиц NDB на одном узле SQL от пользователей, у которых есть привилегии на другом узле SQL. Это верно, даже если вы не используете автоматическое распределение полномочий пользователя. Пример этого: пользователь MySQL root, который может выполнить любое действие на любом объекте базы данных. В сочетании с пустыми разделами [mysqld] или [api] файла config.ini это может быть особенно опасным. Чтобы понять почему, рассмотрите следующий сценарий: Файл config.ini содержит по крайней мере один пустой раздел [mysqld] или [api]. Это означает, что сервер управления кластера NDB не выполняет проверки хоста, от которого MySQL Server (или другой узел API) получает доступ к кластеру NDB. Нет никакого брандмауэра, или брандмауэр не защищает от доступа к кластеру NDB от хостов, внешних к его сети. Имя хоста или IP-адрес сервера управления кластера NDB известны или могут быть определены снаружи сети. Если эти условия верны, то любой, где угодно может начать MySQL Server с опциями --ndbcluster --ndb-connectstring= management_host и получить доступ к этому кластеру NDB. Используя MySQL root этот человек может тогда выполнить следующие действия: Выполнить запрос метаданных, такой как SHOW DATABASES, чтобы получить список всех БД NDB на сервере или SHOW TABLES FROM some_ndb_database, чтобы получить список всех таблиц NDB в любой БД. Управлять любыми запросами MySQL о любой из обнаруженных таблиц, таких как: SELECT * FROM some_table, чтобы прочитать все данные из любой таблицы. DELETE FROM some_table, чтобы удалить все данные из таблицы. DESCRIBE some_table или SHOW CREATE TABLE some_table, чтобы определить схему таблицы. UPDATE some_table SET column1 = some_value, чтобы заполнить столбец таблицы любыми данными, это может на самом деле нанести намного больший ущерб, чем простое удаление всех данных. Больше коварных изменений могло бы включать такие запросы: UPDATE some_table SET an_int_column = an_int_column + 1 или: UPDATE some_table SET a_varchar_column = REVERSE(a_varchar_column) Такие злонамеренные запросы ограничиваются только воображением нападающего. Единственные таблицы, которые были бы безопасны от этого вида погрома, будут теми таблицами, которые были составлены, используя механизмы хранения кроме NDB и невидимы вражескому узлу SQL. Пользователь, который может авторизоваться как root , может также получить доступ к БД INFORMATION_SCHEMA и ее таблицам и тем самым получить информацию о базах данных, таблицах, хранимых процедурах, намеченных событиях и любым другим объектам базы данных, для которых метаданные сохранены в INFORMATION_SCHEMA. Также очень хорошая идея использовать различные пароли для root на различных узлах SQL кластера NDB, если вы не используете распределенные привилегии. В сумме у вас не может быть безопасного NDB Cluster, если он непосредственно доступен снаружи вашей местной сети. Никогда не оставляйте пароль MySQL root пустым. Это столь же верно, управляя MySQL как узлом SQL NDB Cluster, как, управляя им как автономным (некластер) MySQL Server и должно быть сделано как часть процесса установки MySQL прежде, чем формировать MySQL Server как узел SQL в NDB Cluster. Если вы хотите использовать распределенные возможности привилегии кластера NDB, вы не должны просто преобразовывать системные таблицы в базе данных mysql, чтобы использовать NDB вручную. Используйте хранимую процедуру, предоставленную с этой целью, см. раздел 7.16. Иначе, если необходимо синхронизировать системные таблицы mysql между узлами SQL, можно использовать стандартную репликацию MySQL, чтобы сделать это, или использовать скрипт, чтобы скопировать записи таблицы между серверами MySQL. Итог. Наиболее важные моменты относительно системы привилегии MySQL в кластере NDB перечисляются здесь: Пользователи и привилегии, установленные на одном узле SQL, автоматически не существуют на других узлах SQL в кластере. С другой стороны удаление пользователя или привилегии на одном узле SQL в кластере не удаляет пользователя или привилегию ни от каких других узлов SQL. Можно распределить пользователей MySQL и привилегии среди узлов SQL, используя скрипт и хранимые процедуры, которые поставляются с этой целью в распределении кластера NDB. Как только пользователю MySQL предоставляют привилегии на таблице NDB от одного узла SQL в NDB Cluster, тот пользователь видит любые данные в этой таблице независимо от узла SQL, от которого порождены данные, даже если вы не используете распределение привилегии. 7.12.3. NDB Cluster и процедуры защиты MySQL В этой секции мы обсуждаем процедуры стандартной защиты MySQL, поскольку они относятся к управлению кластером NDB. В целом любая стандартная процедура для управления MySQL надежно также относится к управлению MySQL Server как части NDB Cluster. Прежде всего необходимо всегда управлять MySQL Server как ОС-пользователь mysql, это не отличается от управления MySQL в стандартной (некластер) окружающей среде. Системный пользователь mysql должен быть исключительно и ясно определен. К счастью, это поведение по умолчанию для новой установки MySQL. Можно проверить, что процесс mysqld работает как ОС-пользователь mysql при помощи системной команды: shell> ps aux | grep mysql root 104670.00.1 36161380 pts/3S11:53 0:00 \ /bin/sh ./mysqld_safe --ndbcluster --ndb-connectstring=localhost:1186 mysql 105120.22.558528 26636 pts/3Sl 11:53 0:00 \ /usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql \ --datadir=/usr/local/mysql/var --user=mysql --ndbcluster \ --ndb-connectstring=localhost:1186 --pid-file=/usr/local/mysql/var/mothra.pid \ --log-error=/usr/local/mysql/var/mothra.err jon 105790.00.0 2736 688 pts/0S+ 11:54 0:00 grep mysql Если процесс mysqld работает как какой-либо другой пользователь, чем mysql, необходимо немедленно закрыть его и перезапустить как mysql. Если этот пользователь не существует в системе, учетная запись пользователя mysql должна быть создана, и этот пользователь должен быть частью группы mysql, в этом случае необходимо также удостовериться что каталог данных MySQL на этой системе (как установлено использованием опции --datadir для mysqld) принадлежит пользователю mysql, и что файл my.cnf узла SQL включает user=mysql в разделе [mysqld]. Альтернативно, можно начать серверный процесс MySQL с опцией --user=mysql, но предпочтительно использовать опцию в my.cnf, так как вы могли бы забыть использовать параметр командной строки и тем самым получить mysqld, работающий как другой пользователь, неумышленно. Скрипт mysqld_safe вынуждает MySQL работать как пользователь mysql. Никогда не управляйте mysqld как системный пользователь root. Выполнение этого означает, что потенциально любой файл на системе может быть прочитан MySQL. Как упомянуто в предыдущей секции (см. раздел 7.12.2), необходимо всегда устанавливать пароль root для MySQL Server, как только он у вас есть. Необходимо также удалить учетную запись анонимного пользователя, которая устанавливается по умолчанию. Можно выполнить эти задачи, используя следующие запросы: shell> mysql -u root mysql> UPDATE mysql.user SET Password=PASSWORD('secure_password') WHERE User='root'; mysql> DELETE FROM mysql.user WHERE User=''; mysql> FLUSH PRIVILEGES; Будьте очень осторожны, выполняя DELETE, чтобы не опустить WHERE, или вы рискуете удалить всех пользователей MySQL. Хотя... Может быть стоит один раз попробовать именно это. Просто чтобы навсегда запомнить. Обязательно выполните FLUSH PRIVILEGES как только вы изменили таблицу mysql.user, чтобы изменения вступили в силу немедленно. Без FLUSH PRIVILEGES изменения не вступают в силу до следующего раза, когда сервер будет перезапущен. Многие утилиты NDB Cluster, например, ndb_show_tables, ndb_desc и ndb_select_all также работают без идентификации и могут показать имена таблиц, схемы и данные. По умолчанию они устанавливаются на системах стиля Unix с разрешениями rwxr-xr-x (755), что означает, что они могут быть выполнены любым пользователем, который может получить доступ к каталогу mysql/bin. См. главу 6. 7.13. Таблицы данных диска NDB Cluster Возможно сохранить неиндексируемые столбцы таблиц NDB на диске, а не в RAM. Как часть осуществления работы NDB Cluster Disk Data, много улучшений были сделаны в кластере NDB для эффективной обработки очень больших объемов (терабайты) данных во время восстановления узла и перезапуска. Они включают алгоритм no-steal для синхронизации стартового узла с очень большими наборами данных. Для получения дополнительной информации посмотрите Recovery Principles of NDB Cluster 5.1, by NDB Cluster developers Mikael Ronstr and Jonas Oreland. NDB Cluster Disk Data может быть под влиянием многих параметров конфигурации. Для получения информации об этих параметрах и их эффектах см. NDB Cluster Disk Data configuration parameters и NDB Cluster Disk Data storage and GCP Stop errors. Исполнение кластера NDB, который применяет Disk Data, может также быть значительно улучшено, отделив файловые системы узла данных от файлов журнала отмен и файлов данных табличного пространства, что может быть сделано, используя символьные ссылки. Для получения дополнительной информации посмотрите раздел 7.13.2. 7.13.1. Объекты NDB Cluster Disk Data NDB Cluster Disk Data осуществляется, используя много объектов Disk Data. Они включают следующее: Табличные пространства действуют как контейнеры для других дисковых объектов данных. Файлы журнала отмен хранят информацию, запрошенную для того, чтобы откатить транзакции до прежнего уровня. Один или больше файлов журнала отмен назначены на группу файла журнала, которая тогда назначена на табличное пространство. Файлы данных хранят дисковые данные о таблице данных. Файл данных назначен непосредственно на табличное пространство. Файлы журнала и файлы данных это фактические файлы в файловой системе каждого узла данных, по умолчанию они размещаются в ndb_node_id _fs в DataDir, указанном в NDB Cluster config.ini, где node_id это ID узла данных. Возможно поместить их в другое место, определяя абсолютный или относительный путь как часть имени файла, создавая файл журнала или файл данных. Запросы, которые создают эти файлы, показывают позже в этой секции. Табличные пространства кластера NDB и группы файла журнала не осуществляются как файлы. Хотя не все дисковые объекты данных осуществляются как файлы, они все разделяют то же самое пространство имен. Это означает, что каждый дисковый объект данных нужно уникально назвать (и не просто каждый дисковый объект данных данного типа). Например, у вас не может быть табличного пространства и группы файла журнала с одним и тем же именем dd1. Предположим, что вы уже настроили NDB Cluster со всеми узлами (включая управление и узлы SQL), тогда основные шаги для того, чтобы составить таблицу кластера NDB на диске, следующие: Создайте группу файла журнала и назначьте один или больше файлов журнала к ней (файл журнала отмен также иногда упоминается как undofile). Файлы журнала отмен необходимы только для дисковых таблиц данных, они не используются для таблиц NDBCLUSTER, которые сохранены только в памяти. Создайте табличное пространство, назначьте группу файла журнала, а также один или несколько файлов данных к табличному пространству. Создайте дисковую таблицу данных, которая использует это табличное пространство для хранения данных. Каждая из этих задач может быть выполнена, используя SQL-операторы в клиенте mysql. Мы создаем группу lg_1 файла журнала через CREATE LOGFILE GROUP. Эта группа файла журнала должна быть составлена из двух файлов журнала, которые мы называем undo_1.log и undo_2.log, чьи начальные размеры составляют 16 МБ и 12 МБ, соответственно. Размер по умолчанию для файла журнала отмен составляет 128 МБ. Произвольно можно также определить размер для буфера группы файла журнала отмен или разрешить ему принимать значение по умолчанию 8 МБ. В этом примере мы устанавливаем размер буфера UNDO на уровне 2 МБ. Группа файла журнала должна быть создана с файлом журнала отмен, таким образом, мы добавляем undo_1.log в lg_1 в CREATE LOGFILE GROUP: CREATE LOGFILE GROUP lg_1 ADD UNDOFILE 'undo_1.log' INITIAL_SIZE 16M UNDO_BUFFER_SIZE 2M ENGINE NDBCLUSTER; Чтобы добавить undo_2.log к группе файла журнала используйте следующий ALTER LOGFILE GROUP: ALTER LOGFILE GROUP lg_1 ADD UNDOFILE 'undo_2.log' INITIAL_SIZE 12M ENGINE NDBCLUSTER; Некоторые важные моменты: Расширение файла .log, используемое здесь, не требуется. Мы используем его просто, чтобы сделать файлы журнала легко распознаваемыми. Каждый CREATE LOGFILE GROUP и ALTER LOGFILE GROUP должен включать опцию ENGINE. Единственные разрешенные значения для этой опции это NDBCLUSTER и NDB. Там может существовать самое большее одна группа файла журнала в том же самом кластере NDB в любой момент времени. Когда вы добавляете файл журнала отмен к группе файла журнала использованием ADD UNDOFILE 'filename', файл с именем filename создается в подкаталоге ndb_node_id _fs каталога DataDir каждого узла данных в кластере, где node_id это ID узла данных. Каждый файл журнала отмен имеет размер, определенный в SQL-операторе. Например, если у кластера NDB есть 4 узла данных, то ALTER LOGFILE GROUP создает 4 файла журнала, каждый в каталоге данных каждого из 4 узлов данных, каждый из этих файлов называют undo_2.log и он имеет размер 12 МБ. UNDO_BUFFER_SIZE ограничивается суммой доступной системной памяти. Для получения дополнительной информации о CREATE LOGFILE GROUP см. CREATE LOGFILE GROUP Statement. Для получения дополнительной информации о ALTER LOGFILE GROUP см. ALTER LOGFILE GROUP Statement. Теперь мы можем создать табличное пространство, которое содержит файлы, которые будут использоваться таблицами данных кластерного диска NDB для того, чтобы хранить их данные. Табличное пространство также связано с конкретной группой файла журнала. Создавая новое табличное пространство, необходимо определить группу файла журнала, для которой оно должно использоваться, необходимо также определить файл данных. Можно добавить больше файлов данных к табличному пространству после того, как табличное пространство будет создано, также возможно исключить файлы данных из табличного пространства (пример удаления файлов данных обеспечивается позже в этой секции). Предположите, что мы хотим создать табличное пространство, названное ts_1, которое использует lg_1 как его группу файла журнала. Это табличное пространство должно содержать два файла данных data_1.dat и data_2.dat, чьи начальные размеры составляют 32 МБ и 48 МБ, соответственно. Значение по умолчанию для INITIAL_SIZE 128 MB. Мы можем сделать это с использованием двух SQL-операторов, как показано здесь: CREATE TABLESPACE ts_1 ADD DATAFILE 'data_1.dat' USE LOGFILE GROUP lg_1 INITIAL_SIZE 32M ENGINE NDBCLUSTER; ALTER TABLESPACE ts_1 ADD DATAFILE 'data_2.dat' INITIAL_SIZE 48M ENGINE NDBCLUSTER; CREATE TABLESPACE создает табличное пространство ts_1 с файлом данных data_1.dat и связывает ts_1 с группой файла журнала lg_1. ALTER TABLESPACE добавляет второй файл данных (data_2.dat). Некоторые важные моменты: Как имеет место с .log, расширение файла .dat, используемое в этом примере, не имеет никакого специального значения. Когда вы добавляете файл данных к использованию табличного пространства через ADD DATAFILE 'filename', файл с именем filename создается в подкаталоге ndb_node_id _fs каталога DataDir каждого узла данных в кластере, где node_id это ID узла данных. Каждый файл данных имеет размер, определенный в SQL-операторе. Например, если у кластера NDB есть 4 узла данных, то ALTER TABLESPACE создает 4 файла данных, каждый в каталоге данных каждого из 4 узлов данных, каждый из этих файлов называется data_2.dat и имеет размер 48 MB. Все CREATE TABLESPACE и ALTER TABLESPACE должны содержать опцию ENGINE, только таблицы, использующие тот же самый механизм хранения в качестве табличного пространства, могут быть составлены в табличном пространстве. Для табличных пространств кластера NDB единственные разрешенные значения для этого выбора NDBCLUSTER и NDB. Для получения дополнительной информации о CREATE TABLESPACE и ALTER TABLESPACE см. CREATE TABLESPACE Statement и ALTER TABLESPACE Statement. Теперь возможно составить таблицу, неиндексируемые столбцы которой сохранены на диске в табличном пространстве ts_1: CREATE TABLE dt_1 (member_id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, last_name VARCHAR(50) NOT NULL, first_name VARCHAR(50) NOT NULL, dob DATE NOT NULL, joined DATE NOT NULL, INDEX(last_name, first_name)) TABLESPACE ts_1 STORAGE DISK ENGINE NDBCLUSTER; Опция TABLESPACE ... STORAGE DISK говорит NDBCLUSTER использовать табличное пространство ts_1 для дискового хранения данных. Когда таблица ts_1 создана как показано, можно скомандовать INSERT, SELECT, UPDATE и DELETE, как с любой другой таблицей MySQL. Также возможно определить, сохранен ли отдельный столбец на диске или в памяти при помощи опции STORAGE как части определения столбца в CREATE TABLE или ALTER TABLE. STORAGE DISK заставляет колонку быть сохраненной на диске, а STORAGE MEMORY предписывает использовать память. См. CREATE TABLE Statement. Индексация колонок неявно сохранена на диске. Для таблицы dt_1, как определено в примере, только столбцы dob и joined сохранены на диске. Это вызвано тем, что есть индексы на столбцах id, last_name и first_name и таким образом, данные, принадлежащие этим колонкам, хранятся в RAM. Только неиндексируемые столбцы могут быть проведены на диск, индексы и данные об индексированном столбце продолжают храниться в памяти. Этот компромисс между использованием индексов и сохранением RAM необходимо иметь в виду, когда вы проектируете дисковые таблицы данных. Вы не можете добавить индекс к колонке, которая была явно объявлена STORAGE DISK, без изменения типа хранения к MEMORY, любая попытка сделать так терпит неудачу с ошибкой. Колонка, которая неявно использует память на диске, может быть внесена в индекс, когда это сделано, тип хранения столбца изменяется на MEMORY автоматически. Неявно мы имеем в виду колонку, тип хранения которой не объявлен, но которая унаследовала родительской таблице. В следующем CREATE TABLE (используя ранее определенное табличное пространство ts_1) столбцы c2 и c3 используют память на диске неявно: mysql> CREATE TABLE ti (c1 INT PRIMARY KEY, c2 INT, c3 INT, c4 INT) STORAGE DISK TABLESPACE ts_1 ENGINE NDBCLUSTER; Query OK, 0 rows affected (1.31 sec) Так как c2, c3 и c4 самостоятельно не объявлены с STORAGE DISK, возможно внести их в индекс. Здесь мы добавляем индексы к c2 и c3, используя, соответственно, CREATE INDEX и ALTER TABLE: mysql> CREATE INDEX i1 ON ti(c2); Query OK, 0 rows affected (2.72 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> ALTER TABLE ti ADD INDEX i2(c3); Query OK, 0 rows affected (0.92 sec) Records: 0 Duplicates: 0 Warnings: 0 SHOW CREATE TABLE подтверждает, что индексы были добавлены. mysql> SHOW CREATE TABLE ti\G *************************** 1. row *************************** Table: ti Create Table: CREATE TABLE `ti` (`c1` int(11) NOT NULL, `c2` int(11) DEFAULT NULL, `c3` int(11) DEFAULT NULL, `c4` int(11) DEFAULT NULL, PRIMARY KEY (`c1`), KEY `i1` (`c2`), KEY `i2` (`c3`)) /*!50100 TABLESPACE `ts_1` STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.00 sec) Вы видите использование ndb_desc, который индексированные столбцы теперь используют в памяти, а не на диске: shell> ./ndb_desc -d test t1 -- t1 -- Version: 33554433 Fragment type: HashMapPartition K Value: 6 Min load factor: 78 Max load factor: 80 Temporary table: no Number of attributes: 4 Number of primary keys: 1 Length of frm data: 317 Max Rows: 0 Row Checksum: 1 Row GCI: 1 SingleUserMode: 0 ForceVarPart: 1 PartitionCount: 4 FragmentCount: 4 PartitionBalance: FOR_RP_BY_LDM ExtraRowGciBits: 0 ExtraRowAuthorBits: 0 TableStatus: Retrieved Table options: HashMap: DEFAULT-HASHMAP-3840-4 -- Attributes -- c1 Int PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY c2 Int NULL AT=FIXED ST=MEMORY c3 Int NULL AT=FIXED ST=MEMORY c4 Int NULL AT=FIXED ST=DISK -- Indexes -- PRIMARY KEY(c1) - UniqueHashIndex i2(c3) - OrderedIndex PRIMARY(c1) - OrderedIndex i1(c2) - OrderedIndex NDBT_ProgramExit: 0 - OK Замечания о производительности. Исполнение кластера, используя дисковое хранение данных значительно улучшено, если дисковые файлы данных сохранены на отдельном физическом диске от файловой системы узла данных. Это должно быть сделано для каждого узла данных в кластере, чтобы получить любую значимую выгоду. Можно использовать системные пути с ADD UNDOFILE и ADD DATAFILE. Относительные пути вычисляются относительно каталога данных узла данных. Можно также использовать символьные ссылки, см. раздел 7.13.2. Группа файла журнала, табличное пространство и любые дисковые таблицы данных, использующие их, должны быть созданы в особом порядке. То же самое верно для удаления любого из этих объектов: Группа файла журнала не может быть удалена, пока любые табличные пространства используют ее. Табличное пространство не может быть удалено, пока оно содержит любые файлы данных. Вы не можете исключить файлы данных из табличного пространства, пока там остаются любые таблицы, которые используют табличное пространство. Невозможно удалить файлы, созданные в связи с различным табличным пространством, чем то, с которым были созданы файлы (Bug #20053). Например, чтобы удалить все объекты, созданные до сих пор в этой секции, вы использовали бы следующие запросы: mysql> DROP TABLE dt_1; mysql> ALTER TABLESPACE ts_1 DROP DATAFILE 'data_2.dat' ENGINE NDBCLUSTER; mysql> ALTER TABLESPACE ts_1 DROP DATAFILE 'data_1.dat' ENGINE NDBCLUSTER; mysql> DROP TABLESPACE ts_1 ENGINE NDBCLUSTER; mysql> DROP LOGFILE GROUP lg_1 ENGINE NDBCLUSTER; Эти запросы должны быть выполнены в показанном порядке, за исключением того, что два ALTER TABLESPACE ... DROP DATAFILE могут быть выполнены в любом порядке. Можно получить информацию о файлах данных, используемых дисковыми таблицами данных, запросив таблицу FILES в БД INFORMATION_SCHEMA. Дополнительная строка NULL предоставляет дополнительную информацию о файлах журнала отмен. Для получения дополнительной информации и примеров посмотрите The INFORMATION_SCHEMA FILES Table. 7.13.2. Используя символьные ссылки с дисковыми объектами данных Исполнение кластера NDB, который использует дисковое хранение данных, может быть значительно улучшено, отделив файловые системы узла данных от файлов журнала отмен и файлов данных табличного пространства и поместив их на различные диски. В ранних версиях кластера NDB не было никакой прямой поддержки этого в кластеру NDB, но было возможно достигнуть этого разделения, используя символьные ссылки, как описано в этой секции. Кластер NDB поддерживает параметры конфигурации узла данных FileSystemPathDD, FileSystemPathDataFiles и FileSystemPathUndoFiles, которые делают использование символьных ссылок с этой целью ненужным. Для получения дополнительной информации об этих параметрах посмотрите здесь. Каждый узел данных в кластере создает файловую систему в подкаталоге ndb_node_id _fs каталога DataDir, как определено в файле config.ini. В этом примере мы предполагаем, что у каждого хоста узла данных есть 3 диска, /data0, /data1, /data2, а файл config.ini включает: [ndbd default] DataDir= /data0 Наша цель состоит в том, чтобы поместить все дисковые файлы журнала данных в /data1, а все дисковые файлы данных данных в /data2 на каждом хосте узла данных. В этом примере мы предполагаем, что хосты узла данных кластера все используют операционные системы Linux. Для других платформ вы, возможно, должны заменить команды операционной системы. Чтобы достигнуть этого, выполните следующие шаги: В файловой системе узла данных создайте символьные ссылки, указывающие на другие устройства: shell> cd /data0/ndb_2_fs shell> ls D1D10D11D2D8D9LCP shell> ln -s /data0 dnlogs shell> ln -s /data1 dndata У вас должно теперь быть две символьных ссылки: shell> ls -l --hide=D* lrwxrwxrwx 1 user group 30 2007-03-19 13:58 dndata -> /data1 lrwxrwxrwx 1 user group 30 2007-03-19 13:59 dnlogs -> /data2 Мы показываем это только для узла данных с ID 2, однако, необходимо сделать это для каждого узла данных. Теперь в клиенте mysql создайте группу файла журнала и табличное пространство, используя символьные ссылки, как показано здесь: mysql> CREATE LOGFILE GROUP lg1 ADD UNDOFILE 'dnlogs/undo1.log' INITIAL_SIZE 150M UNDO_BUFFER_SIZE = 1M ENGINE=NDBCLUSTER; mysql> CREATE TABLESPACE ts1 ADD DATAFILE 'dndata/data1.log' USE LOGFILE GROUP lg1 INITIAL_SIZE 1G ENGINE=NDBCLUSTER; Проверьте, что файлы были созданы и помещены корректно: shell> cd /data1 shell> ls -l total 2099304 -rw-rw-r--1 user group 157286400 2007-03-19 14:02 undo1.dat shell> cd /data2 shell> ls -l total 2099304 -rw-rw-r--1 user group 1073741824 2007-03-19 14:02 data1.dat Если вы управляете многими узлами данных на одном хосте, необходимо заботиться о том, чтобы они не пытались использовать то же самое пространство для дисковых файлов данных. Можно сделать это, создайте символьную ссылку в каждой файловой системе узла данных. Предположим, что вы используете /data0 для обеих файловых систем узла данных, но вы хотите иметь дисковые файлы данных для обоих узлов на /data1. В этом случае можно сделать что-то подобное тому, что показывают здесь: shell> cd /data0 shell> ln -s /data1/dn2 ndb_2_fs/dd shell> ln -s /data1/dn3 ndb_3_fs/dd shell> ls -l --hide=D* ndb_2_fs lrwxrwxrwx 1 user group 30 2007-03-19 14:22 dd -> /data1/dn2 shell> ls -l --hide=D* ndb_3_fs lrwxrwxrwx 1 user group 30 2007-03-19 14:22 dd -> /data1/dn3 Теперь можно создать группу файла журнала и табличное пространство, используя символьную ссылку: CREATE LOGFILE GROUP lg1 ADD UNDOFILE 'dd/undo1.log' INITIAL_SIZE 150M UNDO_BUFFER_SIZE = 1M ENGINE=NDBCLUSTER; CREATE TABLESPACE ts1 ADD DATAFILE 'dd/data1.log' USE LOGFILE GROUP lg1 INITIAL_SIZE 1G ENGINE=NDBCLUSTER; Проверьте, что файлы были созданы и размещены правильно: shell> cd /data1 shell> ls dn2 dn3 shell> ls dn2 undo1.log data1.log shell> ls dn3 undo1.log data1.log 7.13.3. Требования хранения данных кластерного диска NDB Следующие пункты относятся к дисковым требованиям хранения данных: Столбцы переменной длины дисковых таблиц данных поднимают установленную сумму места. Для каждой строки это равно пространству, требуемому, чтобы сохранить самое большое значение для этого столбца. Для получения общей информации о вычислении этих значений посмотрите Data Type Storage Requirements. Можно получить оценку суммы места, доступного в файлах данных и файлах журнала отмен, запросив таблицу INFORMATION_SCHEMA.FILES. См. The INFORMATION_SCHEMA FILES Table. OPTIMIZE TABLE не имеет никакого эффекта на дисковые таблицы данных. В дисковой таблице данных первые 256 байтов столбца TEXT или BLOB сохранены в памяти, только остаток сохранен на диске. Каждая строка в дисковой таблице данных использует 8 байтов в памяти, чтобы указать на данные на диске. Это означает, что в некоторых экземплярах преобразование колонки в памяти в находящийся на диске формат может на самом деле привести к большему использованию памяти. Например, преобразование CHAR(4) от основанного на памяти в находящийся на диске формат увеличивает сумму DataMemory на строку от 4 до 8 байтов. Старт кластера с опцией --initial не удаляет дисковые файлы данных. Необходимо удалить их вручную до выполнения начального перезапуска кластера. Исполнение дисковых таблиц данных может быть улучшено, минимизировав количество поиска на диске, проверьте, что DiskPageBufferMemory имеет достаточный размер. Можно запросить таблицу diskpagebuffer, чтобы помочь определить, должно ли значение для этого параметра быть увеличено. 7.14. Операции онлайн с ALTER TABLE в кластере NDB MySQL NDB Cluster 7.5 понимает изменения схемы таблицы онлайн, используя стандартный синтаксис ALTER TABLE MySQL Server (ALGORITHM=DEFAULT|INPLACE|COPY). Некоторые более старые выпуски кластера NDB использовали синтаксис, определенный для NDB, для онлайн ALTER TABLE. Тот синтаксис был с тех пор удален. Операции, которые добавляют и удаляют индексы на столбцы переменной ширины таблиц NDB, происходят онлайн. Операции онлайн не копируют, то есть, они не требуют пересоздания индекса. Они не блокируют изменяемую таблицу от доступа другими узлами API в кластере NDB (но посмотрите здесь). Такие операции не требуют однопользовательского режима для таблиц NDB в кластере NDB с многими узлами API, транзакции могут продолжиться непрерывно во время операций DDL онлайн. ALGORITHM=INPLACE может использоваться, чтобы выполнить онлайн ADD COLUMN, ADD INDEX (включая CREATE INDEX) и DROP INDEX на таблицах NDB. Онлайн переименование таблиц NDB также поддерживаются. В настоящее время вы не можете добавить находящиеся на диске столбцы к таблицам NDB онлайн. Это означает, что если вы хотите добавить колонку в памяти к таблице NDB, которая использует уровень таблицы STORAGE DISK, необходимо объявить новую колонку как основанное на памяти хранение явно. Например, предположим, что вы уже создали табличное пространство ts1 и вы составляете таблицу t1: mysql> CREATE TABLE t1 (c1 INT NOT NULL PRIMARY KEY, c2 VARCHAR(30)) TABLESPACE ts1 STORAGE DISK ENGINE NDB; Query OK, 0 rows affected (1.73 sec) Records: 0 Duplicates: 0 Warnings: 0 Можно добавить новую колонку в памяти к этой таблице онлайн как показано здесь: mysql> ALTER TABLE t1 ADD COLUMN c3 INT COLUMN_FORMAT DYNAMIC STORAGE MEMORY, ALGORITHM=INPLACE; Query OK, 0 rows affected (1.25 sec) Records: 0 Duplicates: 0 Warnings: 0 Этот запрос терпит неудачу, если опущена опция STORAGE MEMORY: mysql> ALTER TABLE t1 ADD COLUMN c4 INT COLUMN_FORMAT DYNAMIC, ALGORITHM=INPLACE; ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Adding column(s) or add/reorganize partition not supported online. Try ALGORITHM=COPY. Если вы опускаете COLUMN_FORMAT DYNAMIC, динамический формат столбца используется автоматически, но предупреждение выпущено, как показано здесь: mysql> ALTER ONLINE TABLE t1 ADD COLUMN c4 INT STORAGE MEMORY; Query OK, 0 rows affected, 1 warning (1.17 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> SHOW WARNINGS\G *************************** 1. row *************************** Level: Warning Code: 1478 Message: DYNAMIC column c4 with STORAGE DISK is not supported, column will become FIXED mysql> SHOW CREATE TABLE t1\G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `c1` int(11) NOT NULL, `c2` varchar(30) DEFAULT NULL, `c3` int(11) /*!50606 STORAGE MEMORY */ /*!50606 COLUMN_FORMAT DYNAMIC */ DEFAULT NULL, `c4` int(11) /*!50606 STORAGE MEMORY */ DEFAULT NULL, PRIMARY KEY (`c1`) ) /*!50606 TABLESPACE ts_1 STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.03 sec) STORAGE и COLUMN_FORMAT поддерживаются только в кластере NDB, в любой другой версии MySQL, пытаясь использовать любое из этих ключевых слов в CREATE TABLE или ALTER TABLE, запрос приводит к ошибке. Также возможно использовать запрос ALTER TABLE ... REORGANIZE PARTITION, ALGORITHM=INPLACE без partition_names INTO (partition_definitions) на таблицах NDB. Это может использоваться, чтобы перераспределить данные среди новых узлов данных, которые были добавлены к кластеру онлайн. Это не выполняет дефрагментации, которая требует OPTIMIZE TABLE или null ALTER TABLE. См. раздел 7.15. Ограничения NDB на операции онлайн Онлайн DROP COLUMN не поддерживаются. Онлайн ALTER TABLE, CREATE INDEX или DROP INDEX, которые добавляют столбцы, добавляют или удаляют индексы подвергаются следующим ограничениям: Данный онлайн ALTER TABLE может использовать только один из ADD COLUMN, ADD INDEX или DROP INDEX. Одна или более колонок могут быть добавлены онлайн в отдельном операторе, только один индекс может быть создан или удален онлайн в отдельном операторе. Измененная таблица не заблокирована относительно узлов API кроме того, на котором выполняется онлайн-операция ALTER TABLE ADD COLUMN, ADD INDEX или DROP INDEX (или CREATE INDEX или DROP INDEX). Однако, таблица блокирована против любых других операций, происходящих на том же самом узле API в то время, как операция онлайн выполняется. У таблицы, которая будет изменена, должен быть явный первичный ключ, скрытый первичный ключ, созданный NDB, недостаточен для этой цели. Механизм хранения, используемый таблицей, не может быть изменен онлайн. Когда используется с таблицами данных кластерного диска NDB, невозможно изменить тип хранения (DISK или MEMORY) столбцов онлайн. Это означает, что когда вы добавляете или удаляете индекс таким способом, которым операция была бы выполнена онлайн, и хотите, чтобы тип хранения столбца был изменен, необходимо использовать ALGORITHM=COPY в запросе, который добавляет или удаляет индекс. Столбцы, которые будут добавлены онлайн, не могут использовать BLOB или TEXT и должны соответствовать следующим критериям: Столбцы должны быть динамичными, то есть, должно быть возможно создать их с использованием COLUMN_FORMAT DYNAMIC. Если вы опускаете COLUMN_FORMAT DYNAMIC, динамический формат столбца используется автоматически. Столбцы должны разрешить NULL и не иметь любого явного значения по умолчанию, кроме NULL. Столбцы, добавленные онлайн, автоматически создаются как DEFAULT NULL: mysql> CREATE TABLE t2 (c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY) ENGINE=NDB; Query OK, 0 rows affected (1.44 sec) mysql> ALTER TABLE t2 ADD COLUMN c2 INT, ADD COLUMN c3 INT, ALGORITHM=INPLACE; Query OK, 0 rows affected, 2 warnings (0.93 sec) mysql> SHOW CREATE TABLE t1\G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t2` ( `c1` int(11) NOT NULL AUTO_INCREMENT, `c2` int(11) DEFAULT NULL, `c3` int(11) DEFAULT NULL, PRIMARY KEY (`c1`)) ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.00 sec) Столбцы должны быть добавлены после любых существующих столбцов. При попытке добавить колонку онлайн перед какими-либо существующими столбцами или использования ключевого слова FIRST запрос терпит неудачу с ошибкой. Существующие столбцы таблицы не могут быть переупорядочены онлайн. Для онлайн ALTER TABLE на таблицах NDB столбцы фиксированного формата преобразовываются в динамический, когда они добавляются онлайн, или когда индексы созданы или удалены онлайн, как показано здесь: mysql> CREATE TABLE t2 (c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY) ENGINE=NDB; Query OK, 0 rows affected (1.44 sec) mysql> ALTER TABLE t2 ADD COLUMN c2 INT, ADD COLUMN c3 INT, ALGORITHM=INPLACE; Query OK, 0 rows affected, 2 warnings (0.93 sec) mysql> SHOW WARNINGS; *************************** 1. row *************************** Level: Warning Code: 1478 Message: Converted FIXED field 'c2' to DYNAMIC to enable online ADD COLUMN *************************** 2. row *************************** Level: Warning Code: 1478 Message: Converted FIXED field 'c3' to DYNAMIC to enable online ADD COLUMN 2 rows in set (0.00 sec) Только колонка или столбцы, которые будут добавлены онлайн, должны быть динамичными. Существующие столбцы не должны быть такими, это включает первичный ключ таблицы, который может также быть FIXED: mysql> CREATE TABLE t3 (c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY COLUMN_FORMAT FIXED) ENGINE=NDB; Query OK, 0 rows affected (2.10 sec) mysql> ALTER TABLE t3 ADD COLUMN c2 INT, ALGORITHM=INPLACE; Query OK, 0 rows affected, 1 warning (0.78 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> SHOW WARNINGS; *************************** 1. row *************************** Level: Warning Code: 1478 Message: Converted FIXED field 'c2' to DYNAMIC to enable online ADD COLUMN 1 row in set (0.00 sec) Столбцы не преобразовываются из FIXED в DYNAMIC переименованием. Для получения дополнительной информации о COLUMN_FORMAT см. CREATE TABLE Statement. KEY, CONSTRAINT и IGNORE поддерживаются в ALTER TABLE, используя ALGORITHM=INPLACE. Начиная с NDB Cluster 7.5.7 и 7.6.3, MAX_ROWS = 0 в онлайн ALTER TABLE запрещен. Необходимо использовать копирование ALTER TABLE (Bug #21960004). 7.15. Добавление узлов данных NDB Cluster онлайн Эта секция описывает, как добавить узлы данных NDB Cluster online, то есть не останавливая кластер. В настоящее время необходимо добавить новые узлы данных к кластеру NDB как часть новой группы узлов. Кроме того, невозможно изменить количество точных копий (или количество узлов в группе) онлайн. 7.15.1. Добавление узлов данных NDB Cluster Online: общие мысли Эта секция предоставляет общую информацию о поведении и текущих ограничениях в добавлении узлов кластера NDB онлайн. Перераспределение данных. Способность добавить новые узлы онлайн включает средство реорганизовать данные о таблице NDBCLUSTER и индексы так, чтобы они были распределены через все узлы данных, включая новые, посредством ALTER TABLE ... REORGANIZE PARTITION. Перестройка таблиц данных в памяти и дисковых таблиц данных поддерживается. Это перераспределение в настоящее время не включает уникальные индексы (только упорядоченные индексы перераспределены). Перераспределение для таблиц NDBCLUSTER, уже существующих перед добавлением новых узлов данных, не автоматическое, но может быть достигнут, используя простые SQL-операторы в клиенте mysql. Однако, все данные и индексы, добавленные к таблицам, составленным после добавления новой группы узлов, распределяются автоматически среди всех узлов данных, включая добавленные как часть новой группы узлов. Частичные запуски. Возможно добавить новую группу узлов безо всех новых запускаемых узлов данных. Также возможно добавить новую группу узла к ухудшенному кластеру то есть, кластеру, который только частично начат или где один или несколько узлов данных не работают. В последнем случае у кластера должно быть достаточно узлов, чтобы быть жизнеспособным, прежде чем новая группа узлов сможет быть добавлена. Эффекты на продолжающиеся операции. Нормальные операции DML, использующие данные NDB Cluster, не нарушены созданием или добавлением новой группы узлов или перестройкой таблицы. Однако, невозможно выполнить DDL одновременно с перестройкой таблицы то есть, никакие другие запросы DDL не могут быть сделаны в то время, как выполняется ALTER TABLE ... REORGANIZE PARTITION. Кроме того, во время выполнения ALTER TABLE ... REORGANIZE PARTITION (или выполнения любого другого запроса DDL) невозможно перезапустить узлы данных. Обработка неудачи. Неудачи узлов данных во время создания группы узлов и перестройки таблицы обработаны, как показано в следующей таблице: Таблица 7.61. Обработка неудачи узла данных во время создания группы узлов и перестройки таблицы Неудача во время Неудача в старом узле данных Неудача в новом узле данных Системный отказ Создание группы узлов Если узел кроме ведущего падает: создание группы всегда продвигается вперед. Если падает ведущий: Если внутренний пункт передачи был достигнут: создание группы продвинуто вперед. Если внутренний пункт передачи не был достигнут: создание группы откатывается до прежнего уровня. Если узел кроме ведущего падает: создание группы всегда продвигается вперед. Если падает ведущий: Если внутренний пункт передачи был достигнут: создание группы продвинуто вперед. Если внутренний пункт передачи не был достигнут: создание группы откатывается до прежнего уровня. Если выполнение CREATE NODEGROUP дошло до внутренней точки передачи: когда перезапущен, кластер включает новую группу узлов. Если выполнение CREATE NODEGROUP не дошло до внутренней точки передачи: когда перезапущен, кластер не включает новую группу узлов. Перестройка таблицы Если узел кроме ведущего падает: перестройка таблицы всегда продвигается вперед. Если ведущий падает: Если внутренний пункт передачи был достигнут: перестройка таблицы продвинута вперед. Если внутренний пункт передачи не был достигнут: перестройка таблицы откатывается. Если узел кроме ведущего падает: перестройка таблицы всегда продвигается вперед. Если ведущий падает: Если внутренний пункт передачи был достигнут: перестройка таблицы всегда продвигается вперед. Если внутренний пункт передачи был достигнут: перестройка таблицы откатывается. Если выполнение ALTER TABLE ... REORGANIZE PARTITION достигло внутреннего пункта передачи: когда кластер перезапущен, данные и индексы, принадлежащие таблице, распределяются, используя новый узел данных. Если выполнение ALTER TABLE ... REORGANIZE PARTITION не достигло внутреннего пункта передачи: когда кластер перезапущен, данные и индексы, принадлежащие таблице, распределяются, используя только старые узлы данных. Удаление групп узлов. Клиент ndb_mgm поддерживает команду DROP NODEGROUP, но возможно удалить группу узла только, когда никакие узлы данных в группе не содержат данных. В настоящее время нет никакого способа освободить определенный узел данных или группу узлов. Эта команда работает только в следующих двух случаях: После CREATE NODEGROUP в ndb_mgm, но до любой ALTER TABLE ... REORGANIZE PARTITION в mysql. После удаления всех таблиц NDBCLUSTER через DROP TABLE. TRUNCATE TABLE не работает с этой целью, потому что узлы данных продолжают хранить определения таблиц. 7.15.2. Добавление узла данных NDB Cluster онлайн: основная процедура В этой секции мы перечисляем основные шаги, требуемые, чтобы добавить новые узлы данных к кластеру NDB. Эта процедура применяется, используете ли вы ndbd или ndbmtd для процессов узла данных. Для более подробного примера посмотрите раздел 7.15.3. Предположив, что у вас уже есть NDB Cluster, добавление узлов данных онлайн требует следующих шагов: Отредактируйте кластерную конфигурацию (файл config.ini), добавляя новые разделы [ndbd], соответствующие узлам, которые будут добавлены. В случае если кластер использует многократные серверы управления, эти изменения должны быть внесены во все файлы config.ini. Необходимо быть осторожными в том, что ID узла для любых новых узлов данных, включенных в файл config.ini, не должны накладывться на ID узла, используемые существующими узлами. Если у вас есть узлы API, использующие динамично ассигнованный ID узла, и эти ID соответствуют ID узла, которые вы хотите использовать для новых узлов данных, возможно вынудить любые такие узлы API мигрировать, как описано позже в этой процедуре. Выполните катящийся перезапуск всех серверов управления кластера NDB. Все серверы управления должны быть перезапущены с опциями --reload или --initial, чтобы вызвать чтение новой конфигурации. Выполните катящийся перезапуск всех существующих узлов данных NDB Cluster. Обычно надо использовать опцию --initial. При использовании узлов API с динамично ассигнованными ID, соответствующими какому-либо ID узла, которые вы хотите назначить на новые узлы данных, необходимо перезапустить все узлы API (включая узлы SQL) прежде, чем перезапустить любой из процессов узлов данных в этом шаге. Выполните катящийся перезапуск любого SQL или узлов API, связанных с кластером NDB. Запустите новые узлы данных. Новые узлы данных могут быть начаты в любом порядке. Они могут быть также начаты одновременно, пока они начаты после того, как катящиеся перезапуски всех существующих узлов данных были закончены, но прежде, чем перейти к следующему шагу. Выполните один или больше запросов CREATE NODEGROUP в клиенте управления кластером NDB, чтобы создать новую группу узлов, которой будут принадлежать новые узлы данных. Перераспределите данные кластера среди всех узлов данных, включая новые. Обычно это сделано командой ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION в mysql для каждой таблицы NDBCLUSTER. Исключение: для таблиц, составленных, используя опцию MAX_ROWS, это запрос не работает, вместо этого используйте ALTER TABLE ... ALGORITHM=INPLACE MAX_ROWS=..., чтобы реорганизовать такие таблицы. Необходимо также принять во внимание, что использование MAX_ROWS, чтобы определить номер раздела этим способом удерживается от использования в NDB 7.5.4 и позже, где необходимо использовать PARTITION_BALANCE, см. Setting NDB_TABLE Options. Это должно быть сделано только для таблиц, уже существующих в то время, когда новая группа узлов добавляется. Данные в таблицах, составленных после добавления новой группы, распределяются автоматически, однако, данные, добавленные к любой таблице tbl, которая существовала прежде, чем новые узлы были добавлены, не распределяются, используя новые узлы, пока эта таблица не будет реорганизована. ALTER TABLE ... REORGANIZE PARTITION ALGORITHM=INPLACE реорганизовывает разделение, но не восстанавливает пространство, освобожденное на старых узлах. Можно сделать это, скомандовав для каждой таблицы NDBCLUSTER OPTIMIZE TABLE в mysql. Это работает с местом, использованным колонками переменной ширины в памяти таблиц NDB. OPTIMIZE TABLE не поддерживается для столбцов фиксированной ширины таблиц в памяти, это также не поддерживается для дисковых таблиц данных. Можно добавить все желаемые узлы, затем выпустить несколько команд CREATE NODEGROUP по очереди, чтобы добавить новые группы узлов к кластеру. 7.15.3. Добавление узлов данных кластера NDB онлайн: подробный пример В этой секции мы обеспечиваем подробный пример, иллюстрирующий, как добавить новые узлы данных NDB Cluster онлайн, начиная с кластера NDB, имеющего 2 узла данных в единственной группе узлов и завершая кластером, имеющем 4 узла данных в 2 группах узлов. Стартовая конфигурация. В целях иллюстрации мы принимаем минимальную конфигурацию, и что кластер использует файл config.ini, содержащий только следующую информацию: [ndbd default] DataMemory = 100M IndexMemory = 100M NoOfReplicas = 2 DataDir = /usr/local/mysql/var/mysql-cluster [ndbd] Id = 1 HostName = 198.51.100.1 [ndbd] Id = 2 HostName = 198.51.100.2 [mgm] HostName = 198.51.100.10 Id = 10 [api] Id=20 HostName = 198.51.100.20 [api] Id=21 HostName = 198.51.100.21 Мы оставили промежуток в последовательности между ID узла данных и и другими узлами. Это облегчает позже назначение ID узлов, которые уже не используются, узлам данных, которые недавно добавляются. Мы также предполагаем, что вы уже начали кластер, используя соответствующую командную строку или опции my.cnf, и что SHOW в клиенте управления производит вывод, подобный тому, что показывают здесь: -- NDB Cluster -- Management Client -- ndb_mgm> SHOW Connected to Management Server at: 198.51.100.10:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1@198.51.100.1(5.7.29-ndb-7.5.17, Nodegroup: 0, *) id=2@198.51.100.2(5.7.29-ndb-7.5.17, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=10 @198.51.100.10(5.7.29-ndb-7.5.17) [mysqld(API)] 2 node(s) id=20 @198.51.100.20(5.7.29-ndb-7.5.17) id=21 @198.51.100.21(5.7.29-ndb-7.5.17) Наконец, мы предполагаем, что кластер содержит одну таблицу NDBCLUSTER, составленную как показано здесь: USE n; CREATE TABLE ips (id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY, country_code CHAR(2) NOT NULL, type CHAR(4) NOT NULL, ip_address VARCHAR(15) NOT NULL, addresses BIGINT UNSIGNED DEFAULT NULL, date BIGINT UNSIGNED DEFAULT NULL) ENGINE NDBCLUSTER; Использование памяти и соответствующая информация, показанная позже в этой секции, были произведены после вставки приблизительно 50000 строк в эту таблицу. В этом примере мы показываем ndbd, используемый для процессов узла данных. Можно также применить этот пример, если вы используете многопоточный ndbmtd, заменяя ndbmtd на ndbd везде, где это появляется в шагах. Шаг 1: конфигурационный файл. Откройте глобальный конфигурационный файл в текстовом редакторе и добавьте разделы [ndbd], соответствующие 2 новым узлам данных. Мы даем этим узлам данных ID 3 и 4 и предполагаем, что ими нужно управлять на хост-машинах по адресам 198.51.100.3 и 198.51.100.4, соответственно. После того, как вы добавили новые секции, содержание файла config.ini должно быть похожим на то, что показывают здесь: [ndbd default] DataMemory = 100M IndexMemory = 100M NoOfReplicas = 2 DataDir = /usr/local/mysql/var/mysql-cluster [ndbd] Id = 1 HostName = 198.51.100.1 [ndbd] Id = 2 HostName = 198.51.100.2[ndbd] Id = 3 HostName = 198.51.100.3 [ndbd] Id = 4 HostName = 198.51.100.4 [mgm] HostName = 198.51.100.10 Id = 10 [api] Id=20 HostName = 198.51.100.20 [api] Id=21 HostName = 198.51.100.21 Как только вы внесли необходимые изменения, сохраните файл. Шаг 2: Перезапустите сервер управления. Перезапуск сервера управления кластера требует, чтобы вы дали отдельные команды, чтобы остановить сервер управления и затем запустили его снова: Остановите сервер управления, используя в клиенте управления команду STOP : ndb_mgm> 10 STOP Node 10 has shut down. Disconnecting to allow Management Server to shutdown Поскольку закрытие сервера управления заставляет клиент управления закрываться, необходимо начать сервер управления из системной оболочки. Для простоты мы принимаем, что config.ini в том же самом каталоге, где исполняемый файл сервера управления, но на практике, необходимо задать правильный путь к конфигурационному файлу. Необходимо также задать опцию --reload или --initial, чтобы сервер управления прочитал новую конфигурацию от файла, а не кэша конфигурации. Если текущий каталог вашей оболочки это каталог сервера, то: shell> ndb_mgmd -f config.ini --reload 2008-12-08 17:29:23 [MgmSrvr] INFO -- NDB Cluster Management Server. 5.7.29-ndb-7.5.17 2008-12-08 17:29:23 [MgmSrvr] INFO -- Reading cluster configuration from 'config.ini' Если вы проверяете вывод SHOW в клиенте управления после перезапуска процесса ndb_mgm, необходимо теперь видеть что-то вроде этого: -- NDB Cluster -- Management Client -- ndb_mgm> SHOW Connected to Management Server at: 198.51.100.10:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1@198.51.100.1(5.7.29-ndb-7.5.17, Nodegroup: 0, *) id=2@198.51.100.2(5.7.29-ndb-7.5.17, Nodegroup: 0) id=3 (not connected, accepting connect from 198.51.100.3) id=4 (not connected, accepting connect from 198.51.100.4) [ndb_mgmd(MGM)] 1 node(s) id=10 @198.51.100.10(5.7.29-ndb-7.5.17) [mysqld(API)] 2 node(s) id=20 @198.51.100.20(5.7.29-ndb-7.5.17) id=21 @198.51.100.21(5.7.29-ndb-7.5.17) Шаг 3: Выполните катящийся перезапуск существующих узлов данных. Этот шаг может быть достигнут полностью в клиенте управления кластером, используя RESTART: ndb_mgm> 1 RESTART Node 1: Node shutdown initiated Node 1: Node shutdown completed, restarting, no start. Node 1 is being restarted ndb_mgm> Node 1: Start initiated (version 7.5.17) Node 1: Started (version 7.5.17) ndb_mgm> 2 RESTART Node 2: Node shutdown initiated Node 2: Node shutdown completed, restarting, no start. Node 2 is being restarted ndb_mgm> Node 2: Start initiated (version 7.5.17) ndb_mgm> Node 2: Started (version 7.5.17) После каждой команды X RESTART ждите, пока клиент управления не сообщит Node X: Started (version ...) прежде, чем продолжить. Можно проверить, что все существующие узлы данных были перезапущены, используя обновленную конфигурацию, проверив таблицу ndbinfo.nodes в клиенте mysql. Шаг 4: Выполните катящийся перезапуск всех узлов API. Выполните закрытие и перезапуск каждого сервера MySQL, действующего как узел SQL в кластере, используя mysqladmin shutdown и mysqld_safe (или другой стартовый скрипт). Это должно быть подобно тому, что показывают здесь, где password это пароль MySQL root: shell> mysqladmin -uroot -ppassword shutdown 081208 20:19:56 mysqld_safe mysqld from pid file /usr/local/mysql/var/tonfisk.pid ended shell> mysqld_safe --ndbcluster --ndb-connectstring=198.51.100.10 & 081208 20:20:06 mysqld_safe Logging to '/usr/local/mysql/var/tonfisk.err'. 081208 20:20:06 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var Конечно, точный ввод и вывод зависят от того, как и где MySQL устанавливается в системе. Шаг 5: Выполните начальный запуск новых узлов данных. Из системной оболочки на каждом из хостов новых узлов данных запустите узлы данных как показано здесь, используя опцию --initial: shell> ndbd -c 198.51.100.10 --initial В отличие от перезапуска существующих узлов данных, можно начать новые узлы данных одновременно. Ждите, пока оба новых узла данных не стартуют перед продолжением следующего шага. Как только новые узлы данных начались, вы видите в выводе клиента управления SHOW, что они еще не принадлежат никакой группе узлов: ndb_mgm> SHOW Connected to Management Server at: 198.51.100.10:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1@198.51.100.1(5.7.29-ndb-7.5.17, Nodegroup: 0, *) id=2@198.51.100.2(5.7.29-ndb-7.5.17, Nodegroup: 0) id=3@198.51.100.3(5.7.29-ndb-7.5.17, no nodegroup) id=4@198.51.100.4(5.7.29-ndb-7.5.17, no nodegroup) [ndb_mgmd(MGM)] 1 node(s) id=10 @198.51.100.10(5.7.29-ndb-7.5.17) [mysqld(API)] 2 node(s) id=20 @198.51.100.20(5.7.29-ndb-7.5.17) id=21 @198.51.100.21(5.7.29-ndb-7.5.17) Шаг 6: Создайте новую группу узлов. Можно сделать это, скомандовав CREATE NODEGROUP в клиенте управления кластером. Эта команда берет в качестве аргумента список разделенных запятой значений ID узлов данных, которые будут включены в новую группу, как показано здесь: ndb_mgm> CREATE NODEGROUP 3,4 Nodegroup 1 created Выполнив SHOW снова, можно проверить, что узлы данных 3 и 4 присоединились к новой группе: ndb_mgm> SHOW Connected to Management Server at: 198.51.100.10:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1@198.51.100.1(5.7.29-ndb-7.5.17, Nodegroup: 0, *) id=2@198.51.100.2(5.7.29-ndb-7.5.17, Nodegroup: 0) id=3@198.51.100.3(5.7.29-ndb-7.5.17, Nodegroup: 1) id=4@198.51.100.4(5.7.29-ndb-7.5.17, Nodegroup: 1) [ndb_mgmd(MGM)] 1 node(s) id=10 @198.51.100.10(5.7.29-ndb-7.5.17) [mysqld(API)] 2 node(s) id=20 @198.51.100.20(5.7.29-ndb-7.5.17) id=21 @198.51.100.21(5.7.29-ndb-7.5.17) Шаг 7: Перераспределите данные. Когда группа узлов создается, существующие данные и индексы автоматически не распределяются новым узлам данных кластера, как вы видите, выпуская соответствующую команду REPORT: ndb_mgm> ALL REPORT MEMORY Node 1: Data usage is 5%(177 32K pages of total 3200) Node 1: Index usage is 0%(108 8K pages of total 12832) Node 2: Data usage is 5%(177 32K pages of total 3200) Node 2: Index usage is 0%(108 8K pages of total 12832) Node 3: Data usage is 0%(0 32K pages of total 3200) Node 3: Index usage is 0%(0 8K pages of total 12832) Node 4: Data usage is 0%(0 32K pages of total 3200) Node 4: Index usage is 0%(0 8K pages of total 12832) При помощи ndb_desc с опцией -p, которая заставляет вывод включать информацию о разделах, вы видите, что таблица все еще использует только 2 раздела (в раздел вывода Per partition info): shell> ndb_desc -c 198.51.100.10 -d n ips -p -- ips -- Version: 1 Fragment type: 9 K Value: 6 Min load factor: 78 Max load factor: 80 Temporary table: no Number of attributes: 6 Number of primary keys: 1 Length of frm data: 340 Row Checksum: 1 Row GCI: 1 SingleUserMode: 0 ForceVarPart: 1 FragmentCount: 2 TableStatus: Retrieved -- Attributes -- id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY addresses Bigunsigned NULL AT=FIXED ST=MEMORY date Bigunsigned NULL AT=FIXED ST=MEMORY -- Indexes -- PRIMARY KEY(id) - UniqueHashIndex PRIMARY(id) - OrderedIndex -- Per partition info -- Partition Row count Commit countFrag fixed memory Frag varsized memory 0 26086 26086 1572864 557056 1 26329 26329 1605632 557056 NDBT_ProgramExit: 0 - OK Можно заставить данные быть перераспределенными среди всех узлов данных, выполнив для каждой таблицы NDB команду ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION в клиенте mysql. ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION не работает с таблицами, которые были составлены с MAX_ROWS. Вместо этого используйте ALTER TABLE ... ALGORITHM=INPLACE, MAX_ROWS=.... Следует иметь в виду, что использование MAX_ROWS, чтобы определить номер разделения таблицы удерживается от использования в NDB 7.5.4 и позже, где необходимо использовать PARTITION_BALANCE, см. Setting NDB_TABLE Options. После команды ALTER TABLE ips ALGORITHM=INPLACE, REORGANIZE PARTITION вы видите в выводе ndb_desc, что данные для этой таблицы теперь хранятся, используя 4 раздела, как показано здесь: shell> ndb_desc -c 198.51.100.10 -d n ips -p -- ips -- Version: 16777217 Fragment type: 9 K Value: 6 Min load factor: 78 Max load factor: 80 Temporary table: no Number of attributes: 6 Number of primary keys: 1 Length of frm data: 341 Row Checksum: 1 Row GCI: 1 SingleUserMode: 0 ForceVarPart: 1 FragmentCount: 4 TableStatus: Retrieved -- Attributes -- id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY addresses Bigunsigned NULL AT=FIXED ST=MEMORY date Bigunsigned NULL AT=FIXED ST=MEMORY -- Indexes -- PRIMARY KEY(id) - UniqueHashIndex PRIMARY(id) - OrderedIndex -- Per partition info -- Partition Row count Commit count Frag fixed memory Frag varsized memory 0 12981 52296 1572864 557056 1 13236 52515 1605632 557056 2 13105 13105 819200 294912 3 13093 13093 819200 294912 NDBT_ProgramExit: 0 - OK Обычно ALTER TABLE table_name [ALGORITHM=INPLACE,] REORGANIZE PARTITION используется со списком идентификаторов разделения и строки определений разделения, чтобы создать новую схему выделения разделов для таблицы, которая была уже явно разделена. Его использование здесь, чтобы перераспределить данные на новую группу узлов кластера NDB является исключением в этом отношении: когда используется таким образом, никакие другие ключевые слова или идентификаторы не следуют за REORGANIZE PARTITION. См. ALTER TABLE Statement. Кроме того, для каждо таблицы ALTER TABLE должен сопровождаться OPTIMIZE TABLE, чтобы восстановить потраченное впустую пространство. Можно получить список всех таблиц NDBCLUSTER, используя следующий запрос к таблице INFORMATION_SCHEMA.TABLES: SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'NDBCLUSTER'; Значение INFORMATION_SCHEMA.TABLES.ENGINE для таблиц NDB Cluster всегда NDBCLUSTER, независимо от CREATE TABLE (или ALTER TABLE, которым раньше преобразовывали существующую таблицу из различного механизма хранения), используемый NDB или NDBCLUSTER в опции ENGINE. Вы видите после выполнения этих запросов в выводе ALL REPORT MEMORY, что данные и индексы теперь перераспределены между всеми узлами данных в кластере, как показано здесь: ndb_mgm> ALL REPORT MEMORY Node 1: Data usage is 5%(176 32K pages of total 3200) Node 1: Index usage is 0%(76 8K pages of total 12832) Node 2: Data usage is 5%(176 32K pages of total 3200) Node 2: Index usage is 0%(76 8K pages of total 12832) Node 3: Data usage is 2%(80 32K pages of total 3200) Node 3: Index usage is 0%(51 8K pages of total 12832) Node 4: Data usage is 2%(80 32K pages of total 3200) Node 4: Index usage is 0%(50 8K pages of total 12832) Только одна операция DDL на таблице NDBCLUSTER может быть выполнена за один раз, поэтому необходимо ждать окончания каждого запроса ALTER TABLE ... REORGANIZE PARTITION . Не надо выполнять ALTER TABLE ... REORGANIZE PARTITION для таблиц NDBCLUSTER, составленных после добавления новых узлов данных, данные, добавленные к таким таблицым, распределяются среди всех узлов данных автоматически. Однако, в таблицах NDBCLUSTER, которые существовали до добавления новых узлов, существующие или новые данные не распределяются, используя новые узлы, пока эти таблицы не реорганизованы, используя ALTER TABLE ... REORGANIZE PARTITION. Альтернативная процедура, без катящегося перезапуска. Возможно избежать потребности в катящемся перезапуске, формируя дополнительные узлы данных, но не начиная их, сначала начиная кластер. Мы принимаем, как прежде, что вы хотите начать с двух узлов узлов данных 1 и 2 в одной группе и позже расширить кластер до четырех узлов данных, добавляя вторую группу узлов, состоящую из узлов 3 и 4: [ndbd default] DataMemory = 100M IndexMemory = 100M NoOfReplicas = 2 DataDir = /usr/local/mysql/var/mysql-cluster [ndbd] Id = 1 HostName = 198.51.100.1 [ndbd] Id = 2 HostName = 198.51.100.2 [ndbd] Id = 3 HostName = 198.51.100.3 Nodegroup = 65536 [ndbd] Id = 4 HostName = 198.51.100.4 Nodegroup = 65536 [mgm] HostName = 198.51.100.10 Id = 10 [api] Id=20 HostName = 198.51.100.20 [api] Id=21 HostName = 198.51.100.21 Узлы данных, которые будут получены онлайн в более позднее время (узлы 3 и 4), могут формироваться с NodeGroup = 65536, в этом случае узлы 1 и 2 могут быть начаты как показано здесь: shell> ndbd -c 198.51.100.10 --initial Узлы данных, формируемые с NodeGroup = 65536, рассматриваются сервером управления, как будто вы начали узлы 1 и 2 с использованием --nowait-nodes=3,4 после ожидания сроком на время, определенное StartNoNodeGroupTimeout. По умолчанию это 15 секунд (15000 миллисекунд). StartNoNodegroupTimeout должно быть то же самое для всех узлов данных в кластере, поэтому, необходимо всегда устанавливать его в разделе [ndbd default] файла config.ini, а не для отдельных узлов данных. Когда вы готовы добавить вторую группу узлов, вы должны выполнить только дополнительные шаги: Запустите узлы данных 3 и 4, вызвав процесс узла данных однажды для каждого нового узла: shell> ndbd -c 198.51.100.10 --initial Выполните CREATE NODEGROUP: ndb_mgm> CREATE NODEGROUP 3,4 В mysql выполните ALTER TABLE ... REORGANIZE PARTITION и OPTIMIZE TABLE для каждой таблицы NDBCLUSTER. Как отмечено в другом месте в этой секции, существующие таблицы кластера NDB не могут использовать новые узлы для распределения данных, пока это не было сделано. 7.16. Распределенные привилегии, используя общие таблицы прав доступа NDB Cluster поддерживает распределение пользователей MySQL и привилегий на все узлы SQL в кластере NDB. Эта поддержка не позволена по умолчанию, необходимо выполнить процедуру, обрисованную в общих чертах в этой секции. Обычно таблицы полномочий пользователя сервера MySQL в базе данных mysql должны использовать механизм хранения MyISAM, что означает, что учетная запись пользователя и ее связанные привилегии, созданные на одном узле SQL, недоступны на других узлах кластера SQL. Файл SQL ndb_dist_priv.sql, предоставленный дистрибутивом NDB Cluster, может быть найден в каталоге share каталога установки MySQL. Первый шаг в предоставлении возможности распределенных привилегий должен загрузить этот скрипт MySQL Server, который функционирует как узел SQL (к которому мы обращаемся после этого, как к целевому узлу SQL или MySQL Server). Можно сделать это, выполнив следующую команду из системной оболочки на целевом узле SQL после перехода в его инсталляционный каталог MySQL (где options обозначает любые дополнительные опции, чтобы соединиться с этим узлом SQL): shell> mysql options -uroot < share/ndb_dist_priv.sql Импорт ndb_dist_priv.sql создает много хранимых подпрограмм в БД mysql на целевом узле SQL. После соединения с узлом SQL в mysql (как MySQL root) можно проверить, что они были созданы как показано здесь: mysql> SELECT ROUTINE_NAME, ROUTINE_SCHEMA, ROUTINE_TYPE FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_NAME LIKE 'mysql_cluster%' ORDER BY ROUTINE_TYPE; +---------------------------------------------+----------------+--------------+ | ROUTINE_NAME | ROUTINE_SCHEMA | ROUTINE_TYPE | +---------------------------------------------+----------------+--------------+ | mysql_cluster_privileges_are_distributed | mysql | FUNCTION | | mysql_cluster_backup_privileges | mysql | PROCEDURE | | mysql_cluster_move_grant_tables | mysql | PROCEDURE | | mysql_cluster_move_privileges | mysql | PROCEDURE | | mysql_cluster_restore_local_privileges | mysql | PROCEDURE | | mysql_cluster_restore_privileges | mysql | PROCEDURE | | mysql_cluster_restore_privileges_from_local | mysql | PROCEDURE | +---------------------------------------------+----------------+--------------+ 7 rows in set (0.01 sec) Хранимая процедура mysql_cluster_move_privileges создает резервные копии существующих таблиц привилегий, затем преобразовывает их в NDB . mysql_cluster_move_privileges выполняет резервную копию и преобразование в два шага. Первый шаг должен вызвать mysql_cluster_backup_privileges, который создает два набора копий в БД mysql: Ряд местных копий, которые используют MyISAM. Их имена произведены, добавив суффикс _backup к оригинальным именам таблиц привилегии. Ряд распределенных копий, которые используют NDBCLUSTER. Эти таблицы называют с префиксом ndb_ и добавлением _backup к названиям оригинальных таблиц. После того, как копии создаются mysql_cluster_move_privileges вызывает mysql_cluster_move_grant_tables, который содержит ALTER TABLE ... ENGINE = NDB, которые преобразовывает системные таблицы mysql в NDB. Обычно вы не должны вызывать также mysql_cluster_backup_privileges или mysql_cluster_move_grant_tables вручную: эти хранимые процедуры предназначаются только для использования mysql_cluster_move_privileges. Хотя оригинальные таблицы привилегии поддерживаются автоматически, всегда хорошая идея создать резервные копии вручную существующих таблиц привилегий на всех узлах SQL перед переходом. Можно сделать это с использованием mysqldump: shell> mysqldump options -uroot mysql user db tables_priv columns_priv \ procs_priv proxies_priv > backup_file Чтобы выполнить преобразование, вы должны быть связаны с целевым узлом SQL, используя mysql (как MySQL root). Вызовите хранимую процедуру: mysql> CALL mysql.mysql_cluster_move_privileges(); Query OK, 0 rows affected (22.32 sec) В зависимости от количества строк в таблицах привилегии эта процедура может занять время. Если некоторые таблицы привилегии пусты, вы можете видеть одно или более предупреждений No data - zero rows fetched, selected, or processed, возвращаемых mysql_cluster_move_privileges. В таких экземплярах предупреждения могут быть безопасно проигнорированы. Чтобы проверить, что преобразование было успешно, можно использовать сохраненную функцию mysql_cluster_privileges_are_distributed: mysql> SELECT CONCAT('Conversion ', IF (mysql.mysql_cluster_privileges_are_distributed(), 'succeeded', 'failed'), '.') AS Result; +-----------------------+ | Result | +-----------------------+ | Conversion succeeded. | +-----------------------+ 1 row in set (0.00 sec) mysql_cluster_privileges_are_distributed проверяет на существование распределенных таблиц привилегии и вернет 1, если все таблицы привилегии распределяются, иначе 0. Можно проверить, что резервные копии были созданы, используя запрос: mysql> SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'mysql' AND TABLE_NAME LIKE '%backup' ORDER BY ENGINE; +-------------------------+------------+ | TABLE_NAME | ENGINE | +-------------------------+------------+ | db_backup | MyISAM | | user_backup | MyISAM | | columns_priv_backup | MyISAM | | tables_priv_backup | MyISAM | | proxies_priv_backup | MyISAM | | procs_priv_backup | MyISAM | | ndb_columns_priv_backup | ndbcluster | | ndb_user_backup | ndbcluster | | ndb_tables_priv_backup | ndbcluster | | ndb_proxies_priv_backup | ndbcluster | | ndb_procs_priv_backup | ndbcluster | | ndb_db_backup | ndbcluster | +-------------------------+------------+ 12 rows in set (0.00 sec) Как только преобразование в распределенные привилегии было сделано, в любое время, когда учетная запись пользователя MySQL была создана, удалена или ее привилегии обновили на любом узле SQL, изменения немедленно вступают в силу на всех других серверах MySQL, подключенных к кластеру. Как только привилегии распределяются, любые новые MySQL Server, которые соединяются с кластером автоматически, участвуют в распределении. Для клиентов, связанных с узлами SQL в то время, когда выполнялась mysql_cluster_move_privileges, вы, возможно, должны выполнить FLUSH PRIVILEGES на тех узлах SQL, или разъединить и затем воссоединить клиентов, чтобы быть в состоянии видеть изменения в привилегиях. Все полномочия пользователя MySQL распределяются на все соединненные MySQL Server. Это включает любые привилегии, связанные с обзорами и хранимыми подпрограммами, даже при том, что распределение обзоров и подпрограмм в настоящее время не поддерживается. Если узел SQL отсоединяется от кластера в то время, как mysql_cluster_move_privileges работает, необходимо удалить его таблицы привилегии после повторного подключения к кластеру, используя запрос DROP TABLE IF EXISTS mysql.user mysql.db mysql.tables_priv mysql.columns_priv mysql.procs_priv. Это заставляет узел SQL использовать общие таблицы привилегии, а не собственные локальные версии. Это не надо делать, соединяя новый узел SQL с кластером впервые. В случае начального перезапуска всего кластера, общие таблицы привилегии потеряны. Если это происходит, можно восстановить их, используя оригинальный целевой узел SQL, из любой из резервных копий, сделанных mysql_cluster_move_privileges или из дампа, созданного mysqldump. Если необходимо использовать новый MySQL Server, чтобы выполнить восстановление, необходимо начать его с --skip-grant-tables, соединяясь с кластером впервые, после этого можно локально восстановить таблицы привилегий, затем распределить их снова использованием mysql_cluster_move_privileges. После восстановления и распределения таблиц, необходимо перезапустить этот MySQL Server без опции --skip-grant-tables. Можно также восстановить распределенные таблицы, используя ndb_restore --restore-privilege-tables из резервной копии, сделанной, используя START BACKUP в ndb_mgm. Таблицы MyISAM, составленные mysql_cluster_move_privileges, не поддерживаются командой START BACKUP. ndb_restore по умолчанию не восстанавливает таблицы привилегии, опция --restore-privilege-tables это делает. Можно восстановить местные привилегии узла SQL, используя любую из двух процедур. mysql_cluster_restore_privileges работает следующим образом: Если копии таблиц mysql.ndb_*_backup доступны, пытаются восстановить системные таблицы от них. Иначе делается попытка восстановить системные таблицы из местных резервных копий *_backup (без префикса ndb_). Другая процедура mysql_cluster_restore_local_privileges восстанавливает системные таблицы только из местных резервных копий, не проверяя резервные копии ndb_*. Системные таблицы, воссозданные mysql_cluster_restore_privileges или mysql_cluster_restore_local_privileges, используют механизм хранения сервера MySQL по умолчанию, они не разделяются или распределяются в любом случае и не используют NDB Cluster NDB. Дополнительная хранимая процедура mysql_cluster_restore_privileges_from_local предназначается для использования mysql_cluster_restore_privileges и mysql_cluster_restore_local_privileges. Это не должно быть вызвано непосредственно. Приложения, обращающиеся к NDB Cluster непосредственно, включая API NDB и приложения ClusterJ, не работают с системой привилегий MySQL. Это означает, что, как только вы распределили таблицы, к ним могут свободно получить доступ такие приложения, как они могут работать с любой другой таблицей NDB. В частности необходимо иметь в виду, что API NDB и приложения ClusterJ могут прочитать и написать имена пользователей, имена хоста, хэши пароля и любое другое содержание распределенных таблиц прав доступа без каких-либо ограничений. 7.17. Счетчики и переменные статистики API NDB Много типов статистических счетчиков, касающихся действий, выполненных объектами Ndb, доступны. Такие действия включают старт и закрытие (или прерывание) транзакции, первичный ключ и операции по уникальному ключу, таблица, диапазон и сокращенные просмотры, потоки, заблокированные, ожидая завершения различных операций, данные и события, посланные и полученные NDBCLUSTER. Счетчики увеличены в ядре NDB каждый раз, когда вызовы API NDB сделаны или данные посылают или получают. mysqld выставляет эти счетчики как переменные состояния системы, их значения могут быть прочитаны в выводе SHOW STATUS или запросом к таблице INFORMATION_SCHEMA.SESSION_STATUS или INFORMATION_SCHEMA.GLOBAL_STATUS . Сравнивая значения прежде и после запросов, воздействующих на таблицы NDB, можно наблюдать соответствующие действия на уровне API и таким образом значение выполнения запроса. Можно перечислить все эти переменные статуса, используя следующий запрос SHOW STATUS: mysql> SHOW STATUS LIKE 'ndb_api%'; +--------------------------------------------+----------+ | Variable_name | Value | +--------------------------------------------+----------+ | Ndb_api_wait_exec_complete_count_session | 0 | | Ndb_api_wait_scan_result_count_session | 0 | | Ndb_api_wait_meta_request_count_session | 0 | | Ndb_api_wait_nanos_count_session | 0 | | Ndb_api_bytes_sent_count_session | 0 | | Ndb_api_bytes_received_count_session | 0 | | Ndb_api_trans_start_count_session | 0 | | Ndb_api_trans_commit_count_session | 0 | | Ndb_api_trans_abort_count_session | 0 | | Ndb_api_trans_close_count_session | 0 | | Ndb_api_pk_op_count_session | 0 | | Ndb_api_uk_op_count_session | 0 | | Ndb_api_table_scan_count_session | 0 | | Ndb_api_range_scan_count_session | 0 | | Ndb_api_pruned_scan_count_session | 0 | | Ndb_api_scan_batch_count_session | 0 | | Ndb_api_read_row_count_session | 0 | | Ndb_api_trans_local_read_row_count_session | 0 | | Ndb_api_event_data_count_injector | 0 | | Ndb_api_event_nondata_count_injector | 0 | | Ndb_api_event_bytes_count_injector | 0 | | Ndb_api_wait_exec_complete_count_slave | 0 | | Ndb_api_wait_scan_result_count_slave | 0 | | Ndb_api_wait_meta_request_count_slave | 0 | | Ndb_api_wait_nanos_count_slave | 0 | | Ndb_api_bytes_sent_count_slave | 0 | | Ndb_api_bytes_received_count_slave | 0 | | Ndb_api_trans_start_count_slave | 0 | | Ndb_api_trans_commit_count_slave | 0 | | Ndb_api_trans_abort_count_slave | 0 | | Ndb_api_trans_close_count_slave | 0 | | Ndb_api_pk_op_count_slave | 0 | | Ndb_api_uk_op_count_slave | 0 | | Ndb_api_table_scan_count_slave | 0 | | Ndb_api_range_scan_count_slave | 0 | | Ndb_api_pruned_scan_count_slave | 0 | | Ndb_api_scan_batch_count_slave | 0 | | Ndb_api_read_row_count_slave | 0 | | Ndb_api_trans_local_read_row_count_slave | 0 | | Ndb_api_wait_exec_complete_count | 2 | | Ndb_api_wait_scan_result_count | 3 | | Ndb_api_wait_meta_request_count | 27 | | Ndb_api_wait_nanos_count | 45612023 | | Ndb_api_bytes_sent_count | 992 | | Ndb_api_bytes_received_count | 9640 | | Ndb_api_trans_start_count | 2 | | Ndb_api_trans_commit_count | 1 | | Ndb_api_trans_abort_count | 0 | | Ndb_api_trans_close_count | 2 | | Ndb_api_pk_op_count | 1 | | Ndb_api_uk_op_count | 0 | | Ndb_api_table_scan_count | 1 | | Ndb_api_range_scan_count | 0 | | Ndb_api_pruned_scan_count | 0 | | Ndb_api_scan_batch_count | 0 | | Ndb_api_read_row_count | 1 | | Ndb_api_trans_local_read_row_count | 1 | | Ndb_api_event_data_count | 0 | | Ndb_api_event_nondata_count | 0 | | Ndb_api_event_bytes_count | 0 | +--------------------------------------------+----------+ 60 rows in set (0.02 sec) Эти переменные статуса также доступны в таблицах SESSION_STATUS и GLOBAL_STATUS в БД INFORMATION_SCHEMA: mysql> SELECT * FROM INFORMATION_SCHEMA.SESSION_STATUS WHERE VARIABLE_NAME LIKE 'ndb_api%'; +--------------------------------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +--------------------------------------------+----------------+ | NDB_API_WAIT_EXEC_COMPLETE_COUNT_SESSION | 2 | | NDB_API_WAIT_SCAN_RESULT_COUNT_SESSION | 0 | | NDB_API_WAIT_META_REQUEST_COUNT_SESSION | 1 | | NDB_API_WAIT_NANOS_COUNT_SESSION | 8144375 | | NDB_API_BYTES_SENT_COUNT_SESSION | 68 | | NDB_API_BYTES_RECEIVED_COUNT_SESSION | 84 | | NDB_API_TRANS_START_COUNT_SESSION | 1 | | NDB_API_TRANS_COMMIT_COUNT_SESSION | 1 | | NDB_API_TRANS_ABORT_COUNT_SESSION | 0 | | NDB_API_TRANS_CLOSE_COUNT_SESSION | 1 | | NDB_API_PK_OP_COUNT_SESSION | 1 | | NDB_API_UK_OP_COUNT_SESSION | 0 | | NDB_API_TABLE_SCAN_COUNT_SESSION | 0 | | NDB_API_RANGE_SCAN_COUNT_SESSION | 0 | | NDB_API_PRUNED_SCAN_COUNT_SESSION | 0 | | NDB_API_SCAN_BATCH_COUNT_SESSION | 0 | | NDB_API_READ_ROW_COUNT_SESSION | 1 | | NDB_API_TRANS_LOCAL_READ_ROW_COUNT_SESSION | 1 | | NDB_API_EVENT_DATA_COUNT_INJECTOR | 0 | | NDB_API_EVENT_NONDATA_COUNT_INJECTOR | 0 | | NDB_API_EVENT_BYTES_COUNT_INJECTOR | 0 | | NDB_API_WAIT_EXEC_COMPLETE_COUNT_SLAVE | 0 | | NDB_API_WAIT_SCAN_RESULT_COUNT_SLAVE | 0 | | NDB_API_WAIT_META_REQUEST_COUNT_SLAVE | 0 | | NDB_API_WAIT_NANOS_COUNT_SLAVE | 0 | | NDB_API_BYTES_SENT_COUNT_SLAVE | 0 | | NDB_API_BYTES_RECEIVED_COUNT_SLAVE | 0 | | NDB_API_TRANS_START_COUNT_SLAVE | 0 | | NDB_API_TRANS_COMMIT_COUNT_SLAVE | 0 | | NDB_API_TRANS_ABORT_COUNT_SLAVE | 0 | | NDB_API_TRANS_CLOSE_COUNT_SLAVE | 0 | | NDB_API_PK_OP_COUNT_SLAVE | 0 | | NDB_API_UK_OP_COUNT_SLAVE | 0 | | NDB_API_TABLE_SCAN_COUNT_SLAVE | 0 | | NDB_API_RANGE_SCAN_COUNT_SLAVE | 0 | | NDB_API_PRUNED_SCAN_COUNT_SLAVE | 0 | | NDB_API_SCAN_BATCH_COUNT_SLAVE | 0 | | NDB_API_READ_ROW_COUNT_SLAVE | 0 | | NDB_API_TRANS_LOCAL_READ_ROW_COUNT_SLAVE | 0 | | NDB_API_WAIT_EXEC_COMPLETE_COUNT | 4 | | NDB_API_WAIT_SCAN_RESULT_COUNT | 3 | | NDB_API_WAIT_META_REQUEST_COUNT | 28 | | NDB_API_WAIT_NANOS_COUNT | 53756398 | | NDB_API_BYTES_SENT_COUNT | 1060 | | NDB_API_BYTES_RECEIVED_COUNT | 9724 | | NDB_API_TRANS_START_COUNT | 3 | | NDB_API_TRANS_COMMIT_COUNT | 2 | | NDB_API_TRANS_ABORT_COUNT | 0 | | NDB_API_TRANS_CLOSE_COUNT | 3 | | NDB_API_PK_OP_COUNT | 2 | | NDB_API_UK_OP_COUNT | 0 | | NDB_API_TABLE_SCAN_COUNT | 1 | | NDB_API_RANGE_SCAN_COUNT | 0 | | NDB_API_PRUNED_SCAN_COUNT | 0 | | NDB_API_SCAN_BATCH_COUNT | 0 | | NDB_API_READ_ROW_COUNT | 2 | | NDB_API_TRANS_LOCAL_READ_ROW_COUNT | 2 | | NDB_API_EVENT_DATA_COUNT | 0 | | NDB_API_EVENT_NONDATA_COUNT | 0 | | NDB_API_EVENT_BYTES_COUNT | 0 | +--------------------------------------------+----------------+ 60 rows in set (0.00 sec) mysql> SELECT * FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME LIKE 'ndb_api%'; +--------------------------------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +--------------------------------------------+----------------+ | NDB_API_WAIT_EXEC_COMPLETE_COUNT_SESSION | 2 | | NDB_API_WAIT_SCAN_RESULT_COUNT_SESSION | 0 | | NDB_API_WAIT_META_REQUEST_COUNT_SESSION | 1 | | NDB_API_WAIT_NANOS_COUNT_SESSION | 8144375 | | NDB_API_BYTES_SENT_COUNT_SESSION | 68 | | NDB_API_BYTES_RECEIVED_COUNT_SESSION | 84 | | NDB_API_TRANS_START_COUNT_SESSION | 1 | | NDB_API_TRANS_COMMIT_COUNT_SESSION | 1 | | NDB_API_TRANS_ABORT_COUNT_SESSION | 0 | | NDB_API_TRANS_CLOSE_COUNT_SESSION | 1 | | NDB_API_PK_OP_COUNT_SESSION | 1 | | NDB_API_UK_OP_COUNT_SESSION | 0 | | NDB_API_TABLE_SCAN_COUNT_SESSION | 0 | | NDB_API_RANGE_SCAN_COUNT_SESSION | 0 | | NDB_API_PRUNED_SCAN_COUNT_SESSION | 0 | | NDB_API_SCAN_BATCH_COUNT_SESSION | 0 | | NDB_API_READ_ROW_COUNT_SESSION | 1 | | NDB_API_TRANS_LOCAL_READ_ROW_COUNT_SESSION | 1 | | NDB_API_EVENT_DATA_COUNT_INJECTOR | 0 | | NDB_API_EVENT_NONDATA_COUNT_INJECTOR | 0 | | NDB_API_EVENT_BYTES_COUNT_INJECTOR | 0 | | NDB_API_WAIT_EXEC_COMPLETE_COUNT_SLAVE | 0 | | NDB_API_WAIT_SCAN_RESULT_COUNT_SLAVE | 0 | | NDB_API_WAIT_META_REQUEST_COUNT_SLAVE | 0 | | NDB_API_WAIT_NANOS_COUNT_SLAVE | 0 | | NDB_API_BYTES_SENT_COUNT_SLAVE | 0 | | NDB_API_BYTES_RECEIVED_COUNT_SLAVE | 0 | | NDB_API_TRANS_START_COUNT_SLAVE | 0 | | NDB_API_TRANS_COMMIT_COUNT_SLAVE | 0 | | NDB_API_TRANS_ABORT_COUNT_SLAVE | 0 | | NDB_API_TRANS_CLOSE_COUNT_SLAVE | 0 | | NDB_API_PK_OP_COUNT_SLAVE | 0 | | NDB_API_UK_OP_COUNT_SLAVE | 0 | | NDB_API_TABLE_SCAN_COUNT_SLAVE | 0 | | NDB_API_RANGE_SCAN_COUNT_SLAVE | 0 | | NDB_API_PRUNED_SCAN_COUNT_SLAVE | 0 | | NDB_API_SCAN_BATCH_COUNT_SLAVE | 0 | | NDB_API_READ_ROW_COUNT_SLAVE | 0 | | NDB_API_TRANS_LOCAL_READ_ROW_COUNT_SLAVE | 0 | | NDB_API_WAIT_EXEC_COMPLETE_COUNT | 4 | | NDB_API_WAIT_SCAN_RESULT_COUNT | 3 | | NDB_API_WAIT_META_REQUEST_COUNT | 28 | | NDB_API_WAIT_NANOS_COUNT | 53756398 | | NDB_API_BYTES_SENT_COUNT | 1060 | | NDB_API_BYTES_RECEIVED_COUNT | 9724 | | NDB_API_TRANS_START_COUNT | 3 | | NDB_API_TRANS_COMMIT_COUNT | 2 | | NDB_API_TRANS_ABORT_COUNT | 0 | | NDB_API_TRANS_CLOSE_COUNT | 3 | | NDB_API_PK_OP_COUNT | 2 | | NDB_API_UK_OP_COUNT | 0 | | NDB_API_TABLE_SCAN_COUNT | 1 | | NDB_API_RANGE_SCAN_COUNT | 0 | | NDB_API_PRUNED_SCAN_COUNT | 0 | | NDB_API_SCAN_BATCH_COUNT | 0 | | NDB_API_READ_ROW_COUNT | 2 | | NDB_API_TRANS_LOCAL_READ_ROW_COUNT | 2 | | NDB_API_EVENT_DATA_COUNT | 0 | | NDB_API_EVENT_NONDATA_COUNT | 0 | | NDB_API_EVENT_BYTES_COUNT | 0 | +--------------------------------------------+----------------+ 60 rows in set (0.00 sec) Каждый объект Ndb имеет свои собственные счетчики. Приложения NDB API может прочитать значения счетчиков для использования в оптимизации или контроле. Для многопоточных клиентов, которые используют больше, чем один объект Ndb одновременно, также возможно получить суммированное представление о счетчиках от всех объектов Ndb, принадлежащих данному Ndb_cluster_connection. Выставляются четыре набора этих счетчиков. Один набор относится только к текущей сессии, другие 3 глобальны. Это несмотря на то, что их значения могут быть получены как сессия или как глобальные переменные статуса в mysql. Это означает, что определение SESSION или GLOBAL в SHOW STATUS не имеет никакого эффекта на значения, о которых сообщают для переменных статуса статистики API NDB, и значение для каждой из этих переменных то же самое, получено ли значение из эквивалентного столбца таблицы SESSION_STATUS или GLOBAL_STATUS. Счетчики сессии (определенная сессия). Счетчики сессии касаются объектов Ndb, применяемых (только) текущей сессией. Использование таких объектов другими клиентами MySQL не влияет на эти счетчики. Чтобы минимизировать беспорядок со стандартными переменными сеанса MySQL, мы обращаемся к переменным, которые соответствуют этим счетчикам сессии API NDB как к _session с начальным символом подчеркивания. Ведомые счетчики (global). Этот набор счетчиков касается объектов Ndb, используемых ведомым репликации потока SQL, если есть. Если этот mysqld не действует как ведомый репликации или не использует таблицы NDB, тогда все это количество 0. Мы обращаемся к связанным переменным статуса как к _slave (с начальным символом подчеркивания). Счетчики инжектора (global). Счетчики инжектора касаются объектов Ndb, используемых, чтобы слушать события кластера двоичного потоком инжектора регистрации. Если mysqld не пишет двоичный журнал, он все равно продолжает прислушиваться к некоторым событиям, таким как изменение схемы. Мы обращаемся к переменным статуса, которые соответствуют счетчикам инжектора API NDB как к _injector (с начальным символом подчеркивания). Серверные (глобальные) счетчики (global). Этот набор счетчиков касается всех объектов Ndb, которые в настоящее время используются этим mysqld. Это включает все клиентские приложения MySQL, ведомый поток SQL (если есть), инжектор двоичного журнала и сервисный поток NDB. Мы обращаемся к переменным статуса, которые соответствуют этим счетчикам, как к глобальным переменным или переменным уровняmysqld . Можно получить значения для определенного набора переменных, дополнительно фильтруя по подстроке session, slave или injector в имени переменной (наряду с общим префиксом Ndb_api). Для переменных _session это может быть сделано как показано здесь: mysql> SHOW STATUS LIKE 'ndb_api%session'; +--------------------------------------------+---------+ | Variable_name | Value | +--------------------------------------------+---------+ | Ndb_api_wait_exec_complete_count_session | 2 | | Ndb_api_wait_scan_result_count_session | 0 | | Ndb_api_wait_meta_request_count_session | 1 | | Ndb_api_wait_nanos_count_session | 8144375 | | Ndb_api_bytes_sent_count_session | 68 | | Ndb_api_bytes_received_count_session | 84 | | Ndb_api_trans_start_count_session | 1 | | Ndb_api_trans_commit_count_session | 1 | | Ndb_api_trans_abort_count_session | 0 | | Ndb_api_trans_close_count_session | 1 | | Ndb_api_pk_op_count_session | 1 | | Ndb_api_uk_op_count_session | 0 | | Ndb_api_table_scan_count_session | 0 | | Ndb_api_range_scan_count_session | 0 | | Ndb_api_pruned_scan_count_session | 0 | | Ndb_api_scan_batch_count_session | 0 | | Ndb_api_read_row_count_session | 1 | | Ndb_api_trans_local_read_row_count_session | 1 | +--------------------------------------------+---------+ 18 rows in set (0.50 sec) Чтобы получить список переменных статуса уровня mysqld, отфильтруйте для начала имен переменной ndb_api, которые кончаются на _count: mysql> SELECT * FROM INFORMATION_SCHEMA.SESSION_STATUS WHERE VARIABLE_NAME LIKE 'ndb_api%count'; +------------------------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +------------------------------------+----------------+ | NDB_API_WAIT_EXEC_COMPLETE_COUNT | 4 | | NDB_API_WAIT_SCAN_RESULT_COUNT | 3 | | NDB_API_WAIT_META_REQUEST_COUNT | 28 | | NDB_API_WAIT_NANOS_COUNT | 53756398 | | NDB_API_BYTES_SENT_COUNT | 1060 | | NDB_API_BYTES_RECEIVED_COUNT | 9724 | | NDB_API_TRANS_START_COUNT | 3 | | NDB_API_TRANS_COMMIT_COUNT | 2 | | NDB_API_TRANS_ABORT_COUNT | 0 | | NDB_API_TRANS_CLOSE_COUNT | 3 | | NDB_API_PK_OP_COUNT | 2 | | NDB_API_UK_OP_COUNT | 0 | | NDB_API_TABLE_SCAN_COUNT | 1 | | NDB_API_RANGE_SCAN_COUNT | 0 | | NDB_API_PRUNED_SCAN_COUNT | 0 | | NDB_API_SCAN_BATCH_COUNT | 0 | | NDB_API_READ_ROW_COUNT | 2 | | NDB_API_TRANS_LOCAL_READ_ROW_COUNT | 2 | | NDB_API_EVENT_DATA_COUNT | 0 | | NDB_API_EVENT_NONDATA_COUNT | 0 | | NDB_API_EVENT_BYTES_COUNT | 0 | +------------------------------------+----------------+ 21 rows in set (0.09 sec) Не все счетчики отражены во всех 4 наборах переменных статуса. Для счетчиков события DataEventsRecvdCount, NondataEventsRecvdCount и EventBytesRecvdCount доступны только переменные статуса _injector и уровень mysqld NDB API: mysql> SHOW STATUS LIKE 'ndb_api%event%'; +--------------------------------------+-------+ | Variable_name | Value | +--------------------------------------+-------+ | Ndb_api_event_data_count_injector | 0 | | Ndb_api_event_nondata_count_injector | 0 | | Ndb_api_event_bytes_count_injector | 0 | | Ndb_api_event_data_count | 0 | | Ndb_api_event_nondata_count | 0 | | Ndb_api_event_bytes_count | 0 | +--------------------------------------+-------+ 6 rows in set (0.00 sec) Переменные статуса _injector не осуществляются ни для каких других счетчиков API NDB, как показано здесь: mysql> SHOW STATUS LIKE 'ndb_api%injector%'; +--------------------------------------+-------+ | Variable_name | Value | +--------------------------------------+-------+ | Ndb_api_event_data_count_injector | 0 | | Ndb_api_event_nondata_count_injector | 0 | | Ndb_api_event_bytes_count_injector | 0 | +--------------------------------------+-------+ 3 rows in set (0.00 sec) Названия переменных статуса могут легко быть связаны с названиями соответствующих счетчиков. Каждый счетчик статистики API NDB перечисляется в следующей таблице с описанием, а также названиями любых переменных статуса сервера MySQL, соответствующих ему. Таблица 7.62. Счетчики статистики NDB API Имя счетчика Описание Переменные статуса (статистический тип): Session Slave Injector Server WaitExecCompleteCount Сколько раз поток был заблокирован, ожидая выполнения операции. Включает все вызовы execute(), а также неявные выполнения для blob и auto-increment, невидимый клиентам. Ndb_api_wait_exec_complete_count_session Ndb_api_wait_exec_complete_count_slave [none] Ndb_api_wait_exec_complete_count WaitScanResultCount Сколько раз поток был заблокирован, ожидая основанного на просмотре сигнала, дополнительных результатов или закрытия просмотра. Ndb_api_wait_scan_result_count_session Ndb_api_wait_scan_result_count_slave [none] Ndb_api_wait_scan_result_count WaitMetaRequestCount Сколько раз поток был заблокирован, ожидая основанного на метаданных сигнала, это может произойти, ожидая операции DDL или в течение эпохи, которая будет начата (или закончена). Ndb_api_wait_meta_request_count_session Ndb_api_wait_meta_request_count_slave [none] Ndb_api_wait_meta_request_count WaitNanosCount Полное время (в наносекундах), потраченное на ожидание некоторого типа сигнала от узлов данных. Ndb_api_wait_nanos_count_session Ndb_api_wait_nanos_count_slave [none] Ndb_api_wait_nanos_count BytesSentCount Объем данных (в байтах), посланный в узлы данных Ndb_api_bytes_sent_count_session Ndb_api_bytes_sent_count_slave [none] Ndb_api_bytes_sent_count BytesRecvdCount Объем данных (в байтах), полученный от узлов данных Ndb_api_bytes_received_count_session Ndb_api_bytes_received_count_slave [none] Ndb_api_bytes_received_count TransStartCount Количество транзакций начато. Ndb_api_trans_start_count_session Ndb_api_trans_start_count_slave [none] Ndb_api_trans_start_count TransCommitCount Количество транзакций передано. Ndb_api_trans_commit_count_session Ndb_api_trans_commit_count_slave [none] Ndb_api_trans_commit_count TransAbortCount Количество транзакций прервано. Ndb_api_trans_abort_count_session Ndb_api_trans_abort_count_slave [none] Ndb_api_trans_abort_count TransCloseCount Количество транзакций прерывается. Это значение может быть больше, чем сумма TransCommitCount и TransAbortCount. Ndb_api_trans_close_count_session Ndb_api_trans_close_count_slave [none] Ndb_api_trans_close_count PkOpCount Количество операций на основе или использующих первичные ключи. Это количество включает операции по таблице с частями blob, неявные открывающие операции и операции автоприращения, а также операции по первичному ключу, обычно видимые клиентам MySQL. Ndb_api_pk_op_count_session Ndb_api_pk_op_count_slave [none] Ndb_api_pk_op_count UkOpCount Количество операций на основе или использующих уникальные ключи. Ndb_api_uk_op_count_session Ndb_api_uk_op_count_slave [none] Ndb_api_uk_op_count TableScanCount Количество сканирований таблицы, которые были начаты. Это включает просмотры внутренних таблиц. Ndb_api_table_scan_count_session Ndb_api_table_scan_count_slave [none] Ndb_api_table_scan_count RangeScanCount Количество просмотров диапазона, которые были начаты. Ndb_api_range_scan_count_session Ndb_api_range_scan_count_slave [none] Ndb_api_range_scan_count PrunedScanCount Количество просмотров, которые были сокращены к единственному разделу. Ndb_api_pruned_scan_count_session Ndb_api_pruned_scan_count_slave [none] Ndb_api_pruned_scan_count ScanBatchCount Количество пакетов строк получено (пакет в этом контексте это набор результатов просмотра единственного фрагмента) Ndb_api_scan_batch_count_session Ndb_api_scan_batch_count_slave [none] Ndb_api_scan_batch_count ReadRowCount Общее количество строк, которые были прочитаны. Включает строки, прочитанные, используя первичный ключ, уникальный ключ и операции по просмотру. Ndb_api_read_row_count_session Ndb_api_read_row_count_slave [none] Ndb_api_read_row_count TransLocalReadRowCount Количество строк, прочитанных из того же самого узла данных, на котором управляли транзакцией. Ndb_api_trans_local_read_row_count_session Ndb_api_trans_local_read_row_count_slave [none] Ndb_api_trans_local_read_row_count DataEventsRecvdCount Количество событий изменения строки. [none] [none] Ndb_api_event_data_count_injector Ndb_api_event_data_count NondataEventsRecvdCount Количество полученных событий, кроме изменений строки. [none] [none] Ndb_api_event_nondata_count_injector Ndb_api_event_nondata_count EventBytesRecvdCount Число байтов событий получено. [none] [none] Ndb_api_event_bytes_count_injector Ndb_api_event_bytes_count Чтобы видеть все количество переданных транзакций то есть, все переменные статуса TransCommitCount, можно отфильтровать результаты SHOW STATUS по подстроке trans_commit_count: mysql> SHOW STATUS LIKE '%trans_commit_count%'; +------------------------------------+-------+ | Variable_name | Value | +------------------------------------+-------+ | Ndb_api_trans_commit_count_session | 1 | | Ndb_api_trans_commit_count_slave | 0 | | Ndb_api_trans_commit_count | 2 | +------------------------------------+-------+ 3 rows in set (0.00 sec) От этого можно решить, что 1 транзакция была передана в текущей сессии клиента mysql и 2 транзакции были переданы на этом mysqld после последнего перезапуска. Вы видите, как различные счетчики API NDB увеличены данным SQL-оператором, сравнив значения _session прежде и немедленно после выполнения запроса. В этом примере после получения начальных значений от SHOW STATUS, мы создаем в БД test таблицу NDB с именем t, у которой есть столбец: mysql> SHOW STATUS LIKE 'ndb_api%session%'; +--------------------------------------------+--------+ | Variable_name | Value | +--------------------------------------------+--------+ | Ndb_api_wait_exec_complete_count_session | 2 | | Ndb_api_wait_scan_result_count_session | 0 | | Ndb_api_wait_meta_request_count_session | 3 | | Ndb_api_wait_nanos_count_session | 820705 | | Ndb_api_bytes_sent_count_session | 132 | | Ndb_api_bytes_received_count_session | 372 | | Ndb_api_trans_start_count_session | 1 | | Ndb_api_trans_commit_count_session | 1 | | Ndb_api_trans_abort_count_session | 0 | | Ndb_api_trans_close_count_session | 1 | | Ndb_api_pk_op_count_session | 1 | | Ndb_api_uk_op_count_session | 0 | | Ndb_api_table_scan_count_session | 0 | | Ndb_api_range_scan_count_session | 0 | | Ndb_api_pruned_scan_count_session | 0 | | Ndb_api_scan_batch_count_session | 0 | | Ndb_api_read_row_count_session | 1 | | Ndb_api_trans_local_read_row_count_session | 1 | +--------------------------------------------+--------+ 18 rows in set (0.00 sec) mysql> USE test; Database changed mysql> CREATE TABLE t (c INT) ENGINE NDBCLUSTER; Query OK, 0 rows affected (0.85 sec) Теперь можно выполнить новый SHOW STATUS и наблюдать изменения, как показано здесь: mysql> SHOW STATUS LIKE 'ndb_api%session%'; +--------------------------------------------+-----------+ | Variable_name | Value | +--------------------------------------------+-----------+ | Ndb_api_wait_exec_complete_count_session | 8 | | Ndb_api_wait_scan_result_count_session | 0 | | Ndb_api_wait_meta_request_count_session | 17 | | Ndb_api_wait_nanos_count_session | 706871709 | | Ndb_api_bytes_sent_count_session | 2376 | | Ndb_api_bytes_received_count_session | 3844 | | Ndb_api_trans_start_count_session | 4 | | Ndb_api_trans_commit_count_session | 4 | | Ndb_api_trans_abort_count_session | 0 | | Ndb_api_trans_close_count_session | 4 | | Ndb_api_pk_op_count_session | 6 | | Ndb_api_uk_op_count_session | 0 | | Ndb_api_table_scan_count_session | 0 | | Ndb_api_range_scan_count_session | 0 | | Ndb_api_pruned_scan_count_session | 0 | | Ndb_api_scan_batch_count_session | 0 | | Ndb_api_read_row_count_session | 2 | | Ndb_api_trans_local_read_row_count_session | 1 | +--------------------------------------------+-----------+ 18 rows in set (0.00 sec) Точно так же вы видите изменения в счетчиках статистики API NDB, вызванных, вставляя строку в t: вставьте строку, затем управляйте тем же самым SHOW STATUS, который используется в предыдущем примере, как показано здесь: mysql> INSERT INTO t VALUES (100); Query OK, 1 row affected (0.00 sec) mysql> SHOW STATUS LIKE 'ndb_api%session%'; +--------------------------------------------+-----------+ | Variable_name | Value | +--------------------------------------------+-----------+ | Ndb_api_wait_exec_complete_count_session | 11 | | Ndb_api_wait_scan_result_count_session | 6 | | Ndb_api_wait_meta_request_count_session | 20 | | Ndb_api_wait_nanos_count_session | 707370418 | | Ndb_api_bytes_sent_count_session | 2724 | | Ndb_api_bytes_received_count_session | 4116 | | Ndb_api_trans_start_count_session | 7 | | Ndb_api_trans_commit_count_session | 6 | | Ndb_api_trans_abort_count_session | 0 | | Ndb_api_trans_close_count_session | 7 | | Ndb_api_pk_op_count_session | 8 | | Ndb_api_uk_op_count_session | 0 | | Ndb_api_table_scan_count_session | 1 | | Ndb_api_range_scan_count_session | 0 | | Ndb_api_pruned_scan_count_session | 0 | | Ndb_api_scan_batch_count_session | 0 | | Ndb_api_read_row_count_session | 3 | | Ndb_api_trans_local_read_row_count_session | 2 | +--------------------------------------------+-----------+ 18 rows in set (0.00 sec) Мы можем сделать много наблюдений из этих результатов: Хотя мы создали t без явного первичного ключа 5 операций по первичному ключу были выполнены при этом (различие в значениях до и после для Ndb_api_pk_op_count_session или 6-1). Это отражает создание скрытого первичного ключа, который является особенностью всех таблиц, использующих NDB. Сравнивая последовательные значения для Ndb_api_wait_nanos_count_session, мы видим, что операции API NDB, осуществляющие CREATE TABLE, ждали намного дольше (706871709 - 820705 = 706051004 наносекунд или приблизительно 0.7 секунды) для ответов от узлов данных, чем выполненные INSERT (707370418 - 706871709 = 498709 ns или округленно 0.0005 секунды). Время выполнения, о котором сообщают для этих запросов в mysql, коррелирует примерно с этими числами. На платформах без достаточного (наносекунда) разрешения времени, небольшие изменения в значениях счетчика NDB API WaitNanosCount из-за SQL-операторов, которые выполняются очень быстро, могут не всегда быть видимы в значениях Ndb_api_wait_nanos_count_session, Ndb_api_wait_nanos_count_slave или Ndb_api_wait_nanos_count. INSERT увеличивает оба ReadRowCount и TransLocalReadRowCount счетчика статистики NDB API, как отражено увеличенными значениями Ndb_api_read_row_count_session и Ndb_api_trans_local_read_row_count_session.