mysql

Т.е. для MySQL лучше всё же SSD ?

А разве он не умрет быстро от перезаписи?

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

сравнительно чтения на том же SSD?

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

Да и SSD довольно разные на рынке.

У SSD запись будет быстрее чем на обыкновенный HDD. Но что мы выигрываем используя SSD с плохим временем на запись? Несколько процентов производительности? Затрачивая много денег на покупку памяти.

Смысл брать SSD есть только тогда, когда у них ОЧЕНЬ хорошая скорость на запись (а такие в продаже есть). Тогда можно поставить хороший процессор, всего 1-2 ГБ памяти и SSD.

Мы то хотим не просто потратить деньги а решить поставленную задачу...

И снова я по поводу репликации :)

В общем. Как вариант, придумали схему такую:

2 сервера в режиме "мастер" <-> "мастер". Писать будем одновременно только на один диск, а читать с обоих.

Дополнительно можно будет подключать slave-сервера, если потребуется. (это не суть).

Разделять можно через haproxy. 2 разных порта для чтения и для записи.

1. Запись (к примеру, порт 3301) - указаны 2 mysql-сервера, но один из них "backup", на который запись пойдёт только после падения первого.

2. Чтение (к примеру, порт 3302) - указаны 2 mysql-сервера и балансировка roundrobin.

Теперь есть момент, как собрать чтение/запись на одном порту и распределять в зависимости от запросов.

Нашёл такую штуку, как sqlrelay. Оно умеет раскидывать на разные mysql-сервера, в зависимости от запроса. Т.е. связка sqlrelay + haproxy вполне показалась нормальной. sqlrelay только распределяет, на haproxy уже балансирует и отказоустойчивость обеспечивает.

Т.е. клиент подключается к порту sqlrelay (скажем 3306), а sqlrelay (в зависимости от запроса, на чтение он или на запись) перекидывает к haproxy либо на порт 3301 (для записи), либо на 3302 (для чтения)

Но не совсем понятно, как работает sqlrelay. Там зачем-то указываются свои юзеры для доступа и самое главное (что смутило) - это доступ к mysql-серверам и зачем-то база(!).

Может у кого-то есть опыт работы с sqlrelay или для данной цели может посоветовать что-то другое?

Himiko, почему не mysql-proxy ?

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

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

1. mysql-proxy не умеет разделять чтение/запись. Ей только можно указать несколько серверов только для чтения, но никогда на них она писать не начнёт. И нет понятия "бэкапный сервер", на который пойдёт запись ТОЛЬКО в случае падения основного.

Плюс под mysql-proxy всё на lua-скриптах, которые сами с кучей багов. Не хотелось бы из-за опечатки в программе поймать геморрой. haproxy всё нужное умеет "из коробки".

2. sqlrelay может легко раскидывать запросы по любому признаку. haproxy никогда не будет писать на сервер с пометкой backup, кроме случая падения основного сервера + у haproxy гибкая web-статистика и можно проводить тесты на одном mysql-сервере на разных портах haproxy, чтобы смотреть, куда пошёл запрос.

Ну и haproxy умеет обалденно определять доступность сервисов сама + через мной написанный скрипт.

3. В смысле "отсутствие репликации"? Сервера будут master <-> master и реплицировать друг на друга. Точнее всегда будут работать как master -> slave, но легко меняться ролями, если запросы начнут идти на другой master при проблемах первого.

P.S.: При первом же тесте mysql-proxy завалилась с кучей ошибок и только после обновления с каким-то багфиксом стала работать :)

Сейчас главный вопрос: С помощью какого ПО можно проксировать запросы на разные порты в зависимости от того, на чтение он или на запись. Нужно просто ТУПОЕ проксирование. Остальное будет делать haproxy.

master-master ведет к проблемам, просто поверьте.

mysqlproxy, вроде бы, умеет брать обработчик на lua и в зависимости от него обрабатывать запрос.

1. Не ведёт, если не писать на оба диска одновременно. Он просто будут настроены как master <-> master, но работать всегда будут как master -> slave. Master <-> master нужно, чтобы менять роли без телодвижений

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

Хотя, если просто как-то заставить идти на определённый порт в зависимости от запроса, то может прокатить связка mysql-proxy + haproxy. Хотя не хочется громоздить.