7 GBをインポートしていますfoobar.sql
ローカルデータベースのテーブルを復元します。
$ mysql -h localhost -u root 'my_data' < foobar.sql
$ mysql --version
/usr/local/mysql/bin/mysql Ver 14.12 Distrib 5.0.96, for Apple-darwin9.8.0 (i386) using readline 5.1
進行状況を監視するにはどうすればよいですか?
* nixのCLIからダンプファイルからインポートするだけの場合。
mysql -uxxx -pxxx dbname < /sqlfile.sql
次に、最初に パイプビューア をOSにインストールしてから、次のような方法を試してください。
pv sqlfile.sql | mysql -uxxx -pxxxx dbname
プログラムの実行中に進行状況バーが表示されます。
これは非常に便利で、mysqldumpの進行状況の推定値を取得するためにも使用できます。
pvはsqlfile.sql
をダンプし、それらをmysqlに渡します(パイプ演算子のため)。ダンプしている間、進行状況が表示されます。かっこいいのは、mysqlがデータを処理できるのと同じ速さでデータを取得するため、pvがインポートの進行状況を表示できることです。私には証拠がありません。しかし、そうです。バッファーが使用されていると思いますが、ある時点で、mysql
はまだビジー状態の処理中にデータを読み取っていないと思います。
インポートをすでに開始している場合は、別のウィンドウでこのコマンドを実行して、データベースの現在のサイズを確認できます。これは、インポートする.sqlファイルの合計サイズがわかっている場合に役立ちます。
SELECT table_schema "Data Base Name", sum( data_length + index_length ) / 1024 / 1024 "Data Base Size in MiB"
FROM information_schema.TABLES GROUP BY table_schema;
クレジット: http://forums.mysql.com/read.php?108,201578,201578
MySQL 8.0リファレンス は、精度について次のように述べています。
DATA_LENGTH
MyISAMの場合、DATA_LENGTHはデータファイルの長さ(バイト単位)です。
InnoDBの場合、DATA_LENGTHは、クラスター化インデックスに割り当てられたメモリのおおよその量(バイト単位)です。具体的には、ページ単位のクラスター化インデックスサイズにInnoDBページサイズを掛けたものです。
INDEX_LENGTH
MyISAMの場合、INDEX_LENGTHはインデックスファイルの長さ(バイト単位)です。
InnoDBの場合、INDEX_LENGTHは、非クラスター化インデックスに割り当てられたメモリのおおよその量(バイト単位)です。具体的には、非クラスター化インデックスのサイズ(ページ単位)にInnoDBページサイズを掛けた合計です。
単一のデータベースのmysqldumpを実行すると、すべてのテーブルがアルファベット順にダンプされます。
当然、データベースへのmysqldumpのリロードもアルファベット順になります。
SHOW PROCESSLISTを実行するだけです。 mysqldumpを実行しているDB接続を見つけます。ダンプがリロードされると、DB接続は消えます。
ダンプファイルにどのテーブルがあるかを知りたい場合は、foobar.sqlに対してこれを実行します
cat foobar.sql | grep "^CREATE TABLE" | awk '{print $3}'
テーブルが1つしかないことに気づかず申し訳ありません。
テーブルがMyISAMの場合、監視する唯一の方法はOSの観点からです。理由?テーブルはリロード中は書き込みロックされています。あなたは何を求めますか? .MYD
および.MYI
ファイルのサイズ。もちろん、それをインポート元の他のDBサーバーのテーブルサイズと比較する必要があります。
テーブルがInnoDBであり、 innodb_file_per_table が有効になっている場合、監視する唯一の方法はOSの観点からです。理由?テーブルはリロード中は書き込みロックされています。あなたは何を求めますか? .ibd
ファイルのサイズ。もちろん、それをインポート元の他のDBサーバーのテーブルサイズと比較する必要があります。
テーブルがInnoDBであり、innodb_file_per_tableが無効になっている場合、OSの視点でさえも役立ちません。
私は昨年このようなものに対処しました: 「type db.sql | mysql」の進行状況を%取得するにはどうすればよいですか
標準のmysqldumpは次のようにテーブルを書き込みロックするため:
LOCK TABLES `a` WRITE;
/*!40000 ALTER TABLE `a` DISABLE KEYS */;
INSERT INTO `a` VALUES (123),(451),(199),(0),(23);
/*!40000 ALTER TABLE `a` ENABLE KEYS */;
UNLOCK TABLES;
その場合、テーブルロックが解放されるまで、mysqlで進行状況を取得する方法はありません。
LOCK TABLES
とUNLOCK TABLES
がダンプファイルからコメント化されている場合...
2秒ごとに、実行中のプロセスが表示されます。
watch 'echo "show processlist;" | mysql -uuser -ppassword';
頻度を減らしたい場合は、-n x
を追加します。ここで、xは秒数です。 5秒は次のようになります。
watch -n 5 'echo "show processlist;" | mysql -uuser -ppassword';
停止しているかどうかを確認するだけの場合は、クエリを実行できます
show processlist;
何が実行されているかを確認します。
Pvを機能させることができない人、またはpvが嘘をつく人のための解決策として。データを含む/ var/lib/mysqlのibdata1ファイルのサイズを監視できます。これにより、ソースサーバーのファイルサイズと同じサイズ(またはその前後)になります。
多くのテーブルがある場合は、/ var/lib/mysql/<データベース名>にテーブルが1つずつ表示されることも確認できます。
たまたまこの事実を利用したのは、長期間のデータベースで3〜4年の間に約20Gのログファイルが作成されたときです。転送に時間がかかっていることに気づき、この手法を使用して進捗状況を監視しました。
データベースがどこか他の場所にあるファイルを含まない日が夜明けになる可能性は非常に低いと思います。その間、ファイルを監視して、転送の進行状況を確認できます。私が提案した方法は、最初のSQLデータベースが作成されて以来、何らかの形で実行できる方法でした。手動騎手が頼りになる可能性のある「公式の」手法であると示唆するつもりはなかった。コンピュータ全般、特にUNIXに習熟していることを前提としています。
それ以外の場合はDBが静かで(他のユーザーがアクティブになっていないなど)、読み取り/書き込みアクティビティだけを表示したい場合は、次のようなことを行ってください。
mysqladmin -h<Host>-uroot -p<yourpass> extended -r -i 10 |grep 'row'
読み取り/書き込み/挿入/待機/更新の数が表示されます。
たとえば挿入する場合、次のようなものが表示されます。
Innodb_rows_inserted | 28958
28958は、間隔(私の場合は10秒)に挿入された行の数です。
mysqldump
を使用してパイプビューアの例を探している人は、次のようにします。
mysqldump -hxxx -uxxx -p dbname | pv -W > dump.sql
-W
フラグは、進行状況を表示する前に(プロンプトの後)最初のバイトが来るのを待つようpvに指示するだけです
gnu coreutils/ddバージョン> = 8.24(2015年7月3日リリース)の場合、ddのstatus = progress引数を使用できます。
例えば
cat dbdump.gz | gzip -d | mysql --password=root -v | time dd of=/dev/null status=progress
* PS:notはbusyboxで機能します、busybox ddは「status = progress」を理解しません
OK、別の回避策。しかし、それは最悪で不正確なオプションかもしれません。
そうは言っても、ここに私のWindows向けのソリューションがあります。
を押してタスクマネージャーを開きます
CTRL + SHIFT + ESC
「mysqld.exe」ディスク値の速度をコピーします
e.g. 11mb/s
これを次のような計算機に入れます: https://techinternets.com/copy_calc?do
ETAを見積もります。私の場合は:
Speed: 8 MB/s
Size: 4.9 GB
0 Hours, 11 Minutes and 29 Seconds
結果:
Beg -> 11:19
ETA -> 11:31
End -> 11:39
インポートする500 MBのSQLファイルがありました。 2時間くらいかかりました。 mysqldのCPU使用率は、インポートプロセスの開始時に100%近くでした。しかし、数分後、CPU使用率は15%に低下しました。
私は多くの微調整を試しましたが、これだけが私を助けました:innodb_flush_log_at_trx_commit = 0
この設定を適用してmysqlを再起動した後、インポートはわずか3分で完了しました。 CPU使用率は常に100%でした。
この設定を使用する場合は、「/ etc/mysql/my.cnf」ファイルを編集し、「Sudo service mysql restart」を使用してmysqlサーバーを再起動する必要があります。
これが私の「my.conf」ファイルの設定です。
[mysqld]
innodb_log_buffer_size = 256M
innodb_fast_shutdown = 0
innodb-doublewrite = OFF
innodb_io_capacity = 1000
innodb_flush_log_at_trx_commit = 0
注意: "innodb_flush_log_at_trx_commit = 0"は、毎秒だけコミットを行います。したがって、これはACIDに準拠していませんが、一括インポートは許容されます。インポート後、「innodb_flush_log_at_trx_commit」の値を1に戻し、データベースを再起動できます。 mySQLドキュメントへのリンク
私は https://github.com/Xfennec/progress を使用してwatch
で監視しています
watch progress
インポートの起動後zcat example.sql.gz | mysql -u root -proot -h localhost example
フォルダー\ Msql\Data [DB名]のインポートを監視できます