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

ndb_restore должен быть выполнен однажды для каждых из файлов резервных копий, которые создавались START BACKUP команда, используемая, чтобы создать резервное копирование (см. Раздел 17.5.3.2, "Используя MySQL Cluster Management Client to Create Резервное копирование"). Это равно числу узлов данных в кластере в то время, когда резервное копирование создавалось.

Следующая таблица включает опции, которые являются определенными для MySQL Cluster собственная резервная программа восстановления ndb_restore. Дополнительные описания следуют за таблицей. Для опций, характерных для большинства программ MySQL Cluster (включая ndb_restore), см. Раздел 17.4.25, "Опции, Характерные для MySQL Cluster Programs — Опции, Характерные для MySQL Cluster Programs".

Типичные варианты для этой утилиты показываются здесь:

ndb_restore [-c connectstring] -n node_id [-m] -b backup_id \    -r --backup_path=/path/to/backup/files

-c опция используется, чтобы определить connectstring, который говорит ndb_restore где определить местоположение сервера управления кластером. (См. Раздел 17.3.2.3, "MySQL Cluster Connectstring", для информации о connectstrings.), Если эта опция не используется, то ndb_restore пытается соединиться с сервером управления на localhost:1186. Эта утилита действия как узел API кластера, и так требует, чтобы бесплатное подключение "слот" соединилось с сервером управления кластером. Это означает, что должен быть по крайней мере один [api] или [mysqld] раздел, который может использоваться этим в кластере config.ini файл. Это - хорошая идея сохранить по крайней мере один пустым [api] или [mysqld] раздел в config.ini это не используется для сервера MySQL или другого приложения по этой причине (см. Раздел 17.3.2.7, "Определяя SQL и Другие Узлы API в MySQL Cluster").

Можно проверить, что ndb_restore соединяется с кластером при использовании команды SHOW в ndb_mgm клиенте управления. Можно также выполнить это от системной оболочки, как показано здесь:

shell> ndb_mgm -e
        "SHOW"

-n используется, чтобы определить ID узла узла данных, на котором были взяты резервные копии.

В первый раз, когда Вы выполняете ndb_restore программу восстановления, Вы также должны восстановить метаданные. Другими словами следует воссоздать таблицы базы данных — это может быть сделано, выполняя это с --restore_meta (-m) опция. Восстановление metdata должно быть сделанным только на единственном узле данных; это достаточно, чтобы восстановить это ко всему кластеру. Отметьте, что у кластера должна быть пустая база данных, начиная восстанавливать резервное копирование. (Другими словами следует запустить ndbd с --initial до выполнения восстановления.)

Возможно восстановить данные, не восстанавливая табличные метаданные. Поведение значения по умолчанию, делая это для ndb_restore, чтобы перестать работать с ошибкой, если табличные данные не соответствуют табличную схему; это может быть переопределено, используя --skip-table-check или -s опция.

Некоторые из ограничений на несоответствия в определениях столбца, восстанавливая данные, используя ndb_restore ослабляются; когда с одним из этих типов несоответствий встречаются, ndb_restore не останавливается с ошибкой, поскольку это сделало ранее, а скорее принимает данные и вставляет это в целевую таблицу, выпуская предупреждение пользователю, что это делается. Это поведение происходит действительно ли любая из опций --skip-table-check или --promote-attributes используется. Эти различия в определениях столбца имеют следующие типы:

ndb_restore поддерживает ограниченное продвижение атрибута почти таким же способом, которым это поддерживается репликацией MySQL; то есть, данные, поддержанные от столбца данного типа, могут обычно быть восстановлены столбцу, используя "больший, подобный" тип. Например, данные от a CHAR(20) столбец может быть восстановлен столбцу, объявленному как VARCHAR(20), VARCHAR(30), или CHAR(30); данные от a MEDIUMINT столбец может быть восстановлен столбцу типа INT или BIGINT. См. Раздел 16.4.1.9.2, "Репликация Столбцов, Имеющих Различные Типы данных", для таблицы преобразований типов, в настоящий момент поддерживаемых продвижением атрибута.

Продвижение атрибута ndb_restore должно быть включено явно, следующим образом:

--lossy-conversions, -L

