MySQLdumpは、MySQLデータベースの論理バックアップを実行するために使用されるクライアントユーティリティです。この人気のある移行ツールは、次のようなMySQLのさまざまなユースケースに役立ちます。
- データベースのバックアップと復元。
- あるサーバーから別のサーバーへのデータの移行。
- さまざまなマネージドMySQLサービスプロバイダー間でのデータの移行。
- 異なるバージョンのMySQL間でのデータの移行。
Mysqldumpは、ソースデータベースオブジェクトを読み取り、ダンプファイルに格納される一連のSQLステートメントを生成することで機能します。宛先データベースサーバーでこれらのステートメントを再生することにより、元のデータが再構築されます。このモデルはデータベース全体の読み取りと基本的な再構築を使用するため、大規模なデータベースでは、ダンプと復元の両方に時間のかかる操作が行われます。ダンプまたは復元中にエラーが発生した場合、問題を修正して操作を再実行する可能性があるため、プロセスが煩雑になる可能性があります。これが、ダンプと復元のアクティビティを開始する前に十分に計画することが重要である理由です。
この2部構成のブログシリーズでは、ダンプと復元のアクティビティを成功させるために事前に処理する必要がある一般的な側面のいくつかについて説明します。最初の部分では、MySQLテーブルデータをインポートするときに注意する必要のある前提条件に焦点を当て、2番目の部分では、ストアドプログラムオブジェクトとビューのインポートを処理する方法について説明します。
1。スペース要件
まず、宛先データベースボリュームにインポートされたデータを保持するのに十分なスペースがあることを確認することが重要です。特に、宛先のMySQLデータベースでバイナリログが有効になっている場合は注意が必要です。データのインポート中に生成されるバイナリログは、データ自体とほぼ同じサイズになる可能性があるためです。 1台のサーバーでデータを復元し、それを複製する場合は、バイナリログが必要です。このような場合は、ソースデータベースのサイズの2倍を超える宛先サイズを計画することをお勧めします。
mysqldump出力ファイルを生成するボリュームで十分なスペースが使用可能であることを確認することも重要です。これらの予防措置を講じないと、長時間実行した後のスペースが不足しているためにダンプまたは復元が失敗し、生産的な時間と労力が失われる可能性があります。
2。 Sql_mode
MySQLサーバーのsql_mode設定は、サーバーが操作に対して実行するSQLステートメントの構文とデータ検証チェックを決定します。 sql_modeを確認することが重要です ソースと宛先のMySQLサーバーは相互に互換性があります。そうしないと、取得したダンプの復元中に障害が発生する可能性があります。例を使ってこれを示しましょう。
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
厳密なsql_modeを想定します （およびNO_ZERO_DATE ）ソースでは無効になっていますが、宛先では有効になっています–このような行を復元すると、次のような失敗が発生します：
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
通常、mysqldumpの一部としてコンパクトオプションを有効にしてコンパクトダンプを取得している場合、このような問題が発生します。
コンパクトが無効になっている場合（デフォルト）、mysqldumpはダンプの一部として次の条件ステートメントを生成するため、この問題は発生しません。
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
これは、復元中にsql_modeを意味します 'NO_AUTO_VALUE_ON_ZERO'に設定されています テーブルデータを復元する前に、復元が正常に行われるようにします。
3。 Unique_checksとforeign_key_checks
デフォルトでは（–compactオプションを使用しない場合）、mysqldumpは以下も設定します：
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
ここで説明するように、セッション中に一意性チェックを一時的にオフにすることで、復元操作を高速化できます。大きなテーブルの場合、InnoDBは変更バッファーを使用してセカンダリインデックスレコードをバッチで書き込むことができるため、これによりディスクI/Oが大幅に節約されます。
FOREIGN KEYをお持ちの場合 テーブルに制約がある場合は、復元セッション中に外部キーチェックをオフにすることで、テーブルの復元操作を高速化できます。大きなテーブルの場合、これによりディスクI/Oを大幅に節約できます。
FOREIGN_KEY_CHECKSを無効にする また、復元操作中の外部キー制約チェックによるエラーを回避するのにも役立ちます。外部キー制約のあるテーブルが作成されるときはいつでも、MySQLは外部キーによって参照される親テーブルがすでに存在することを想定しています。 mysqldumpユーティリティはテーブルをアルファベット順にダンプするため、これは問題です。これを示す例を見てみましょう。
ソースデータベースには、2つのテーブルがあります：
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
テーブルref_table solution_tableを参照する外部キー制約があります 。アルファベット順に基づいて、mysqldumpは最初にref_tableの内容をダンプします 。復元時にこれを再生すると、次のエラーで失敗します：
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
これは、‘ref_table’のcreatetableステートメントの実行中に発生します 。
要約すると、--compactを指定すると、発生する可能性のある問題に注意してください。 mysqldumpの実行中のオプション。
4。 mysqldumpの実行に必要な権限
データベースをダンプするためにmysqldumpに必要な最小権限はSELECTです。 そのデータベースで。
ただし、データベースにビューがある場合、mysqldumpは常にデータベースのテーブルとともにビューをダンプするため、SHOWVIEW権限も必要になります。 SHOW VIEWがないとします 権限がある場合、mysqldumpは次のように失敗します：
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
もう1つの重要な点は、ダンプユーザーがSELECTを持っているかどうかです。 データベースの特定のテーブルに対する権限のみ。mysqldumpはその特定のテーブルのデータのみをダンプし、他のテーブルまたはビューを自動的に無視します。
したがって、後で予期しない事態や失敗を避けるために、mysqldumpを実行するユーザーがすべての適切な権限を事前に持っていることを確認してください。
|
5。 Max_allowed_packet
mysqlによって処理される最大の通信パケットは、設定max_allowed_packetによって決定されます。 。インポートのコンテキストでは、通信パケットは、復元中にMySQLサーバーに送信される単一のSQLステートメント、またはダンプ中にクライアントに送信される単一の行です。
max_allowed_packetのデフォルト値 mysqldumpの場合は24MBです。 mysqldumpがこれより大きいパケットを受信した場合、エラーが発生する可能性があります：
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
したがって、mysqldumpがmax_allowed_packetと同じかそれ以上の値を使用するようにします。 ソースMySQLインスタンスで構成されています。
オプションはフラグ--max-allowed-packet=value mysqldumpを呼び出すとき。
ダンプを復元するときは、max_allowed_packetを確認してください。 宛先サーバーのサイズは、ダンプファイルからパケットを受信するのに十分な大きさです。
それ以外の場合、ダンプの復元中にエラーメッセージが表示されます：
ERROR 2006 (HY000) at line 70: MySQL server has gone away
MySQLサーバーがシャットダウンまたはクラッシュしたと思われる場合があるため、このエラーは少し誤解を招く可能性があります。ただし、これは、サーバーが構成されたサイズのmax_allowed_packetよりも大きいサイズのパケットを受信したことを意味します。 。繰り返しになりますが、ベストプラクティスは、max_allowed_packetを確認することです。 移行先サーバーの値は、移行元サーバーの値と同じです。これは、後でエラーに直面するのではなく、事前に確認して適切に設定できる重要な設定でもあります。
mysqldumpシリーズのこの最初のパートでは、複数の試行と非生産的な時間を回避するために、大規模なMySQLデータベースのダンプと復元操作を成功させるための前提条件について説明しました。
次のパートでは、MySQLデータベースからストアドプログラムとビューをインポートするためのベストプラクティスについて説明します。