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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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:* [email protected] [mailto:[email protected]] *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/
>
>
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
