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

А какие удобные инструменты? Я сходу для mysql только mysqldump вспоминаю.

LVM - гораздо гораздее архивов винды а дампы создавать для 300 гигов - это самоубийство

В руководстве же linux советуют. Причём сравнивают только с солярисом (без офтопа).

Добавлю ещё, что если довольствоваться дефолтным конфигом, а хоть немного его покрутить, то доказывать ничего не придётся.

что если довольствоваться

не, блин

Инструменты одни и те же. Делаете реплику mysql на linux и бекапите там так, как вам нравится - без переездов и рисков

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

Технический вопрос в толксах..

Да что угодно будет лучше базы на NTFS...

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

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

база 300 гиг
MySQL на винде

вместо стоимости винды лучше купить еще планку мозгов, добавить в сервер, увеличить буферы мускулю.

перейти на Linux ввиду его удобного инструмента бэкапирования

это какого?

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

Вынесите из базы картинки, музыку, фильмы и прочие документы.

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

даже если потушить инстанс перед бэкапом?

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

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

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

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

а пояснить?

нужны серьезные обоснования, подскажите куда копать:

Например, что-то я не видел Percona toolkit под венду, может, плохо смотрю.

+ MySQL у нас 32битный

единственный аргумент. Но, есть встречный вопрос - а как вы огребли MySQL в offtopic`е ? Точнее что за коммерчески значимые задачи на нём ?? Точно не бухгалтерия, точно не doc-flow. То есть очевидно что-то своё, полуавтономное..

Ищите корень бед. Неэффективные запросы переездом не исправляются.

А потом проблема странная - ну идет бекап 5 часов..да хоть 25 - если вам не приходится вручную дискетки подставлять с пятницы на понедельник, лишь-бы бекап был корректным

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

Percona toolkit

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

MySQL на винде

база 300 гиг

А месье знает толк в извращениях...

MySQL на винде
база 300 гиг
MySQL у нас 32битный

Что у вас там вообще происходит?

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

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

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

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

так говорите как буд-то это мое решение, а не разработчиков ПО

согласен, сам в шоке как увидел

Точно не бухгалтерия, точно не doc-flow. То есть очевидно что-то своё, полуавтономное..

ПО разработано не нами, и база тоже, требования разработчиков - винда и 32бита мускуля БРЕД!!!! вот потому все и тупит неимоверно, вот почему и хочу перевести на линух

ну идет бекап 5 часов..да хоть 25

нет, база раздает инфу о ценах и товарах, утром база должна быть как штык, и в раздаче инфы кууууче клиентов

Правильно это делать master-slave репликацию

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

это самый лучший вариант.

возникла давече проблема с бэкапами бд MySQL на винде (база 300 гиг и бэкап тянется 5 часов) в связи с чем решили перейти на Linux ввиду его удобного инструмента бэкапирования

бред. СУБД бекапят средствами СУБД.

мега скорость запросов, производительность, надежность, итд

при чём тут Linux?

MySQL у нас 32битный

расслабься. разрабы MySQL решили, что тип INTEGER будет 32х битным. ВСЕГДА. Зачем тебе 64 бита? А вот индекс вдвое распухнет. Вам этого надо? Ты хоть попробуй ради прикола на локалхосте развернуть, потом предлагай.

LVM - гораздо гораздее архивов винды

ты предлагаешь нагруженную СУБД LVMом бекапить??

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

ППКС.

Да что угодно будет лучше базы на NTFS...

на самом деле, ФС тут вообще не главное, и возможно даже не нужное.

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

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

даже если потушить инстанс перед бэкапом?

почему тогда не mysqldump?

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

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

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

так говорите как буд-то это мое решение, а не разработчиков ПО

Этих разработчиков что, из таджиков набирали, а потом ещё мешком с кирпичами пристукнули? Иного объяснения сему мегаизврату я найти не могу.

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

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

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

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

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

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

Как это не главное?

NTFS Ниразу не надежная, Я базу держал бы только на EXT3.

## Админ локалхоста.

NTFS Ниразу не надежная, Я базу держал бы только на EXT3.

если у тебя настроена репликация, или хотя-бы бекап раз в сутки, в чём проблема?

Кстати EXT3 - плохой выбор, там fsck долгая.

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

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

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

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

А зачем?

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

Неужели это приятно в 3 часа ночи поднимать базу из бэкапа?

Не проще просто взять нормальную ФС?

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

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

Неужели это приятно в 3 часа ночи поднимать базу из бэкапа? Не проще просто взять нормальную ФС?

крайности какие - NTFS уж не настолько тупая, что-бы рушиться без видимых причин, причём сильно чаще, чем HDD.