[Artom_12]

приветствую всех!

 

может кто подскажет есть windows server 2016

диски в нём SSD

оперативки 32Гб

 

нужно добиться максимальной производительности MYSQL

версия от 5,1 до 5,5

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

в основном INNOBD всё пишется в базу и из неё же и читается

[alibek]

22 минуты назад, Artom_12 сказал:

или что подкрутить чтобы стало хорошо?

Такого не бывает.

Изучать, мониторить, профилировать, тюнить.

Поменять ОС на Linux, версию на 10+, а движок на MyISAM (или Aria с отключенными транзакциями).

 

[Artom_12]

есть же "рекомендуемые" настройки? исходя из памяти и процессора минимум? нет?

[jffulcrum]

Рекомендации по настройке буферов одинаковы для Win и Lin, заимствуйте из туториалов с поправкой на большее потребление памяти на ОС. Более тонкий тюнинг - phpmyadmin дает некоторые советы на вкладках "Состояние" и "Переменные". В осталном - все упирается в то, что высоконагруженный MySQL на Win - терра инкогнита, потому что никому там не требуется, нет таких задач. Будете первопроходцем, огребая что-нибудь вроде http://www.dskims.com/mysql-innodb-insert-performance-windows/ , а лучше сделайте Hyper-V машину, вкатите Линь, Hyper-V integration, и настраивайте дальше как все порядочные красноглазые люди.

[NiTr0]

13 часов назад, alibek сказал:

а движок на MyISAM (или Aria с отключенными транзакциями).

угу, и получить битую базу при первом же отключении питания :) не говоря уже о том, что myisam толком не тюнится, и при сколь-либо большой нагрузке встает раком.

[andryas]

MyISAM всё-же годится под логи и справочники, на чтение быстр, компактен.

[Andrei]

6 часов назад, NiTr0 сказал:

получить битую базу при первом же отключении питания :)

У нас на MyISAM работает один из часто упоминаемых на этом форуме биллингов. Работает с 2010 года. Отключений по питанию за 8 с лишним лет было много, база ни разу не билась.

[shafiev]

Советую запустить на рабочем компе с субд  https://github.com/pmachapman/mysqltuner/

 

Там будут все подсказки

[NiTr0]

46 минут назад, Andrei сказал:

Отключений по питанию за 8 с лишним лет было много, база ни разу не билась.

а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность.

 

+ ко всему - если память без ЕСС, при случайных глюках MyISAM прекрасно портит данные - нет никакой проверки корректности данных в кеше (в InnoDB - есть), так на локальном форуме одному форумчанину насчитало 1 млн постов.

[shafiev]

4 minutes ago, NiTr0 said:

а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность.

 

+ ко всему - если память без ЕСС, при случайных глюках MyISAM прекрасно портит данные - нет никакой проверки корректности данных в кеше (в InnoDB - есть), так на локальном форуме одному форумчанину насчитало 1 млн постов.

советую смотреть на drop-in-replacement mysql от percona mariadb

[Andrei]

13 минут назад, NiTr0 сказал:

а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность.

Сорри, некоторое время назад оказывается тоже перешли на innodb :)

[alibek]

innodb тоже ломается, и починить ее куда сложнее, чем MyISAM.

MyISAM обеспечивает большую производительность, а для защиты от потерь данных нужно использовать ИБП, память с ECC и регулярные бэкапы.

[Artom_12]

всем спасибо за инфу!

еще вопрос щас стоит всё на Version: '5.1.40-community' стоит пробовать перенакатить на как минимум 5.5 ?

[s.lobanov]

8 минут назад, Artom_12 сказал:

всем спасибо за инфу!

еще вопрос щас стоит всё на Version: '5.1.40-community' стоит пробовать перенакатить на как минимум 5.5 ?

на 5.5 точно не стоит ибо она eos. если уж перекатываться, то хотя бы на 5.6 

 

https://en.wikipedia.org/wiki/MySQL#Release_history

 

А вообще, зависит от задач. Если у вас не шаредная база для шаред-хостера, где каждый может дрючить вашу базу эксплойтами, то перекатываться смысла мало. И вообще, тут больше зависит от потребителей вашей БД. Если потребитель БД это какой-нибудь биллинг и он официально умеет работать с mysql 5.6, то перекатывайтесь, а иначе 5 раз подумайте

[NiTr0]

4 часа назад, alibek сказал:

innodb тоже ломается, и починить ее куда сложнее, чем MyISAM.

ломается крайне редко. в отличие от myisam, которая ломается при любом нештатном ребуте

 

4 часа назад, alibek сказал:

MyISAM обеспечивает большую производительность

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

[GrandPr1de]

22 часа назад, alibek сказал:

innodb тоже ломается, и починить ее куда сложнее, чем MyISAM.

MyISAM обеспечивает большую производительность, а для защиты от потерь данных нужно использовать ИБП, память с ECC и регулярные бэкапы.

Никогда не подходите больше ни к одной БД.

Не ваше оно.

[s.lobanov]

@GrandPr1de 

мне тоже не нравится совет alibek на тему защиты от потери данных (ибп+ecc+бэкапы как решение)

