web-dev-qa-db-ja.com

mysqlインポートの速度を改善する

22GBの大規模なデータベースがあります。以前は、mysqldumpコマンドをgzip形式でバックアップしていました。

Gzファイルを抽出すると、.sqlの16.2GBファイルが生成されます

ローカルサーバーにデータベースをインポートしようとすると、インポートに約48時間かかります。インポートプロセスの速度を上げる方法はありますか？

また、パフォーマンスを向上させるためにハードウェアの変更が必要かどうかを知りたいです。

現在のシステム構成

 Processor: 4th Gen i5
 RAM: 8GB

＃update

my.cnfは次のとおりです

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
Nice        = 0

[mysqld]
#
# * Basic Settings
#
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address        = 127.0.0.1
#
# * Fine Tuning
#
key_buffer      = 16M
max_allowed_packet  = 512M
thread_stack        = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit   = 4M
query_cache_size        = 512M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries   = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M
#binlog_do_db       = include_database_name
#binlog_ignore_db   = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet  = 512M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer      = 512M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

3日間アップロードされており、現在9.9 GBがインポートされています。データベースには、MyISAMテーブルとInnoDBテーブルの両方があります。インポートのパフォーマンスを向上させるにはどうすればよいですか？

mysqldumpを使用してgz形式で各テーブルを個別にエクスポートし、次のコードを実行するPHPスクリプトを介して各テーブルをインポートします

$dir="./";
$files = scandir($dir, 1);
array_pop($files);
array_pop($files);
$tablecount=0;
foreach($files as $file){
    $tablecount++;
    echo $tablecount."     ";

    echo $file."\n";
    $command="gunzip < ".$file." | mysql -u root -pubuntu cms";

    echo exec($command);
}
mysqllinuxdatabase-administration
43
DharanBro

問題の理由を完全に理解するために、欠落している多くのパラメーターがあります。といった：

  1. MySQLバージョン
  2. ディスクの種類と速度
  3. MySQLサーバーを起動する前にサーバーのメモリを解放します
  4. mysqldumpの前後のiostat出力。
  5. 最初にダンプファイルを作成するために使用するパラメーターは何ですか。

などなど。

だから私はあなたの問題がディスクにあると推測しようとします、なぜなら私はそれらの1つに3TBのデータで管理するMySQLの150のインスタンスがあり、通常はディスクが問題だからです

今すぐソリューションに：

まず第一に-あなたのMySQLは最高のパフォーマンスのために設定されていません。

構成する最も重要な設定については、Perconaのブログ投稿で読むことができます： http://www.percona.com/blog/2014/01/28/10-mysql-settings-to-tune-after-installation /

特にパラメーターを確認してください：

innodb_buffer_pool_size 
innodb_flush_log_at_trx_commit
innodb_flush_method

問題がディスクである場合-同じドライブからファイルを読み取ることで、問題が悪化しています。

また、MySQLサーバーが十分なRAMが利用できないためにスワップを開始する場合-問題はさらに大きくなります。

それを把握するために、復元手順の前後にマシンで診断を実行する必要があります。

さらに、別のテクニックを使用して再構築タスクを実行することをお勧めします。これはmysqldumpよりも高速に動作します。

それはPercona Xtrabackupです- http://www.percona.com/doc/percona-xtrabackup/2.2/

バックアップを作成し、そこから復元するか、実行中のサーバーからストリーミングオプションで直接再構築する必要があります。

また、5.5以降のMySQLバージョン-InnoDBはMyISAMよりも高速に動作します。すべてのテーブルをそれに変更することを検討してください。

11
Tata

説明されている方法でダンプと復元を行うと、MySQLはデータのインポート時にインデックスを完全に再構築する必要があります。また、毎回データを解析する必要があります。

MySQLがすでに理解している形式でデータファイルをコピーできれば、はるかに効率的です。これを行う良い方法は、Perconaの innobackupex を使用することです

（オープンソースであり、 XtraBackup の一部として配布されています here からダウンロードできます）。

