novatt, ерунду вам советуют. --ignore-table это для mysqldump, а mysql ничего такого не умеет. Не умеет и все.
Sypex dumper умел БЫ, если заранее слили дамп со его специальными пометками, но вы же не слили ?

Если объем данных гигантский и не хочется заново делать дамп, таблички все myisam, могу посоветовать вариант для сильных духом хакеров :
сначала экспортируете структуру с помощью mysqldump --no-data из пустой инсталляции zabbix той же версии без данных, но там будут операторы create table.
закачиваете эту пустую структуру и при этом создаются файлы метаданных .frm и пустые файлы данных .MYD
с помощью расстановки прав на файловую систему делаете отдельные таблицы доступными для модификации, а отдельные нет.
закачиваете полный дамп с помощью mysql -f . - то есть игнорированием ошибок.
меняете права на файлы для нормальной работы. перезапускаете mysql.

С innodb тот же способ. Но предлагаю расставить права с помощью Grant table . С какой-нибудь утилитой типа dbforge поудобнее будет.

novattМожно ли папку с БД MySQL подложить для нового MySQL и подтянет ли их он. В чем проблема - БД занимает в развёрнутом виде 600 Gb а поднимать из dump - это дня 3
Что есть:
- по сути есть диск со всем содержимым
- dump базы

В общем случае - ответ ДА.
myisam не меняется годами и почти наверняка версия mysql значения не имеет.
Да и в innodb пара ходовых форматов. Просто ставите свежую версию и новая поймет старую. Всякие старперские верования в bytesex пришли из других БД и в конфиги можете игнорировать. Это есть в документации.
Осторожные высказывания про файл конфигурации возникли из-за того, потому что innodb действительно может и не завестись. Тут лишь нужно угадать как были настроены параметры innodb_data_file_path, а параметр log size оценить из размеров этих файлов.
Остальные параметры не так важны.

Ну и еще мне не понятно как могла рухнуть Azure ?
Может просто починить с помощью repair table ?