RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 		 Visa 
4274 3200 2453 6495 

Глава 5. Фазы запуска NDB Cluster

Старт узла данных NDB Cluster обрабатывается в серии фаз, которая синхронизирована с другими узлами, которые запускают параллельно с этим узлом, а также с уже стартовавшими узлами. Следующие несколько разделов этой главы описывают каждую из этих фаз подробно.

5.1. Фаза инициализации (фаза -1)

Прежде чем узел данных на самом деле стартует, много других установок и задач инициализации должны быть сделаны для объектов блока, транспортеров и различных проверок.

Этот процесс инициализации начинается в storage/ndb/src/kernel/main.cpp с рядом вызовов globalEmulatorData.theThreadConfig->doStart(). При запуске ndbd с опцией -n или --nostart будет только один вызов метода, иначе будет два, причем второй на самом деле запускает узел данных. Первый вызов doStart() посылает сигнал START_ORD блоку CMVMI, второй посылает сигнал START_ORD в NDBCNTR.

Когда START_ORD получен блоком NDBCNTR, сигнал немедленно передается подблоку MISSRA блока NDBCNTR, который обращается с процессом запуска, посылая сигналы READ_CONFIG_REQ всем блокам в порядке, определенном в массиве readConfigOrder:

  1. NDBFS

  2. DBTUP

  3. DBACC

  4. DBTC

  5. DBLQH

  6. DBTUX

  7. DBDICT

  8. DBDIH

  9. NDBCNTR

  10. QMGR

  11. TRIX

  12. BACKUP

  13. DBUTIL

  14. SUMA

  15. TSMAN

  16. LGMAN

  17. PGMAN

  18. RESTORE.

NDBFS должен запуститься прежде, чем с любым из остающихся блоков свяжутся, чтобы удостовериться, что это может запустить потоки блоков CMVMI.

5.2. Фаза конфигурации (фаза STTOR -1)

Сигнал READ_CONFIG_REQ предоставляет всем ядерным блокам возможность прочитать данные конфигурации, которые сохранены в глобальном объекте, доступном для всех блоков. Все выделение памяти в узлах данных происходит во время этой фазы.

Связи между ядерными блоками и файловой системой NDB также настраивается во время фазы 0. Это необходимо, чтобы позволить блокам легко определить, какие части структуры таблицы должны быть написаны на диск.

NDB выполняет выделения памяти двумя различными способами. Первый из них при помощи метода allocRecord() (определенного в storage/ndb/src/kernel/vm/SimulatedBlock.hpp). Это традиционный метод, посредством чего к записям получают доступ, используя макрос ptrCheckGuard (определен в storage/ndb/src/kernel/vm/pc.hpp). Другой метод должен ассигновать память, используя метод setSize(), определенный с помощью шаблона в storage/ndb/src/kernel/vm/CArray.hpp.

Эти методы иногда также инициализируют память, гарантируя, что выделение памяти и инициализация сделаны с защитой.

Много блоков также выполняют определенную для блока инициализацию, которая часто влечет за собой создание связанных списков (и в некоторых случаях хэш-таблиц).

Многие размеры, используемые в распределении, вычисляются в методе Configuration::calcSizeAlt() в storage/ndb/src/kernel/vm/Configuration.cpp.

Некоторые приготовления к более интеллектуальному объединению ресурсов памяти были сделаны. DataMemory и дисковые записи уже принадлежат этому пулу глобальной памяти.

5.3. STTOR фаза 0

Большинство NDB ядерных блоков начинают свои фазы запуска в STTOR фазе 1, за исключением NDBFS и NDBCNTR, которые начинаются с фазы 0, просматривая первое значение для каждого элемента в массиве ALL_BLOCKS (определен в src/kernel/blocks/ndbcntr/NdbcntrMain.cpp). Кроме того, когда сигнал STTOR посылают в блок, сигнал возвращения STTORRY всегда содержит список фаз начала, в которых у блока есть интерес. Только в этих стартовых фазах блок на самом деле получает сигнал STTOR.

