Безопасно ли mysqldump раздел отсутствующих данных для реимпорта с моими флагами?
Допустим, в тестовой базе данных данные за год были стерты. Я получил два идентификатора для данных в течение одного года, и данных для другого, самое позднее, и, следовательно, диапазон того, чего здесь не хватает. Мой вопрос; Есть ли какая-либо опасность при использовании следующей команды из полного экземпляра базы данных, чтобы получить рабочий дамп, который можно использовать для восстановления базы данных с отсутствующим фрагментом информации в ней? Команда:
mysqldump -t --insert-ignore --skip-opt --single-transaction --quick --where="id<156789339" -w"id>124054297" -u root -p database table > partial.sql
И это импортировать после gzipping / перемещения его:
zcat partial.sql.gz | mysql -u root -p database table
Можно упомянуть одно предостережение: данные поступают из mysql 5.5 (percona) при импорте в экземпляр mysql 5.1, хотя я думаю, что нет никаких проблем с совместимостью, о которых я знаю, которые могут возникнуть из-за этого.
я понимаю -t
чтобы избежать создания CREATE TABLE
заявления (--no-create-info
), --insert-ignore
в случае, если мой диапазон перекрывается, поэтому он игнорирует, если этот идентификатор уже существует, и --skip-opt
за то, что он не делает целую кучу вещей, которые могли бы испортить вещи при импорте (--add-drop-tab, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables, --quick, and --set-charset
в соответствии с man-страницей для mysqldump). Просто хочу знать наверняка, что это все, что мне нужно при экспорте, и если есть что-то, что я пропускаю при импорте, прежде чем будут допущены возможные ошибки.
1 ответ
Вероятно, это будет хорошо. Есть несколько особых случаев, когда он может потерпеть неудачу.
В вашей БД есть КЛЮЧЕВЫЕ КЛЮЧИ, указывающие на вашу таблицу с помощью оператора ON DELETE CASCADE. В этом случае вы потеряли другие данные в результате предыдущего удаления, и вам также нужно найти и скопировать эти данные. Если ваша база данных использует MYISAM, у вас нет внешних ключей, поэтому вы в безопасности.
Вы используете специальные функции, не поддерживаемые в предыдущей версии, например. FULLTEXT индексы. Поскольку вы сказали, что это тестовый дБ, я полагаю, что модель идентична. В этом случае не должно быть проблем.
Вы используете различную кодировку/сопоставление в двух БД, и у вас есть не ASCII (локализованные) текстовые поля в таблице. Опять же, если модель такая же, проблем быть не должно. (Если ваша таблица не имеет явного определения кодировки и кодировка по умолчанию на серверах MySQL отличается, у вас могут быть проблемы, но это маловероятно).
Если вы используете INNODB, возможно, вы захотите выполнить весь свой дамп в СДЕЛКЕ (между BEGIN и COMMIT;)