может есть сторонний софт для таких целей

Есть. Сам не пользовался, но в памяти всплывает что-то вроде percona xtra backup. Но кажется оно ускоряет только дамп. Впрочем не знаю.

Ещё есть хардкорный вариант — скопировать файлы баз.

Для ускорения заливки дампа можно временно отключить индексы, что-бы индекс не пересчитывался при каждом инсерте. Впрочем возможно сейчас это уже делается автоматически.

Терпеть незаметно

А сделать нынешний slave мастером и реплицировать (условно) неделю в фоновом режиме нельзя?

Банально: если запись не слишком интенсивна, то делаешь снапшот раздела, копируешь раздел, убираешь снапшот. mysqldump не нужен, даунтайм тоже (хотя если записи много — просядет).

чтобы её залить на новый сервер нужно порядка 2 дней.

Звучит бредово.

Для начала следует выбросить мускуль и поставить марию на принимающей стороне.
Ну и вцелом пора уже переходить на нормальные облачные виртуалки, чтобы можно было на эти полчаса арендовать сколько надо ядер и iops, а не страдать от ограничения ресурсов.

Innobackupex (Xtrabuckup)

http://www.slideshare.net/profyclub_ru/percona-xtra-backup

можно бекапить на лету, но лучше не во время высоких нагрузок.

Сколько ошибок в слове postgresql.

Возможно у него там просто интернет тормозючий или диск убитый.

как вариант, но если большие нагрузки, то лучше бинарно скопировать мускуль Xtrabuckup-ом и потом уже реплицировать.

Сбэкапить базу, залить на мастер, сделать его слейвом, запустить репликацию, как завершится, то поменять мастер и слейв местами. А вообще, при таких условиях, может, надо задуматься о мастер-мастер?

линк между серверам 1гбит
проц
[code]
# cat /proc/cpuinfo |grep name
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
[/code]
оперативы 32.
две такие железки, одна под мастер вторая под слейв.
ssd 300x2 в рейд1 adaptec

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

Быстро развернуть бекап - это слейв, который сейчас на себя нагрузку принял, в ночное время отдайунтаймить и /var/lib/mysql или где там у тебя скинуть в tar файл. Потом запустить мускул, файлы по сети передать на починенный мастер. Мастер потом должен реплицировать то, что на слейв шло, т.е. слейв тоже должен быть настроен как мастер. А мастер как слейв. После того, как затянет всё, что с момента бекапа было изменено, запросы перенаправить на мастер, слейв сделать опять слейвом. Хотя, бинари логи можно и оставить, чтобы в следующий раз телодвижений было меньше. Только так видится.

ssd 300x2 в рейд1 adaptec

Я на linux серверах давно перешёл на софтварный рейд. Не без своих приколов, но не боится умиранция контроллера рейда.

Да у тебя вообще отличные условия. Тот tar файл менее чем за час зальётся на другой сервак.

мастер-мастер - давно уже думаю

Ну, чтобы было быстро, они должны будут быть в одной сети. И также их нужно не менее 3-х, чтобы мозг не раздвоился. :) Есть и и свои ограничения, конечно.

Хотя, ещё говорят про percona Xtrabackup, его можно глянуть, может, и даунтаймить не придётся.

вот я сейчас его и думаю поглядеть и потренироватся на тестовом стенде.

