Управление NDB Cluster включает много задач, первая из которых должна сформировать и запустить NDB Cluster. См. главы 5 и 6.
Следующие несколько секций покрывают управление NDB Cluster.
Для получения информации о проблемах безопасности, касающихся управления и развертывания кластера NDB, посмотрите раздел 7.12.
Есть по существу два метода активного управления NDB Cluster.
Первый из них с помощью команд клиента управления, посредством чего статус
кластера может быть проверен, изменены уровни регистрации, резервные копии
начаты и остановлены и запущены или остановлены узлы. Второй метод включает
изучение содержания регистрации кластера
ndb_
, это обычно находится в каталоге
node_id
_cluster.logDataDir
сервера управления,
но это местоположение может быть отвергнуто, используя опцию
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.
Эта секция обеспечивает упрощенную схему шагов, когда узлы данных
NDB Cluster начаты. Более полная информация может быть найдена в
NDB Cluster Start Phases в
NDB
Internals Guide.
Эти фазы совпадают с теми, о которых сообщают в выводе
в клиенте управления (см.
раздел 7.2).
Об этих фазах начала также сообщают в столбце
node_id
STATUSstart_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
.
После того, как этот процесс закончен для начального или системного перезапуска, операционная обработка позволена. Для перезапуска узла или начального перезапуска узла завершение процесса запуска означает, что узел может теперь действовать как операционный координатор.
В дополнение к центральному конфигурационному файлу кластером можно также управлять через интерфейс командной строки, доступный через клиент управления 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
, которое указывает, что команда должна быть
применена ко всем узлам данных кластера.
Информация обо всех доступных командах.
Соединяется с сервером управления, обозначенным строкой подключения. Если клиент уже связан с этим сервером, клиент снова соединяется.
Информация о статусе кластера. Возможные значения статуса узла включают
UNKNOWN
, NO_CONTACT
,
NOT_STARTED
,
STARTING
, STARTED
,
SHUTTING_DOWN
и
RESTARTING
.
Вывод этой команды также указывает, когда кластер находится в
однопользовательском режиме (статус
SINGLE USER MODE
).
Получает онлайн узел данных, определенный
node_id
(или все сразу).
ALL START
работает только со всеми узлами данных и не затрагивает узлы управления.
Чтобы использовать эту команду, чтобы получить
узел данных онлайн, узел данных должен быть запущен, используя опцию
--nostart
или -n
.
Останавливает узел данных или управления, определенный
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_id
(или для всех).
Вывод этой команды также указывает, когда кластер находится в однопользовательском режиме.
Показывает сообщение о типе
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
,
может получить доступ к базе данных.
Выход из однопользовательского режима, позволяя всем узлам SQL (то есть, всем процессам mysqld) получить доступ к базе данных.
Возможно использовать EXIT SINGLE USER MODE
даже когда кластер не в однопользовательском режиме, хотя команда не имеет
никакого эффекта в этом случае.
Завершает клиент управления.
Эта команда не затрагивает узлов, связанных с кластером.
Закрывает все узлы данных и узлы управления. Чтобы выйти из клиента
управления после этого, надо использовать
EXIT
или
QUIT
.
Эта команда не закрывает узлов SQL или узлов API, которые связаны с кластером.
CREATE NODEGROUP
nodeid
[,
nodeid
, ...]
Создает новую группу узлов NDB Cluster и заставляет узлы данных присоединяться к ней.
Эта команда используется после добавления новых узлов данных онлайн к кластеру NDB и заставляет их присоединяться к новой группе узлов и таким образом начинать участвовать полностью в кластере. Команда берет в качестве параметра список разделенных запятой значений ID узлов, добавленных и запущенных, которые должны присоединиться к новой группе узлов. Количество узлов должно совпасть с количеством узлов в каждой группе, которая уже является частью кластера (у каждой группы узлов кластера NDB должно быть то же самое количество узлов). Другими словами, если у кластера NDB есть 2 группы из 2 узлов данных каждая, то у новой группы должно также быть 2 узла данных.
ID новой группы, созданной этой командой, определяется автоматически, и это всегда следующая самый большой неиспользованный ID, невозможно установить его вручную.
См. раздел 7.15 .
Удаляет группу узлов 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 .
Изменяет приглашение в
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.
Следующие несколько секций описывают, как подготовиться и затем создать резервную копию кластера NDB с использованием функциональности, с этой целью найденной в клиенте управления ndb_mgm. Чтобы отличить этот тип резервной копии от резервной копии сделанной, используя mysqldump, мы иногда именуем ее как native резервную копию кластера NDB Cluster. Для получения информации о создании резервных копий с помощью mysqldump см. mysqldump A Database Backup Program. Восстановление резервных копий кластера NDB сделано, используя утилиту ndb_restore, которую предоставляет дистрибутив NDB Cluster, см. ndb_restore. О ее использовании в восстановлении резервных копий кластера NDB посмотрите раздел 6.24.
Резервная копия это снимок базы данных в установленный срок. Резервная копия состоит из трех главных частей:
Метаданные. Имена и определения всех таблиц базы данных
Записи таблицы. Данные, сохраненные в таблицах базы данных в то время, когда резервная копия была сделана
Журнал транзакций. Последовательный отчет, говорящий, как и когда данные хранились в базе данных
Каждая из этих частей сохранена на всех узлах, участвующих в резервной копии. Во время резервной копии каждый узел пишет эти три части в три файла на диске:
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.3.
Команда START BACKUP
используется, чтобы создать резервную копию:
START BACKUP [backup_id
] [wait_option
] [snapshot_option
]wait_option
: WAIT {STARTED | COMPLETED} | NOWAITsnapshot_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>
Когда резервная копия началась, клиент управления покажет это сообщение:
Backupbackup_id
started from nodenode_id
backup_id
это
уникальный идентификатор для этой конкретной резервной копии.
Этот идентификатор соханен в журнале кластера, если не настроено иначе.
node_id
это идентификатор сервера
управления, который координирует резервную копию с узлами данных.
В этом пункте в процессе резервного копирования кластер получил и обработал
запрос. Это не означает, что резервная копия закончилась.
Пример этого запроса:
Node 2: Backup 1 started from node 1
Клиент управления указывает в сообщении, что резервная копия началась:
Backupbackup_id
started from nodenode_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
, клиент управления не делает
ответа, и при этом это не обозначает в регистрации кластера, что послали
недействительную команду аварийного прекращения работы.
Пять параметров конфигурации важны для резервной копии:
Объем памяти для буферизации данных, прежде чем они будут записаны на диск.
Объем памяти для буферизации записей журнала, прежде чем они будут записаны на диск.
Общая память ассигнуется в узле данных для резервных копий. Это должно быть суммой памяти, ассигнованной для буфера данных резервного копирования и буфера журнала резервного копирования.
Размер по умолчанию блоков записи на диск. Это применяется к буферу данных резервного копирования и буферу журнала резервного копирования.
Максимальный размер блока записи на диск. Это применяется к буферу данных резервного копирования и буферу журнала резервного копирования.
См. подробности здесь.
Можно также установить местоположение для резервных файлов, используя
BackupDataDir
. По умолчанию
FileSystemPath
/BACKUP/BACKUP-
.backup_id
Если код ошибки возвращен в ответ на запрос, наиболее вероятная причина в том, что недостаточно памяти или дискового пространства. Необходимо проверить, что есть достаточно памяти, ассигнованной для резервной копии.
Если вы установили
BackupDataBufferSize
,
BackupLogBufferSize
и их сумму в больше, чем
4MB, необходимо также установить
BackupMemory
.
Необходимо также удостовериться, что есть достаточное пространство на разделе жесткого диска.
NDB
не поддерживает повторяемое чтение, что
может вызвать проблемы с процессом восстановления. Хотя процесс резервного
копирования горячий, восстановление
NDB Cluster из резервной копии не является 100% горячим
. Это вследствие того, что на время восстановления
транзакции получают неповторяемые чтения от восстановленных данных.
Это означает, что статус данных непоследовательный
в то время, как происходит восстановление.
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
.
Эта секция обсуждает, как выполнить катящийся перезапуск NDB Cluster, именуемый так потому, что он включает остановку и старт (или перезапуск) каждого узла в свою очередь, чтобы сам кластер остался готовым к эксплуатации. Это часто делается как часть катящейся модернизации, где высокая доступность кластера обязательна, и никакое время простоя кластера в целом недопустимо.
Есть много причин, почему катящийся перезапуск мог бы быть желательным. Они описаны в следующих нескольких параграфах.
Изменение конфигурации. Чтобы вносить изменение в конфигурации кластера, такое как добавление узла SQL к кластеру или урегулирование параметра конфигурации к новому значению.
Обновление программного обеспечения кластера NDB. Чтобы модернизировать кластер до более новой версии программного обеспечения NDB Cluster (или понизить его до более старой версии). Это обычно упоминается как катящаяся модернизация).
Изменение на хосте узла. Чтобы вносить изменения в аппаратной или операционной системе, на которой работает процессы узла кластера NDB.
Системный перезапуск. Чтобы перезапустить кластер, потому что это достигло нежелательного статуса. В таких случаях часто желательно перезагрузить данные и метаданные одного или более узлов данных. Это может быть сделано любым из трех способов:
Начните каждый процесс узла данных
(
ndbd или
ndbmtd) с опцией
--initial
, которая вынуждает узел данных очистить свою файловую
систему и перезагрузить все данные
и метаданные от других узлов данных.
Создайте резервную копию, используя в клиенте
ndb_mgm команду
START BACKUP
до выполнения перезапуска. После модернизации восстановите узел или узлы,
используя
ndb_restore.
Используйте команду 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.
В этой секции мы обсуждаем типы журналов событий, предоставленных кластером NDB, и типы событий, которые зарегистрированы.
NDB Cluster обеспечивает два типа журнала событий:
Регистрация кластера, которая включает события, произведенные всеми узлами кластера. Регистрация кластера это регистрация, рекомендуемая для большей части использования, потому что это предоставляет информацию для всего кластера в единственном месте.
По умолчанию регистрация кластера сохранена в файле
ndb_
,
(где node_id
_cluster.lognode_id
ID
узла сервера управления) в каталоге
DataDir
сервера управления.
Информацию о регистрации кластера можно также послать в
stdout
или syslog
в дополнение или вместо того, чтобы писать данные в файл, как определено
набором значений для
DataDir
и
LogDestination
. См.
раздел 5.3.5.
Регистрации узла локальна для каждого узла.
Вывод, произведенный регистрацией событий узла, написан в файл
ndb_
(где node_id
_out.lognode_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 узла, сообщающего о событии.
Описание события. Наиболее распространенные типы событий, чтобы появиться в регистрации являются связями и разъединениями между различными узлами в кластере, и когда контрольные точки происходят. В некоторых случаях описание может содержать информацию о статусе.
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, связанного с одним
сервером управления, затрагивает только регистрации, произведенные тем
сервером управления, но не любыми другими.
Отчет событий, о котором сообщают в конечном счете, имеет следующий формат:
datetime [string] severity -- message
Например:
09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed
Эта секция обсуждает все заслуживающие публикации события, упорядоченные по категориям и уровню серьезности в каждой категории.
В описании GCP и LCP означают Global Checkpoint и Local Checkpoint.
Эти события связаны со связями между узлами кластера.
Таблица 7.3. События, связанные со связями между узлами кластера
Событие | Приоритет | Важность | Описание |
---|---|---|---|
Connected |
8 | INFO |
Узлы данных связаны |
Disconnected |
8 | ALERT |
Узлы данных разъединены |
CommunicationClosed |
8 | INFO |
Узел SQL или данных закрыл связь |
CommunicationOpened |
8 | INFO |
Узел SQL или данных открыл связь |
ConnectedApiVersion |
8 | INFO |
Связь использует версию API |
Регистрирующиеся сообщения, показанные здесь, связаны с контрольными точками.
Таблица 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 |
Следующие события произведены в ответ на запуск узла или кластера и его успешности или неуспешности. Они также предоставляют информацию, касающуюся прогресса процесса запуска, включая информацию относительно регистрирующихся действий.
Таблица 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 |
Восстановление индексов |
Следующие события произведены, перезапуская узел и касаются успешности или неуспешности процесса перезапуска узла.
Таблица 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 |
Отчет, найден ли арбитр или нет,
есть семь различных возможных исходов, ища арбитра, перечисленные здесь:
|
ArbitResult |
2 | ALERT |
Сообщите о результатах арбитра, есть восемь различных возможных
результатов для арбитражных попыток, перечисленные здесь:
|
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 |
Фаза неудачи узла потерпела неудачу |
Следующие события имеют статистическую природу. Они предоставляют информацию, такую как числа транзакций и других операций, объем данных, посланный или полученный отдельными узлами, и использование памяти.
Таблица 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 |
Многопоточные сигналы |
Эти события касаются операций по схеме кластера NDB.
Таблица 7.8. События, касающиеся операций по схеме кластера NDB
Событие | Приоритет | Важность | Описание |
---|---|---|---|
CreateSchemaObject |
8 | INFO |
Схема создана |
AlterSchemaObject |
8 | INFO |
Объект схемы обновляется |
DropSchemaObject |
8 | INFO |
Объект схемы удален |
Эти события касаются ошибок кластера и предупреждений. Присутствие одного или больше из них обычно указывает, что произошел сбой.
Таблица 7.9. События, касающиеся ошибок кластера и предупреждений
Событие | Приоритет | Важность | Описание |
---|---|---|---|
TransporterError |
2 | ERROR |
Ошибка транспортера |
TransporterWarning |
8 | WARNING |
Предупреждение транспортера |
MissedHeartbeat |
8 | WARNING |
Узел X пропустил
Y | синхроимпульсов
DeadDueToHeartbeat |
8 | ALERT |
Узел X объявлен
мертвым из-за пропущенного синхроимпульса |
WarningEvent |
2 | WARNING |
Общее событие предупреждения |
SubscriptionStatus |
4 | WARNING |
Изменение в подписном статусе |
Эти события предоставляют общую информацию о статусе кластера и действий, связанных с обслуживанием кластера, таких как передача регистрации и синхроимпульсов.
Таблица 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
.
Эти события связаны с входом и выходом из однопользовательского режима.
Таблица 7.11. События, касающиеся однопользовательского режима
Событие | Приоритет | Важность | Описание |
---|---|---|---|
SingleUser |
7 | INFO |
Вход или выход из однопользовательского режима |
Эти события предоставляют информацию о резервных копиях, создаваемых или восстановленных.
Таблица 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 |
Событие сохранено |
Клиент управления 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.
Эта секция содержит информацию о сообщениях, написанных регистрации
кластера в ответ на различные события кластера. Это предоставляет
дополнительную более определенную информацию об ошибках транспортера
NDB
.
В следующей таблице перечислены наиболее распространенные сообщения кластера. Для получения информации о регистрации кластера, событиях регистрации и типах событий см. раздел 7.6. Эти сообщения регистрации также соответствуют типам событий регистрации в MGM API, посмотрите The Ndb_logevent_type Type.
Таблица 7.13. Общие сообщения регистрации NDB cluster
Сообщение | Описание | Событие | Тип | Приоритет | Важность |
---|---|---|---|---|---|
Node
|
Узел данных, имеющий ID узла
node_id ,
соединился с сервером управления (узел
mgm_node_id ). |
Connected |
Connection |
8 | INFO |
Node |
Узел данных, имеющий ID узла
data_node_id ,
разъединился от сервера управления (узел
mgm_node_id ). |
Disconnected |
Connection |
8 | ALERT |
Node
|
Узел API или узел SQL, имеющий ID узла
api_node_id
больше не общается с узлом данных
data_node_id . |
CommunicationClosed |
Connection |
8 | INFO |
Node
|
Узел API или узел SQL, имеющий ID узла
api_node_id
теперь общается с узлом данных
data_node_id . |
CommunicationOpened |
Connection |
8 | INFO |
Node |
Узел API, имеющий ID узла
api_node_id
соединился с узлом управления
mgm_node_id через
NDB API версии
version (обычно то же самое,
как номер версии MySQL). |
ConnectedApiVersion |
Connection | 8 | INFO |
Node |
Глобальная контрольная точка с ID
gci была начата, узел
node_id отвечает за эту
глобальную контрольную точку. |
GlobalCheckpointStarted |
Checkpoint |
9 | INFO |
Node |
Глобальная контрольная точка, имеющая ID
gci была закончена, узел
node_id
отвечал за эту глобальную контрольную точку. |
GlobalCheckpointCompleted |
Checkpoint |
10 | INFO |
Node
|
Местная контрольная точка, имеющая ID
lcp начата на узле
node_id .
У нового GCI, который может использоваться, есть индекс
current_gci
и у самого старого GCI, от которого может быть восстановлен
кластер, есть индекс old_gci . |
LocalCheckpointStarted |
Checkpoint |
7 | INFO |
Node
|
Местная контрольная точка, имеющая ID
lcp на узле node_id
успешно закончена. |
LocalCheckpointCompleted |
Checkpoint |
8 | INFO |
Node |
Узел был неспособен определить новый применимый GCI. | LCPStoppedInCalcKeepGci |
Checkpoint |
0 | ALERT |
Node
|
Фрагмент таблицы был сброшен на диск на узле
node_id .
У происходящего GCI есть индекс
started_gci
и у нового GCI, который был закончен, есть индекс
completed_gci . |
LCPFragmentCompleted |
Checkpoint |
11 | INFO |
Node
|
Регистрация отмен заблокирована, потому что буфер регистрации близок к переполнению. | UndoLogBlocked |
Checkpoint |
7 | INFO |
Node |
Узел данных node_id , работающий
с NDB версии
version , начал запуск. |
NDBStartStarted |
StartUp |
1 | INFO |
Node
|
Узел данных node_id ,
работающий с NDB версии
version , успешно запущен. |
NDBStartCompleted |
StartUp |
1 | INFO |
Node |
Узел получил сигнал, указывающий, что перезапуск кластера закончен. | STTORRYRecieved |
StartUp |
15 | INFO |
Node |
Узел закончил фазу запуска phase
из type .
Для списка фаз посмотрите
раздел 7.1.
(type одно из
initial , system ,
node , initial node ,
или <Unknown> ). |
StartPhaseCompleted |
StartUp |
4 | INFO |
Node
|
Узел president_id
был отобран как president.
own_id и
dynamic_id должны всегда совпадать
с ID (node_id ) узла сообщения. |
CM_REGCONF |
StartUp |
3 | INFO |
Node
|
Узел сообщения (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
|
Узел обнаружил свои соседние узлы в кластере (узлы
id_1 и
id_2 ).
node_id ,
own_id и
dynamic_id
должны всегда быть теми же самыми, если это не так, это указывает на
серьезную неверную конфигурацию узлов кластера. |
FIND_NEIGHBOURS |
StartUp |
8 | INFO |
Node |
Узел получил сигнал закрытия.
type закрытия также
Cluster или
Node . |
NDBStopStarted |
StartUp |
1 | INFO |
Node [,
]
[Initiated by signal
] |
Узел был закрыт. Этот доклад может включать в себя
action ,
который, если существует, один из
restarting , no
start или initial .
Доклад может также включать в себя ссылку на
NDB Protocol
signal , см.
Operations and Signals. |
NDBStopCompleted |
StartUp |
1 | INFO |
Node
[,
action ]. [Occurred
during startphase
]
[ Initiated by
]
[Caused by error
[(extra info
]] |
Узел был принудительно закрыт.
action (одно из
restarting , no
start , or initial ) также указан, если
есть. Если закрытие произошло в то время, как узел запускался, доклад
включает в себя start_phase
во время которой потерпел неудачу узел. Если это было результатом
отправки узлу сигнала signal ,
эта информация также предоставляется (см.
Operations and Signals).
Если ошибка, вызвавшая сбой, известна, это также включено, см.
NDB Cluster API Errors. |
NDBStopForced |
StartUp |
1 | ALERT |
Node |
Процесс закрытия узла был прерван пользователем. | NDBStopAborted |
StartUp |
1 | INFO |
Node
|
Это сообщает о глобальных контрольных точках, на которые ссылаются во
время запуска узла. Журнал отката до keep_pos
удален. last_pos
это последняя глобальная контрольная точка, в которой узел данных участвовал,
restore_pos это глобальная
контрольная точка, которая на самом деле используется, чтобы восстановить
все узлы данных. |
StartREDOLog |
StartUp |
4 | INFO |
startup_message
[Listed separately; see below.] |
Есть много возможных сообщений запуска, которые могут быть зарегистрированы при различных обстоятельствах. Они перечисляются отдельно, см. раздел 7.7.2. | StartReport |
StartUp |
4 | INFO |
Node |
Копирование информации словаря данных перезапущенному узлу было закончено. | NR_CopyDict |
NodeRestart |
8 | INFO |
Node |
Копирование информации о распределении данных перезапущенному узлу было закончено. | NR_CopyDistr |
NodeRestart |
8 | INFO |
Node |
Копирование фрагментов к запускаемому узлу данных
node_id началось |
NR_CopyFragsStarted |
NodeRestart |
8 | INFO |
Node |
Фрагмент fragment_id таблицы
table_id скопирован узлу данных
node_id |
NR_CopyFragDone |
NodeRestart |
10 | INFO |
Node |
Копирование всех фрагментов таблицы перезапускаемому узлу данных
node_id завершено |
NR_CopyFragsCompleted |
NodeRestart |
8 | INFO |
Node
|
Узел данных node1_id
обнаружил сбой узла данных node2_id
|
NodeFailCompleted |
NodeRestart |
8 | ALERT |
All nodes completed failure of Node
|
Все (остающиеся) узлы данных обнаружили сбой узла данных
node_id |
NodeFailCompleted |
NodeRestart |
8 | ALERT |
Node failure of
|
Сбой узла данных node_id
был обнаружен в ядерном блоке block
NDB , где block это
1 из DBTC ,
DBDICT , DBDIH или
DBLQH , см.
NDB Kernel Blocks |
NodeFailCompleted |
NodeRestart |
8 | ALERT |
Node
|
Узел данных потерпел неудачу. Его статус во время неудачи описан
арбитражным кодом статуса
state_code ,
возможные статусные кодовые обозначения могут быть найдены в файле
include/kernel/signaldata/ArbitSignalData.hpp . |
NODE_FAILREP |
NodeRestart |
8 | ALERT |
President restarts arbitration
thread [state= or
Prepare arbitrator node
or
Receive arbitrator node
or
Started arbitrator node
or
Lost arbitrator node
or
Lost arbitrator node
or
Lost arbitrator node
|
Это отчет о текущем состоянии и прогрессе арбитража в кластере.
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
or
Arbitration lost - negative reply from node
or
Network partitioning - no arbitrator
available or Network partitioning - no
arbitrator configured or Arbitration
failure - |
Это сообщение сообщает относительно результата арбитража.
В случае арбитражной неудачи
error_message и арбитражный
state_code предоставлены,
определения для обоих из них найдены в
include/kernel/signaldata/ArbitSignalData.hpp . |
ArbitResult |
NodeRestart |
2 | ALERT |
Node |
Этот узел пытается принять на себя ответственность за следующую глобальную контрольную точку (то есть, это становится главным узлом) | GCP_TakeoverStarted |
NodeRestart |
7 | INFO |
Node |
Этот узел стал ведущим и принял на себя ответственность за следующую глобальную контрольную точку | GCP_TakeoverCompleted |
NodeRestart |
7 | INFO |
Node
|
Этот узел пытается принять на себя ответственность за следующий набор местных контрольных точек (то есть, это становится главным узлом) | LCP_TakeoverStarted |
NodeRestart |
7 | INFO |
Node
|
Этот узел стал ведущим и принял на себя ответственность за следующий набор местных контрольных точек | LCP_TakeoverCompleted |
NodeRestart |
7 | INFO |
Node
|
Это сообщение о действии транзакций дано приблизительно один раз в 10 секунд | TransReportCounters |
Statistic |
8 | INFO |
Node |
Количество операций, выполняемых этим узлом, дано приблизительно один раз в 10 секунд | OperationReportCounters |
Statistic |
8 | INFO |
Node |
Таблица, имеющая этот ID, была составлена | TableCreated |
Statistic |
7 | INFO |
Node | JobStatistic |
Statistic |
9 | INFO | |
Mean send size to Node =
|
Этот узел посылает в среднем bytes
байт за передачу узлу node_id
|
SendBytesStatistic |
Statistic |
9 | INFO |
Mean receive size to Node =
|
Этот узел получает в среднем bytes
байт данных каждый раз, когда получает данные от узла
node_id |
ReceiveBytesStatistic |
Statistic |
9 | INFO |
Node
/
Node |
Этот отчет произведен, когда
DUMP 1000
выдается в клиенте управления кластером |
MemoryUsage |
Statistic |
5 | INFO |
Node
|
Ошибка транспортера произошла, общаясь с узлом
node2_id ,
для списка кодов ошибок транспортера и сообщений см.
NDB Transporter Errors в
MySQL NDB Cluster Internals Manual |
TransporterError |
Error |
2 | ERROR |
Node
|
Предупреждение потенциальной проблемы транспортера, общаясь с узлом
node2_id ,
для списка кодов ошибок транспортера и сообщений см.
NDB Transporter Errors |
TransporterWarning |
Error |
8 | WARNING |
Node
|
Этот узел пропустил синхроимпульс от узла
node2_id |
MissedHeartbeat |
Error |
8 | WARNING |
Node
|
Этот узел пропустил по крайней мере 3 синхроимпульса от узла
node2_id и объявлен
мертвым |
DeadDueToHeartbeat |
Error |
8 | ALERT |
Node
|
Этот узел послал синхроимпульс в узел
node2_id |
SentHeartbeat |
Info |
12 | INFO |
(NDB 7.5.0 и ранее) Node
|
Этот отчет создается во время тяжелого использования буфера событий, например, когда много обновлений применяются за относительно короткий период времени, отчет показывает число байтов и процент используемой буферной памяти событий, ассигнованные байты и проценты все еще доступной памяти и последние восстанавливаемые эпохи | EventBufferStatus |
Info |
7 | INFO |
(NDB 7.5.1 и позэе) Node
|
Этот отчет создается во время тяжелого использования буфера событий, например, когда много обновлений применяются за относительно короткий период времени, отчет показывает число байтов и процент используемой буферной памяти событий, ассигнованные байты и проценты все еще доступной памяти и потребляемые эпохи, для получения дополнительной информации посмотрите раздел 7.7.3 | EventBufferStatus2 |
Info |
7 | INFO |
Node
, Node
, Node
|
Эти записи написаны к регистрации кластера, входя и выходя из
однопользовательского режима, API_node_id
это ID API или SQL, имеющего эксклюзивный доступ к кластеру
(для получения дополнительной информации см.
раздел 7.8),
сообщение Unknown single user report
указывает, что ошибка произошла и никогда не должна возникать
при нормальном функционировании |
SingleUser |
Info |
7 | INFO |
Node
|
Резервная копия была начата, используя наличие узла управления
mgm_node_id , это сообщение также
показано в клиенте управления кластером, когда выполняется команда
START BACKUP , см.
раздел 7.3.2 |
BackupStarted |
Backup |
7 | INFO |
Node
|
Резервная копия, имеющая ID backup_id
, закончена, для получения дополнительной информации посмотрите
раздел 7.3.2 |
BackupCompleted |
Backup |
7 | INFO |
Node
|
Резервная копия не началась, для кодов ошибок посмотрите MGM API Errors | BackupFailedToStart |
Backup |
7 | ALERT |
Node
|
Резервная копия была закончена после старта, возможно из-за вмешательства пользователя | BackupAborted |
Backup |
7 | ALERT |
Возможные сообщения запуска с описаниями предоставлены в следующем списке:
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]
NDB
применяет
один или несколько буферов памяти для событий от узлов данных.
Есть один такой буфер для каждого объекта
Ndb
,
подписывающегося на события таблицы, что означает, что обычно есть два буфера
для каждого mysqld
(один буфер для событий схемы, и один для событий данных). Каждый буфер
содержит эпохи, составленные из событий. Эти события состоят из операционных
типов (вставка, обновление, удаление) и данных о строке (перед и после
изменений плюс метаданные).
NDB
производит сообщения в регистрации
кластера, чтобы описать статус этих буферов. Хотя эти записи появляются в
регистрации кластера, они обращаются к буферам на узлах API (в отличие от
большинства других сообщений кластера, которые произведены узлами данных).
Эти сообщения и структуры данных, лежащие в основе их, были изменены
значительно в NDB 7.5.1 с добавлением типа
NDB_LE_EventBufferStatus2
и структуры
ndb_logevent_EventBufferStatus2
(см.
The Ndb_logevent_type Type).
Остаток от этого обсуждения сосредотачивается на внедрении на основе
NDB_LE_EventBufferStatus2
.
Записи о буфере событий в регистрации кластера используют формат, показанный здесь:
Nodenode_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
:
Все полученные эпохи буферизуются, что означает, что есть достаточная
буферная память событий. Разрыв в потоке событий был преодолен.
Эта секция перечисляет коды ошибок, имена и сообщения, которые написаны регистрации кластера в случае ошибок транспортера.
TE_NO_ERROR
No error
TE_ERROR_CLOSING_SOCKET
Error found during closing of socket
TE_ERROR_IN_SELECT_BEFORE_ACCEPT
Error found before accept. The transporter will retry
TE_INVALID_MESSAGE_LENGTH
Error found in message (invalid message length)
TE_INVALID_CHECKSUM
Error found in message (checksum)
TE_COULD_NOT_CREATE_SOCKET
Error found while creating socket (can't create socket)
TE_COULD_NOT_BIND_SOCKET
Error found while binding server socket
TE_LISTEN_FAILED
Error found while listening to server socket
TE_ACCEPT_RETURN_ERROR
Error found during accept (accept return error)
TE_SHM_DISCONNECT
The remote node has disconnected
TE_SHM_IPC_STAT
Unable to check shm segment
TE_SHM_UNABLE_TO_CREATE_SEGMENT
Unable to create shm segment
TE_SHM_UNABLE_TO_ATTACH_SEGMENT
Unable to attach shm segment
TE_SHM_UNABLE_TO_REMOVE_SEGMENT
Unable to remove shm segment
TE_TOO_SMALL_SIGID
Sig ID too small
TE_TOO_LARGE_SIGID
Sig ID too large
TE_WAIT_STACK_FULL
Wait stack was full
TE_RECEIVE_BUFFER_FULL
Receive buffer was full
TE_SIGNAL_LOST_SEND_BUFFER_FULL
Send buffer was full, and trying to force send fails
TE_SIGNAL_LOST
Send failed for unknown reason (signal lost)
TE_SEND_BUFFER_FULL
The send buffer was full, but sleeping for a while solved
TE_SHM_IPC_PERMANENT
Shm ipc Permanent error
Коды ошибок транспортера с 0x17 по 0x20 и 0x22 резервируются для связей SCI, которые не поддерживаются в этой версии кластера NDB, и не включены здесь.
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:
Перезапустите узлы хранения до входа в однопользовательский режим.
Эта секция обсуждает несколько SQL-операторов, которые могут оказаться полезными в управлении и контроле сервера MySQL, который связан с кластером NDB, и в некоторых случаях предоставляют информацию о самом кластере.
SHOW ENGINE NDB STATUS
,
SHOW ENGINE
NDBCLUSTER STATUS
.
Вывод этого запроса содержит информацию о связи сервера с кластером, создании и использовании объектов кластера NDB и двоичной регистрации для репликации кластера NDB.
Этот запрос может использоваться, чтобы определить, позволено ли объединение в кластеры в сервере MySQL, и если так, активно ли это.
Этот запрос не поддерживает
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 | +---------+
Этот запрос предоставляет список большинства системных переменных сервера,
касающихся 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)
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.
Это запрос показывает, действует ли сервер 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 был построен с поддержкой кластера, но это не связано с кластером, все строки в выводе этого запроса содержат ноль или пустую строку.
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 для использования в скриптах
в целях контроля и автоматизации.
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.
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.
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
.
Таблица 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
показывает, связан ли этот узел с кластером как арбитр.
Таблица 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.
Таблица 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.
Таблица 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
.
Таблица 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
.
Таблица 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.
Таблица 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, так как поддержанные параметры могут измениться из-за различий между выпусками программного обеспечения, аппаратными конфигурациями кластера и другими факторами.
Таблица 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)
Таблица 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.
Таблица 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.
Ааналогично
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.
Как
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.
Таблица 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.
Таблица 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 | Полностью компетентное имя объекта, для таблицы у этого
есть форма , для первичного ключа форма
sys/def/ , для уникального ключа это
sys/def/ |
Таблица добавлена в NDB 7.5.4.
Таблица dict_obj_types
это статическая таблица, перечисляющая возможные типы объектов словаря,
используемые в ядре NDB. Это те же самые типы, определенные
Object::Type
в NDB API.
Таблица 7.29. Столбцы dict_obj_types
Имя | Тип | Описание |
---|---|---|
type_id |
integer | Идентификатор типа для этого типа |
type_name |
string | Название этого типа |
Таблица 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 (базовые данные) |
Таблица disk_write_speed_aggregate
предоставляет соединенную информацию о скорости записей на диск во время
LCP, резервной копии и восстановления.
Таблица 7.31. Столбцы disk_write_speed_aggregate
Имя | Тип | Описание |
---|---|---|
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 | Число байтов, написанных на диск журналу отката в секунду, усредненно за прошлые 60 секунд|
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 |
Таблица 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 секунд |
Таблица 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.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.
Таблица 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.
Таблица 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).
Таблица предоставляет информацию об использовании пространства регистрации кластера 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 | Место, занятое журналом |
Таблица 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 имеют право стать арбитрами.
Запрос этой таблицы предоставляет информацию, подобную обеспеченной
командой
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 байтов.
Таблица 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
.
Эта таблица содержит информацию о статусе узлов данных. Для каждого узла данных, который работает в кластере, соответствующая строка в этой таблице предоставляет 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
использует тот же самый диапазон значений как используемые в выводе
(см.
раздел 7.2).
Если узел в настоящее время не начинается, то эта колонка показывает
node_id
STATUS0
. Для списка фаз старта кластера 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)
Таблица 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
,
который ограничивает количество просмотров, которые можно выполнить
одновременно на единственной точной копии фрагмента.
Эта таблица содержит информацию о процессах узла кластера 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.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 МБ, может быть сверхассигнован, чтобы использовать любую остающуюся доступную память. |
Таблица 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.
Таблица 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.
Таблица 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
.
Таблица 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
.
Таблица 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.
Таблица 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.
Таблица 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.
Таблица 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.
Таблица 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).
Таблица 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
обеспечивает ядерный
номер экземпляра блока.
Таблица 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.
Таблица 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.
Эта таблица содержит информацию о транспортерах 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.
Две табицы INFORMATION_SCHEMA
предоставляют информацию, которая имеет конкретное применение, управляя
кластером NDB. Таблица FILES
предоставляет информацию о файлах данных кластерного диска NDB.
ndb_transid_mysql_connection_map
обеспечивает отображение между транзакциями, операционными
координаторами и узлами API.
Дополнительные статистические и другие данные о транзакциях кластера NDB,
операциях, потоках, блоках и других аспектах работы могут быть получены из
таблиц в БД
ndbinfo
. См.
раздел 7.10.
Эта секция обсуждает соображения безопасности, чтобы принять во внимание, настраивая и управляя кластером NDB.
Темы, затронутые в этой секции, включают следующее:
NDB Cluster и проблемы сетевой безопасности
Проблемы конфигурации, касающиеся управления кластером NDB
NDB Cluster система привилегии MySQL
Процедуры стандартной защиты MySQL, применимые к кластеру 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 |
|
Узел данных или управления |
|
Любой трафик кроме показанного в таблице для данного типа узла должен отрицаться.
Специфические особенности формирования брандмауэра варьируются от применения брандмауэра и выходят за рамки этого руководства. iptables это очень общее и надежное приложение брандмауэра, которое часто используется с APF в качестве фронтэнда, чтобы сделать конфигурацию легче. Вы можете ознакомиться с документацией для программного брандмауэра, который вы используете, чтобы понять, должны ли вы принимать решение осуществить установку сети NDB Cluster этого или смешанного типа.
Также возможно использовать комбинацию первых двух методов, используя оба аппаратных и программных обеспечения, чтобы обеспечить безопасность. Это между первыми двумя схемами и с точки зрения уровня безопасности и с точки зрения стоимости. Этот тип сетевой установки держит кластер позади аппаратного брандмауэра, но разрешает поступающим пакетам перемещаться вне маршрутизатора, соединяющего все хосты кластера, чтобы достигнуть узлов SQL.
Одно возможное развертывание сети кластера NDB, используя аппаратные и программные брандмауэры в комбинации показывают здесь:
Рис. 7.4. NDB Cluster с комбинацией аппаратных и программных брандмауэров
В этом случае можно установить правила в аппаратном брандмауэре, чтобы отрицать любой внешниий трафик кроме как к узлам SQL и API, а затем разрешить трафик только на портах, требуемых приложениями.
Безотносительно конфигурации сети, которую вы используете, помните, что ваша цель с точки зрения безопасности кластера остается той же самой: препятствовать тому, чтобы любой посторонний трафик достиг кластера, гарантируя самую эффективную связь между узлами в кластере.
Поскольку кластер NDB требует большие количества открытых портов для связей между узлами, рекомендуемый выбор состоит в том, чтобы использовать отдельную сеть. Это представляет самый простой способ препятствовать тому, чтобы нежелательный трафик достиг кластера.
Если вы хотите управлять кластером NDB удаленно (то есть, снаружи местной сети), рекомендуемый способ сделать это: использовать ssh или другую безопасную оболочку, чтобы получить доступ к хосту узла SQL. От этого хоста можно тогда управлять клиентом управления, чтобы получить доступ к серверу управления безопасно из собственной местной сети кластера.
Даже при том, что возможно сделать так в теории, не рекомендуется использовать ndb_mgm, чтобы управлять кластером непосредственно снаружи местной сети, в которой работает кластер. Ни идентификация, ни шифрование не происходят между клиентом управления и сервером, это представляет чрезвычайно опасное средство управления кластером и почти наверняка поставится под угрозу рано или поздно.
В этой секции мы обсуждаем, как система привилегии 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=
и получить доступ к этому кластеру NDB. Используя MySQL
management_host
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, от которого порождены
данные, даже если вы не используете распределение привилегии.
В этой секции мы обсуждаем процедуры стандартной защиты 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.
Возможно сохранить неиндексируемые столбцы таблиц
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.
NDB Cluster Disk Data осуществляется, используя много объектов Disk Data. Они включают следующее:
Табличные пространства действуют как контейнеры для других дисковых объектов данных.
Файлы журнала отмен хранят информацию, запрошенную для того, чтобы откатить транзакции до прежнего уровня.
Один или больше файлов журнала отмен назначены на группу файла журнала, которая тогда назначена на табличное пространство.
Файлы данных хранят дисковые данные о таблице данных. Файл данных назначен непосредственно на табличное пространство.
Файлы журнала и файлы данных это фактические файлы в файловой системе
каждого узла данных, по умолчанию они размещаются в
ndb_
в node_id
_fsDataDir
, указанном в
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
_fsDataDir
каждого узла данных в кластере, где
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
_fsDataDir
каждого узла данных в кластере, где
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.
Исполнение кластера NDB, который использует дисковое хранение данных,
может быть значительно улучшено, отделив файловые системы узла данных от
файлов журнала отмен и файлов данных табличного пространства и поместив их на
различные диски. В ранних версиях кластера NDB не было никакой прямой
поддержки этого в кластеру NDB, но было возможно достигнуть этого разделения,
используя символьные ссылки, как описано в этой секции. Кластер NDB
поддерживает параметры конфигурации узла данных
FileSystemPathDD
,
FileSystemPathDataFiles
и
FileSystemPathUndoFiles
,
которые делают использование символьных ссылок с этой целью ненужным.
Для получения дополнительной информации об этих параметрах посмотрите
здесь.
Каждый узел данных в кластере создает файловую систему в подкаталоге
ndb_
каталога
node_id
_fsDataDir
, как определено в файле
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
Следующие пункты относятся к дисковым требованиям хранения данных:
Столбцы переменной длины дисковых таблиц данных поднимают установленную сумму места. Для каждой строки это равно пространству, требуемому, чтобы сохранить самое большое значение для этого столбца.
Для получения общей информации о вычислении этих значений посмотрите 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
, чтобы помочь определить,
должно ли значение для этого параметра быть увеличено.
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.
Онлайн 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).
Эта секция описывает, как добавить узлы данных NDB Cluster online, то есть не останавливая кластер.
В настоящее время необходимо добавить новые узлы данных к кластеру NDB как часть новой группы узлов. Кроме того, невозможно изменить количество точных копий (или количество узлов в группе) онлайн.
Эта секция предоставляет общую информацию о поведении и текущих ограничениях в добавлении узлов кластера 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. Обработка неудачи узла данных во время создания группы узлов и перестройки таблицы
Неудача во время | Неудача в старом узле данных | Неудача в новом узле данных | Системный отказ |
---|---|---|---|
Создание группы узлов |
|
|
|
Перестройка таблицы |
|
|
|
Удаление групп узлов.
Клиент
ndb_mgm поддерживает
команду
DROP NODEGROUP
, но возможно удалить группу узла только, когда
никакие узлы данных в группе не содержат данных. В настоящее время нет
никакого способа освободить
определенный узел данных или группу узлов. Эта команда работает
только в следующих двух случаях:
После
CREATE NODEGROUP
в
ndb_mgm, но до любой
ALTER TABLE ...
REORGANIZE PARTITION
в
mysql.
После удаления всех таблиц
NDBCLUSTER
через
DROP TABLE
.
TRUNCATE TABLE
не работает с этой целью, потому что узлы данных продолжают
хранить определения таблиц.
В этой секции мы перечисляем основные шаги, требуемые, чтобы добавить новые узлы данных к кластеру 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
по очереди, чтобы добавить новые
группы узлов к кластеру.
В этой секции мы обеспечиваем подробный пример, иллюстрирующий, как добавить новые узлы данных 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
используется со списком идентификаторов разделения и строки определений
разделения, чтобы создать новую схему выделения разделов для таблицы, которая
была уже явно разделена. Его использование здесь, чтобы перераспределить
данные на новую группу узлов кластера NDB является исключением в этом
отношении: когда используется таким образом, никакие другие ключевые слова
или идентификаторы не следуют за
table_name
[ALGORITHM=INPLACE,] REORGANIZE PARTITIONREORGANIZE PARTITION
.
Кроме того, для каждо таблицы
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
не могут использовать новые узлы для распределения данных, пока это
не было сделано.
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 могут прочитать и написать имена пользователей, имена хоста, хэши
пароля и любое другое содержание распределенных таблиц прав доступа без
каких-либо ограничений.
Много типов статистических счетчиков, касающихся действий, выполненных
объектами 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
Имя счетчика | Описание | Переменные статуса (статистический тип):
|
---|---|---|
WaitExecCompleteCount
| Сколько раз поток был заблокирован, ожидая выполнения операции.
Включает все вызовы
execute() , а также неявные
выполнения для blob и auto-increment, невидимый клиентам. |
|
WaitScanResultCount |
Сколько раз поток был заблокирован, ожидая основанного на просмотре сигнала, дополнительных результатов или закрытия просмотра. | |
WaitMetaRequestCount |
Сколько раз поток был заблокирован, ожидая основанного на метаданных сигнала, это может произойти, ожидая операции DDL или в течение эпохи, которая будет начата (или закончена). | |
WaitNanosCount |
Полное время (в наносекундах), потраченное на ожидание некоторого типа сигнала от узлов данных. | |
BytesSentCount |
Объем данных (в байтах), посланный в узлы данных | |
BytesRecvdCount |
Объем данных (в байтах), полученный от узлов данных | |
TransStartCount |
Количество транзакций начато. | |
TransCommitCount |
Количество транзакций передано. | |
TransAbortCount |
Количество транзакций прервано. | |
TransCloseCount |
Количество транзакций прерывается. Это значение может быть больше, чем
сумма TransCommitCount и
TransAbortCount . |
|
PkOpCount |
Количество операций на основе или использующих первичные ключи. Это количество включает операции по таблице с частями blob, неявные открывающие операции и операции автоприращения, а также операции по первичному ключу, обычно видимые клиентам MySQL. | |
UkOpCount |
Количество операций на основе или использующих уникальные ключи. | |
TableScanCount |
Количество сканирований таблицы, которые были начаты. Это включает просмотры внутренних таблиц. | |
RangeScanCount |
Количество просмотров диапазона, которые были начаты. | |
PrunedScanCount |
Количество просмотров, которые были сокращены к единственному разделу. | |
ScanBatchCount |
Количество пакетов строк получено (пакет в этом контексте это набор результатов просмотра единственного фрагмента) | |
ReadRowCount |
Общее количество строк, которые были прочитаны. Включает строки, прочитанные, используя первичный ключ, уникальный ключ и операции по просмотру. | |
TransLocalReadRowCount |
Количество строк, прочитанных из того же самого узла данных, на котором управляли транзакцией. | |
DataEventsRecvdCount |
Количество событий изменения строки. |
|
NondataEventsRecvdCount |
Количество полученных событий, кроме изменений строки. | |
EventBytesRecvdCount |
Число байтов событий получено. |
|
Чтобы видеть все количество переданных транзакций то есть, все
переменные статуса 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
.