Сигналы STTOR отосланы в порядке, в котором ядерные блоки перечисляются в массиве ALL_BLOCKS. В то время, как NDBCNTR проходит фазы начала от 0 до 255, большинство из них пусто.

Оба действия в фазе 0 имеют отношение к инициализации файловой системы NDB. Во-первых, при необходимости, NDBFS создает каталог файловой системы для узла данных. В случае начального запуска NDBCNTR очищает любые существующие файлы в каталоге узла данных, чтобы гарантировать, что блок DBDIH впоследствии не обнаружит системных файлов (если DBDIH найдет любые системные файлы, это не будет интерпретировать старт правильно как начальный запуск).

Каждый раз, когда NDBCNTR заканчивает отправку одной фазы начала всем ядерным блокам, это посылает сигнал NODE_STATE_REP всем блокам, который эффективно обновляет везде NodeState.

Каждый раз, когда NDBCNTR заканчивает непустую фазу начала, он сообщает об этом серверу управления, в большинстве случаев это зарегистрировано в журнале.

Наконец, после завершения всех фаз начала, NDBCNTR обновляет статус узла во всех блоках, используя сигнал NODE_STATE_REP, это также посылает отчет событий, сообщая, что все фазы выполнены. Кроме того, все другие узлы данных предупреждены, что этот узел закончил все свои фазы старта, чтобы гарантировать, что все узлы знают о статусе друг друга. Каждый узел данных посылает всем блокам NODE_START_REP, но это значительно только для DBDIH, чтобы он знал, когда может открыть блокировку для изменений схемы на DBDICT.

В следующей таблице, и всюду по этому тексту, мы иногда обращаемся к фазам STTOR просто как к фазам старта или Phase N (где N некоторое число). Стартовые фазы NDB_STTOR всегда квалифицируются как таковые и таким образом упоминаются как фазы старта NDB_STTOR или фазы NDB_STTOR .

Таблица 5.1. Ядерные блоки NDB и фазы старта

Ядерный блок Соответствующие стартовые фазы
NDBFS0
DBTC1
DBDIH1
DBLQH1, 4
DBACC1
DBTUP1
DBDICT1, 3
NDBCNTR 0, 1, 2, 3, 4, 5, 6, 8, 9
CMVMI 1 (до QMGR), 3, 8
QMGR1, 7
TRIX1
BACKUP1, 3, 7
DBUTIL1, 6
SUMA 1, 3, 5, 7, 100 (пусто), 101
DBTUX1,3,7
TSMAN 1, 3 (обе игнорируются)
LGMAN 1, 2, 3, 4, 5, 6 (все игнорируются)
PGMAN 1, 3, 7 (фаза 7 сейчас пустая)
RESTORE 1, 3 (только в фазе 1 идет любая реальная работа)

Таблица была актуалена в то время, когда этот текст был написан, но вероятно будет изменяться со временем. Последняя информация может быть найдена в исходном коде.

5.4. STTOR фаза 1

Это одна из фаз, в которых участвует большинство ядерных блоков (см. раздел 5.3). Иначе большинство блоков включается, прежде всего, в инициализацию данных, например, это делается DBTC.

Много блоков инициализируют ссылки на другие блоки в фазе 1. DBLQH инициализирует ссылки блока на DBTUP, DBACC инициализирует ссылки блока на DBTUP и DBLQH. DBTUP инициализирует ссылки блока на DBLQH, TSMAN и LGMAN.

NDBCNTR инициализирует некоторые переменные и настраивает ссылки блока на DBTUP, DBLQH, DBACC, DBTC, DBDIH и DBDICT, они необходимы в специальной обработке фазы запуска этих блоков с использованием сигналов NDB_STTOR, где на самом деле происходит большая часть процесса запуска узла.

