Какие параметры mysql наиболее сильно влияют на скорость втягивания дампов?

Суть в том, что на скорость отдачи плевать (условно), важна именно скорость загрузки дампов.

LOAD DATA INFILE нужно юзать. Mysql делает дампы в виде INSERT и быстро загружаться они не будут.

Скажите mysqldump чтобы он выгружал дамп в csv.

LOAD DATA INFILE нужно юзать

Оно, разве совместимо с master-data? Чтобы не городить огороды с переводами сервера в R/O?

Ну вы попробуйте)

Попробую. Как закончит текущий 10Гб дамп втягивать :)

А лучше и совсем, взять да postgresql попробовать. Там pg_basebackup поднимается слейв копированием датафайлов с мастера на скорости сети/дисков притом на ходу. Никаких дампов, загрузок не нужно.

попробуй отключать контроль целостности:

SET unique_checks=0;
SET foreign_key_checks=0;

Ну и autocommit, ессно выключить

А лучше и совсем, взять да postgresql попробовать

Он уже умеет мастер-мастер репликацию в произвольных цепочках?

попробуй отключать контроль целостности

Попробую.

Можно еще попробовать задрать key_buffer_size до гига к примеру

Жирно ему будет :) Хотя, если только для загрузки… Но не думаю, что сильно поможет. Он же больше влияет на скорость чтения. А тут, фактически, тормозит в первую очередь построение индексов, полагаю.

Вот же ж блин. mysql без танцев с бубном не умеет схему «несколько мастеров на один слейв». Придётся, видимо, по LXC-контейнерам раскидывать.

Innodb:

If you have UNIQUE constraints on secondary keys, you can speed up a table import by turning off the uniqueness checks temporarily during the import operation:

SET unique_checks=0;... import operation ...
SET unique_checks=1;
For big tables, this saves a lot of disk I/O because InnoDB can then use its insert buffer to write secondary index records as a batch. Be certain that the data contains no duplicate keys. unique_checks permits but does not require storage engines to ignore duplicate keys.

Ага, я уже по совету выше ( Какие параметры mysql наиболее сильно влияют на скорость втягивания дампов? (комментарий) ) делал. Вроде, чуть шустрее стало, но не сильно.

Он уже умеет мастер-мастер репликацию в произвольных цепочках?

А mysql умеет?

А mysql умеет?

Ну, кроме того, что мастер должен быть один (соответственно, мультимастерные системы только в виде кольца), в остальном — как угодно. Т.е. на любые мастера или слейвы вешается любое число слейвов, которые, в том числе, могут быть мастерами для своих мастеров.

Собственно, это, вообще, скорее просто вопрос с подначкой был. Как в Слонике сейчас с репликацией? Раньше как-то всё плохо было :)

Кольцо из трёх серверов как сложно/просто сделать?

В MySQL в простейшем виде это несколько строк в конфигах, сброс дампа с блокировкой, втягивание дампа на машинах кольца и поочерёдное включение их в цепочку. Всё, кроме прописывания строчек в конфиг не требует рестарта.

Репликация кольцом?.. А вы знаете толк в извращениях...

postgresql, afaik, не умеет репликацию со слейва на другой слейв

Репликация кольцом?.. А вы знаете толк в извращениях...

Вообще-то, очень распространённое решение.

Например, выпадает один сервер, нагрузка (в том числе модификация) спокойно переходит на другие. Сервер возвращается, быстро догоняет отставание от своего мастера и продолжает работать. Соответственно, подразумевается, что падение любого сервера разрывает на время кольцо, но восстановление его приводит к общей синхронизации.

postgresql, afaik, не умеет репликацию со слейва на другой слейв

С 9.2 умеет.

http://www.postgresql.org/docs/9.2/static/warm-standby.html#CASCADING-REPLICA...

С 9.2 умеет.

А мастер может быть слейвом другому мастеру? В кольце?

Нет.