Эта опция предназначается к дополнению --promote-attributes опция. Используя --lossy-conversions позволяет преобразования с потерями значений столбцов (введите понижения в должности или изменения в знаке), восстанавливая данные от резервного копирования. С некоторыми исключениями правила, управляющие понижением в должности, являются тем же самым что касается репликации MySQL; см. Раздел 16.4.1.9.2, "Репликация Столбцов, Имеющих Различные Типы данных", для информации о преобразованиях определенного типа, в настоящий момент поддерживаемых понижением в должности атрибута.

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

--preserve-trailing-spaces опция (краткая форма -R) конечные пробелы причин, которые будут сохранены, способствуя фиксированному-width символьному типу данных его переменный-width эквивалент — то есть, продвигая a CHAR значение столбца к VARCHAR или a BINARY значение столбца к VARBINARY. Иначе, любые конечные пробелы отбрасываются от таких значений столбцов, когда они вставляются в новые столбцы.

-b опция используется, чтобы определить Идентификационный или порядковый номер резервного копирования, и является тем же самым числом, показанным клиентом управления в Backup backup_id completed сообщение выводится на экран после завершения резервного копирования. (См. Раздел 17.5.3.2, "Используя MySQL Cluster Management Client to Create Резервное копирование".)

--restore_epoch (краткая форма: -e) добавляет (или восстановления) информацию об эпохе к таблице состояния репликации кластера. Это полезно для запуска репликации на ведомом устройстве репликации MySQL Cluster. Когда эта опция используется, строка в mysql.ndb_apply_status наличие 0 в id столбец обновляется, если он уже существует; такая строка вставляется, если она уже не существует. (См. Раздел 17.6.9, "MySQL Cluster Replication MySQL Cluster Backups With".)

--restore_data

Эта опция заставляет ndb_restore выводить NDB табличные данные и журналы.

--restore_meta

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

--restore-privilege-tables

ndb_restore не делает распределенными таблицами полномочия MySQL восстановления значения по умолчанию. Эта опция заставляет ndb_restore восстанавливать таблицы полномочия.

Это работает, только если таблицы полномочия были преобразованы в NDB прежде, чем резервное копирование было взято. Для получения дополнительной информации см. Раздел 17.5.14, "Распределенный MySQL Privileges для MySQL Cluster".

--backup_path

Путь к резервному каталогу требуется; это предоставляется ndb_restore, используя --backup_path опция, и должна включать подкаталог, соответствующий резервному копированию ID резервного копирования, которое будет восстановлено. Например, если узел данных DataDir /var/lib/mysql-cluster, тогда резервный каталог /var/lib/mysql-cluster/BACKUP, и файлы резервных копий для резервного копирования с ID 3 могут быть найдены в /var/lib/mysql-cluster/BACKUP/BACKUP-3. Путь может быть абсолютным или относительно каталога, в котором ndb_restore исполнимая программа располагается, и может быть дополнительно снабжена префиксом backup_path=.

Возможно восстановить резервное копирование к базе данных с различной конфигурацией, чем это создавалось из. Например, предположите что резервное копирование с резервным ID 12, создаваемый в кластере с двумя узлами базы данных, имеющими ID узла 2 и 3, должен быть восстановлен кластеру с четырьмя узлами. Затем ndb_restore должен быть выполнен дважды — однажды для каждого узла базы данных в кластере, где резервное копирование было взято. Однако, ndb_restore не может всегда восстанавливать резервные копии, сделанные из кластера, выполняющего одну версию MySQL к кластеру, выполняющему различную версию MySQL. См. Раздел 17.2.8, "Обновляя и Кластер MySQL Downgrading NDB 7.3", для получения дополнительной информации.

Для более быстрого восстановления данные могут быть восстановлены параллельно, при условии, что есть достаточное число доступных соединений кластера. Таким образом, восстанавливая к многократным узлам параллельно, Вы должны иметь [api] или [mysqld] раздел в кластере config.ini файл, доступный для каждого параллельного процесса ndb_restore. Однако, файлы данных должны всегда применяться перед журналами.

--no-upgrade

При использовании ndb_restore, чтобы восстановить резервное копирование, VARCHAR столбцы создали использование старого фиксированного формата, изменяются и воссоздал использование переменного-width формата, теперь используемого. Это поведение может быть переопределено, используя --no-upgrade опция (краткая форма: -u) работая ndb_restore.

--print_data

--print_data опция заставляет ndb_restore направлять свой вывод к stdout.

TEXT и BLOB значения столбцов являются всегда усеченными к первым 256 байтам в выводе; это не может в настоящий момент быть переопределено при использовании --print_data.