но нужно понимать что всё зависит от требований. допустим, это БД zabbix-а где он хранит свои "конфиги" (настройки что и как нужно мониторить) и данные мониторинга, а мониторит он сеть мухосранск-телекома на 2К абонов. предположим, что ибп+ecc не спасли, тогда разворачиваем из бэкапа - теряем до 1 дня (типичная периодичность бэкапа). ну внесли туда руками пару свитчей за этот день, ну внесут заново. ну не будет мониториться сеть пару часов - и ладно, всё равно реакция одного единственного админа-саппортёра-сварщика-подключальщика когда он в отпуске составляет больше этого времени

в данном случае те методы, которые предлагает alibek вполне допустимы

в принципе, даже БД радиуса потерять не страшно, если есть резервный план как раздать всем Интернет безусловно (а если ещё и статические ip-адреса сохранятся при этом, то вообще шикарно)

а вот например с БД всяких биллингов поинтереснее. к примеру, нужно поднять из бэкапа БД, сделали это за пару часов, начали фигачить новые записи в БД (подключать новых абонентов и т.д.), а через день вспомнили что надо всё-таки восстановить потерянные записи (договора, заключенные между падением БД и восстановлением) и тут началось - номера генерятся подряд, в результате части более новых абонов присвоили потерянные номера и что с этим делать и как дальше жить - хз, особенно если оплату принимаете по номеру договора и 2ух абонентов оказались договора с одним номером... 

т.е. нужно просто составить требования к надёжности данных (не просто от балды, а исходя из реальных потребностей) и дальше уже решать как её обеспечивать - с помощью ибп, рейда и ecc или с помощью онлайн-реплики, которая в любой момент может стать основной БД (вручную или автоматом - опять же зависит от потребностей и возможностей(наличия людей в смене и т.д.))

[alibek]

26 минут назад, s.lobanov сказал:

в данном случае те методы, которые предлагает alibek вполне допустимы

В тех задачах, где обычно используется MySQL, надежное железо и регулярные бэкапы будут практичнее.

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

А если кто-то держит на MySQL терабайтные базы, то он должен и сам понимать, чем это может кончиться.

На более критичных задачах обычно используют другие СУБД.

 

У меня летом умудрилась повредиться биллинговая БД Oracle.

Но хоть и не без седых волос и потерь времени, но все получилось восстановить.

А будь это MySQL, то скорее всего пришлось бы про базу забыть и восстанавливаться из бэкапа, что для биллинга далеко не лучший выход.

[s.lobanov]

1 минуту назад, alibek сказал:

На более критичных задачах обычно используют другие СУБД.

вы это уберу скажите) https://www.mysql.com/customers/view/?id=1269 . ну и вообще https://www.mysql.com/customers/

 

mysql очень старая (т.е. довольно вылизанная) и далеко не самая худшая БД

 

если вы говорите про oracle, то без опытного dba вы вряд ли обеспечите надёжность данных выше, чем по howto'шкам из инета для mysql

[alibek]

8 минут назад, s.lobanov сказал:

mysql очень старая

Мудрость не всегда приходит с возрастом, иногда возраст приходит один.

Это как раз про MySQL, по крайней мере классический (5.x).

Если уж хочется эту СУБД использовать. то лучше смотреть на MariaDB.

Что касается того, где используется MySQL, то это не показатель качества, а наследственность.

Фейсбук формально вообще на PHP, но это не значит, что PHP эффективен на высоконагруженных проектах.

 

14 минут назад, s.lobanov сказал:

если вы говорите про oracle, то без опытного dba вы вряд ли обеспечите надёжность данных выше, чем по howto'шкам из инета для mysql

Да, но я имел ввиду другое.

Я не слишком большой специалист в Oracle, но в этой СУБД огромный практический опыт (практика) и надежность.

И с помощью статей и инструментов мне удалось восстановить физически поврежденную БД.

Если бы СУБД была MySQL, то скорее всего итогом было «умерла так умерла».

[GrandPr1de]

3 часа назад, alibek сказал:

Если бы СУБД была MySQL, то скорее всего итогом было «умерла так умерла».

Ну после совета про MyISAM не удивительно. 

[alibek]

У меня на трех серверах суммарно где-то полтора десятка баз MySQL есть, из них штук 5 MyISAM, остальные InnoDB.

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

На этом сервере было несколько баз данных, пара MyISAM, остальные InnoDB.

MyISAM восстановить удалось. InnoDB восстановить не удалось, не помогло даже  innodb_force_recovery=6.

[st_re]

А данные то точно не побились ? А то был случай, что "ура, не побилось", а через неделю искали как накатить новонабитое в недельной давности бакап, ибо часть базы, как потом выяснилось, стало мусором.... и хорошо что через неделю, а не через пол года.

 

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

[NiTr0]

26 минут назад, st_re сказал:

А данные то точно не побились ?

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

[alibek]

10 часов назад, NiTr0 сказал:

ну подумаешь, мелочь какая

А ведь и правда, нужно было проверить.

Как же это я не подумал.

Ладно, значит будет предварительным подарком на новый год.