4

innodb テーブルを使用して mysql データベースをエクスポート/インポートする最速の方法は何ですか?

お客様の問題をデバッグするために、定期的に開発マシンにダウンロードする必要がある実稼働データベースがあります。現在これを行う方法は、"mysql -B dbname" を使用して生成され、gzip された通常のデータベース バックアップをダウンロードすることです。次に、「gunzip -c backup.gz | mysql -u root」を使用してインポートします。

「mysqldump --help」を読んでわかることから、mysqldump はデフォルトで --opt を使用して実行されます。これにより、インデックスをオフにするなど、インポートを高速化すると思われる多くのことがオンになるようです。テーブルを 1 つの大量の import ステートメントとしてインポートします。

これを行うためのより良い方法はありますか、またはさらに最適化する必要がありますか?

注:データベースを開発マシン (大量の RAM を搭載した比較的最近の macbook pro) にロードするのにかかる時間を最適化したいと考えています。現在、バックアップ時間とネットワーク転送時間は大きな問題ではありません。

アップデート：

回答で提起されたいくつかの質問に答えるには:

  • 本番データベースのスキーマは、週に数回まで変更されます。Rails を実行しているため、古い本番データに対して移行スクリプトを実行するのは比較的簡単です。

  • 本番データを開発環境に入れる必要があるのは、1 日または 1 時間単位になる可能性があります。これは、開発者が何に取り組んでいるかに完全に依存します。多くの場合、開発環境でデバッグする必要があるデータベース内のいくつかのテーブルにまたがる一部のデータの結果である特定の顧客の問題があります。

  • 正直なところ、mysqldump にかかる時間はわかりません。現在は 2 時間ごとに実行しているため、2 時間未満です。ただし、それは最適化しようとしているものではなく、開発者ワークステーションへのインポートを最適化する必要があります。

  • 完全な実稼働データベースは必要ありませんが、必要なものと不要なものを区別するのは簡単ではありません (外部キー関係を持つテーブルがたくさんあります)。これはおそらく最終的に行かなければならない場所ですが、できればもう少し長く避けたいと思っています.

4

2 に答える 2

3

It depends on how you define "fastest".

As Joel says, developer time is expensive. Mysqldump works and handles a lot of cases you'd otherwise have to handle yourself or spend time evaluating other products to see if they handle them.

The pertinent questions are:

How often does your production database schema change?

Note: I'm referring to adding, removing or renaming tables, columns, views and the like ie things that will break actual code.

How often do you need to put production data into a development environment?

In my experience, not very often at all. I've generally found that once a month is more than sufficient.

How long does mysqldump take?

If it's less than 8 hours it can be done overnight as a cron job. Problem solved.

Do you need all the data?

Another way to optimize this is to simply get a relevant subset of data. Of course this requires a custom script to be written to get a subset of entities and all relevant related entities but will yield the quickest end result. The script will also need to be maintained through schema changes so this is a time-consuming approach that should be used as an absolute last resort. Production samples should be large enough to include a sufficiently broad sample of data and identify any potential performance problems.

Conclusion

Basically, just use mysqldump until you absolutely can't. Spending time on another solution is time not spent developing.

于 2009-04-26T01:32:41.680 に答える
2

レプリケーションの使用を検討してください。これにより、コピーをリアルタイムで更新でき、MySQL レプリケーションにより、スレーブをシャットダウンする必要がある場合でも追いつくことができます。オンライン バックアップをサポートする MyISAM テーブルにデータをレプリケートする通常のサーバーで、並列 MySQL インスタンスを使用することもできます。テーブルが同じ定義を持っている限り、MySQL はこれを許可します。

検討する価値のあるもう 1 つのオプションは、著名な MySQL パフォーマンス スペシャリスト Percona の XtraBackup です。InnoDB のオンライン バックアップ ソリューションです。ただし、自分で調べたことがないので、安定性や、問題の実行可能な解決策でさえあることを保証しません.

于 2009-04-26T01:41:57.257 に答える