Несколько дополнительных опций доступны для использования с --print_data опция в генерировании дампов данных, любого к stdout, или к файлу. Они подобны некоторым из опций, используемых с mysqldump, и показываются в следующем списке:

--print_meta

Эта опция заставляет ndb_restore печатать все метаданные к stdout.

--print_log

--print_log опция заставляет ndb_restore выводить свой журнал к stdout.

--print

Причины ndb_restore, чтобы напечатать все данные, метаданные, и журналы к stdout. Эквивалентный использованию --print_data, --print_meta, и --print_log опции вместе.

--dont_ignore_systab_0

Обычно, восстанавливая табличные данные и метаданные, ndb_restore игнорирует копию NDB системная таблица, которая присутствует в резервном копировании. --dont_ignore_systab_0 заставляет системную таблицу быть восстановленной. Эта опция предназначается для экспериментального, и разработка используют только, и не рекомендуется в продуктивной среде.

--ndb-nodegroup-map, -z

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

--no-binlog

Эта опция препятствует тому, чтобы любые соединенные узлы SQL писали данные, восстановленные ndb_restore их двоичным журналам.

--no-restore-disk-objects, -d

Эта опция мешает ndb_restore восстановить любой MySQL Cluster Disk Data objects, такой как группы файла журнала и табличные области; см. Раздел 17.5.12, "MySQL Cluster Disk Data Tables", для получения дополнительной информации о них.

--parallelism=#, -p

Определяет максимальное количество параллельных транзакций, которые ndb_restore пытается использовать. По умолчанию это 128; минимум 1, и максимум 1024.

--progress-frequency=N

Напечатайте отчет о состоянии каждый N секунды, в то время как резервное копирование происходит. 0 (значение по умолчанию) не заставляет отчетов о состоянии быть напечатанными. Максимум 65535.

--verbose=#

Устанавливает уровень для многословия вывода. Минимум 0; максимум 255. Значение по умолчанию 1.

Возможно восстановить только выбранные базы данных, или выбранные таблицы от единственной базы данных, используя синтаксис, показанный здесь:

ndb_restore other_options db_name,[db_name[,...] | tbl_name[,tbl_name][,...]]

Другими словами можно определить любой из следующих, которые будут восстановлены:

--include-databases=db_name[,db_name][,...]

--include-tables=db_name.tbl_name[,db_name.tbl_name][,...]

Используйте --include-databases опция или --include-tables опция для того, чтобы восстановить только определенные базы данных или таблицы, соответственно. --include-databases берет разграниченный запятой список баз данных, которые будут восстановлены. --include-tables берет разграниченный запятой список таблиц (в database.table формат), чтобы быть восстановленным.

Когда --include-databases или --include-tables используется, только те базы данных или таблицы, названные опцией, восстанавливаются; все другие базы данных и таблицы исключаются ndb_restore, и не восстанавливаются.

Следующая таблица показывает несколько вызовов использования ndb_restore --include-* опции (другие опции, возможно требуемые, были опущены для ясности), и эффекты они имеют при восстановлении от резервного копирования MySQL Cluster:

Можно также использовать эти две опции вместе. Например, следующие причины все таблицы в базах данных db1 и db2, вместе с таблицами t1 и t2 в базе данных db3, быть восстановленным (и никакие другие базы данных или таблицы):

shell> ndb_restore [...] --include-databases=db1,db2
        --include-tables=db3.t1,db3.t2

(Снова мы опустили другой, возможно потребовали, опции в примере, только показанном.)

--exclude-databases=db_name[,db_name][,...]

--exclude-tables=db_name.tbl_name[,db_name.tbl_name][,...]

Возможно препятствовать тому, чтобы одна или более баз данных или таблицы были восстановлены, используя ndb_restore опции --exclude-databases и --exclude-tables. --exclude-databases берет разграниченный запятой список одной или более баз данных, которые не должны быть восстановлены. --exclude-tables берет разграниченный запятой список одной или более таблиц (использование database.table формат), который не должен быть восстановлен.

Когда --exclude-databases или --exclude-tables используется, только те базы данных или таблицы, названные опцией, исключаются; все другие базы данных и таблицы восстанавливаются ndb_restore.

Эта таблица показывает несколько вызовов ndb_restore usng --exclude-* опции (другие опции, возможно требуемые, были опущены для ясности), и эффекты эти опции имеют при восстановлении от резервного копирования MySQL Cluster:

Можно использовать эти две опции вместе. Например, следующие причины все таблицы во всех базах данных за исключением баз данных db1 и db2, наряду с таблицами t1 и t2 в базе данных db3, не быть восстановленным:

shell> ndb_restore [...] --exclude-databases=db1,db2
        --exclude-tables=db3.t1,db3.t2

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

Можно использовать --include-* и --exclude-* опции вместе согласно следующим правилам:

Например, следующий набор опций заставляет ndb_restore восстанавливать все таблицы от базы данных db1 кроме db1.t1, не восстанавливая никакие другие таблицы от любых других баз данных:

          --include-databases=db1 --exclude-tables=db1.t1

Однако, инвертирование порядка опций, только данных просто, вызывает все таблицы от базы данных db1 быть восстановленным (включая db1.t1, но никакие таблицы от любой другой базы данных), потому что --include-databases опция, будучи самым дальним направо, является первым соответствием против базы данных db1 и таким образом имеет приоритет по любой другой опции, которая соответствует db1 или любые таблицы в db1:

          --exclude-tables=db1.t1 --include-databases=db1

--exclude-missing-columns

Также возможно восстановить только выбранные столбцы таблицы, используя --exclude-missing-columns опция. Когда эта опция используется, ndb_restore игнорирует любые столбцы, отсутствующие в таблицах, восстанавливаемых по сравнению с версиями тех таблиц, найденных в резервном копировании. Эта опция применяется ко всем восстанавливаемым таблицам. Если Вы хотите применить эту опцию только к выбранным таблицам или базам данных, можно использовать ее в комбинации с один или больше опций, описанных в предыдущем абзаце, чтобы сделать так, то восстановить данные к остающимся таблицам, используя дополнительный набор этих опций.

--disable-indexes

Отключите восстановление, индексирует во время восстановления данных от собственного резервного копирования NDB. Впоследствии, можно восстановить, индексирует для всех таблиц сразу с многопоточным зданием, индексирует использование --rebuild-indexes, который должен быть быстрее, чем восстановление индексирует одновременно для очень больших таблиц.

--rebuild-indexes

Можно использовать эту опцию с ndb_restore, чтобы вызвать многопоточное восстановление упорядоченного, индексирует, восстанавливая собственное NDB резервное копирование.

--skip-broken-objects

Эта опция заставляет ndb_restore игнорировать поврежденные таблицы, читая собственное NDB резервное копирование, и продолжать восстанавливать любые остающиеся таблицы (которые также не повреждаются). В настоящий момент, --skip-broken-objects опция работает только в случае недостающих таблиц частей блоба.

--skip-unknown-objects

Этот ndb_restore причин опции, чтобы проигнорировать любую схему возражает, что это не распознает, читая собственное NDB резервное копирование. Это может использоваться для того, чтобы восстановить резервное копирование, сделанное из кластера рабочий MySQL Cluster NDB 7.3 к кластеру рабочий MySQL Cluster NDB 7.2.

--rewrite-database=old_dbname,new_dbname

Эта опция позволяет восстановить к базе данных, имеющей другое имя от используемого в резервном копировании. Например, если резервное копирование делается из названной базы данных products, можно восстановить данные, которые это содержит к названной базе данных inventory, используйте эту опцию как показано здесь (опускающий любые другие опции, которые могли бы требоваться):

shell> ndb_restore --rewrite-database=product,inventory

Опция может использоваться многократно в единственном вызове ndb_restore. Таким образом возможно восстановить одновременно от названной базы данных db1 к названной базе данных db2 и от базы данных называется db3 к одному именованному db4 использование --rewrite-database=db1,db2 --rewrite-database=db3,db4. Другие ndb_restore опции могут использоваться между многократными возникновениями --rewrite-database.

В случае конфликтов между многократным --rewrite-database опции, последнее --rewrite-database используемая опция, читая слева направо, является той, которая вступает в силу. Например, если --rewrite-database=db1,db2 --rewrite-database=db1,db3 используется, только --rewrite-database=db1,db3 соблюдается, и --rewrite-database=db1,db2 игнорируется. Также возможно восстановить от многократных баз данных до единственной базы данных, так, чтобы --rewrite-database=db1,db3 --rewrite-database=db2,db3 восстановления все таблицы и данные от баз данных db1 и db2 в базу данных db3.

Сообщение об ошибке. ndb_restore сообщает и о нерегулярных и систематических ошибках. В случае нерегулярных ошибок это может способный восстановиться от них, и отчетов Restore successful, but encountered temporary error, please look at configuration в таких случаях.