Artom_12 Posted January 5, 2019 Posted January 5, 2019 приветствую всех! может кто подскажет есть windows server 2016 диски в нём SSD оперативки 32Гб нужно добиться максимальной производительности MYSQL версия от 5,1 до 5,5 может кто подскажет есть ли аналог mysql тюнер? или что подкрутить чтобы стало хорошо? (грубо говоря готовый my.ini) в основном INNOBD всё пишется в базу и из неё же и читается Вставить ник Quote
alibek Posted January 5, 2019 Posted January 5, 2019 22 минуты назад, Artom_12 сказал: или что подкрутить чтобы стало хорошо? Такого не бывает. Изучать, мониторить, профилировать, тюнить. Поменять ОС на Linux, версию на 10+, а движок на MyISAM (или Aria с отключенными транзакциями). Вставить ник Quote
Artom_12 Posted January 5, 2019 Author Posted January 5, 2019 есть же "рекомендуемые" настройки? исходя из памяти и процессора минимум? нет? Вставить ник Quote
jffulcrum Posted January 5, 2019 Posted January 5, 2019 Рекомендации по настройке буферов одинаковы для Win и Lin, заимствуйте из туториалов с поправкой на большее потребление памяти на ОС. Более тонкий тюнинг - phpmyadmin дает некоторые советы на вкладках "Состояние" и "Переменные". В осталном - все упирается в то, что высоконагруженный MySQL на Win - терра инкогнита, потому что никому там не требуется, нет таких задач. Будете первопроходцем, огребая что-нибудь вроде http://www.dskims.com/mysql-innodb-insert-performance-windows/ , а лучше сделайте Hyper-V машину, вкатите Линь, Hyper-V integration, и настраивайте дальше как все порядочные красноглазые люди. Вставить ник Quote
NiTr0 Posted January 6, 2019 Posted January 6, 2019 13 часов назад, alibek сказал: а движок на MyISAM (или Aria с отключенными транзакциями). угу, и получить битую базу при первом же отключении питания :) не говоря уже о том, что myisam толком не тюнится, и при сколь-либо большой нагрузке встает раком. Вставить ник Quote
andryas Posted January 6, 2019 Posted January 6, 2019 MyISAM всё-же годится под логи и справочники, на чтение быстр, компактен. Вставить ник Quote
Andrei Posted January 6, 2019 Posted January 6, 2019 6 часов назад, NiTr0 сказал: получить битую базу при первом же отключении питания :) У нас на MyISAM работает один из часто упоминаемых на этом форуме биллингов. Работает с 2010 года. Отключений по питанию за 8 с лишним лет было много, база ни разу не билась. Вставить ник Quote
shafiev Posted January 6, 2019 Posted January 6, 2019 Советую запустить на рабочем компе с субд https://github.com/pmachapman/mysqltuner/ Там будут все подсказки Вставить ник Quote
NiTr0 Posted January 6, 2019 Posted January 6, 2019 46 минут назад, Andrei сказал: Отключений по питанию за 8 с лишним лет было много, база ни разу не билась. а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность. + ко всему - если память без ЕСС, при случайных глюках MyISAM прекрасно портит данные - нет никакой проверки корректности данных в кеше (в InnoDB - есть), так на локальном форуме одному форумчанину насчитало 1 млн постов. Вставить ник Quote
shafiev Posted January 6, 2019 Posted January 6, 2019 4 minutes ago, NiTr0 said: а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность. + ко всему - если память без ЕСС, при случайных глюках MyISAM прекрасно портит данные - нет никакой проверки корректности данных в кеше (в InnoDB - есть), так на локальном форуме одному форумчанину насчитало 1 млн постов. советую смотреть на drop-in-replacement mysql от percona mariadb Вставить ник Quote
Andrei Posted January 6, 2019 Posted January 6, 2019 13 минут назад, NiTr0 сказал: а у нас - практически после каждого отключения питания надо mysqlcheck біло пинать. и да, переход на innodb сильно улучшил производительность. Сорри, некоторое время назад оказывается тоже перешли на innodb :) Вставить ник Quote
alibek Posted January 6, 2019 Posted January 6, 2019 innodb тоже ломается, и починить ее куда сложнее, чем MyISAM. MyISAM обеспечивает большую производительность, а для защиты от потерь данных нужно использовать ИБП, память с ECC и регулярные бэкапы. Вставить ник Quote
Artom_12 Posted January 6, 2019 Author Posted January 6, 2019 всем спасибо за инфу! еще вопрос щас стоит всё на Version: '5.1.40-community' стоит пробовать перенакатить на как минимум 5.5 ? Вставить ник Quote
s.lobanov Posted January 6, 2019 Posted January 6, 2019 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 раз подумайте Вставить ник Quote
NiTr0 Posted January 6, 2019 Posted January 6, 2019 4 часа назад, alibek сказал: innodb тоже ломается, и починить ее куда сложнее, чем MyISAM. ломается крайне редко. в отличие от myisam, которая ломается при любом нештатном ребуте 4 часа назад, alibek сказал: MyISAM обеспечивает большую производительность при сколь-либо сложных вложенных запросах, да на базах хотя бы в несколько гигабайт - нихрена не обеспечивает. Вставить ник Quote
GrandPr1de Posted January 7, 2019 Posted January 7, 2019 22 часа назад, alibek сказал: innodb тоже ломается, и починить ее куда сложнее, чем MyISAM. MyISAM обеспечивает большую производительность, а для защиты от потерь данных нужно использовать ИБП, память с ECC и регулярные бэкапы. Никогда не подходите больше ни к одной БД. Не ваше оно. Вставить ник Quote
s.lobanov Posted January 7, 2019 Posted January 7, 2019 @GrandPr1de мне тоже не нравится совет alibek на тему защиты от потери данных (ибп+ecc+бэкапы как решение) но нужно понимать что всё зависит от требований. допустим, это БД zabbix-а где он хранит свои "конфиги" (настройки что и как нужно мониторить) и данные мониторинга, а мониторит он сеть мухосранск-телекома на 2К абонов. предположим, что ибп+ecc не спасли, тогда разворачиваем из бэкапа - теряем до 1 дня (типичная периодичность бэкапа). ну внесли туда руками пару свитчей за этот день, ну внесут заново. ну не будет мониториться сеть пару часов - и ладно, всё равно реакция одного единственного админа-саппортёра-сварщика-подключальщика когда он в отпуске составляет больше этого времени в данном случае те методы, которые предлагает alibek вполне допустимы в принципе, даже БД радиуса потерять не страшно, если есть резервный план как раздать всем Интернет безусловно (а если ещё и статические ip-адреса сохранятся при этом, то вообще шикарно) а вот например с БД всяких биллингов поинтереснее. к примеру, нужно поднять из бэкапа БД, сделали это за пару часов, начали фигачить новые записи в БД (подключать новых абонентов и т.д.), а через день вспомнили что надо всё-таки восстановить потерянные записи (договора, заключенные между падением БД и восстановлением) и тут началось - номера генерятся подряд, в результате части более новых абонов присвоили потерянные номера и что с этим делать и как дальше жить - хз, особенно если оплату принимаете по номеру договора и 2ух абонентов оказались договора с одним номером... т.е. нужно просто составить требования к надёжности данных (не просто от балды, а исходя из реальных потребностей) и дальше уже решать как её обеспечивать - с помощью ибп, рейда и ecc или с помощью онлайн-реплики, которая в любой момент может стать основной БД (вручную или автоматом - опять же зависит от потребностей и возможностей(наличия людей в смене и т.д.)) Вставить ник Quote
alibek Posted January 7, 2019 Posted January 7, 2019 26 минут назад, s.lobanov сказал: в данном случае те методы, которые предлагает alibek вполне допустимы В тех задачах, где обычно используется MySQL, надежное железо и регулярные бэкапы будут практичнее. Если база небольшая, то развернуть ее из бэкапа будет быстрее, чем восстанавливать поврежденный innodb. А если кто-то держит на MySQL терабайтные базы, то он должен и сам понимать, чем это может кончиться. На более критичных задачах обычно используют другие СУБД. У меня летом умудрилась повредиться биллинговая БД Oracle. Но хоть и не без седых волос и потерь времени, но все получилось восстановить. А будь это MySQL, то скорее всего пришлось бы про базу забыть и восстанавливаться из бэкапа, что для биллинга далеко не лучший выход. Вставить ник Quote
s.lobanov Posted January 7, 2019 Posted January 7, 2019 1 минуту назад, alibek сказал: На более критичных задачах обычно используют другие СУБД. вы это уберу скажите) https://www.mysql.com/customers/view/?id=1269 . ну и вообще https://www.mysql.com/customers/ mysql очень старая (т.е. довольно вылизанная) и далеко не самая худшая БД если вы говорите про oracle, то без опытного dba вы вряд ли обеспечите надёжность данных выше, чем по howto'шкам из инета для mysql Вставить ник Quote
alibek Posted January 7, 2019 Posted January 7, 2019 8 минут назад, s.lobanov сказал: mysql очень старая Мудрость не всегда приходит с возрастом, иногда возраст приходит один. Это как раз про MySQL, по крайней мере классический (5.x). Если уж хочется эту СУБД использовать. то лучше смотреть на MariaDB. Что касается того, где используется MySQL, то это не показатель качества, а наследственность. Фейсбук формально вообще на PHP, но это не значит, что PHP эффективен на высоконагруженных проектах. 14 минут назад, s.lobanov сказал: если вы говорите про oracle, то без опытного dba вы вряд ли обеспечите надёжность данных выше, чем по howto'шкам из инета для mysql Да, но я имел ввиду другое. Я не слишком большой специалист в Oracle, но в этой СУБД огромный практический опыт (практика) и надежность. И с помощью статей и инструментов мне удалось восстановить физически поврежденную БД. Если бы СУБД была MySQL, то скорее всего итогом было «умерла так умерла». Вставить ник Quote
GrandPr1de Posted January 7, 2019 Posted January 7, 2019 3 часа назад, alibek сказал: Если бы СУБД была MySQL, то скорее всего итогом было «умерла так умерла». Ну после совета про MyISAM не удивительно. Вставить ник Quote
alibek Posted January 7, 2019 Posted January 7, 2019 У меня на трех серверах суммарно где-то полтора десятка баз MySQL есть, из них штук 5 MyISAM, остальные InnoDB. Не так давно в серверной была авария по питанию, сервер несколько раз подряд перегружался с небольшими интервалами (в настройках BIOS было включение при появлении напряжения). На этом сервере было несколько баз данных, пара MyISAM, остальные InnoDB. MyISAM восстановить удалось. InnoDB восстановить не удалось, не помогло даже innodb_force_recovery=6. Вставить ник Quote
st_re Posted January 7, 2019 Posted January 7, 2019 А данные то точно не побились ? А то был случай, что "ура, не побилось", а через неделю искали как накатить новонабитое в недельной давности бакап, ибо часть базы, как потом выяснилось, стало мусором.... и хорошо что через неделю, а не через пол года. А еще была класная, небьющаяся "база" акцесс... опс, и все снова работает (ну фигня, от сих до сих контрольная сумма не бьется, значит тихо выкидываем и не раздражаем пользователя сообщениями.. бросок по питанию и вуаля, база на 20% тоньше.) Вставить ник Quote
NiTr0 Posted January 7, 2019 Posted January 7, 2019 26 минут назад, st_re сказал: А данные то точно не побились ? да кого те данные интересуют, сказано же - база заработала, ну и отлично. а то, что какому-то абону пару лямов в биллинге на счет бонусом упало в момент краша - ну подумаешь, мелочь какая :) Вставить ник Quote
alibek Posted January 8, 2019 Posted January 8, 2019 10 часов назад, NiTr0 сказал: ну подумаешь, мелочь какая А ведь и правда, нужно было проверить. Как же это я не подумал. Ладно, значит будет предварительным подарком на новый год. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.