MySQL (MariaDB) & SSD

Имеет ли смысл тащить на SSD базу мускуля?
По скорости работы винта - понятно что будет выигрыш, но где-то на просторах "этих ваших интернетов" читал что если памяти - норм, то и не будет проблем с винтом. Памяти - 128Г, юзается 7-8Г, ЛА до 30 с пиках доходит (обычно 0.5-1) если делать что-то монструозное на базе (и на живом трафе). atop показывает что винт хорошенечко так юзается. пробую SSD сейчас делать, но даже если будет лучше, то есть опасения "а что если SSD - каюк?". база там вроде как не кеш (кеши уже давно на SSD), в базе данные очень полезные и нужные, причем они там "живые", т.е. не статика, а меняются постоянно. база - порядка 50Г, бакап так часто особенно не поделаешь.

 

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

 

hellman, без физического доступа к серверу рейд не сильно имеет смысл. это только позволит в горячем режиме поменять диск если что-то не так с ОДНИМ ИЗ дисков. если проблема будет с сервером или с рейдом (юбывало и такое), то никакой хостер данные на дисках восстанавливать не будет (проверено и не раз на личном опыте). так что закладываться на такой вариант сильно не хочется. ну либо покупать недешевый SLA, когда по твоему звонку половина ДЦ бросает всю работу и бежит по байтикам твой винт восстанавливать. но данные конечно же важны, но не так дорого стоят. это доры, обычные доры. просто они "живые", постоянно генерятся и собираются. т.е. как бы данные важны, важны каждую секунду, но не так уж и много денег то приносят чтобы платить за бешеный SLA.

кстати с SSD стало получше. как минимум те операции что ложили сервак, стали выполняться. но страх все потерять теперь остался.

 

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

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

--- Добавлено 20.2.2021---

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

 

вот прямо сейчас у меня ситуация. сервер лежит, винт не работает. КУДА я софтверно выдам команды?
саппорт готов поменять винт. данные он восстанавливать не будет (не входит в SLA).

именно об этом я и говорю. т.е. мне об этом надо обеспокоиться заранее.

кинь ссыль, только чтобы попроще.

вот об этом и речь. случаи то разные бывают. у меня за всю жизнь так чтобы один из дисков в рейде полетел, а сервер продолжал работать было наверное 1 случай из тысячи. все остальные - это полный факап. с потерей ВСЕХ данных.

--- Добавлено 20.2.2021---

P.S. SSD не помог кстати. не долго промучалась старушка, к сожаленю

ситуация такая. был сервак, 4 коры, 64Гб мозгу, винт САТА + ССД. все работало лет 5, но морально устарел, а стоит столько же. я купил в +- такую цену тачку МОЩНЕЕ (там и корей больше и проц новее и прочее) и все туда перенес. "и началось"
видимо новый хостер - оказался с душком и железки у них херовые.

 

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

 

hellman,

--- Добавлено 20.2.2021---

к чему слова, если ЭТО ЕСТЬ

--- Добавлено 20.2.2021---

хорошо что это еще пока не продакшн-сервер и данные на нем не важны. но а если бы это был продакшн?

 

ну статей немерянно, все они примерно одинаковые
Настройка репликации master-slave в MySQL
гугли просто master-slave репликация.

--- Добавлено 20.2.2021---

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

--- Добавлено 20.2.2021---

Я просто это говорю как человек у которого работает



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

 

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

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

 

а че за хостер то?
ну если бы у меня так железо вылетало я б повесился =)
мы в саппорт пишем хостеру ну ОЧЕНЬ редко, только по критичным случаям каким то или за допами.

 

до этого был ovh, сейчас вот решил попробовать servdiscount (порекомендовали). сла естественно нулевое. так что переписываюсь щас с сапортом в режиме "пару писем в день".

 

SSD диск - это всегда неплохо, но раз возникло желание поговорить, тогда вопрос не содержит описания главных компонент:
1) какой табличный движок, его режимы/настройки и даже версии
2) какой характер/типы запросов

В идеале для анализа нужен дамп /etc/my.cnf , дамп БД и логи SQL-запросов...ну то есть тут решать должен инженер, непосредственно работающий с БД.