Если кластер формируется, чтобы блокировать страницы (то есть, если LockPagesInMainMemory установлен), CMVMI обрабатывает эти блокировки.

Блок QMGR вызывает метод initData() (определен в storage/ndb/src/kernel/blocks/qmgr/QmgrMain.cpp), вывод которого обработан всеми другими блоками в фазе READ_CONFIG_REQ (см. раздел 5.1 ). После этих инициализаций QMGR посылает сигнал DIH_RESTARTREQ DBDIH, который определяет, существует ли надлежащий системный файл, если это так, начальный запуск не выполняется. После приема этого сигнала происходит процесс интеграции узла среди других узлов данных в группе, где узлы данных входят в группу по одному. Первый, который войдет, становится ведущим, каждый раз, когда он падает, новый ведущий всегда узел, который работал в течение самого долгого времени из тех, которые остаются.

QMGR настраивает таймеры, чтобы гарантировать, что включение в группу не занимает больше времени, чем конфигурация группы собирается разрешить (см. Controlling Timeouts, Intervals, and Disk Paging), после чего устанавливается коммуникация ко всем другим узлам данных. В этом пункте сигнал CM_REGREQ сигнал посылают во все узлы данных. Только координатор группы отвечает на этот сигнал, он разрешает одному узлу за один раз входить в группу. Если никакой узел не отвечает в течение 3 секунд, координатор становится ведущим. Если несколько узлов запускают одновременно, то узел с самым низким ID узла становится координатором. Он посылает CM_REGCONF в ответ на этот сигнал, но также посылает и CM_ADD всем узлам, которые в настоящее время живы.

Затем стартовый узел посылает сигнал CM_NODEINFOREQ всем текущим живым узлам данных. Когда эти узлы получают такой сигнал, они посылают NODE_VERSION_REP всем узлам API, которые соединились с ними. Каждый узел данных также посылает CM_ACKADD координатору, чтобы сообщить, что получил сигнал CM_NODEINFOREQ от нового узла. Наконец каждый из текущих узлов данных посылает CM_NODEINFOCONF в ответ на стартовый узел. Когда стартовый узел получил все эти сигналы, он также посылает CM_ACKADD координатору.

Когда координатор получил все ожидаемые сигналы CM_ACKADD, это знает, что все узлы данных (включая новейший) ответили на CM_NODEINFOREQ. Когда координатор получает финальный CM_ACKADD, он посылает сигнал CM_ADD всем текущим узлам данных (то есть, за исключением узла, который только что запустился). После получения этого сигнала существующие узлы данных позволяют связь с новым узлом, они начинают посылать синхронизацию в него и включают в список соседей, используемых протоколом синхронизации.

Структура start перезагружается, чтобы она могла обращаться с новыми стартовыми узлами, затем каждый узел данных посылает CM_ACKADD координатору, который тогда посылает CM_ADD стартовавшему узлу после того, как были получены все сигналы CM_ACKADD. Новый узел тогда открывает все свои каналы связи к узлам данных, которые были уже связаны с кластером, это также настраивает свои собственные структуры и начинает посылать синхронизацию. Это также посылает сообщение CM_ACKADD в ответ координатору.

Передачу сигналов между стартовым узлом данных, уже живыми узлами данных, координатором и любыми узлами API, подключенными к группе во время этой фазы, показывают на следующей диаграмме:

Exchange of signals in cluster STTOR start phase 1

Как заключительный шаг, QMGR также начинает обработку таймера, за которую это ответственно. Это означает, что он производит сигнал блокам, которые просили его. Этот сигнал посылают 100 раз в секунду, даже если какой-либо случай сигнала отложен.

