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/