Если данные полезные и ценные, тогда у тебя БД должна каждый чих писать на диск (чтобы максимально обеспечить ACID) -> это самый медленный режим (это что-то вроде innodb в режим trx_commit = 1 и включенный binlog и его sync) , а значит нам хочется иметь диск побыстрее и тогда рейд SSD твой выбор.

Но можно выдумать задачи, где можно полностью отказаться от физического диска и работать с только памятью, периодически делая дампы на диск на случай сбоя. Так скорость работы будет выше примерно на 1-2 порядка и при этом SSD не особо нужен.

Далее, внутри решения задачи разные запросы могут работать с диском по разному, и даже один и тот же запрос может использовать или не использовать диск. И часто так бывает, что один тип запросов портит всю картину, утилизируя дисквый IO на 100%. Тогда его фикс или изменение алгоритма/подхода даст ускорение системы (отказ от апгрейда). Кроме алгоритмов/запросов, у табличных дижков есть куча настроек про то, как они работают с дисками (типа такого: Group Commit for the Binary Log )

PS: я на сайтиках использую innodb в режиме trx_commit = 0 и софтварные бекапы, получая неплохую производительность и имею промежуточные бекапы, но потерять чуток данных теоретически возможно. А SSD по мере возможности.

 

сейчас это mariadb, если конкретно, то сейчас это 10.5.3, но нет желания привязываться к конкретным версиям или даже вообще движкам (несколько лет назад это был мускуль, но все перелезло автоматически на "марию" просто в результате плавных апгрейдов ОС". я вообще сторонник мейнстрима, где это только возможно (!!! в разумных пределах конечно же).

абсолютно разнообразный. и мало того, меняющийся от задачи, которые приходят и уходят. база - не константа. да, большинство баз по структуре не менялись несколько лет, но мир не стоит на месте, происходят изменения(зачастую не сильно значительные) строятся дополнительные индексы по мере надобности, запросы меняются/добавляются. отличительной особенностью баз являются большие (ну в рамках моих проектов) объемы записей. миллионы и десятки миллионов записей. в основном - селекты, но делаются и апдейты (с целью оптимизации, апдейты - не онлайн, а по расписанию и масс-апдейты).

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

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


P.S. к слову сказать, все ради чего я этот пост завел, решилось совершенно иначе и прозаичнее.
попытка переноса на SSD привела к положительным результатам, но, как потом выяснилось, не в ней было дело. а дело было в НЕ-SSD, диске, который был просто неисправен железно. хостер что-то там мямлил на на тему "это очень странное стечение обстоятельств и в ТВОЕМ СЛУЧАЕ странная комбинация контролера и винтов (WD Blue, я так понял) вывела из строя винт". перенеся базу на SSD я просто перестал "дрючить" неисправный винт и временно (!) это дало решение проблемы. но на битом железе далеко не уедешь. и через день-два все повторилось, причем до уровня "оно вааще не грузится, давайте делать реплейс железа". железо поменяли, в силу нулевого сла естественно никто мне данные не восстанавливал. предлагалось мне через resque mode там ковыряться, но слава богу это еще не был продакшн и потерь сильных не было, взял бакап с продакшна и забил ковыряться. тупо сделал реинстал.

 

mariadb не является табличным движком (storage engine), но именно с этого нужно начинаться разговор, а потом уже про версии субд и алгоритмы

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

это мало, скучно, бытовуха ))

если это не рандомные выборки и если данные, непосредственно попадающие в столбцы селекта имеют небольшой объем, то от нагрузки на диск нужно/можно избавляться

тем более

пффф, тогда весь разговор о "в базе данные очень полезные и нужные" теряет смысл

посмотри сравнение режимов trx_commit
при значении "0" innodb превращается в myisam...ну почти

а так в общем и целом в myisam особого смысла нет, он устаревший и не развивается.

Если хочешь скорости, то используй Memory engine - я его разгонял почти до 200к атомарных операций select-update в секунду.
Если нужна надежность и прочий ACID, тогда innodb в trx_commit=1 и бинлоги.
Если хочешь компромисс, которым в древние времена был myisam, то теперь это innodb в режиме trx_commit=2