Ядерный блок BACKUP также начинает посылать сигнал периодически. Это должно гарантировать, что чрезмерные объемы данных не написаны на диск и что записываемые данные остаются в рамках пределов того, что было определено в файле кластерной конфигурации в течение и после перезапусков. Блок DBUTIL инициализирует транзакционную идентичность, а DBTUX создает ссылку на блок DBTUP в то время, как PGMAN инициализирует указатели на блоки LGMAN и DBTUP. Ядерный блок RESTORE создает ссылки на DBLQH и DBTUP, чтобы позволить быстрый доступ к тем блокам при необходимости.

5.5. STTOR фаза 2

Единственный ядерный блок, который участвует в этой фазе, это NDBCNTR.

В этой фазе NDBCNTR получает текущее состояние каждого формируемого узла данных. Сообщения, посылаемые NDBCNTR из QMGR, сообщают об изменениях в статусе любого узла NDBCNTR также задает таймеры, соответствующие StartPartialTimeout, StartPartitionTimeout и StartFailureTimeout.

Следующий шаг это сигнал CNTR_START_REQ, который пошлют в предложенный главный узел. Обычно координатор также выбран в качестве ведущего. Однако, во время системного перезапуска, где у стартового узла есть более новая глобальная контрольная точка, чем та, что выжила на координаторе, этот узел вступит в должность главного узла, даже при том, что это не признано координатором QMGR. Если стартовый узел выбран в качестве нового ведущего, то другим узлам сообщают об этом с использованием сигнала CNTR_START_REF.

Ведущий не подает сигнал CNTR_START_REQ пока это не готово начать новый узел или весь кластер для начального или системного перезапуска.

Когда стартовый узел получает CNTR_START_CONF, это начинает фазы NDB_STTOR в следующем порядке:

  1. DBLQH

  2. DBDICT

  3. DBTUP

  4. DBACC

  5. DBTC

  6. DBDIH

5.6. NDB_STTOR фаза 1

DBDICT при необходимости, инициализирует файл схемы. DBDIH, DBTC, DBTUP и DBLQH инициализируют переменные. DBLQH также инициализирует отправку статистики по операциям по базе данных.

5.7. STTOR фаза 3

DBDICT инициализирует переменную, которая отслеживает тип выполняемого перезапуска.

NDBCNTR выполняет вторую фазу запуска NDB_STTOR без другой деятельности NDBCNTR, происходящей во время этой фазы STTOR.

5.8. NDB_STTOR фаза 2

Блок DBLQH позволяет свой обмен внутренними отчетами с DBTUP и DBACC в то время, как DBTC разрешает обмен его внутренними отчетами DBDIH. Ядерный блок DBDIH создает mutexes, используемый ядром NDB, и читает узлы, используя сигнал READ_NODESREQ. С данными от ответа до этого сигнала DBDIH может создать списки узла, группы узла и т.д. Для (возможно, начальных) перезапусков узла DBDIH также просит у ведущего разрешение выполнить перезапуск. Ведущий спросит все живые узлы, если они будут готовы разрешить новому узлу присоединяться к группе. Если начальный перезапуск узла должен быть выполнен, то все LCP лишены законной силы как часть этой фазы.

LCP от узлов, которые не являются частью группы во время начального перезапуска узла, не лишены законной силы. Причина этого состоит в том, что никогда нет никакого шанса для узла, чтобы стать ведущим системного перезапуска, используя любой из LCP, которые были лишены законной силы, так как этот узел должен закончить перезапуск узла, включая местную контрольную точку, прежде, чем сможет присоединиться к группе и возможно стать главным узлом.

Ядерный блок CMVMI активирует отправку упакованных сигналов, которая происходит только как часть операций по базе данных. Упаковка должна быть позволена до начала любых таких операций во время выполнения журнала отката или фаз восстановления узла.

Блок DBTUX устанавливает тип в настоящее время происходящего запуска в то время, как блок BACKUP устанавливает тип перезапуска, который должен быть выполнен, если есть (в каждом случае блок на самом деле устанавливает переменную, значение которой отражает тип запуска или перезапуска). Блок SUMA остается бездействующим во время этой фазы.

