import dump MySQL très lent
Bonjour, Je vous expose mon problème: Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard pour y migrer notre master MySQL actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520 Il y a environ 400G à migrer selon:
SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur. J'importe le dump dans MySQL (mysql < /mon/dump.sql) J'ai lançé ça vendredi aprem, aujourd'hui je ne suis même pas à la moitié. *Je trouve ça super lent* ! :( Points faibles: downgrade sur des HDD classique (Toshiba 7200RPM). dump lu et mysql écrit sur le même Raid array. J'ai un peu du mal à interpreter les top,iotop,iostat, etc... ça pourrait coincerau niveau de? disque, raid, lvm, os, mysql Merci de votre aide ;) quelques diags: # top
top - 16:14:55 up 4 days, 5:17, 0 users, load average: 1.08, 1.43, 1.52 Tasks: 198 total, 1 running, 197 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.0 sy, 0.0 ni, 92.9 id, 6.9 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 13206078+total, 13143241+used, 628360 free, 163260 buffers KiB Swap: 523260 total, 180480 used, 342780 free, 14950824 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20118 mysql 20 0 0.107t 0.107t 3400 S 1.996 86.84 263:48.50 mysqld
# iotop
Total DISK READ : 0.00 B/s | Total DISK WRITE : 5.15 M/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 5.21 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 22591 be/4 mysql 0.00 B/s 2.63 M/s 0.00 % 99.99 % mysqld --defaults-file=/etc/mysql/my.cnf
le READ ne bouge pas de 0...?!! le WRITE fait quelques pointes à 15M. ça me parait bien peu. # iostat -x sda 5
Linux 3.10.9-xxxx-grs-ipv6-64 () 12/09/2013 _x86_64_ (12 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0.49 0.10 0.10 5.11 0.00 94.19 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.04 10.25 2.92 181.33 331.98 9347.70 105.07 4.33 23.53 6.76 23.80 3.32 61.14 avg-cpu: %user %nice %system %iowait %steal %idle 0.37 0.00 0.03 7.02 0.00 92.58 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 7.60 0.00 102.40 0.00 6775.20 132.33 14.43 184.29 0.00 184.29 9.34 95.68 avg-cpu: %user %nice %system %iowait %steal %idle 0.33 0.00 0.05 7.93 0.00 91.68 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 8.40 0.00 117.20 0.00 7396.80 126.23 32.26 234.63 0.00 234.63 8.16 95.68 avg-cpu: %user %nice %system %iowait %steal %idle 0.28 0.00 0.02 7.80 0.00 91.90 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 9.80 0.00 222.20 0.00 8681.60 78.14 48.62 236.17 0.00 236.17 4.35 96.64 avg-cpu: %user %nice %system %iowait %steal %idle 0.27 0.00 0.05 8.00 0.00 91.68 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 8.60 0.00 135.60 0.00 5524.00 81.47 54.92 402.54 0.00 402.54 7.13 96.72 avg-cpu: %user %nice %system %iowait %steal %idle 0.13 0.00 0.02 8.50 0.00 91.35 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 5.00 0.00 93.60 0.00 4231.20 90.41 52.75 471.53 0.00 471.53 10.50 98.32 avg-cpu: %user %nice %system %iowait %steal %idle 0.27 0.00 0.07 7.82 0.00 91.85 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 7.80 25.40 188.20 3251.20 7312.00 98.91 44.31 237.12 2.46 268.79 4.53 96.72 avg-cpu: %user %nice %system %iowait %steal %idle 0.28 0.00 0.03 7.50 0.00 92.18 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 11.00 0.00 224.40 0.00 10137.60 90.35 57.25 258.35 0.00 258.35 4.29 96.32 avg-cpu: %user %nice %system %iowait %steal %idle 0.13 0.00 0.05 8.08 0.00 91.73 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 8.20 0.00 212.80 0.00 8072.00 75.86 55.89 266.83 0.00 266.83 4.62 98.24 avg-cpu: %user %nice %system %iowait %steal %idle 0.13 0.00 0.05 8.13 0.00 91.68 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 7.80 0.00 199.80 0.00 7280.80 72.88 63.85 299.11 0.00 299.11 4.91 98.16
On 2013-12-09 16:33, Axel Vittecoq wrote:
Bonjour,
Je vous expose mon problème:
Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard pour y migrer notre master MySQL actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520
Il y a environ 400G à migrer selon:
SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur. J'importe le dump dans MySQL (mysql < /mon/dump.sql) Mauvais outils .....
http://dev.mysql.com/doc/refman/5.6/en/load-data.html Sinon jouer avec alter table ... disable keys / enable keys. -- Thomas
A voir aussi : si tes tables contiennent des index (ce dont je ne doute pas vu la volumétrie), il est préférable supprimer les index avant le restore (donc idéalement avant le dump). Pourquoi ? à chaque insert, les index sont recalculés. Si au début ca va vite, après quelques millions de lignes, ca devient plus coton. Une fois la restore faite, remettre les index en place. Joël. From: frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] On Behalf Of Thomas Pedoussaut Sent: lundi 9 décembre 2013 16:39 To: Axel Vittecoq Cc: French SysAdmin Group Subject: Re: [FRsAG] import dump MySQL très lent On 2013-12-09 16:33, Axel Vittecoq wrote: Bonjour, Je vous expose mon problème: Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard pour y migrer notre master MySQL actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520 Il y a environ 400G à migrer selon: SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema; J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur. J'importe le dump dans MySQL (mysql < /mon/dump.sql) Mauvais outils ..... http://dev.mysql.com/doc/refman/5.6/en/load-data.html Sinon jouer avec alter table ... disable keys / enable keys. -- Thomas
Salut, Fais un dump par table. Ensuite tu importes en parallèle. Par exemple tu fais 4 threads d'import. L'idée c'est de répartir les tables équitablement. Dans ton dump mets les options pour le disable keys/ensable keys. La parallélisation te permettra de tirer parti de ton hard. Dans l'idéal tu peux aussi passer par un autre disque que le serveur final. Sur un lan privé tu auras tendance à "piper" le dump direct vers l'import. Tu gagnes sur les io. -- Guillaume Le 9 déc. 2013 19:36, "Joël DEREFINKO" <joel.derefinko@118218.fr> a écrit :
A voir aussi : si tes tables contiennent des index (ce dont je ne doute pas vu la volumétrie), il est préférable supprimer les index avant le restore (donc idéalement avant le dump).
Pourquoi ? à chaque insert, les index sont recalculés. Si au début ca va vite, après quelques millions de lignes, ca devient plus coton.
Une fois la restore faite, remettre les index en place.
Joël.
*From:* frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] *On Behalf Of *Thomas Pedoussaut *Sent:* lundi 9 décembre 2013 16:39 *To:* Axel Vittecoq *Cc:* French SysAdmin Group *Subject:* Re: [FRsAG] import dump MySQL très lent
On 2013-12-09 16:33, Axel Vittecoq wrote:
Bonjour,
Je vous expose mon problème:
Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard
pour y migrer notre master MySQL
actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520
Il y a environ 400G à migrer selon:
SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur.
J'importe le dump dans MySQL (mysql < /mon/dump.sql)
Mauvais outils .....
http://dev.mysql.com/doc/refman/5.6/en/load-data.html
Sinon jouer avec alter table ... disable keys / enable keys.
-- Thomas
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
C'est vrai que c'est trop lent... Peux ton avoir une partie de la config MySQL ? Ce sont des tables InnoDB ? Le 9 décembre 2013 20:21, DjinnS DjinnS <snnijd@gmail.com> a écrit :
Salut,
Fais un dump par table. Ensuite tu importes en parallèle. Par exemple tu fais 4 threads d'import. L'idée c'est de répartir les tables équitablement.
Dans ton dump mets les options pour le disable keys/ensable keys.
La parallélisation te permettra de tirer parti de ton hard.
Dans l'idéal tu peux aussi passer par un autre disque que le serveur final. Sur un lan privé tu auras tendance à "piper" le dump direct vers l'import. Tu gagnes sur les io.
-- Guillaume Le 9 déc. 2013 19:36, "Joël DEREFINKO" <joel.derefinko@118218.fr> a écrit :
A voir aussi : si tes tables contiennent des index (ce dont je ne doute pas vu la volumétrie), il est préférable supprimer les index avant le restore (donc idéalement avant le dump).
Pourquoi ? à chaque insert, les index sont recalculés. Si au début ca va vite, après quelques millions de lignes, ca devient plus coton.
Une fois la restore faite, remettre les index en place.
Joël.
*From:* frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] *On Behalf Of *Thomas Pedoussaut *Sent:* lundi 9 décembre 2013 16:39 *To:* Axel Vittecoq *Cc:* French SysAdmin Group *Subject:* Re: [FRsAG] import dump MySQL très lent
On 2013-12-09 16:33, Axel Vittecoq wrote:
Bonjour,
Je vous expose mon problème:
Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard
pour y migrer notre master MySQL
actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520
Il y a environ 400G à migrer selon:
SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur.
J'importe le dump dans MySQL (mysql < /mon/dump.sql)
Mauvais outils .....
http://dev.mysql.com/doc/refman/5.6/en/load-data.html
Sinon jouer avec alter table ... disable keys / enable keys.
-- Thomas
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
oui mysqldump c'est une mauvaise idée en fin de compte. j'ai lançé ça un peu vite avant le WE en pensant que 2 jours lui suffirait ! les import parallèles ça ferait plus d'IO en même temps donc pas forcement mieux?! le load data à l'air intéressant, ça nécessite un peu de préparation d'abord quand même au final je pensais faire, comme suggéré, un backup à froid: une copie du datadir (/var/lib/mysql) d'un slave que je peux arrêter à souhait. ou dans le même genre j'ai repéré ça http://www.percona.com/software/percona-xtrabackup pour du hotbackup mais ça doit bien marcher à froid. full InnoDB [mysqld]
character-set-server = utf8 user = mysql port = 3306 socket = /var/run/mysqld/mysqld.sock pid-file = /var/run/mysqld/mysqld.pid log-error = /var/log/mysql/mysqld.err log-slow-queries = /var/log/mysql/mysqld-slow_queries.log long_query_time = 300 basedir = /usr datadir = /var/lib/mysql/db-master skip-external-locking key_buffer = 16M max_allowed_packet = 32M table_cache = 64 sort_buffer_size = 512K net_buffer_length = 8K read_buffer_size = 256K read_rnd_buffer_size = 512K default-storage-engine = INNODB innodb_buffer_pool_size = 100G innodb_additional_mem_pool_size = 20M innodb_data_file_path = ibdata1:10M:autoextend:max:10G innodb_log_file_size = 5M innodb_log_buffer_size = 8M innodb_log_files_in_group=2 innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 innodb_file_per_table
tmpdir en tmpfs innodb_flush_log_at_trx_commit = 0 pour le moment Le 9 décembre 2013 23:10, Greg <greg-frsag@duchatelet.net> a écrit :
C'est vrai que c'est trop lent... Peux ton avoir une partie de la config MySQL ? Ce sont des tables InnoDB ?
Le 9 décembre 2013 20:21, DjinnS DjinnS <snnijd@gmail.com> a écrit :
Salut,
Fais un dump par table. Ensuite tu importes en parallèle. Par exemple tu fais 4 threads d'import. L'idée c'est de répartir les tables équitablement.
Dans ton dump mets les options pour le disable keys/ensable keys.
La parallélisation te permettra de tirer parti de ton hard.
Dans l'idéal tu peux aussi passer par un autre disque que le serveur final. Sur un lan privé tu auras tendance à "piper" le dump direct vers l'import. Tu gagnes sur les io.
-- Guillaume Le 9 déc. 2013 19:36, "Joël DEREFINKO" <joel.derefinko@118218.fr> a écrit :
A voir aussi : si tes tables contiennent des index (ce dont je ne doute pas vu la volumétrie), il est préférable supprimer les index avant le restore (donc idéalement avant le dump).
Pourquoi ? à chaque insert, les index sont recalculés. Si au début ca va vite, après quelques millions de lignes, ca devient plus coton.
Une fois la restore faite, remettre les index en place.
Joël.
*From:* frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] *On Behalf Of *Thomas Pedoussaut *Sent:* lundi 9 décembre 2013 16:39 *To:* Axel Vittecoq *Cc:* French SysAdmin Group *Subject:* Re: [FRsAG] import dump MySQL très lent
On 2013-12-09 16:33, Axel Vittecoq wrote:
Bonjour,
Je vous expose mon problème:
Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard
pour y migrer notre master MySQL
actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520
Il y a environ 400G à migrer selon:
SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur.
J'importe le dump dans MySQL (mysql < /mon/dump.sql)
Mauvais outils .....
http://dev.mysql.com/doc/refman/5.6/en/load-data.html
Sinon jouer avec alter table ... disable keys / enable keys.
-- Thomas
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
C'est le but de faire plus d'io :) avec une thread d'import tu ne vas pas exploiter les capacité de ton serveur. Ce qui te limite c'est MySQL. Ce n'est pas un problème de conf. Le disable/enable keys est très important. Si tu ne changes pas de version de MySQL tu peux le faire avec une simple copie (voire même un rsync avec le dernier suite à un lock+flush). Si tu changes de version il vaut mieux faire un export/import pour bien reconstruire les données. Le 10 déc. 2013 14:43, "Axel Vittecoq" <avittecoq@multiposting.fr> a écrit :
oui mysqldump c'est une mauvaise idée en fin de compte. j'ai lançé ça un peu vite avant le WE en pensant que 2 jours lui suffirait !
les import parallèles ça ferait plus d'IO en même temps donc pas forcement mieux?!
le load data à l'air intéressant, ça nécessite un peu de préparation d'abord quand même
au final je pensais faire, comme suggéré, un backup à froid: une copie du datadir (/var/lib/mysql) d'un slave que je peux arrêter à souhait.
ou dans le même genre j'ai repéré ça http://www.percona.com/software/percona-xtrabackup pour du hotbackup mais ça doit bien marcher à froid.
full InnoDB
[mysqld]
character-set-server = utf8 user = mysql port = 3306 socket = /var/run/mysqld/mysqld.sock pid-file = /var/run/mysqld/mysqld.pid log-error = /var/log/mysql/mysqld.err log-slow-queries = /var/log/mysql/mysqld-slow_queries.log long_query_time = 300 basedir = /usr datadir = /var/lib/mysql/db-master skip-external-locking key_buffer = 16M max_allowed_packet = 32M table_cache = 64 sort_buffer_size = 512K net_buffer_length = 8K read_buffer_size = 256K read_rnd_buffer_size = 512K default-storage-engine = INNODB innodb_buffer_pool_size = 100G innodb_additional_mem_pool_size = 20M innodb_data_file_path = ibdata1:10M:autoextend:max:10G innodb_log_file_size = 5M innodb_log_buffer_size = 8M innodb_log_files_in_group=2 innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 innodb_file_per_table
tmpdir en tmpfs innodb_flush_log_at_trx_commit = 0 pour le moment
Le 9 décembre 2013 23:10, Greg <greg-frsag@duchatelet.net> a écrit :
C'est vrai que c'est trop lent... Peux ton avoir une partie de la config MySQL ? Ce sont des tables InnoDB ?
Le 9 décembre 2013 20:21, DjinnS DjinnS <snnijd@gmail.com> a écrit :
Salut,
Fais un dump par table. Ensuite tu importes en parallèle. Par exemple tu fais 4 threads d'import. L'idée c'est de répartir les tables équitablement.
Dans ton dump mets les options pour le disable keys/ensable keys.
La parallélisation te permettra de tirer parti de ton hard.
Dans l'idéal tu peux aussi passer par un autre disque que le serveur final. Sur un lan privé tu auras tendance à "piper" le dump direct vers l'import. Tu gagnes sur les io.
-- Guillaume Le 9 déc. 2013 19:36, "Joël DEREFINKO" <joel.derefinko@118218.fr> a écrit :
A voir aussi : si tes tables contiennent des index (ce dont je ne doute pas vu la volumétrie), il est préférable supprimer les index avant le restore (donc idéalement avant le dump).
Pourquoi ? à chaque insert, les index sont recalculés. Si au début ca va vite, après quelques millions de lignes, ca devient plus coton.
Une fois la restore faite, remettre les index en place.
Joël.
*From:* frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] *On Behalf Of *Thomas Pedoussaut *Sent:* lundi 9 décembre 2013 16:39 *To:* Axel Vittecoq *Cc:* French SysAdmin Group *Subject:* Re: [FRsAG] import dump MySQL très lent
On 2013-12-09 16:33, Axel Vittecoq wrote:
Bonjour,
Je vous expose mon problème:
Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard
pour y migrer notre master MySQL
actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520
Il y a environ 400G à migrer selon:
SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur.
J'importe le dump dans MySQL (mysql < /mon/dump.sql)
Mauvais outils .....
http://dev.mysql.com/doc/refman/5.6/en/load-data.html
Sinon jouer avec alter table ... disable keys / enable keys.
-- Thomas
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Ton logfile innodb est beaucoup trop petit, essayes ceci : service mysql stop rm -vf /var/lib/mysql/db-master/ib_log* innodb_log_file_size = 1024M service mysql start (il va créer les fichier ib_logfile1 et 2) C'est un autre débat mais je ne pense pas qu'un dump mysqldump soit "mauvais", il a le mérite d'être compatible entre versions de MySQL / MariaDB. Je fais un dump par table, 8 en //, tout simplement : mysql -ABN -e "SELECT TABLE_SCHEMA, TABLE_NAME FROM TABLES WHERE TABLE_SCHEMA NOT LIKE '%_schema'" information_schema | xargs -n2 -P8 -I {} dash -c 'a="{}"; echo "$a" | while read b c ; do mysqldump $b $c | gzip -9
backup/$b.$c.sql.gz ; break ; done'
(la boucle while read est moche mais c'est ce qui m'est venu à l'esprit sans lire de manpage) Tu peux ainsi restaurer de la même manière, en parallèle grace à xargs. Greg Le 10 décembre 2013 21:14, DjinnS DjinnS <snnijd@gmail.com> a écrit :
C'est le but de faire plus d'io :) avec une thread d'import tu ne vas pas exploiter les capacité de ton serveur.
Ce qui te limite c'est MySQL. Ce n'est pas un problème de conf. Le disable/enable keys est très important.
Si tu ne changes pas de version de MySQL tu peux le faire avec une simple copie (voire même un rsync avec le dernier suite à un lock+flush).
Si tu changes de version il vaut mieux faire un export/import pour bien reconstruire les données. Le 10 déc. 2013 14:43, "Axel Vittecoq" <avittecoq@multiposting.fr> a écrit :
oui mysqldump c'est une mauvaise idée en fin de compte. j'ai lançé ça un
peu vite avant le WE en pensant que 2 jours lui suffirait !
les import parallèles ça ferait plus d'IO en même temps donc pas forcement mieux?!
le load data à l'air intéressant, ça nécessite un peu de préparation d'abord quand même
au final je pensais faire, comme suggéré, un backup à froid: une copie du datadir (/var/lib/mysql) d'un slave que je peux arrêter à souhait.
ou dans le même genre j'ai repéré ça http://www.percona.com/software/percona-xtrabackup pour du hotbackup mais ça doit bien marcher à froid.
full InnoDB
[mysqld]
character-set-server = utf8 user = mysql port = 3306 socket = /var/run/mysqld/mysqld.sock pid-file = /var/run/mysqld/mysqld.pid log-error = /var/log/mysql/mysqld.err log-slow-queries = /var/log/mysql/mysqld-slow_queries.log long_query_time = 300 basedir = /usr datadir = /var/lib/mysql/db-master skip-external-locking key_buffer = 16M max_allowed_packet = 32M table_cache = 64 sort_buffer_size = 512K net_buffer_length = 8K read_buffer_size = 256K read_rnd_buffer_size = 512K default-storage-engine = INNODB innodb_buffer_pool_size = 100G innodb_additional_mem_pool_size = 20M innodb_data_file_path = ibdata1:10M:autoextend:max:10G innodb_log_file_size = 5M innodb_log_buffer_size = 8M innodb_log_files_in_group=2 innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 innodb_file_per_table
tmpdir en tmpfs innodb_flush_log_at_trx_commit = 0 pour le moment
Le 9 décembre 2013 23:10, Greg <greg-frsag@duchatelet.net> a écrit :
C'est vrai que c'est trop lent... Peux ton avoir une partie de la config MySQL ? Ce sont des tables InnoDB ?
Le 9 décembre 2013 20:21, DjinnS DjinnS <snnijd@gmail.com> a écrit :
Salut,
Fais un dump par table. Ensuite tu importes en parallèle. Par exemple tu fais 4 threads d'import. L'idée c'est de répartir les tables équitablement.
Dans ton dump mets les options pour le disable keys/ensable keys.
La parallélisation te permettra de tirer parti de ton hard.
Dans l'idéal tu peux aussi passer par un autre disque que le serveur final. Sur un lan privé tu auras tendance à "piper" le dump direct vers l'import. Tu gagnes sur les io.
-- Guillaume Le 9 déc. 2013 19:36, "Joël DEREFINKO" <joel.derefinko@118218.fr> a écrit :
A voir aussi : si tes tables contiennent des index (ce dont je ne doute pas vu la volumétrie), il est préférable supprimer les index avant le restore (donc idéalement avant le dump).
Pourquoi ? à chaque insert, les index sont recalculés. Si au début ca va vite, après quelques millions de lignes, ca devient plus coton.
Une fois la restore faite, remettre les index en place.
Joël.
*From:* frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] *On Behalf Of *Thomas Pedoussaut *Sent:* lundi 9 décembre 2013 16:39 *To:* Axel Vittecoq *Cc:* French SysAdmin Group *Subject:* Re: [FRsAG] import dump MySQL très lent
On 2013-12-09 16:33, Axel Vittecoq wrote:
Bonjour,
Je vous expose mon problème:
Nous avons pris ce serveur http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid hard
pour y migrer notre master MySQL
actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520
Il y a environ 400G à migrer selon:
SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le serveur.
J'importe le dump dans MySQL (mysql < /mon/dump.sql)
Mauvais outils .....
http://dev.mysql.com/doc/refman/5.6/en/load-data.html
Sinon jouer avec alter table ... disable keys / enable keys.
-- Thomas
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir, On Mon, 9 Dec 2013 16:33:48 +0100 Axel Vittecoq <avittecoq@multiposting.fr> wrote:
| Je vous expose mon problème: | | Nous avons pris ce serveur | http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid | hard | pour y migrer notre master MySQL | actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520 | | Il y a environ 400G à migrer selon: | | > SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / | > 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP | > BY table_schema; | | | J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le | serveur. | J'importe le dump dans MySQL (mysql < /mon/dump.sql) | | J'ai lançé ça vendredi aprem, aujourd'hui je ne suis même pas à la moitié. *Je | trouve ça super lent* ! :(
Question bête: l'autocommit est bien désactivé (set autocommit=0) dans ton dump ? Manuel -- ______________________________________________________________________ Manuel Guesdon - OXYMIUM
pour conclure: j'ai rsync le /var/lib/mysql d'un slave stoppé. ça m'a pris 1h ou 2. le serveur a démarré sans problème là dessus. et a rattrapé son retard via la réplication en 1 petite journée très simple et très rapide. c'est parfait :) Le 10 décembre 2013 21:45, Manuel Guesdon <ml+frsag@oxymium.net> a écrit :
Bonsoir,
On Mon, 9 Dec 2013 16:33:48 +0100 Axel Vittecoq <avittecoq@multiposting.fr> wrote:
| Je vous expose mon problème: | | Nous avons pris ce serveur | http://www.ovh.co.uk/dedicated_servers/enterprise/2014-SP-128.xml + Raid | hard | pour y migrer notre master MySQL | actuellement c'est un Raid0 soft de SSD, 24G RAM, Xeon i7 W3520 | | Il y a environ 400G à migrer selon: | | > SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / | > 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP | > BY table_schema; | | | J'ai fait un dump classique (qui pèse 200G). le dump a été transféré sur le | serveur. | J'importe le dump dans MySQL (mysql < /mon/dump.sql) | | J'ai lançé ça vendredi aprem, aujourd'hui je ne suis même pas à la moitié. *Je | trouve ça super lent* ! :(
Question bête: l'autocommit est bien désactivé (set autocommit=0) dans ton dump ?
Manuel
-- ______________________________________________________________________ Manuel Guesdon - OXYMIUM _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (6)
-
Axel Vittecoq -
DjinnS DjinnS -
Greg -
Joël DEREFINKO -
Manuel Guesdon -
Thomas Pedoussaut