оптимальный перенос базы большого размера

[toshnota]

оптимальный перенос базы большого размера

база MySql
размер ~ 2.5 Gb
задача перенести с локального сервера, на сервер хостера
Возможен так же вариант личного приезда к хостеру

Вопрос: Какими средствами оптимально выполнить задачу?

 

[Romantik]

dump еще никто не отменял

 

[vovanium]

Можешь попробовать дампер, если нет жёстких ограничений на время работы скриптов. 600 метров он обрабатывал без проблем, так что можешь попробовать, к тому же он умеет со сжатыми дампами работать, так что придется переносить в 4-5 раз меньший файл.

 

[toshnota]

Спасибо!

 

[Klaus]

дабы не создавать новую тему...

база 15Gb на первом винте.
поставил на сервер еще один винт,
хочу его заюзать чисто под мускуль.
хостер говорит, что на время переноса с одного винта на другой надо стопорить мускуль, а это 20 мин дауна.
что можно предпринять, чтобы мускуль бесперебойно воркал?

RedHat 7.2
MySQL 3.23.58

 

[Yurik]

поставить ещё один MySQL на машину, настроить его как слейв к основному, а когда он трансфер завершит - остановить главный и когда тот остановится - перевести Слейв в Мастер.

-~{}~ 13.02.05 03:12:

но это только если оно изначально работало с журналом log-bin

 

[rozhik]

Автор оригинала: Klaus
хостер говорит, что на время переноса с одного винта на другой надо стопорить мускуль, а это 20 мин дауна.
что можно предпринять, чтобы мускуль бесперебойно воркал?

Совсем безперебойно не получится, но если создать симлинки на базы с нового винта на старый, затем поочередно заблокировать каждую таблицу для записи, затем скопировать три файлика с табличкой затем разблокировать и удалить оригинал - то даунтайма будет возможно меньше. Для таблиц в которые не идёт запись - даунтайм = 0.
В качестве рекомендации - старайтесь держать таблици и индексы на разных винтах. mysminks rulezz

 

[Klaus]

вобщем за неимением бесперебойного решения базу тупо остановили и слили, заняло все 12 мин почему-то. Собсно беспокоился из-за бота гугля, который в послед время не уходит с сервера.

Автор оригинала: rozhik
В качестве рекомендации - старайтесь держать таблици и индексы на разных винтах. mysminks rulezz

Скажи, пожалуйста, почему так лучше?

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

 

[Yurik]

Скажи, пожалуйста, почему так лучше?

потому что шина памяти и процесор значительно быстрее шины и скорости чтения/записи одного винта

 

[ONK]

потому что шина памяти и процесор значительно быстрее шины и скорости чтения/записи одного винта

И поэтому мы будем юзать сразу два винта...

 

[rozhik]

Автор оригинала: Klaus
...

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

Это из области операционной системы а не базы данных (читать тут http://unix.ginras.ru/apps/sh006.html).

Скажи, пожалуйста, почему так лучше?

Я не хочу вести экскурс в табличные пространства и другие вещи, скажу просто.
При использовании больших баз данных таблички не влазят полностью в кэш память. На сколько я понял RAID массивы не используются, а в одиночных винчестерах существует проблемка: скорость чтения гига последовательных данных в разы быстрее чем разбросанных по диску (вспомните defrag, speeddisk....) . Это происходит изза того, что операция позиционирования головок более медленная чем операция чтения кластера. Разнесение файлов на разные винты значительно сокращает кол-во операций позиционирования, повышает эффективность внутреннего кэша винта итп.
===
случай из жизни: MySQL база с двумя огромными табличками и кучей мелких. С помощью рассовывания индексов и файлов таблиц по разным винтам удалось получить почти 70% повышения производительности.