Ядерный блок PGMAN формирует два повторных сигнала, первый очищает обработку, этот сигнал посылают каждые 200 миллисекунд. Другой сигнал обращается со статистикой и послан однажды в секунду.

5.9. STTOR фаза 4

Только ядерные блоки DBLQH и NDBCNTR непосредственно вовлечены в эту фазу. DBLQH ассигнует отчет в блоке BACKUP, используемом в выполнении местных контрольных точек, используя сигнал DEFINE_BACKUP_REQ. NDBCNTR предписывает NDB_STTOR выполнять NDB_STTOR фаза 3, иначе нет никакой другой деятельности NDBCNTR во время этой фазы STTOR.

5.10. NDB_STTOR фаза 3

Блок DBLQH выполняет здесь проверку файлов журнала. Тогда это получает статусы узлов данных, используя сигнал READ_NODESREQ. Если начальный запуск или перезапуск узла не выполняются, проверка файлов журнала обработана параллельно со многими другими фазами. Для начальных запусков должны быть инициализированы файлы журнала, это может быть долгим процессом и должно иметь некоторый статус прогресса

От этого пункта есть два параллельных пути, один это продолжение перезапуска, а другой это чтение и определение статуса файлов журнала отката.

Блок DBDICT запрашивает информацию об узлах данных о группе, используя сигнал READ_NODESREQ. DBACC сбрасывает системный флаг перезапуска, если это не системный перезапуск, это используется только, чтобы проверить, что никакие запросы не получены из DBTUX во время системного перезапуска. DBTC запрашивает информацию обо всех узлах посредством сигнала READ_NODESREQ.

DBDIH устанавливает внутренний основной статус и делает другие приготовления исключительно к начальному запуску. В случае начального запуска неосновные узлы выполняют некоторые начальные задачи, главный узел сработает как только все неосновные узлы сообщат, что их задачи выполнены. Эта задержка на самом деле ненужная, так как нет никакой причины ждать, инициализируя главный узел.

При перезапуске узла и начальном перезапуске узла больше никакой работы не сделано в этой фазе. При начальном запуске работа сделана, когда все узлы создали начальную информацию о перезапуске и инициализировали системный файл.

Когда система перезапускается, это именно то место, где большая часть работы выполняется, посылая сигнал NDB_STARTREQ из NDBCNTR в DBDIH ведущего. Этот сигнал посылают, когда все узлы в системном перезапуске достигли этой точки в перезапуске. Это можно отметить, как первую точку синхронизации для системных перезапусков, определяемых WAITPOINT_4_1.

Для описания системной версии перезапуска фазы 4 посмотрите раздел 5.21.

После завершения выполнения сигнала NDB_STARTREQ ведущий посылает сигнал CNTR_WAITREP с WAITPOINT_4_2 всем узлам. Это заканчивает фазу 3 NDB_STTOR, а также (STTOR) фазу 4.

5.11. STTOR фаза 5

Все, что происходит в фазе 5, является доставкой NDBCNTR фазы 4 NDB_STTOR, единственный блок, который действует на этот сигнал, это DBDIH, который управляет большей частью запуска узла данных, который связан с базой данных.

5.12. NDB_STTOR фаза 4

Некоторая инициализация местных переменных контрольной точки происходит в этой фазе, для начальных перезапусков это все, что происходит в этой фазе.

Для системных перезапусков также выполняются все необходимые поглощения. В настоящее время это означает, что все узлы, статусы которых не могли быть восстановлены, используя журнал отката, перезапущены, копируя им все необходимые данные из живых узлов данных.

Для перезапусков узла и начальных перезапусков узла главный узел выполняет много услуг, которые требуются, посылая сигнал START_MEREQ. Эта фаза закончена, когда ведущий отвечает START_MECONF, и описана в разделе 5.22.

