テスト データベースで約 1 年分のデータが消去されたとします。私は、早くても 1 年分のデータの 2 つの ID を取得し、遅くとももう 1 年分のデータを取得しました。したがって、ここで何が欠落しているかの範囲がわかります。質問です。データベースの完全なインスタンスから次のコマンドを使用して、欠落した情報チャンクを含むデータベースを修復するために使用できる作業ダンプを取得することに、まったく危険はありませんか? コマンド:
mysqldump -t --insert-ignore --skip-opt --single-transaction --quick --where="id<156789339" -w"id>124054297" -u root -p database table > partial.sql
これを gzip 圧縮/移動した後にインポートします:
zcat partial.sql.gz | mysql -u root -p database table
言及する価値のある注意点が 1 つあります。データは mysql 5.5 (percona) から取得され、mysql 5.1 インスタンスにインポートされますが、これによって発生する可能性のある互換性の問題は、私の知る限り存在しないと思います。
私が理解しているのは、ステートメント ( )-tの作成を避けるため、範囲が重複している場合にその ID がすでに存在するかどうかを無視するため、およびインポート時に物事を台無しにするような一連の操作を行わないようにするためです ( mysqldump のマニュアル ページによると)。エクスポートに必要なのはこれだけであること、そして間違いが起こる前にインポート時に何か見落としていることがないかを知りたいだけです。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
答え1
おそらくそれで大丈夫です。ただし、失敗する特殊なケースもあります。
ON DELETE CASCADE ステートメントを使用してテーブルを指す FOREIGN KEY が DB にあります。この場合、以前の削除の結果として他のデータが失われ、そのデータも検索してコピーする必要があります。DB が MYISAM を使用している場合は、外部キーがないため安全です。
以前のバージョンではサポートされていなかった特別な機能 (例: FULLTEXT インデックス) を使用しています。テスト データベースだとおっしゃっているので、モデルは同一だと思います。その場合、問題はないはずです。
異なるエンコーディング/照合2つのDBに非ASCII（ローカライズされた）テキストフィールドがある場合。モデルが同じであれば、問題は発生しません。（テーブルに明示的なエンコーディング定義がなく、mysqlサーバーのデフォルトのエンコーディングが異なる問題が発生する可能性はありますが、その可能性は低いです。
INNODB を使用している場合は、ダンプ全体を TRANSACTION (BEGIN; と COMMIT; の間) で実行することをお勧めします。