LINUX.ORG.RU
ФорумTalks

Перевод MySQL с Windows на Linux


0

1

Приветствую,

возникла давече проблема с бэкапами бд MySQL на винде (база 300 гиг и бэкап тянется 5 часов) в связи с чем решили перейти на Linux ввиду его удобного инструмента бэкапирования но нужны серьезные обоснования, подскажите куда копать: мега скорость запросов, производительность, надежность, итд чтобы с каменным лицом оперировать фактами (+ MySQL у нас 32битный, тормоза жуткие)

спасибо

Ответ на: комментарий от Reset

Правильно это делать master-slave репликацию. А за использование снапшотов lvm я бы пристреливал.

Сударь поясните столь высокий уровень агрессии по отношению к lvm снапшотам?

MikeDM ★★★★★
()
Ответ на: комментарий от Komintern

бекапить мускуль с InnoDB на уровне ФС невозможно.

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

в итоге есть бекап и простой базы 2 - 5 минут. если это допустимо то и делать бекап с LVM допустим.

MikeDM ★★★★★
()
Ответ на: комментарий от Reset

Создает мнимое ощущение надежности.

а пояснить?

MikeDM ★★★★★
()
Ответ на: комментарий от Komintern

в случае такой огромной базы я чувствую будет гораздо больше чем 2-5 минут.

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

MikeDM ★★★★★
()
Ответ на: комментарий от MikeDM

300 гигов на венде в мускулах расположенных на NTFS это вообще нечто.

А с чего ты взял, что там NTFS? Может он ещё бОльший извращенец и там не NTFS, а UDF, или ext2 с виндовым драйвером.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от Komintern

бекапить мускуль с InnoDB на уровне ФС невозможно.

можно. Я бекапил. Мне стыдно…

drBatty ★★
()
Ответ на: комментарий от drBatty

он же строит файл из insert-or-update'ов, нет? Он вначале 2 суток будет создавать это файл, а потом на другом сервере 4 суток этот файл будет загружаться в базку.

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

он же строит файл из insert-or-update'ов, нет? Он вначале 2 суток будет создавать это файл

ага. А вот копирование LVM у тебя мгновенно пролетит? Да?

drBatty ★★
()
Ответ на: комментарий от drBatty

ничего не знаю про копирование LVM, но скопировать 300-гигабайтный файл по сети явно в тучу раз быстрее, чем сначала превратить его в полуторатерабайтный кусок хлама, скопировать полуторатерабайтный, распарсить полуторатерабайтный кусок хлама, буферизовано склеить из него назад 300-гигабайтный и запустить =)

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

но скопировать 300-гигабайтный файл по сети явно в тучу раз быстрее, чем сначала превратить его в полуторатерабайтный кусок хлама, скопировать полуторатерабайтный, распарсить полуторатерабайтный кусок хлама, буферизовано склеить из него назад 300-гигабайтный и запустить =)

ты так говоришь, что сеть у тебя 100гигабитная, а СУБД лежит на поверхности HDD одним куском в 300Гб.

drBatty ★★
()
Ответ на: комментарий от drBatty

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

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

ага. потому-то я и говорю, что там ФС - не главное.

По-моему, можно партицировать таблицы по датам

можно. А зачем?

drBatty ★★
()
Ответ на: комментарий от stevejobs

чтобы перетаскивать только дельта-обновления.

ну можно наверное. но дамп ИМХО проще и не медленнее. Можно перетаскивать также дифф дампа.

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.