После обеспечения того, что задачи, назначенные DBDIH в фазе NDB_STTOR выполнены, NDBCNTR выполняет некоторую работу самостоятельно. Для начальных запусков это создает системную таблицу, которая отслеживает уникальные идентификаторы, такие как используемые для AUTO_INCREMENT. После точки синхронизации WAITPOINT_4_1 все системные перезапуски немедленно переходят к фазе 5 NDB_STTOR, которая обработана блоком DBDIH, см. раздел 5.13.

5.13. NDB_STTOR фаза 5

Для начальных запусков и системных перезапусков эта фаза означает выполнение местной контрольной точки. Это обработано ведущим так, чтобы другие узлы немедленно возвратились из этой фазы. Перезапуски узла и начальные перезапуски узла выполняют копирование отчетов от основной точной копии фрагмента к стартовым точным копиям фрагмента в этой фазе. Местные контрольные точки позволены прежде, чем процесс копирования начат.

Копирование данных к стартовому узлу является частью протокола поглощения узла. Как часть этого протокола, обновляется статус стартового узла, это сообщено, используя глобальный протокол контрольной точки. Ожидание этих событий гарантирует, что новый статус узла сообщен всем узлам и их системным файлам.

После того, как статус узла был сообщен, все узлы предупреждены, что мы собираемся начать протокол поглощения для этого узла. Часть этого протокола состоит из шагов 3-9 во время системной фазы перезапуска, как описано позже в этой секции. Это означает что восстановление всех фрагментов, подготовка к выполнению журнала отката, выполнению журнала отката и наконец отчет перед DBDIH, когда выполнение журнала отката закончено, это все части этого процесса.

После того, как приготовления завершены, копирование для каждого фрагмента в узле должно быть выполнено. Процесс копирования фрагмента включает следующие шаги:

  1. Ядерному блоку DBLQH в стартовом узле сообщают, что процесс копирования собирается начаться, посылая ему сигнал PREPARE_COPY_FRAGREQ.

  2. Когда DBLQH признает этот запрос, сигнал CREATE_FRAGREQ посылают во все узлы, уведомляя их относительно подготовки, сделанной, чтобы скопировать данные к этой точной копии фрагмента для этого фрагмента таблицы.

  3. После того, как все узлы признали это, сигнал COPY_FRAGREQ посылают в узел, с которого данные должны быть скопированы к новому узлу. Это всегда основная точная копия фрагмента. Узел копирует все данные к стартовому узлу в ответ на это сообщение.

  4. После того, как копирование было закончено, и получено сообение COPY_FRAGCONF, все узлы проинформированы относительно завершения через сигнал UPDATE_TOREQ.

  5. После того, как все узлы обновили, чтобы отразить новое состояние фрагмента, ядерному блоку DBLQH стартового узла сообщают о том, что копия была закончена, точная копия фрагмента теперь актуальна, а любые неудачи нужно теперь рассматривать как реальные неудачи.

  6. Новая точная копия фрагмента преобразовывается в основную точную копию фрагмента, если это роль, которую это имело, когда таблица была составлена.

  7. После завершения этого сообщения CREATE_FRAGREQ посылают во все узлы, сообщая им, что поглощение фрагмента завешено.

  8. После этого процесс повторяется со следующим фрагментом, если он есть.

  9. Когда больше нет фрагментов для поглощения узлом, всем узлам сообщают об этом, посылая сигнал UPDATE_TOREQ.

  10. Состояние узла обновляется, используя полную глобальную контрольную точку. Как с местной контрольной точкой в предыдущем шаге, глобальной контрольной точке нужно разрешить начаться и затем закончиться.

  11. Когда глобальная контрольная точка закончится, она сообщит успешную местную контрольную точку этого перезапуска узла, посылая сигнал END_TOREQ всем узлам.

  12. Сигнал START_COPYCONF передан обратно в стартовый узел, сообщающий ему, что перезапуск узла был закончен.

  13. Получение сигнала START_COPYCONF завершает NDB_STTOR фазу 5. Это обеспечивает другую точку синхронизации для системных перезапусков, определяемую как WAITPOINT_5_2.