これにより、MyISAMテーブルのスナップショットが作成され、InnoDBテーブルの場合は、基礎となるファイルがコピーされ、トランザクションログがそれらに対して再生され、一貫した状態が確保されます。ダウンタイムなしでライブサーバーからこれを行うことができます（それがあなたの要件であるかどうかはわかりませんか？）

ドキュメントを読むことをお勧めしますが、バックアップをとるには最も簡単な形式を使用します。

$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
$ innobackupex --apply-log /path/to/BACKUP-DIR/

データが同じマシン上にある場合、innobackupexには単純な復元コマンドもあります。

$ innobackupex --copy-back /path/to/BACKUP-DIR

バックアップを実際に行うには、さらに多くのオプションと異なる方法がありますので、始める前にドキュメントをよく読んでください。

速度については、約600 IOPSを実行する低速のテストサーバーは、この方法を使用して約4時間で500 GBのバックアップを復元できます。

最後に、インポートを高速化するために何ができるかを説明しました。それは主にボトルネックが何であるかに依存します。通常、インポート操作はI/Oバウンドであり（io待機を確認することでテストできます）、高速化する方法は、ディスクスループットを高速化することです（ディスク自体が高速であるか、それらの多くが一致します）。

11
AndySavage

あなたができることの一つは

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS=0

また、値で遊ぶこともできます

innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_flush_method

my.cnfを使用して作業を進めますが、一般的には innodbパラメーターの残り も参照して、最適なものを確認する必要があります。

これは私が過去に抱えていた問題です。完全に取り組んだとは感じていませんが、始めからこの方向に自分自身を向けていたことを願っています。かなりの時間を節約できただろう。

7
fakedrake

「max_allowed_pa​​cket」変数を十分なサイズに増やしてください。これは、大量のテキストデータがある場合に非常に役立ちます。高性能のハードウェアを使用すると、データのインポート速度が確実に向上します。

mysql --max_allowed_packet=256M -u root -p < "database-file.sql"
5
koolkoda

RAMを増やし、プロセッサを高速化し、SSDを取得して書き込みを高速化します。挿入をバッチ処理して、個々の挿入よりも速く実行されるようにします。それは巨大なファイルであり、時間がかかります。

2
holtc

方法1：fakedrakeが示唆したように外部キーを無効にします。

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS = 0

方法2：BigDumpを使用して、mysqldumpファイルをチャンクしてからインポートします。 http://www.ozerov.de/bigdump/usage/

質問：アップロードしていると言いましたか？ダンプのインポート方法は？サーバー/コマンドラインから直接ではありませんか？

2
Vivek

私は同じ問題に対処しなければなりませんでした。 mysqldumpを使用してCSVファイルに出力していることがわかりました（次のように）。

mysqldump -u [username] -p -t -T/path/to/db/directory [database] --fields-enclosed-by=\" --fields-terminated-by=,

次に、mysqlクライアント内からLOAD DATA INFILEクエリを使用してそのデータをインポートします（次のように）。

LOAD DATA FROM INFILE /path/to/db/directory/table.csv INTO TABLE FIELDS TERMINATED BY ',';

データを含むSQLクエリを実行するよりも1桁高速になります。もちろん、すでに作成されている（および空の）テーブルにも依存します。

もちろん、最初に空のスキーマをエクスポートしてからインポートすることでも同様に実行できます。

2
Vinbot

選択肢は定かではありませんが、これを実行する最善の方法は、TataとAndySavageがすでに言ったことです。実稼働サーバーからデータファイルのスナップショットを取得し、Perconaを使用してローカルボックスにインストールすることです。 innobackupex。 InnoDbテーブルを一貫した方法でバックアップし、MyISAMテーブルの書き込みロックを実行します。

実稼働マシンで完全バックアップを準備します。

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html

バックアップファイルをローカルマシンにコピー（またはバックアップ中にSSH経由でパイプ-詳細 here ）して、それらを復元します。

バックアップを復元します。

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/restoring_a_backup_ibk.html

Innobackupexの完全なドキュメントは次の場所にあります。 http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html

復元時間は、SQLダンプの読み取りよりもはるかに高速です。

0
Diego