и да, мастер-слейв находятся в одной сети(192.168.х.х), в соседних стояках, пинг меньше 1мс.
вот наверно ночью буду снимать дамп перконой и tar`ом.

Как получилось 2 дня непонятно:

http://www.wolframalpha.com/input/?i=time to transfer 1TB at 1000BASE‐T speed

Для передачи 1 ТБ через гигабитный линк требуется:

time | 8000 seconds
= 133.3 minutes
= 2.222 hours

ты процесс импорта базы mysql -uxxx -pxxx < dump.sql возьми в расчет. перекинуть то не проблема. а вот импортировтаь быстро - это попа.

Так не надо импортировать. Просто файлы положи и всё ок будет. Правда, там будет то же, что и на том, некоторые настройки нужно будет перебить.

Зачем импортировать если

все таблици в innodb

достаточно сделать снапшот и скопировать файлы

Значит хреновый адаптек или хреновые ssd.
По гигабитке за полчаса максимум должен дамп слиться, раздампливаться на такой жэелезке он должен за пару часов максимум.

Значит хреновый адаптек или хреновые ssd.

Написано же, что сгорел контроллер. То есть хреновый адаптек. Но и вообще, аппаратные контроллеры - буэээ... Хотя, иногда, в них есть смысл.

Для статистики. Недавно переносил базу на 110 Гб. Intel Xeon E3-1240v2, Intel SSD 335 240Gb. Разворачивалась 5 часов.

mysql размер базы порядка 150гб

Ни хрена себе. Mysql для таких БД не лучшее решение.

все ответы кроме xtrabackup неверные

Сколько ошибок в слове postgresql.

У него этот процесс быстрее ?

Ну так у тебя и ядер вдвое меньше и эсэсди вдвое меньше.
И база, возможно, не лучшим образом оптимизирована для разворотов.

Тупо скопировать /var/lib/mysql с одного сервера на другой уже предлагали?

то делаешь снапшот раздела, копируешь раздел, убираешь снапшот

Не лучшее решение делать снапшот lvm, если ты о нём (а автор даже не сказал, что у него там LVM есть), на единственном оставшемся в живых сервере, снепшоты lvm умеют очень хорошо ложить I/O на сервере полностью до ребута.
Варианта тут только 2:
1. Копия /var/lib/mysql (предварительно надо не забыть запомнить позицию в бинлоге), как раз за полчаса скопируется, и будет получасовой даунтайм.
2. innobackupex. Даунтайма не будет, одни профиты. Единственное что вроде бы для этого нужен патченный перконой mysql, без него может не взлететь.

Эм... А зачем позицию запоминать?

Мастер останавливается, копия переливается на слэйв, потом - поднимаются оба сервера (если там кластер на pacemaker'е - ресурс запускается, и пофиг кто из них станет мастером а кто слэйвом - копии идентичны).

Давеча пришлось такое делать на 120ГБ БД, на которой произошел сплит брэйн в процессе апдейта (и некорректной остановки) pacemaker'а.

xtrabackup и никаких даунтаймов. тыщу раз так делал.

Эм... А зачем позицию запоминать?

Я рассматриваю такой вариант развития событий (как бы делал я, по крайней мере):
1. Мастер переводится в RO (запоминается позиция в бинлоге), и останавливается.
2. Делается локально копия /var/lib/mysql (чтоб быстрее).
3. Мастер снова запускается.
4. На вторую машину переливается сделанная копия /var/lib/mysql.
5. На второй машине запускается mysql (с параметром read-only) и делается слейвом на основе позиции из п.1.
6. Слейв догоняется, и после этого мастер переключается на этот слейв.
Такой подход минимизирует даунтайм и позволит избежать сплит-брейнов, когда у тебя поднимется сразу 2 мастера и всё сойдет с ума потенциально.

Ни один уважающий себя CRM не поднимет 2 мастера.

что ты имеешь в виду? Вдруг там у ОПа стоит haproxy, с round-robin балансировкой на мастеры, он же этого не уточнял, так что спокойно могут запросы политься в 2 мастера одновременно. В моей схеме сплитбрейна не случится 100% да ещё и даунтайм минимален (для способа без xtrabackup). А у тебя после поднятия второго мастера случится непонятно что, да ещё и часть запросов потеряется, если ты старый мастер предлагаешь просто прибить.

Какой раунд-робин на мастеры, вы о чем? У ТСа стандартный мастер-слэйв. С каким-то CRM или его подобием для переключения мастер-слэйв.

аппаратные контроллеры хорошая вещь, но когда они стоят 600-3000$, а когда покупают контроллер за 100 баксов естественно всё дохнет.

Ты так говоришь, будто контроллеры за 600-3000$ вообще не дохнут.

те что стоят от 2000, тебе о своей смерти скажут заранее,а вот за 100 баксов сначала пару раз убьют рейды, а уже потом здохнут.

Ну тогда ок. Но всё равно, как я и писал, использование аппаратных рейдов не всегда оправдано. И если оправдано их использование, то тогда брать надо тот, который от 2000 для снижения рисков.