Процесс копирования в этой фазе может в теории быть выполненным параллельно несколькими узлами. Однако, все сообщения от ведущего ко всем узлам в настоящее время посылают в один узел за один раз, но это можно сделать абсолютно параллельно. Это, вероятно, будет сделано в не слишком отдаленном будущем.

В начальном запуске и начальном перезапуске узла блок SUMA просит подписки от SUMA главного узла. NDBCNTR выполняет фазу 6 NDB_STTOR. Нет другой активности NDBCNTR.

5.14. NDB_STTOR фаза 6

В этой фазе NDB_STTOR DBLQH и DBDICT очищают их внутренние флаги, представляющие текущий тип перезапуска. Блок DBACC сбрасывает системный флаг перезапуска, DBACC и DBTUP запускают периодический сигнал для проверки использования памяти однажды в секунду. DBTC устанавливает внутреннюю переменную, указывающую, что системный перезапуск был закончен.

5.15 STTOR фаза 6

Блок NDBCNTR определяет группы узлов кластера, блок DBUTIL инициализирует много структур данных, чтобы облегчить действия отправки к системным таблицам. DBUTIL также настраивает единственную связь с ядерным блоком DBTC.

5.16. STTOR фаза 7

В QMGR координатор запускает арбитра (если эта опция не была отключена, установив значение ArbitrationRank = 0 для всех узлов, см. Defining an NDB Cluster Management Server и Defining SQL and Other API Nodes in an NDB Cluster. Кроме того, активируется проверка узлов API посредством синхронизации.

Также во время этой фазы блок BACKUP устанавливает скорость записи на диск в значение, используемое после завершения перезапуска. Главный узел во время начального запуска также вставляет запись ведения учета, которая делают копию ID, который затем должен использоваться. Блоки SUMA и DBTUX устанавливают переменные, указывающие, что фаза 7 запуска была закончена, и это запрашивает DBTUX, когда управление журналом отката больше не должно игнорироваться.

5.17. STTOR фаза 8

NDB_STTOR выполняет фазу 7 NDB_STTOR, другой активности NDBCNTR нет.

5.18. NDB_STTOR фаза 7

Если это системный перезапуск, главный узел начинает восстановление всех индексов от DBDICT во время этой фазы.

Ядерный блок CMVMI открывает каналы связи для узлов API (включая серверы MySQL, действующие как узлы SQL), и указывает в globalData то, что узел запуен.

5.19. STTOR фаза 9

NDBCNTR сбрасывает некоторые переменные запуска.

5.20. STTOR фаза 101

Это SUMA, фаза передачи, во время которой о GCP договариваются и используют в качестве ориентира для изменения источника события и подписок повторения от существующих узлов только, чтобы включать недавно запущенный узел./p>

5.21. Системная обработка перезапуска в фазе 4

Это состоит из следующих шагов:

  1. Ведущий устанавливает последний GCI как GCI перезапуска и затем синхронизирует его системный файл со всеми другими узлами, вовлеченными в системный перезапуск.

  2. Следующий шаг должен синхронизировать схему всех узлов в системном перезапуске. Это выполняется в 15 проходов. Проблема, которую мы пытаемся решить здесь, происходит, когда объект схемы был создан в то время, как узел запущен, но был удален при выключении узла, и возможно новый объект был даже создан с тем же самым ID схемы в то время, как тот узел был недоступен. Чтобы обращаться с этой ситуацией, необходимо сначала воссоздать все объекты, которые, как предполагается, существуют с точки зрения стартового узла. После этого удалены любые объекты, которые были удалены другими узлами в группе в то время, как этот узел был выключен, это также относится к любым таблицам, которые были потеряны во время отключения электричества. Наконец, любые таблицы, которые были составлены другими узлами, в то время как стартовый узел был недоступен, воссоздаются на стартовом узле. Все эти операции местные по отношению к стартовому узлу. Как часть этого процесса, также необходимо гарантировать, что все таблицы, которые должны быть воссозданы, были составлены в местном масштабе и что надлежащие структуры данных были настроены для них во всех ядерных блоках.

    После выполнения процедуры, описанной для главного узла, новый файл схемы посылают всем другим участникам системного перезапуска, и они выполняют ту же самую синхронизацию.

  3. У всех фрагментов, вовлеченных в перезапуск, должны быть надлежащие параметры, как получено из DBDIH. Это вызывает много сигналов START_FRAGREQ, которые посланы из DBDIH в DBLQH. Это также начинает восстановление фрагментов, которые восстановлены один за другим и один отчет за один раз в ходе чтения данных с диска и параллельного восстановления данных, прочитанных с диска в оперативную память. Это восстанавливает только части оперативной памяти таблиц.

  4. Как только все фрагменты были восстановлены, сообщение START_RECREQ посылают во все узлы в стартовой группе, затем применяют все журналы отмен для любых частей дисковых данных таблиц.

  5. После применения отмен в LGMAN, необходимо выполнить некоторые восстановительные работы в TSMAN, это требует просмотра заголовков экстентов табличных пространств.

  6. Затем необходимо подготовиться к выполнению журнала отката, что может быть выполнено максимум в четырех фазах. Для каждого фрагмента может требоваться выполнение журналов отката от нескольких различных узлов. Это обработано, выполнив журналы отката в различных фазах для определенного фрагмента, как решено в DBDIH посылая сигнал START_FRAGREQ. Сигнал EXEC_FRAGREQ посылают для каждой фазы и фрагмента, который требует выполнения в этой фазе. После того, как эти сигналы посылают, сигнал EXEC_SRREQ посылают во все узлы, чтобы сказать им, что они могут начать выполнять журнал отката.

    Перед стартовым выполнением первого журнала отката необходимо удостовериться, что работа, которая была начата ранее (в фазе 4) DBLQH закончилась, или ждать, пока это не закончится перед продолжением.

  7. До выполнения журнала отката необходимо вычислить, где начать читать и где конец журнала отката должен был быть достигнут. Конец журнала отката должен быть найден, когда последний GCI, который надо восстановить, был достигнут.

  8. После завершения выполнения журналов отката все страницы журнала отката, которые были написаны вне последнего GCI для восстанавления, лишены законной силы. Учитывая циклическую природу журналов отката, это могло бы перенести аннулирование в новые файлы журнала отката мимо последнего выполненного.

  9. После завершения предыдущего шага DBLQH сообщает об этом DBDIH сообщением START_RECCONF.

  10. Когда ведущий получил это сообщение назад от всех стартовых узлов, он посылает сигнал NDB_STARTCONF назад NDBCNTR.

  11. Сообщение NDB_STARTCONF сигнализирует о конце фазы 4 STTOR, который является единственным блоком, включенным до любого существеннго действия в этой фазе.

5.22. Обработка START_MEREQ

Первый шаг в обработке START_MEREQ должен гарантировать, что никакая местная контрольная точка в настоящее время не происходит, иначе необходимо ждать, пока это не будет закончено. Следующий шаг должен скопировать всю информацию о распределении от ведущего DBDIH в запускаемый DBDIH. После этого все метаданные синхронизированы в DBDICT (см. раздел 5.21).

После блокирования местных контрольных точек и затем синхронизации информации о распределении и информации о метаданных, глобальные контрольные точки заблокированы.

Следующий шаг должен объединить стартовый узел в глобальном протоколе контрольной точки, местном протоколе контрольной точки и всех других распределенных протоколах. Как часть этого также обновляется статус узла.

После завершения этого шага глобальному протоколу контрольной точки разрешают начаться снова, сигнал START_MECONF посылают, чтобы указать стартовому узлу, что следующая фаза может продолжаться.

Поиск

  

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru