☰

Безопасно ли mysqldumpить раздел отсутствующих данных для повторного импорта с моими флагами?

tag-icon • tag-icon mysql mysql-replication mysqldump
Безопасно ли mysqldumpить раздел отсутствующих данных для повторного импорта с моими флагами?

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

mysqldump -t --insert-ignore --skip-opt --single-transaction --quick --where="id<156789339" -w"id>124054297" -u root -p database table > partial.sql

А это для импорта после сжатия/перемещения:

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согласно странице руководства для mysqldump). Просто хочу знать наверняка, что это все, что мне нужно при экспорте, и есть ли что-то, чего я, возможно, упускаю при импорте, прежде чем будут сделаны возможные ошибки.

решение1

Наверное, это будет нормально. Есть некоторые особые случаи, когда это может не сработать.

  • В вашей базе данных есть FOREIGN KEY, указывающие на вашу таблицу с помощью оператора ON DELETE CASCADE, в этом случае вы потеряли другие данные в результате предыдущего удаления, и вам нужно найти и скопировать эти данные. Если ваша база данных использует MYISAM, у вас нет внешних ключей, поэтому вы в безопасности.

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

  • Вы используете разныекодирование/подборкав двух БД и у вас есть не ASCII (локализованные) текстовые поля в таблице. Опять же, если модель та же самая, проблем быть не должно. (Если в вашей таблице нет явного определения кодировки и кодировка по умолчанию в серверах mysqlотличаетсяу вас могут возникнуть проблемы, но это маловероятно).

Если вы используете INNODB, вам может потребоваться выполнить весь дамп в ТРАНЗАКЦИИ (между BEGIN; и COMMIT;)

Связанный контент