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.
Нанимайте. Главное, чтобы эти люди вас сами не кинули или действительно понимали. Если у вас в этом опыта нет, то и проверить толком работу вы никак не сможете. Да и сделать её лучше и качественнее. Или будете им говорить "я нифиге не знаю, но нужно лучше!" или "я нифига не понимаю, но где-то ты меня обманываешь!" ?
Я считаю ужасным руководителем того человека, который в своей сфере не разбирается. От этого и вы пострадаете и люди, которые работают. Будет полное непонимание. Вы будете требовать не реальных вещей, а люди будут делать то, что вам не понятно и доказывать, что так надо.
P.S.: Мне уже жаль ваших сотрудников.
На 100% согласен. Я видел несколько таких руководителей и теперь стараюсь всё делать точно так же.
Himiko добавил 28.07.2010 в 11:17
С таким подходом вряд ли что-то дельное получится.
Деньги тут совершенно не причём. Вы думаете, что заплатили бабла и за вас всё сделали и оно работает?
1. У вас есть саппорт + прямо отличные ребята, а вы спрашиваете по форуму, что купить и как сделать?
2. Вы уже и цены откуда-то взяли, хотя ничего не организовали ещё.
Странный у вас какой-то подход. Обычно сначала всё просчитывают, определяются по оборудованию и стоимости рабочей силы + решают, нужно ли оно. А уже потом приобретают оборудование и нанимают сотрудников. У вас как-то наоборот. Всё есть, вот только не знаю что надо... :)
И снова я по поводу репликации :)
В общем. Как вариант, придумали схему такую:
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 или для данной цели может посоветовать что-то другое?
Какие там были Ip-адреса не важно. А если партнёр вам продавал лицензию помесячно (имеет право) и теперь вы не платите ему? Да много разных вариаций.
Могу сказать сразу - лицензия принадлежит не вам и ваши отношения с мсхост не регулируются ispsystem.
P.S.: Выбрирайте надёжных партнёров.
Вот у нас:
http://passport.webmoney.ru/asp/CertView.asp?wmid=164383883355
Убрали 8 отзывов в архив. И к BL это не имеет отношения)
Не согласен. Никогда не умрёт услуга, которая удобнее для среднестатистического клиента.
Если не нужны специфические настройки и нет желания разбираться в настройках сервера, то совершенно незачем VDS. По поводу "соседей" - они всегда есть на VDS. По поводу проблем на сервере, так же с VDSами могут быть проблемы на ноде.
Да знаю... уроды блин🙅
Там 0 отзывов.
